The new clearance policy that I discussed in my blog about Protecting Sensitive Data is always enforced by the kernel, but is completely transparent by default, so there is no need for a switch for enabling or disabling this label-based policy. By default, all process are assigned the maximum clearance, Admin_High, and all files are assigned the minimum label, Admin_Low, so nothing is denied. Administrators can safely experiment with the new labeling interfaces while they refine their security policy. As they gain familiarity, they can make the policy increasingly robust by applying clearances to all users and SMF services, and by labeling filesystem objects. But it is important to remember that no process can raise its clearance nor observe any resource for which it is not cleared.


The default clearance for all user accounts and SMF services is specified via the CLEARANCE property in /etc/security/policy.conf. This property should eventually be set to Admin_Low, once explicit user clearances have been assigned administratively. SMF services that assign clearances to user processes, such as the RAD service, are explicitly assigned the Admin_High clearance. For example:


     # svccfg -s rad listprop method_context/clearance

     method_context/clearance astring    ADMIN_HIGH


Explicit clearances are specified in user_attr(5) and may be set by usermod(8), useradm(8), or the Account Manager BUI. A default clearance for newly created local or LDAP accounts can also be specified. For example:


     # useradd -S files -D -K clearance=Public

     # useradd -S ldap -K clearance=Public default@


As part of the policy, labels should be assigned to ZFS filesystem objects. Prior to setting labels, the multilevel property must be enabled on new or existing filesystems. For example, the following three steps will restrict access to the audit trail to processes with the Admin_High clearance.


     # zfs set multilevel=on rpool/VARSHARE

     # setlabel Admin_High /var/audit

     # audit -n


The following examples demonstrate how access to labeled data can be managed and monitored. First, to reduce the auditing overhead, the audit policy is adjusted to record all read access to labeled files, while ignoring read access to unlabeled files.


     # auditconfig -setpolicy +labeled_only

     # auditconfig -setflags fr,fw,fm,fd,ex,sstore

     user default audit flags = sstore,fr,fw,fm,fd,ex(0x28003902b,0x28003902b)


Using the compliance labels discussed in a previous blog, we lower root's current process clearance to the highest label in that encodings file so that root's audit records will include its clearance.


     # plabel "Confidential Highly Restricted" $$


Then we create two labeled filesystems whose access is only restricted by process clearance.


     # zfs create -o multilevel=on rpool/export/payments

     # setlabel "Confidential Payment Data" /export/payments


     # zfs create -o multilevel=on rpool/export/patients

     # setlabel "Confidential Health Records" /export/patients


     # chmod 777 /export/payments /export/patients


Next we create accounts for bob and alice as discussed previously:


     # useradm add -PK clearance="Confidential Payment Data" bob

     New Password->

     Confirm Password->

     Password Accepted


     # useradm add -PK clearance="Confidential Health Records" alice

     New Password->

     Confirm Password->

     Password Accepted


As bob, we create a file in /export/payments that is automatically labeled:


     bob$ touch /export/payments/foo

     bob$ getlabel !$

     /export/payments/foo: Confidential Payment Data


As alice, we create a file in /export/patients that is automatically labeled:


     alice$ touch /export/patients/bar

     alice$ getlabel !$

     /export/patients/bar: Confidential Health Records


Then alice tries to list the payments directory for which she is not cleared:


     alice$ ls /export/payments

     Permission denied


Finally, we can get a report of the entire sequence using a script which extracts the labeled records from the audit trail and reformats the results into an html file. This script must be executed with an Admin_High clearance since that is now the label of the audit trail.


     # plabel


     # /usr/demo/tsol/auditfiles.ksh auditlog.html


The tabular results are shown below. Note that only label-relevant events are shown, and that the process IDs for each event are hyperlinked to their corresponding commands. Reports like this are useful for accountability and compliance.



Oracle Solaris Audit Trail
Access Events Affecting Labeled Files
Date/TimePIDReal UserEffective UserEventPathnameData Label(s)Error Value
2018-02-07 16:34:37.371-08:0010378rootrootrelabel file/export/paymentsADMIN_LOW
Confidential Payment Data
2018-02-07 16:34:45.359-08:0010381rootrootrelabel file/export/patientsADMIN_LOW
Confidential Health Records
2018-02-07 16:34:55.219-08:0010382rootrootchmod(2)/export/paymentsConfidential Payment Data
2018-02-07 16:34:55.219-08:0010382rootrootchmod(2)/export/patientsConfidential Health Records
2018-02-07 16:37:25.426-08:0010461bobbobopen(2) - write,creat,trunc/export/payments/fooConfidential Payment Data
2018-02-07 16:38:36.930-08:0010489alicealiceopen(2) - write,creat,trunc/export/patients/barConfidential Health Records
2018-02-07 16:39:12.874-08:0010491alicealiceopen(2) - read/export/paymentsConfidential Payment Data
failure: Permission denied

Execution Events Affecting Labeled Files
Date/TimePIDAudit UserClearanceEventCommand# of FilesError Value
2018-02-07 16:34:37.369-08:0010378gfadenConfidential Highly Restrictedexecve(2)/usr/bin/setlabel Confidential Payment Data /export/payments  1success
2018-02-07 16:34:45.357-08:0010381gfadenConfidential Highly Restrictedexecve(2)/usr/bin/setlabel Confidential Health Records /export/patients  1success
2018-02-07 16:34:55.217-08:0010382gfadenConfidential Highly Restrictedexecve(2)/usr/bin/chmod 777 /export/payments /export/patients  2success
2018-02-07 16:37:25.424-08:0010461bobConfidential Payment Dataexecve(2)/usr/bin/touch /export/payments/foo  1success
2018-02-07 16:38:36.927-08:0010489aliceConfidential Health Recordsexecve(2)/usr/bin/touch /export/patients/bar  1success
2018-02-07 16:39:12.871-08:0010491aliceConfidential Health Recordsexecve(2)/usr/bin/ls /export/payments  1success