Friday Mar 14, 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.



 

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.

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 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.

Friday Mar 09, 2007

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.



Tuesday Feb 27, 2007

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.

Wednesday Feb 14, 2007

Prototyping Multilevel Mail

One of the potential use cases for Trusted Extensions is dealing with multilevel mail. In Trusted Solaris 1.x, which was based on OpenLook, we had an application called postmaster, which kept track of the arrival of a user's mail by periodically checking all the instances of the /var/mail/username in the multilevel directory. In Trusted Solaris 2.5 through 8, we integrated this functionality into the the CDE front panel. The CDE code in Trusted Extensions has this feature  disabled because most people are using remote mal services like IMAP or POP, rather than UNIX local mail (movemail).

I have been working on an architecture for multilevel mail in Trusted Extensions in which mail can be delivered  to labeled zones that are only in the ready state (mounted but not running). This would reduce the overhead of the current polyinstantiation approach in which  an instance of sendmail is running in each zone.

 At this point, all I have is a bunch of shell scripts to mimic the behavior of postmaster. But I think they are illustrative of how to launch applications in zones that may not be running. The txmailmgr script looks for all labeled instances of /var/mail for a user, and presents a list from which instances of thunderbird can be launched or popped up.

To signal thunderbird to pop up, I used the mozilla-xremote-client command with the openInbox option. However, it didn't work correctly, so I modified the JavaScript file nsMailDefaultHandler.js to open the correct window using the same logic that is used for a similar function in this file. You will need to replace the existing file in your lib/thunderbird/components directory to get the desired behavior.

The four shell scripts,  txmailmgr, runatlabel, waitforzone, and openMail should all be installed in /opt/txdemo/bin. You can  put them elsewhere if you edit the PATH variable in the scripts.

The txmailmgr script uses zenity and takes no command line arguments. It must be started in the global zone by assuming the root role. You should see a window like this:

mail manager

 One of the more interesting aspects of this prototype is how the runatlabel and waitforzone scripts interact when the zone is found to be in the ready state.  The following fragment starts the waitforzone script in the specified zone, and puts up a progress window giving the user feedback.

(zlogin ${zone} $DEMOPATH/waitforzone ${user} ${progname} ${DISPLAY} $@ ;echo 100)|zenity --progress --auto-close --title="Please Wait" --text="${zone} zone is booting"

The waitforzone script periodically checks for the presence of the user's home directory. It doesn't show up until the the zone's automountd has processed  auto_home_zonename
which implies that suffficient zone services are up to support running thunderbird.  Once a second it checks for the directory, and pipes a progress percentage back to the instance of the zenity progress bar which is running in the global zone. It's not a real percentage, just a good guess.

 

progress=25
while [ ! -d /home/${user} ]; do
        print $progress
        sleep 1
        let progress+=10
done

In the openMail script, the code first tries to determine if thunderbird is running befor invoking the mozilla-xremote-client facility. I found that it is faster to use pgrep than the mozilla ping facilty. The latter method generates hundreds of X window calls.

 

for f in `pgrep -U $user thunderbird`; do
    d=`/usr/ucb/ps -eww $f|tr " " "\\n"|grep DISPLAY`
        if [ $? = 0 ]; then
            DISPLAY=`echo $d|cut -f2 -d"="`
            export DISPLAY
            mozilla-xremote-client -a thunderbird  \\
               "xfeDoCommand(openInbox)" &
            exit;
    fi
done
 

Some of these scripts could be used to launch  applications in zones  that are not even in ready state, but txmailmgr ignores zones whose filesystems are not mounted or labeled at ADMIN_HIGH.

 

label=$(getlabel /zone/\*/root/var/mail/$user|\\
    grep -v ADMIN_HIGH|cut -f2|zenity \\
    --list \\
    --title="$title" \\
    --width=300 \\
    --height=200 \\
    --column="Available Mail Labels for $user")


 

 


 

Monday Jan 22, 2007

Glenn's Big Day

It was announced today that I have been promoted to the rank of Distinguished Engineer. That's a pretty big deal at Sun, and I'm feeling pretty good about it. And as if that weren't enough, one of the new videos that I mentioned in my earlier blog entry has been posted to Sun's corporate website. It is called Using Solaris Trusted Extensions and the Java Desktop System and features yours truly.  The video includes a live demo of Trusted JDS, but the image is a bit fuzzy, so you may want to review the Flash demo that covers some of the same material.

