Glenn Faden's Blog

  • October 10, 2006

Clarifying Some Misconceptions About Trusted Extensions

Guest Author
On May 23, Joshua Brindle posted a reply to an open letter written by
one my colleagues, Darren Moffat . In that reply entitled  Trusted What? there were several statements made about Trusted Extensions that are
apparently misunderstandings. Rather than trying to squeeze my reply into
the comment window in his blog, I decided to post a more more complete
reply here, and create a link from his blog to mine. For contextual
purposes I have copied portions of his posting.

Trusted Extensions is in beta, not well tested, not present in any
released (and supported) Solaris and also has not been evaluated
(http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem ).

Solaris 10 is currently under
evaluation for CAPP and RBACPP
(http://niap.nist.gov/cc-scheme/in_evaluation.html#s ) and has
apparently not started LSPP. SELinux, on the other hand, has been
released in at least 2 commercially supported distributions (Red Hat
and Engarde), and in several community supported distributions. Red Hat
has EAL4+ in CAPP and is currently in evaluation for LSPP and RBACPP.
SELinux is pretty far ahead of Solaris and Trusted Extensions with
regard to evaluations.

Solaris and Trusted Solaris have been continuously evaluated for more
than a dozen years. The Solaris 10 GA evaluation is nearly complete,
and Solaris 10 11/06, which includes Trusted Extensions, is currently
in evaluation using the same EAL4+ assurance level and the same
protection profiles as RHEL5. However, the Trusted Extensions
evaluation includes additional end-user functionality such as
multilevel windowing and NFS.

Since Red Hat has not yet released any system that supports an MLS
policy, it seems presumptuous to assume that the RHEL5 evaluation is
ahead of Trusted Extensions. Having been through six evaluations, I
know you can't predict how long these evaluations will last.

are also some fundamental changes between the Trusted Extensions
implementation and Trusted Solaris. Since Trusted Extensions has
abandoned fine grained labels in favor of labeled zones it is difficult
to specify specific interactions applications running in different
zones can have on one another, more on this later. (This is my
understanding of Trusted Extensions, please correct me if I'm wrong).

Actually, the new architecture makes it easier to specify such
interactions. For example, the zone configuration includes an
enumeration of multilevel ports and the label ranges or disjoint label
sets for which they are effective. In addition, the zone configuration
includes the directories which may be shared via LOFS or NFS. The
kernel guarantees that all such mounts are consistent with the MAC
policy, rather than requiring the operator to specify mount labels.

Since zones are course grained and the only way for them to interact with one another is over network sockets this architecture
is not possible.

In addition to network sockets, Trusted Extensions supports one-way
FIFOs, and reading down to lower-level zones via LOFS and NFS.

might be tempted to do one of 2 things. The first is to put the agent
and the applications in the same zone. This breaks the security goal
since application servers can then interfere with the agent and the
other applications. There is no way to separate any part of the
architecture and you've gained very little (if anything).

In Solaris 10, the Service
Management Facility, smf(5)
provides this separation. The process
credentials of each service (uid, gid, and minimum privileges) and its
related authorizations are specified in a manifiest for each
service. See smf_security(5) and rbac(5). Neither the service nor the administrator need to run as root; they have distinct identities and credentials.

The global zone is effectively unconstrained. Any service running in it can affect all the other zones.

This is a misunderstanding.
Processes in the global zone are constrained by their privileges just
as processes in labeled zones. For example, a global zone process
cannot observe non-global zone processes unless it has been granted the
proc_zone privilege. It can further be constrained by the proc_info
privilege. Similarly, the files belonging to zones are inaccessable
unless the file_dac_search privilege is granted.

Furthermore, in Trusted Extensions, port polyinstantiation and namespace
isolation prevent the global zone services from interacting with
non-global zone clients unless explictly specified as multilevel

in itself violates the security goal since the applications (whether
they are in their own zones or not) have no integrity assurance. An
exploit of any application running in the global zone can affect the
applications (and therefore the data).

This is also untrue. No
file is writable in more than one zone. Files in the global zone have
the highest integrity. Files exported from the global zone are always

SELinux the passwd command is allowed to write to the password file but
it can't, for example, write to user home directories or use raw
devices or use the network. This level of granularity for confining
trusted applications is necessary to ensure integrity of any
application running on the system.

Root is not exempt from the
privilege policy in Solaris 10, so a root process that can update
/etc/shadow is not necessarily privileged to write to a user's home
directory (file_dac_write) nor use raw_devices (sys_devices, or
net_rawaccess). Furthermore, Solaris 10 introduced the concept of basic
privileges. These are privileges that can be removed from processes to
make them weaker than traditional unprivileged processes. Although
there is currently no basic privilege to prevent a process from
accessing the network, such functionality is planned for a future

There is always a trade-off in the design of any system. Clearly
SELinux provides additional controls that are not available in Trusted
Extensions. The Trusted Extensions team learned from its experience
with Trusted Solaris that simplicity is an essential component of
security. With that understanding, we used a straight-forward approach
to provide strong mandatory controls while minimizing complexity and

Join the discussion

Comments ( 5 )
  • Anonymous Tuesday, October 10, 2006
    Please add that Sun can indemify government users of Trusted Extensions in Solaris against potential claims against their intellectual property - and Red Hat, given that they do not own their own intellectual property, cannot offer this protection to customers - which as best I understand, is a violation of FARS.

    This is why Red Hat includes language to this effect in the Risk Factors portion of their SEC filings. For government users, this is an absolute imperative - and Red Hat has begun losing momentum due to their avoidance of the issue.

  • Chad Sellers Wednesday, October 11, 2006
    I think you missed some of Josh's points (disclaimer - I am a friend of Josh's).

    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.

    2) Conscerning 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.

    Anyway, I think the main point here is that Trusted Extensions != Trusted Solaris. They are quite different. I applaud you guys for figuring out a way to get MAC out of a one-off product and useable with your mainstream product. But people who are used to Trusted Solaris should not think Trusted Extensions are the same thing. As you pointed out, you had to make trade-offs in security capabilities to make the system simpler. So, system developers need to examine those tradeoffs closely before making a decision about their platform of choice.
  • Joshua Brindle Friday, October 13, 2006
    I'm not going to counter this (as I said on my blog) except to note that 1) when I wrote my blog it was absolutely accurate, TX had not entered any evaluations, let alone LSPP which RH has been in for well over a year and 2) it might be easier to write an accurate article (though there were no technical errors, only differences in opinion on the usefullness of certain things) if TX could actually be downloaded and tried out, which AFAIK isn't available to the public still. So it seems like I was totally right for saying in May the British Gov was right to choose SELinux over TX.
  • Glenn Faden Friday, October 13, 2006
    Josh is correct with respect to item (1). TX didn't enter evaluation until about a month after he wrote his blog entry. It was announced on June 27 in the following OpenSolaris URL:
    , but Sun didn't make a formal press release until September.
    With respect to item (2), TX became available about a month after his initial blog. In fact, my first blog entry, on June 15, was an announcement of its availability to the public. You can still download the free OpenSolaris version from Distributions .
    I'm not going to discuss our customers in this blog.
  • billig extensions Thursday, December 2, 2010

    Well, trusted extensions are really nice but i am getting some info about the cold fusion extensions which govt. is not supporting or hiding it from the real world.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.