Saturday Jul 19, 2008

Running Trusted Extensions with opensolaris.2008.05

When the LiveCD for opensolaris was released last May there was no support for Trusted Extensions. We've made some progress, and I'm happy to report that I am posting this blog in a labeled zone running opensolaris. There are workarounds for the zone installation, X11 remote connections, and desktop login, which are all temporary until the underlying bugs are fixed.

This week the repository at http://pkg.opensolaris.org  was updated to contain packages based on Nevada build 93. This is being referred to as opensolaris.2008.11 since we are targeting the next release in November. There are posted directions for upgrading the pkg software for this build, and then doing a complete pkg image-update. I tried this, but I was not able to install any zones with the new pkg software. So I came up with my own procedure. Instead of doing a complete pkg image-update, start by installing the 2008.05 LiveCD.

Make sure that the entry for root in /etc/user_attr does NOT specify type=role.

Then do the following:

# pkg refresh --full
# pkg install SUNWts@0.5.11,5.11-0.93
# pkg install SUNWtsg SUNWxorg-tsol-module

# pkg install SUNWtgnome–tstripe SUNWtgnome–tsoljdsselmgr SUNWtgnome–tsoljdslabel SUNWtgnome–tsoljdsdevmgr SUNWtgnome–xagent
# pkg install SUNWgnome-file-mgr@0.5.11-0.93
# pkg install SUNWgnome-wm@0.5.11-0.93

This will get you the subset of updated and new packages required to run Trusted Extensions. Next you should download and install a set of files which specify a new labeled zone brand. Extract the tar file into /usr/lib/brand. The labeled brand needs to be specified in the default template, so edit the file /etc/zones/SUNWtsoldef.xml to specify that brand:

 <zone name="tsoldef" zonepath="" autoboot="true" brand="labeled" >

It is necessary to enable TCP connections to the X11 server. This must be specified for gdm and well as Xorg. To configure the gdm property, run the gdmsetup GUI. Select the Security tab, and uncheck the setting for Deny TCP connection to Xserver. Then run the following command:

# svccfg -s x11-server setprop options/tcp_listen=true 

There is another problem with argument passing between gdm and tsoljdslabel, which requires some fiddling. First do the following:

# cd /usr/bin

# mv tsoljdslabel tsoljdslabel.orig

Next create an executable shell script named tsoljdslabel with the following contents:

#!/bin/sh
/usr/bin/tsoljdslabel.orig /etc/dt/config/Xinitrc.tjds

Now do the following:

# mkdir -p /etc/dt/config

# cp /usr/dt/config/Xinitrc.tjds /etc/dt/config

There is another problem where  Xlib misinterprets DISPLAY variables of the form hostname:0. Also, the path for users and roles is too restrictive. The workaround is to edit the file /etc/dt/config/Xinitrc.tjds as follows:

export DISPLAY=127.0.0.1:0
export PATH=/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/X11/bin:/usr/dt/bin:/usr/sfw/bin
echo 'Starting gnome-session'
exec $command

The last workaround is to move the top panel to the bottom to prevent it from being obscured by the screenstripe. To do this, mouse over an empty area in the top panel, and use the right mouse button to bring up the Properties dialog. Change the orientation from Top to Bottom.

To enable Trusted Extensions, do the following:

# svccfg import /var/svc/manifest/system/labeld.xml

# svcadm enable -s labeld

# reboot

If you were very careful, you should be able to login as root. Do not specify a session type since you can only run a Trusted JDS session. Now create your zones using the txzonemgr. Since all filesystems are using zfs, you should not create a zpool for zones. A dataset for each zone will be created automatically.

Currently the Solaris Management Console is not included in the repository, so you will need to create users and roles with other commands. Once you get this working, you may want to install the NWAM configuration files I discussed in the previous posting, Updated Laptop Configuration Instructions.

Monday Jul 07, 2008

Updated Laptop Configuration Instructions