I am also scheduled to appear on the February 28th edition of the Sun Developer Channel so you can put that on your calendar.

Sunday Jan 21, 2007

Writing Down to Files from the Global Zone

The global zone in Trusted Extensions is restricted to administrative roles and system processes. It is a multilevel environment in which all process run at the ADMIN_HIGH label, but it has some unique filesystem MLS policies compared to labeled zones. In labeled zones, writing down to lower-level files is never permitted, even by processes with all privileges; the Bell-Lapadula policy is strictly enforced. But writing down within the global zone is possible for processes with sufficient privileges. There is no explicit file_mac_write privilege, as there was in Trusted Solaris 8, but there are a few relevant privileges and configuration restrictions.

Preventing Writing Down to Shared Directories 

The first case to consider is for directories such as /usr and /sbin that are loopback mounted from the global zone into labeled zones. These filesystems are labeled with the ADMIN_LOW label, and are exported as read-only. Since most of the files in these directories are owned by root, they can only be modified in the global zone by  root, or by a process with all privileges. However, it is possible to prevent any process from writing down by remounting these directories using read-only loopback mounts. While such a strategy improves the system's integrity, it is generally inconvenient. For example, adding packages and patches that affect these directories is not possible while these loopback mounts are in place. Nevertheless, it is something that should be considered if it meets your requirements.

As an example,  the following entry in /etc/vfstab would make /usr read-only in the global zone when the system is rebooted:

/usr    -    /usr   lofs   -   yes    ro

In order to make /usr writeable again, you would need to comment out this entry and reboot.

Writing Down to Labeled Zone Files

The root directory of a labeled zone is assigned the same label as the zone. The parent of this directory, known as the zonepath, is only visible from the global zone, and is only traverseable by root, or by a process with the file_dac_search privilege. Such a privileged process in the global zone, may be able to read or write files under the zonepath that are local to the zone. However, there are still further restrictions with respect to automounted filesystems in labeled zones. Such filesystem mount points can only be traversed from the zone which  mounted them.

It is possible to overcome this restriction by remounting the remote filesystem into the global zone. However, there are several additional restrictions that affect this operation:

  1. The global zone must have network connectivity to the remote NFS server. This may not be allowed in some configurations.
  2. The process doing the mount must have all privileges.
  3. The label of the mount point must equal the label of the remote filesystem, but must be outside the labeled zone, itself. The only place this requirement can be met is in a directory above the zone's root directory, but below the zonepath.

For example, if the zone public has a zonepath of /zone/public, then its root path is is /zone/public/root. The global zone automounter could request a read-write mount of a remote home directory from a PUBLIC NFS server, using the pathname /zone/public/home/gfaden. In this case, the mounted filesystem is labeled as PUBLIC, but its mount is owned by the global zone. Only privileged processes in the global zone can traverse the  mount point because of the restrictive permissions of the zonepath. The public zone cannot see this mount point, but its own automounter can mount the same remote filesystem within its own namespace.

Writing down from the global zone is unusal, but there are a few cases where it is useful. For example. the setflabel(3TSOL) library function is implemented using a door call to a global zone daemon, labeld. The daemon  requires read-write access to the source and destination directories even if they exist in remote filesystems. It relies on the function getpathbylabel(3TSOL) to handle any required remounting so that global zone-relative pathnames can be used to access the source and destination directories. In the current implementation, such remote directories must be accessable via the global zone's automounter.

This discussion has been limited to the MLS policy for filesystem objects. The MLS policies for X11 and network objects are slightly different and will be explained in a future blog entry.


 

Saturday Jan 20, 2007

Who, What, When, Where, and Why?

Last week Sun made a big marketing splash about the new features of Solaris 10 11/06. Information about Trusted Extensions is now available at a variety of multimedia URLs which provide answers to the questions listed in this entry's title. Among the cool sites are:

A Flash demo of the Trusted Java Desktop System by Stephen Browne

Marketing manager Mark Thacker's videos

Trusted Extensions Data Sheet 

Updated Solaris Security Overview 

