Trusted Extensions Security Policy
Sensitivity labels control access to data and maintain the classification of data.
All processes and objects have a sensitivity label that is used in
MAC decisions. The labels are attributes that are interpreted by the system
security policy. The system security policy is the set of rules that is enforced
by system software to protect information being processed on the system.
The following sections describe how the Trusted Extensions security policy affects multilevel
operations, zones, and labels.
Multilevel Operations
When you create an operation that runs at multiple security levels, you
must consider the following issues:
Operations that run at multiple security levels are controlled by the global
zone because only processes in the global zone can initiate processes at
specified labels.
Write-Down Policy in the Global Zone
The ability of a subject, such as a process, to write an
object whose label it dominates is referred to as writing down. The write-down
policy in the global zone is specified administratively. Because global zone processes
run at the ADMIN_HIGH label, certain file systems that are associated with
other labels can be mounted read-write in the global zone. However, these
special file system mounts must be administratively specified in automount maps, and
they must be mounted by the global zone automounter. These mounts must
have mount points within the zone path of the zone that has
the same label as the exported file system. However, these mount points
must not be visible from within the labeled zone.
For example, if the PUBLIC zone has a zone path of /zone/public,
a writable mount point of /zone/public/home/mydir is permitted. However, a writable mount
point of /zone/public/root/home/mydir is not permitted because it can be accessed by
the labeled zone and not by the global zone. No cross-zone NFS
mounts are permitted, which means that the NFS-mounted files can only be
accessed by processes that run in the zone that mounted the file
system. Global zone processes can write down to such files, subject to
the standard discretionary access control (DAC) policy.
Local file systems associated with zones are protected from access by global
zone processes by DAC, which uses file permissions and access control lists
(ACLs). The parent directory of each zone's root (/) directory is only
accessible by root processes or by processes that assert the file_dac_search privilege.
In general, the ability to write down from the global zone is
restricted. Typically, writing down is used only when a file is reclassified
by using the setflabel() interface or when privileged users drag and drop
files between File Manager applications in different zones.
Default Security Attributes
Default security attributes are assigned to messages that arrive on Trusted Extensions
hosts from other host types. The attributes are assigned according to settings in
the network database files. For information about host types, their supported security
attributes, and network database file defaults, see Solaris Trusted Extensions Administrator’s Procedures.
Default Network Policy
For network operations that send or receive data, the default policy is
that the local process and the remote peer must have the same
label. This policy applies to all zones, including the global zone, whose
network label is ADMIN_LOW. However, the default network policy is more flexible
than the policy for mounting file systems. Trusted Extensions provides administrative interfaces
and programmatic interfaces for overriding the default network policy. For example, a
system administrator can create an MLP in the global zone or in
a labeled zone to enable listening at different labels.
Multilevel Ports
Caution - Use extreme caution when using a multilevel port to violate MAC policy.
When you must use this mechanism, ensure that your server application enforces
MAC policy.
Multilevel ports (MLPs) are listed in the tnzonecfg administrative database. Processes within
the zone can bind to MLPs if these processes assert the net_bindmlp
privilege. If the port number is less than 1024, the net_privaddr privilege
must also be asserted. Such bindings allow a process to accept connections
at all labels that are associated with the IP addresses to which
the process is bound. The labels that are associated with a network
interface are specified in the tnrhdb database and the tnrhtp database. The
labels can be specified by a range, by a set of explicit
enumerated labels, or by a combination of both.
When a privileged process that is bound to an MLP receives a
TCP request, the reply is automatically sent with the label of the
requester. For UDP datagrams, the reply is sent with the label that
is specified by the SO_RECVUCRED option.
The privileged process can implement a more restrictive MAC policy by comparing
the label of the request to other parameters. For example, a web
server could compare the label of the requesting process with the label
of the file specified in the URL. The remote label can be
determined by using the getpeerucred() function, which returns the credentials of the
remote peer. If the peer is running in a zone on the
same host, the ucred_get() library routine returns a full set of credentials.
Regardless of whether the peer is local or remote, the label of
the peer is accessible from the ucred data structure by using the
ucred_getlabel() function. This label can be compared with other labels by using
functions such as bldominates().
A zone can have single-level ports and multilevel ports. See Multilevel Port Information.
MAC-Exempt Sockets
The Trusted Extensions software provides an explicit socket option, SO_MAC_EXEMPT, to specify
that the socket can be used to communicate with an endpoint at
a lower label.
Caution - The SO_MAC_EXEMPT socket option must never be used unintentionally. Use extreme caution
when using this socket option to disable MAC policy. When you must
use this mechanism, ensure that your client application enforces MAC policy.
The Trusted Extensions software restricts the use of the SO_MAC_EXEMPT option in
these ways:
To explicitly set the socket option, a process must assert the net_mac_aware privilege.
To further restrict the use of this socket option, the net_mac_aware privilege can be removed from the limit set for ordinary users.
See the user_attr(4) man page for details.
Sometimes, explicitly setting the socket option is not practical, such as when
the socket is managed by a library. In such circumstances, the socket
option can be set implicitly. The setpflags() system call enables you to
set the NET_MAC_AWARE process flag. Setting this process flag also requires the
net_mac_aware privilege. All sockets that are opened while the process flag is
enabled automatically have the SO_MAC_EXEMPT socket option set. See the setpflags(2) and
getpflags(2) man pages.
For applications that cannot be modified or recompiled, use the ppriv -M command
to pass the net_mac_aware process flag to the application. In this case,
all sockets that are opened by the application have the SO_MAC_EXEMPT option
set. However, child processes of the application do not have this process
flag or the related privilege.
Whenever you can, scrutinize and modify the source code of an application
when you need to use the SO_MAC_EXEMPT socket option. If you cannot
make such modifications to the code or if a safer method is
not available to you, you may use the ppriv -M command.
The SO_MAC_EXEMPT socket option has been used sparingly by the Solaris OS.
This option has been used by the NFS client. An NFS client
might need to communicate with an NFS server that runs at a
different label on an untrusted operating system. The NFS client enforces MAC
policy to ensure that inappropriate requests are not granted.
In the Solaris OS, both the NFS server and client code include
and enforce MAC policy so that communications between the Solaris client or
server and an untrusted client or server has MAC policy enabled. To
enable an untrusted host to communicate with a system that runs Trusted
Extensions, the untrusted host must have an entry in the tnrhdb database.
For more information, see Configuring Trusted Network Databases (Task Map) in Solaris Trusted Extensions Administrator’s Procedures.
Note - For examples of how the Trusted Extensions APIs are used in the
Solaris OS, see the Solaris source code. Go to the Open Solaris web site and
click Source Browser in the left navigation bar. Use the Source Browser
to search through the Solaris source code.
Zones and Labels
All objects on a system configured with Trusted Extensions are associated with
a zone. Such zones are called labeled zones. A labeled zone is a
non-global zone and is accessible to ordinary users. A user who is
cleared at more than one label is permitted access to a zone
at each of those labels.
The global zone is a special zone that contains files and processes that
control the security policy of the system. Files in the global zone
can only be accessed by roles and by privileged processes.
Labels in the Global Zone
The global zone is assigned a range of labels. The range is
from ADMIN_LOW to ADMIN_HIGH. ADMIN_HIGH and ADMIN_LOW are administrative labels.
Objects in the global zone that are shared with other zones are
assigned the ADMIN_LOW label. For example, files in the /usr, /sbin, and
/lib directories are assigned the ADMIN_LOW label. These directories and their contents
are shared by all zones. These files and directories are typically installed
from packages and are generally not modified, except during packaging or patching
procedures. To modify ADMIN_LOW files, a process must typically be run by
superuser or by someone who has all privileges.
Information that is private to the global zone is assigned the label
ADMIN_HIGH. For example, all processes in the global zone and all administrative
files in the /etc directory are assigned the ADMIN_HIGH label. Home directories
that are associated with roles are assigned the ADMIN_HIGH label. Multilevel information
that is associated with users is also assigned the ADMIN_HIGH label. See
Multilevel Operations. Access to the global zone is restricted. Only system services and
administrative roles can execute processes in the global zone.
Labeled Zones
Non-global zones are called labeled zones. Each labeled zone has a unique label.
All objects within a labeled zone have the same label. For example,
all processes that run in a labeled zone have the same label.
All files that are writable in a labeled zone have the same
label. A user who is cleared for more than one label has
access to a labeled zone at each label.
Trusted Extensions defines a set of label APIs for zones. These APIs
obtain the labels that are associated with labeled zones and the path
names within those zones:
getpathbylabel()
getzoneidbylabel()
getzonelabelbyid()
getzonelabelbyname()
getzonerootbyid()
getzonerootbylabel()
getzonerootbyname()
For more information about these APIs, see Accessing Labels in Zones.
The label of a file is based on the label of the
zone or of the host that owns the file. Therefore, when you
relabel a file, the file must be moved to the appropriate labeled
zone or to the appropriate labeled host. This process of relabeling a
file is also referred to as reclassifying a file. The setflabel() library
routine can relabel a file by moving the file. To relabel a
file, a process must assert the file_upgrade_sl privilege or the file_downgrade_sl privilege.
See the getlabel(2) and setflabel(3TSOL) man pages.
For more information about setting privileges, see Developing Privileged Applications, in Solaris Security for Developers Guide.