The Laptop Instructions for Trusted Extensions have been revised to focus on the latest updates of Solaris 10 and Nevada. In Solaris 10 update 5 and Nevada, there is no longer a separate installation step, since Trusted Extensions is enabled as an SMF service. However, there are still some significant differences with respect to configuring a laptop using DHCP. The new instructions take advantage of the Network Auto-Magic project (NWAM). Included in the instructions is a tarball of shell scripts for specifying label-related behavior of the dynamically assigned address. These scripts conditionally assign the appropriate default network template, public or internal, based on the domain name returned by the DHCP server. For example, in my case, if the domain is sun.com, then the default template is internal. You can edit the INTERNAL_DOMAIN variable in the check-configuration file to specify your own internal domain.

These NWAM scripts also manage an additional logical interface using the physical interface that is currently in use. It is only visible in the global zone to support NFS file sharing, and is therefore called mynfs. To avoid conflicts with network assigned addressses, I used a private network address of 127.0.0.2 for mynfs, and use the all-zones DHCP assigned address to route NFS requests from labeled zones into the global zone. 

I prefer using an NFS server on my laptop, instead of relying on the cross-zone LOFS mounts of /export/home that are automatically created when zones are booted. The LOFS mechanism occasionally get out of sync with the automount daemon depending on the order in which the zones are booted. Furthermore, the NFS mechanism is more configurable and demonstrates some commonly misunderstood features of Trusted Extensions.

Instead of separate instances of /etc/dfs/dfstab for each zone, I am using the sharemgr tool. I created a sharemgr group for each zone, e.g.

# sharemgr create public

# sharemgr add /zone/public/root/export/home public

The actual sharing occurs when the zone is booted. There are two shell scripts in /usr/lib/zones that are called when zones are either booted or halted. I modified zoneshare to call

sharemgr enable $zonename

and similarly, I modified zoneunshare to call

sharemgr disable $zonename

Then I modified the file /etc/auto_home_public in each of the higher-level zones, as follows:

*       mynfs:/zone/public/root/export/home/&

This works well for me unless my network connection changes while the NFS mount is active. That's because the underlying logical interface for mynfs is unplumbed and moved to a new logical interface when I switch between wired to wireless.



Monday Jun 23, 2008

Common Criteria Certification

The Solaris 10 11/06 release of Trusted Extensions has finally received its Common Criteria certification. Like it's predecessor, Trusted Solaris 8, the assurance rating is EAL4+ in conformance with the Controlled Access, Role-Based Access, and Label Security Protection Profiles. The evaluation was performed by CGI Information Systems & Management Consultants Inc, and is listed on the Canadian Common Criteria list of certified products. You can also view the certificate and the Security Target on this page. The evaluated configuration, described in Section 2.3, page 8,  is the most comprehensive for any product at this level. Among the Solaris features included are both the JDS (GNOME) and CDE desktops, the Solaris Management Console, both SPARC, x64 and x86 hardware, UFS, ZFS and NFS, and a distributed configurations administered using LDAP.

The currently shipping release, Solaris 10 5/08, will go through the rating maintenance process so that the certification can be applied to the latest software and hardware.

Friday Apr 18, 2008

Fully Open-Sourced Multilevel Desktop

It's taken a while to get all the legalities worked out, but I'm pleased to announce that all of the source code that you need to build the Trusted Java Desktop System (aka TJDS), is now fully open and browsable in the OpenSolaris source browser. Most of the code has been open for for two years, and was written before marketing picked the name Trusted Extensions. So all of these component have names containing the abbreviation tsol, which originally stood for Trusted Solaris. The newly available source includes:

libgnometsol - functions for label selection and role assumption

tsoljds-tstripe - trusted stripe and trusted path menus

tsoljdsdevmgr - device allocation GUI

tosljdslabel - GUIs for initiating multilevel and single level sessions

tsoljdsselmgr - trusted selection manager