Podcast about Trusted Extensions and Secure by Default featuring Darren Moffat and Glenn Brunette

I've also recorded a couple of videos which will appear on Sun's website next month. This is the fun part of the project!

Sunday Dec 03, 2006

HP shows path to Linux for trusted Solaris customers

HP has written a new white paper Legacy MLS/Trusted Systems and SELinux – concepts and comparisons to simplify migration and adoption . This paper does a great job of comparing the current SELinux development efforts with Sun's legacy Trusted Solaris product. However, it says nothing about Sun's current offering, Solaris Trusted Extensions. Considering the HP paper was published in  August 2006, and that Sun announced that Trusted Extensions would replace Trusted Solaris more than a year ago, this is unfortunate. But the OpenSolaris download has only been available since July , and the complete set of manuals for Trusted Extensions have only been online since September. To help HP bring their article up-to-date, I am providing pointers to the latest information.

In HP shows path to Linux for trusted Solaris customers  it is asserted that

SUN is forcing customers to move off of Trusted Solaris 8 with the end of support life this fall.  SUN's solution requires significant porting to support Solaris 10 with Trusted Extensions since it's based on a new architecture.

First, Sun has announced no plans to end support of Trusted Solaris 8. Second, the effort to port from Trusted Solaris to Trusted Extensions is pretty minor when compared to a similar SELinux port. Sun has published Solaris Trusted Extensions Transition Guide which provides equivalent interfaces between the two systems.

I have included excerpts from section 11, Technical comparison: legacy MLS vs. SELinux. The subsection 11.1 Principle of least privilege  does a good job of explaining the legacy MLS privilege model in Trusted Solaris 8. However, the new privilege implementation in Trusted Extensions is the same as that in Solaris 10, and doesn't depend on MLS.

One important distinction is that in traditional MLS systems a process is empowered with privilege but in SELinux, the domain is endowed with capabilities and attributes. This means that in SELinux a process's privilege is limited by the domain. Traditional MLS privileged processes have no bound on the scope of their privilege.

In Trusted Extensions, each domain is associated with a Solaris zone. A process's privileges in a zone is limited by the zone's privilege limit set, which is configurable on a per-zone basis. Even a root process in a labeled zone is subject to this limit.

11.2.1 MLS Privileges as a means to least privilege

Similarly, a process having the privilege
file_mac_read is able to bypass Bell-LaPadula policy MAC controls to read any file.

The privileges file_mac_read and file_mac_write are obsolete and are not implemented in Trusted Extensions. The corresponding window system privileges, win_mac_read and win_mac_write, are not available in labeled zones, by default. Even a process with all privileges, such as a root process in the zone, cannot override the MAC policy specified for the zone.

 2.2 Separate trusted and commercial versions
Any program that relied on the root user had to be modified to use privileges. Administration programs had to be modified to manage the new security features and new utilities had to be developed for security features that did not exist in the commercial systems. The end result was that the trusted version of the commercial release lagged commercial versions and it was impossible to stay current.

Since the privilege policy in Trusted Extensions is identical to that of the standard Solaris OS, there are no special requirements to customize applications, and the trusted version is now incorporated into the commericial release.

11.2.2 SELinux domain capabilities and attributes as a means to least privilege

Thus to accomplish tasks which cannot be done as a normal user, a process must be running as UID=0 and have SELinux policy rules to allow access.
Using the Apache web server as an example, the httpd process needs to run as the root user for several reasons. One reason is to spawn off child processes running with a different user identity. The policy for the Apache web server domain is assigned the Linux capability setuid to be able to do this. Thus the Apache web server is running with the root user id to pass the Linux kernel tests to set a different user id to a child process and the setuid capability is assigned to its domain to pass the SELinux policy test.

In Trusted Extensions, the Apache server does not need to run as root because it can be assigned the required proc_setid, via an RBAC or SMF policy file. This privilege cannot be abused to escalate its privilege set because it doesn't allow a transition to root.

The rules governing type enforcement are not overridden by the capabilities and/or attributes. Thus a process could only wreak havoc within a single domain in SELinux while a privileged process could wreak system-wide havoc in a traditional MLS system.

Similarly, in Trusted Extensions, an all-privileged process can only wreak havoc within its own zone.

