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
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
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)
. 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 theproc_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
) nor use raw_devices (sys_devices
). 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