These components  depend on two Trusted Extensions libraries:

libtsol - functions for label translation and comparison

libXtsol - functions for managing labels in the X11 server

While all of these components are open, they are covered by different license agreements, depending on their consolidation. The GNOME-related components are covered by GNU General Public License version 2. The library libtsol is covered by the Common Development and Distribution License , and libXtsol is covered by the X.Org license.

Monday Apr 07, 2008

Virtualized Instances of Vista in Labeled Zones

You may have read Sun's announcement about acquiring innotek, and the VirtualBox software. VirtualBox runs on a variety of operating systems including OpenSolaris, and supports a variety of guest operating systems, such as Microsoft Vista. Since VirtualBox is a user application, it can also be run in Solaris zones. Getting Vista to run in labeled zone requires a few extra configuration steps, which are described below.

VirtualBox can be downloaded from the Sun Download Center and installed in the global zone. When VirtualBox is started in the global zone a device driver is loaded which is accessed through the pathname /dev/vboxdrv. To access this device from a zone, modify the zone's configuration using the following zonecfg commands:

add device

set match="/dev/vboxdrv"

end

Since zones cannot load kernel modules directly, you must have an instance of VirtualBox running in the global zone to load the driver. I suppose you could alternatively load the driver via modload, but I haven't tried that yet.

In addition, the zone needs to be running the OpenGL service. To enable this service, run the following command in the zone:

 svcadm enable ogl-select

VirtualBox acts as a network proxy between the host and guest operating systems. This works fine in the global zone, but presents a few issues when running in a labeled zone. The DNS service that VirtualBox provides to the guest OS does not go through the name service switch. Therefore each zone must have its own DNS configuration, and a remote DNS server whose label matches that of the zone. To set this up you should halt your zones and select Configure per-zone name services from the top level menu of txzonemgr. Since your labeled zones will no longer be able to access any of your global zone databases, you should copy the /etc/hosts, /etc/passwd, /etc/shadow and /etc/user_attr files from the global zone into the corresponding /etc directory for each of your zones. You will also need a customized /etc/resolv.conf file for each zone to specify the appropriate DNS server for each label.

If you are using DHCP, you will be limited to name resolution in a single zone. You can rely on the nwam service (which is enabled by default) to set up your networking in the global zone. To make the network available to a labeled zone, you should share the configured network with all-zones (via txzonemgr or ifconfig) and assign the approriate single-level remote host template to the DNS server specified in /etc/resolv.conf. Then copy the resolv.conf file into the appropriate zone.

Once you have set up your zones and networking, you can install Vista, or your another OS as the guest OS. After the guest OS is installed, you should verify that the guest OS can access the Internet. If so, you should download and install the guest additions ISO image. This will allow you to cut and paste between Vista and Solaris applications in the same zone. It also provides dynamic resizing of the guest OS window, and smooth mouse transitions between the host and guest windows.

Saturday Mar 15, 2008

Flexible Mandatory Access Control

A new project, FMAC,  has been initiated to add a security server based on the Flux Advanced Security Kernel (Flask) architecture to OpenSolaris. A press release has been issued announcing the joint effort between Sun and the National Security Agency. Several bloggers ( bvassjimlaurentbarton808 ) have already posted comments and there seems to be significant interest in the community.

However, I think that it's prudent to look closely at these announcements rather that making assumptions about what is being proposed. Flask provides significant opportunities to customize the policies enforced in the kernel and in user space, but it's flexibility also poses configuration challenges. One of the things that makes Solaris popular is that it provides stable, backward-compatible binary and procedural interfaces. This constraint applies to all new projects including FMAC. Core Solaris features like Role-Based Access Control, Process Rights Management, and Multilevel Security must co-exist with new polices based on Flask. For this reason, the initial emphasis of the FMAC project should be to supplement these existing access control policies where they are deficient.