11.4 Polyinstatiation

However, the implementation is not complete as of the publication of this paper but it is expected to be finished in time for the release of Red Hat Enterprise Linux 5.

In Trusted Extensions, polyinstantiation is automatic and completely implemented..

11.5 Audit

In SELinux, audit records are used to determine what changes need to be made to the policy to allow an authorized program to accomplish its task. The policy rather than the program is modified.

The same is true in Trusted Extensions. The privilege specifications are part of the SMF and RBAC policies.

11.6 Trusted path

 For a rogue program to masquerade as the login program, it would have to execute in a domain which had
access to device files used for login purposes. This circumstance would not exist in the rule base

Trusted Extensions reserves a portion of the screen for constant feedback so that the user can determine when a login prompt is trustworthy. Spoofing is not something that SELinix can prevent in a policy rule.

11.8 Trusted X Windows

Linux does not include an implementation of trusted X Windows

Trusted Extensions ships with a choice of multilevel CDE or GNOME desktops. Both are layered on the Trusted X11 server, which implements  fine-grained MAC and DAC policies transparently. It interprets process privileges and labels for policy enforcement and audits all security-relevant events. Sun has contributed its implementation of trusted X Windows to X.org.


Saturday Dec 02, 2006

Comparing SELinux with Solaris Trusted Extensions

I am frequently asked to compare Solaris Trusted Extensions to SELinux. Although this seems like a simple question, it is hard to make a fair comparison because the goals of each system are different. I am not an expert on SELinux but there is quite a lot of information on the Web. One of the best sites I have found is The UnOffical SELinux FAQ

Solaris Trusted Extensions is just a configuration of Solaris, so it is best to start there. Like all modern operating systems, Solaris is highly configurable. Policy is configured in multiple ways in multiple databases, but there are two primary mechanisms. Most user-based policy is defined via the Role-Based Access Control (RBAC) databases. Most service-based policy is defined using the Service Management Facility (SMF). Both frameworks leverage process rights management (privileges) which are interpreted by the kernel to grant or deny access to protected resources. The privilege policy is extensible but is always enforced. While the Solaris policy is abstracted via policy hooks, Sun only provides a single set of policy functions which rely on the privilege mechanism exclusively. Most of these functions are contained in a single file policy.c .

Compared to the Linux Security Modules (LSM) framework, the Solaris implementation is not optimized to be extended or replaced. Sun could have easily delivered these functions in a loadable module, as was done in  the original implementation in Trusted Solaris 8. However, experience with Trusted Solaris showed that multiple policy implementations were difficult to support. Therefore, the Solaris kernel always enforces policy based on process privileges; there is no mechanism for loading alternate policies nor disabling the privilege policy.

In contrast LSM is all about policy extensibility. Multiple polices can be loaded simultaneously, of which SELinux is just one example. The policy enforcement can be disabled, or set to permissive or enforcing modes. The policies associated with SELinux are described in a policy language and are compiled and loaded into the kernel. There is so much flexibility that defining policy is the biggest obstacle to deploying SELinux. Red Hat discusses this issue in Discussion of Policies where they explain why they have Targeted, Strict, and MLS policies.

So rather than comparing all of SELinx to Solaris Trusted Extensions, it makes more sense to compare the MLS policies of the two systems. Both systems are designed to meet the same evaluation criteria, EAL4+/LSPP , but the implementations are radically different. Trusted Extensions adds security labels to  Solaris Containers (zones) while SELinux extends Type Enforcement to support labels as an additional field in the security context.

Although the general rules for information flow are similar in both systems, the same trade-off in simplicity vs. flexibility applies to multilevel polices. SELinux provides MLS labels at the same granularity as other Type Enforcement rules. MLS policies must be defined for applications, directories, services and network ports.


On the other hand, Trusted Extensions derives most MLS subject and object labels from zone associations. Since zones provide a completely virtualized environment, applications in labeled zones run without modification. There is no need for new filesystem attributes like multilevel directories to resolve naming conflicts. Labeling policies for file sharing, networking, and windowing automatically conform to  the MLS policies.

