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.
Posted at 05:21PM Apr 18, 2008 by gfaden in Sun | Comments[3]
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.
Posted at 05:36PM Apr 07, 2008 by gfaden in Personal | Comments[2]
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 ( bvass, jimlaurent, barton808 ) 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.
Posted at 12:17AM Mar 15, 2008 by gfaden in Sun | Comments[4]
In Loving Memory
My wife Betty passed away yesterday. It is intensely personal and difficult for me to post this. But my daughter's journal of the last month is so moving, that I wanted to share it with my friends and acquaintances.
Posted at 12:29PM Feb 15, 2008 by gfaden in Personal | Comments[15]
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.
Posted at 03:48PM Jan 06, 2008 by gfaden in Personal | Comments[0]
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.
Posted at 05:40PM Dec 31, 2007 by gfaden in Personal | Comments[2]
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
Posted at 11:53AM Dec 28, 2007 by gfaden in Sun | Comments[3]
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):
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.
Posted at 06:17PM Dec 27, 2007 by gfaden in Sun | Comments[0]
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.
Posted at 03:36PM Oct 09, 2007 by gfaden in Personal | Comments[0]
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:
- cp /usr/dt/config/Xservers /etc/dt/config
- cp /usr/dt/config/Xsetup /etc/dt/config
# :0 Local local_uid@console root /usr/X11/bin/Xserver :0 -nobannerand added the following to /etc/dt/config/Xsetup
:0 Local local_uid@none root /usr/openwin/bin/Xvfb :0 -nobanner -dev vfb screen 0 1024x768x24
# VNCThe password for VNC access is set by the utility vncpasswd. Since I ran it as root on the server, it is stored under /.vnc
/usr/local/bin/x0vncserver display=:0 PasswordFile=/.vnc/passwd >/dev/null 2>&1 &
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-loginOn 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.
Posted at 04:45PM Aug 16, 2007 by gfaden in Sun | Comments[0]
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).
Posted at 04:02PM Jul 21, 2007 by gfaden in Personal | Comments[2]
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.
Posted at 11:27PM May 26, 2007 by gfaden in Sun | Comments[1]
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.
Posted at 01:36PM Apr 01, 2007 by gfaden in Sun | Comments[0]
Better Late Than Never
This week I got a letter from the US Patent Office announcing that one of my patent applications had been isssued. Naturally, I was pleased, since I had applied for several patents last year related to Trusted Extensions. However, when I looked up the case on the web I was shocked to find that it was the Policy Abstraction Mechanism that was first implemented in Trusted Solaris 2.5. This application was filed on June 24, 1996, so it only took 11 years to be issued.
Obviously there have been many changes in OS security over the past decade, but the mechanisms described in this invention are still in use today. Originally we used the same hooks and table-driven policy implementation in both the Trusted Solaris kernel and in the Trusted X11 server. Over time, the kernel implementation evolved into the current set of policy hooks now used in policy.c in Solaris 10 and OpenSolaris.
However, the original implementation is still being used today in the X11 server. You can download the code from the OpenSolaris X Window System website. It contains the table of protectect resources and methods described in the patent application. The web page provided by the US patent office is poorly formatted so that the orignal table has been run together without rows and columns. If you want to see how it is supposed to look, you can find it in this file:
XW_NV/open-src/xserver/xorg/sun-src/tsol/tsolpolicy.c
which contains:
/*
* X POLICY FUNCTION TABLE. One row per resource.
*
* TSOL_RES_NAME READ MODIFY CREATE DESTROY SPECIAL
*/
static int (*XTSOL_policy_table[TSOL_MAX_XRES_TYPES][TSOL_MAX_XMETHODS])() = {
...
The table is accessed using the function:
int
xtsol_policy(xresource_t res, xmethod_t method,void *resource, void *subject, xpolicy_t policy_flags, void *misc);
In the original implementation, xtsol_policy()was the single hook we used in the various X protocol functions to enforce the policy. However, we are now using the more generic SecurityHook mechanism which is part of the X-ACE framework. This abstraction allows Trusted Extension to use the same hooks that are used by the SELinux community. The details are described in Alan Coopersmiths' blog. The SecurityHook structure contains an abstraction of about ten functions, which are called throughout various X11 device independent functions. In Trusted Extensions, these functions are simply wrappers around the original xtsol_policy function.
During the eleven years that this patent application languished, the open source community has changed the playing field. The Linux community has now standardized on the Linux Security Modules mechanism which provides equivalent functionality.
Posted at 03:19PM Mar 09, 2007 by gfaden in Sun | Comments[0]
Trusted Extensions Featured on BigAdmin
I have written a new article for Sun's BigAdmin website entitled Comparing the Multilevel Security Policies of the Solaris Trusted Extensions and Red Hat Enterprise Linux Systems
There is also a table summarizing the main points of the article. Hopefully, I have fairly represented the upcoming Red Hat release. I welcome comments if I there are factual errors.
Posted at 07:42PM Feb 27, 2007 by gfaden in Sun | Comments[1]