For example, it is difficult to restrict untrusted applications which run in a user context from modifying the files owned by that user. The related Fine-Grained Access Policy project addresses this issue by handling exceptions to access control denials that occur due to lack of privilege. In contrast, FMAC plans to pass all access control decisions through an extensible policy server which will make access decisions based on the policy defined for the security contexts of the subjects and objects.

Flask has been implemented in SELinux, SEBSD, and SEDarwin, but the level of complexity has caused many end-users to disable it. We don't want this to happen in OpenSolaris, so we will need to balance improvements in the safety of running untrusted applications while making it transparent to normal users.

Type Enforcement will be the key technology upon which such flexible policies will be based. Unlike MLS sensitivity labels, there is no inherent hierarchy associated with Types, and it is common for the Type to change when a parent executes a new application. MLS labels are static, and are associated with labeled zones in OpenSolaris. Types are also quite different from the authorizations and process rights (privileges) upon which Solaris RBAC is based. Type Enforcement rules can be used to define more flexible policies than these existing mechanisms.

The challenge facing this project will be to add value to Solaris without compromising its existing strengths. For example, the MLS policy in use today is completely invisible to applications because all conflicting resources are polyinstantiated using zones. My preference is that the FMAC project should focus on defining new policies based on Type Enforcement, while preserving the existing policies for Discretionary Access, Multilevel Security, user authorizations, and process privileges that we have today.



 

Sunday Jan 06, 2008

Using Xvnc for Remote MLS Sessions

This is an update to my posting Remote Multilevel Desktop Sessions from last August. At that time I suggested using a combination of Xvfb(1) and vino-session (x86) or x0vncserver (SPARC) to get both the features of vnc and the Trusted Extensions X protocol extension to work together. However, starting in SXDE 1/08 and the upcoming Solaris 10 update 5 beta, we now deliver a version of Xvnc which supports both protocols in a single binary based on the current version of Xorg. Since it uses a virtual framebuffer, it should work with either architecture.

 The easiest way to take advantage of this on a headless server running Trusted Extensions is customize the file /etc/dt/config/Xservers. Simply comment out the default line and add this new one:
 

#   :0  Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner
  :0   Local local_uid@none root /usr/X11/bin/Xvnc :0 -nobanner -AlwaysShared -SecurityTypes None -geometry 1024x768x24 -depth 24

Note that I have disabled password authentication because I am using this machine for software development. If you need more restrictive access, remove the -SecurityTypes option.

To make a remote connection (using a vnc client) your client machine should be assigned the admin_low template in server's tnrhdb file.

Monday Dec 31, 2007

Multilevel Mail Revisited

In my posting last February, Prototyping Multilevel Mail, I discussed some techniques for  implementing an email service to support labeled zones. It turns out that a company called BlueSpace Software has done just that. They have a very cool demo showing their label-aware email client running under Trusted Extensions using the Trusted Java Desktop System. The product is called BlueSpaced TransMail Trusted Edition. Here is a quote from their web page:

TransMail Trusted Edition tightly integrates with Solaris 10 Trusted Extentions to ensure appropriate content management between the different security zones, including data labelling so that the interface operates mutliple network sessions simultanteously. 

I haven't had a chance to try it out, but I'm looking forward to doing so when it is available. 

Friday Dec 28, 2007

Regressions Get Fixed

Some months ago I regretfully posted an entry entitled Regressions Shouldn't Happen.

All of the bugs referenced in that posting have been fixed and patches have been released. In addition, a large number of additional bugs have been found and fixed. The current list of required patches is available here, and on the OpenSolaris Trusted Extensions page.  If you are installing from the latest OpenSolaris build, or the upcoming Solaris 10 update 5 beta release, these fixes have already been incorporated into those distributions.

On a related issue, we have completed the integration of all of the "Extra Value" packages for Trusted Extensions into the standard Solaris and OpenSolaris metaclusters. I first wrote about this in Automatic Installation of Trusted Extensions.  Starting with the Solaris 10 update 5 beta release, there is no longer any separate installation step for Trusted Extensions software. To enable multilevel security you will need to enter the following SMF service:

svcadm enable -s labeld
 

Thursday Dec 27, 2007

Sun Tech Days in Tokyo

I haven't posted to my blog in a couple of months, so my New Year's resolution is to post more often.

Last month I took a working vacation through Japan, which started and finished in Tokyo. Here's what a working vacation looks like:


 

I was there to participate in the local Sun Tech Days conference.  Here are the slides for two of my presentations: New Security Features in Solaris 10 and OpenSolaris, and Let SMF Deal With That: An Introduction to SMF.  I visited some customer sites, so I got a Japanese business card for introductions (with two hands, as is the custom):

Japanese Card 

I was also interviewed for a local publication; here is partial transcript. I pasted one of these answers into Google's translation service, and got back this:

Q: How is the reputation of Solaris OS?

A: Until see the introduction of the Solaris to the high expectations
and satisfaction. However, the OS is secure because it was, all issues
to be settled is not. It is actually the most difficult, as the
organization's security policy planners think. Sun has experienced so
many engineers, we encourage you want to ask.

Which is (hopefully) not exactly what I actually said. Anyway, it was a great trip, and I'm looking forward to my next Sun Tech Days trip to St. Petersburg, Russia.

Tuesday Oct 09, 2007

Automatic Installation of Trusted Extensions

If you have recently installed Trusted Extensions on OpenSolaris (since build 71), you may have noticed that the number of packages listed in the Install Wizard is shrinking. This is a feature, not a bug.

We are currently migrating all of the Trusted Extensions packages into standard Solaris metaclusters, and expect to complete this process by OpenSolaris build 76. At that time there will be no separate installation step for Trusted Extensions.

Starting with OpenSolaris build 71, you specify the labeling behavior of the system via the SMF service,  labeld. To enable labeling,  you should run this command:

svcadm enable labeld

This setting will take effect on the next system boot.

It is now also possible to disable the multilevel behavior by disabling the service, and rebooting. However, you won't be permitted to do so unless you have removed your labeled zones. We will contiunue to enforce the MLS policy as long as there is labeled data on the system.

We plan to backport these changes into a future update of Solaris 10.




 

Thursday Aug 16, 2007

Remote Multilevel Desktop Sessions

Trusted Extensions does not currently support remote desktop sessions using the X Display Manager Protocol, XDMCP. See dtlogin(1X). We currently lack a mechanism for passing the user and role identities of remote X11 clients to the trusted X11 server. The security policy for role assumption and DAC isolation depend on these attributes. We do use the Secure RPC protocol (see xhost(1)) to maintain an access control list for X11 connections, but we use getpeerucred(2) to match clients uids against this list. The corresponding ucredgetuid(3) function is not supported for remote connections.

Remote X11 client access is generally disabled, and only Trusted Path processes can modify the X11 server access control policy. For remote CDE access, we provide a script, dtappsession(1), which brings up a remote Tooltalk session and Application Manager. But this is a pretty limited solution. We are working on a secure solution based on XDMCP.

Meanwhile, I have developed a workaround which uses VNC. I am currently using this on a headless T2000 system, storms.sfbay, running Solaris 10 update 4. Since it has no graphics display, I considered using Xvnc, which is a combined X11 and VNC server. But that server doesn't support the xtsol extension, so it wasn't viable. Instead, I am using a shell script called Xvfb(1), which is a wrapper around Xsun(1), that uses a virtual framebuffer, and requires no mouse or keyboard. I am using a VNC server called x0vncserver, which is downloadable from the RealVNC web site. It is included in the VNC Free Edition for Solaris 7 (SPARC). Yes, it's that old!

There is a better VNC server that is included in Solaris Expresss Developer Edition, in /usr/bin/vino-session, that  works on x86/x64. I haven't found a pre-compiled version of vino-session or x0vncserver (x86) for Solaris 10, but the sources are available, so we could build one.