In some respects, the zones policy is more robust than that of the strict SELinux policy. For example, the labels within a zone are fixed. There are no interfaces to transition the label of a subject, or object within the zone. Even a process with all privileges in a labeled zone is subject to the MLS policy. The MLS label and privilege limits for each zone are specified by global zone administrative roles and cannot be changed while the zone is running.

When comparing these systems, one must consider the design goals. As Red Hat states on its polices page, the MLS policy for it upcoming RHEL5 is designed for servers only. Solaris Trusted Extensions was designed to provide multilevel environments for end users as well as services. So ease-of-use was was built into the security policy.

The Trusted CDE system was ported to Trusted Extensions from Trusted Solaris 8, and has been available through OpenSolaris since July. The upcoming build 54 will also include an alternative trusted desktop, Trusted Java Desktop System , based on GNOME 2.16.

We are very close to the first commercial release of Solaris Trusted Extensions. It will be delivered as part of Solaris 10 11/06  in  about two weeks. It will include Trusted CDE and a version of Trusted JDS based on GNOME 2.6.

Wednesday Oct 11, 2006

More Clarifications: Fine-grained file access

Chad Sellers posted some thoughtful comments about my previous posting. So this posting is my reply.

1) Concerning fine-grained labeling:
I believe Josh's point was that you didn't have fine-grained labeling on files. And using a loopback filesystem (bind mount to us Linux users) or network filesystem is a hack that becomes necessary when you don't have this sort of per-file labeling.

Actually, I tend to view per-file labeling as a hack.

After years of experience with extended file attributes in Trusted Solaris, we decided that fine-grained file labeling created a false sense of security. The labeling of files was easily bypassed. For example, if you mounted a multilevel UFS file system from Trusted Solaris 8 on a standard Solaris system, the labels were ignored. Similarly, an all-privileged subject could ignore labels.  Operating with unlabeled NFS servers was problematic and error prone. Customers were forced to use our special version of UFS instead of their preferred file systems.

Then there was the issue of complexity. Not only were there performance issues with performing MAC checks on file access, but there was the complexity of archiving the labeled filesystems. In Trusted Solaris we required customized archival tools which were not supported by major vendors. Non-standard NFS protocol extensions were required. Privileged users could change the labels of files in ways that prevented the system from working correctly. Pathname traversals would fail because directories had a higher label than the files they contained. Applications needed to be analyzed to determine if they needed multilevel directories or special labeling privileges.

Finally there was the issue of multilevel databases and documentation systems. These environments maintain finer-grained labeling than we could provide at the file system level.

When we realized that we could build multilevel environments without creating customized file systems we saw this as an elegant solution, not a hack. There was still significant engineering required to make the labeling policy robust and automatic. There were many small leaks to stop. But any lingering doubt was removed when we first ran ZFS with Trusted Extensions. It worked properly with no customization, and provided the reliability, scalability, and convenience that we were lacking in Trusted Solaris 8. Now each zone (domain for you SELinux users) has its own file system, and we can clone zones instantaneouly via ZFS snapshots. It's very cool.


2) Concerning constraining the global zone: Josh's point was that the global zone wasn't constrained by the zone infrastructure. I realize that all processes (even those in the global zone) are constrained by privileges (seem to be analogous to capabilities in the Linux world), but from what I can tell these are coarse-grained privileges that are not bound to a particular object (please correct me if I'm wrong). So, as soon as a privileged process needs to write one file it doesn't own, you grant it file_dac_write and it can write to any file it doesn't own. This is why you need per-file labeling (which TSOL had) to begin with. Privileges are not sufficient.

It's true that privileges by themselves can be fairly coarse. But modern file systems provide Access Control Lists which are sufficiently granular. While this is an example of a DAC policy, not MAC, it is robust when applied to root-owned files. To prevent privilege escalation, Solaris 10 doesn't honor privileges like file_dac_write when applied to root-owned objects. And there are no privileges to override the mount policy thus ensuring that label relationships are always correct. Lower-level files can only be mounted read-only.

Like all developement efforts, Trusted Extensions is a moving target. We are working with the ZFS team to provide file encryption based on zone labels. We feel that this is ultimately more secure than extended file attributes.
About

This blog explores some of the security features of Oracle Solaris. In particular, topics such as Role-Based Access Control and Labeled Security are my special interests.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks