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

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
   /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:


which contains:

 \* X POLICY FUNCTION TABLE. One row per resource.
static int (\*XTSOL_policy_table[TSOL_MAX_XRES_TYPES][TSOL_MAX_XMETHODS])() = {


The table is accessed using the function: 

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.


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

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)" &

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!


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.


« July 2016