The RealVNC bundle includes a vncviewer that you can use on your local system. In my case, I run it in my internal zone. This doesn't require CIPSO, but your local system must be assigned the admin_low network template in the tnrhdb(4) file of the headless system.

On the headless system, I copied following two files:

  1.  cp  /usr/dt/config/Xservers /etc/dt/config
  2. cp  /usr/dt/config/Xsetup /etc/dt/config
I modified /etc/dt/config/Xservers.
#   :0  Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner

  :0   Local local_uid@none root /usr/openwin/bin/Xvfb :0 -nobanner -dev  vfb screen 0 1024x768x24

and added the following to /etc/dt/config/Xsetup
# VNC
   /usr/local/bin/x0vncserver display=:0 PasswordFile=/.vnc/passwd >/dev/null 2>&1 &

The password for VNC access is set by the utility vncpasswd. Since I ran it as root on the server, it is stored under /.vnc
I ran the same program on my local system so that I don't need to enter the password each time.

After modifying these files, you need to restart the dtlogin process:
svcadm restart cde-login
On the client side I just run this:
vncviewer PasswordFile=/home/gfaden/.vnc/passwd  storms.sfbay

 You can also use the Java-based vino viewer in SXDE, by running /usr/share/gnome/vino/vino-client.jar .

The dtgreet(1)  window (Welcome to storms) comes up and you can choose trusted CDE or JDS. They should both work fairly well. When you logout, the VNC session ends, too.

There are a few minor problems, such as the cursor not being updated correctly, and there is an issue with changing Trusted JDS workspace labels. In my previous blog, I mentioned a workaround for this bug which disabled the MIT Shared Pixmap extension, MIT-SHM. However, the VNC server requires this extension, so it must be enabled.

VNC supports encryption between the client and server if you need it. In my case, I didn't bother; I'm on a protected network (SWAN), or using IPsec when working from home.

Saturday Jul 21, 2007

Regressions Shouldn't Happen

Unfortunately, they do. Before new features may be added to Solaris they must go through architectural review and exhaustive testing. Nevertheless, stuff happens. In Solaris 10 Update 4, and Nevada there are several new features that have had unexpected impact on Trusted Extensions functionality. Most of these get discovered and fixed quickly, but a few weren't understood and couldn't be fixed properly in time for the Update 4 release. So we have a few workarounds that will be required. I've been involved in the analysis of each of the these issues and thought it would be interesting to show why they were hard to find. In each case, the affected Trusted Extensions component had not changed since Update 3, so we weren't expecting breakage.

The first issue showed up in Trusted JDS authentication interfaces like role assumption. The Sparks Project enhanced the name service cache daemon (nscd), but changed the policy for accessing encrypted passwords. Previously, a process with all privileges but with a normal user ID, could call the PAM account management service which provides password aging and account locking. But the new architecture for nscd had the side-effect that root was now required. Although nscd has been fixed in Nevada to restore the previous behavior, there was insufficient time to backport this fix to Update 4. Therefore we integrated a workaround in the PAM stack for Trusted JDS to skip the failing check. A proper fix will be delivered in Update 5.

The next problem affected Trusted JDS workspace labeling. When a new label is applied to a workspace, the Trusted Stripe application uses the zone_enter() system call to initiate a session in the corresponding zone. Another project Duckhorn enhanced the resource management features of zones. One of these features, the capped-memory resource, imposed a new restriction on the zone_enter() syscall that prevented a process with a System V shared memory object from transitioning to a non-global zone. Meanwhile the GNOME toolkit was changed to use the X11 shared pixmap feature which affected the behavior of the Trusted Stripe process. As a result, the process was unable to initiate new sessions in labeled zones. Again, the root cause was discovered too late for a proper fix to be included in Update 4. Meanwhile, the workaround is to customize the TrustedExtensionsPolicy(4) file to disable the MIT-SHM X11 extension.

