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
# useradm add -PK clearance="Confidential Health Records" alice
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
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.
# /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.
|Date/Time||PID||Real User||Effective User||Event||Pathname||Data Label(s)||Error Value|
|2018-02-07 16:34:37.371-08:00||10378||root||root||relabel file||/export/payments||ADMIN_LOW|
Confidential Payment Data
|2018-02-07 16:34:45.359-08:00||10381||root||root||relabel file||/export/patients||ADMIN_LOW|
Confidential Health Records
|2018-02-07 16:34:55.219-08:00||10382||root||root||chmod(2)||/export/payments||Confidential Payment Data||success|
|2018-02-07 16:34:55.219-08:00||10382||root||root||chmod(2)||/export/patients||Confidential Health Records||success|
|2018-02-07 16:37:25.426-08:00||10461||bob||bob||open(2) - write,creat,trunc||/export/payments/foo||Confidential Payment Data||success|
|2018-02-07 16:38:36.930-08:00||10489||alice||alice||open(2) - write,creat,trunc||/export/patients/bar||Confidential Health Records||success|
|2018-02-07 16:39:12.874-08:00||10491||alice||alice||open(2) - read||/export/payments||Confidential Payment Data||failure: Permission denied|
|Date/Time||PID||Audit User||Clearance||Event||Command||# of Files||Error Value|
|2018-02-07 16:34:37.369-08:00||10378||gfaden||Confidential Highly Restricted||execve(2)||/usr/bin/setlabel Confidential Payment Data /export/payments||1||success|
|2018-02-07 16:34:45.357-08:00||10381||gfaden||Confidential Highly Restricted||execve(2)||/usr/bin/setlabel Confidential Health Records /export/patients||1||success|
|2018-02-07 16:34:55.217-08:00||10382||gfaden||Confidential Highly Restricted||execve(2)||/usr/bin/chmod 777 /export/payments /export/patients||2||success|
|2018-02-07 16:37:25.424-08:00||10461||bob||Confidential Payment Data||execve(2)||/usr/bin/touch /export/payments/foo||1||success|
|2018-02-07 16:38:36.927-08:00||10489||alice||Confidential Health Records||execve(2)||/usr/bin/touch /export/patients/bar||1||success|
|2018-02-07 16:39:12.871-08:00||10491||alice||Confidential Health Records||execve(2)||/usr/bin/ls /export/payments||1||success|