The third problem affects Trusted CDE in the specific laptop configuration that is described in the OpenSolaris Laptop Instructions. A change was made in Nevada to remove the installation question about enabling IPv6. Instead, the loopback interface is now plumbed with an IPv6 address, and services like the portmapper now support both IPv4 and IPv6 addresses. This configuration is partially incompatible with the use of the Virtual Network Interface, vni(7), as described in the laptop instructions. The Tooltalk RPC service which is used in Trusted CDE to initiate the Trusted Path does not get registered correctly with the portmapper when there are no physical interface plumbed. As a result the Trusted CDE session hangs. There are a variety of workarounds for this problem, and most people will never see it. In Update 4, don't enable IPv6 when asked, or don't use Trusted CDE until a physical interface has been plumbed. For Nevada, the workaround is described in step 4a of the revised laptop configuration procedures.

I'm frustrated by the above regressions, but I'm optimistic that things are getting better. The entire Trusted Extensions test suite has now been integrated into the Solaris Pre-Integration Test Suite (PIT).

Saturday May 26, 2007

Label-aware Web Services

Last year I posted an entry about Safe Browsing in which URLs were forwarded to separate browsers corresponding to the label of the website. Now I want to refer to the opposite scenario, in which the website itself is label aware. In this case the web server enforces a dominance policy, comparing the label of the HTTP request to XML labeling tags within the document. A label-aware Java servlet can be plugged into a standard Application Server, which is bound to a multilevel port. The server only returns those portions of the document which are dominated by the client's label.

Trusted Extensions provides C library interfaces for acquiring, comparing, and translating labels. Corresponding Java bindings have been implemented by John Weeks which use the Java Native Interfaces (JNI) to access the underlying C interfaces. These Experimental Java classes and documentation have been posted to the OpenSolaris Trusted Extensions project page. A new chapter will soon be added to the Trusted Extensions Developer's Guide which will cover these Java methods. An early version of the chapter is available here.

The design of the label-aware Java servlet, the XML labeling tag, and the use of XACML to represent the policy were presented by John at this month's JavaOne Conference. The session, Leveraging Solaris Trusted Extensions to Implement Platform Security Services for the Java Language is described on the Sun Developer Network website. It includes a detailed set of slides summarizing the design and implementation.

John has been working on this project for about a year, and plans to post the source code of the servlet by the end of June. He's done a great job! I've been using his code when I give presentations, and it has been very well received.

 

Sunday Apr 01, 2007

Comments about Trusted Operating Systems

Karl MacMillan has written a detailed response to my article comparing the MLS policies of Trusted Extensions and SELinux. Although I don't agree with many of his assertions, I think this is a healthy discussion. I've posted comments on his blog, but I have one other point to make here.

Despite the fact that my article was about the MLS policies in TX and SELinux, Mr. MacMillan generally played down MLS as a viable security technology. He states:

The problem, in my view, is that the separation offered by MLS systems is more severe than most commercial customers can tolerate and there is no secure way to relax those restrictions. That is where type enforcement really shines. It is possible to clearly and securely specify how information can flow to allow limited flow of data in certain circumstances through specific, trusted processes. The inflexibility of MLS doesn’t offer this: process are either confined by the policy or are trusted to circumvent it in coarse-grained ways. Relaxing the policy to make it useful essentially destroys any security benefit.

I disagree that relaxing the MLS policy destroys any security benefit. In Trusted Extensions, the MLS policy for labeled zones is always enforced, even for privileged processes. The policy can be relaxed to permit specific trusted processes to request that individual files are upgraded or downgraded, but such relabeling is still subject to review by TCB processes in the global zone. Multilevel ports can be configured for use by trusted processes, but they are still constrained to communicate at specific levels.

Type Enforcement has a lot of potential, but MLS, as implemented in Trusted Extensions, provides unique advantages. I am pleased to see a growing awareness in the secure OS community.