On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
For starters, we would appear to already have a very capable
labelling system which can do *all* of this, completely and without
exceptions, in a much more flexible way. Admittedly it's more
complicated, but one does have to have complexity in order to handle
everything from CD burning in X, to Apache daemons, to only allowing
Top-Secret-level logins over the IPsec tunnel on the Top Secret
network, etc. Do you see any particular reason this couldn't be
implemented as a very *very* simplified SELinux wrapper? For
example, this set of rules basically defines your described "read-vs-
write-vs-exec" policy as best I can figure out:
user uu roles rr;
role rr types { star floor hat huh };
define(`r',`
allow $1 $2:file { read getattr };
allow $1 $2:socket { read getattr getopt recvfrom recv_msg };
allow $1 $2:ipc { getattr read associate unix_read };
## List of more "read" allow rules for different types of objects... ##
')
define(`w',`
allow $1 $2:file { ioctl write create setattr lock append unlink link
rename swapon quotaon mounton };
allow $1 $2:socket { ioctl write create setattr lock append bind
connect listen accept setopt shutdown sendto send_msg name_bind };
allow $1 $2:ipc { create destroy setattr write unix_write };
## List of more "write" allow rules for different types of objects... ##
')
define(`x',`
allow $1 $2:file { execute };
allow $1 $2:dir { search };
## List of more "execute" allow rules for different types of
objects... ##
')
And now to describe these rules:
## These are calls to the above macros which plug in the necessary
arguments
r(hat, {*})
x(hat, {*})
r(~{star}, floor)
x(~{star}, floor)
r(~{star}, star)
w(~{star}, star)
x(~{star}, star)
r(~{star}, self)
w(~{star}, self)
x(~{star}, self)
## Include your "loaded rule set" here ##
Maybe worth a little utility to convert a file full of
"subject,object,access" triples to an appropriate SELinux policy
would be appropriate?
SELinux can do this as well. It even includes support for
conditional policy:
bool foo_can_do_logging true;
if (foo_can_do_logging) {
allow foo_t foo_log_t:file { create read getattr append };
}
The SELinux tools also have support for policy modules, so you can
extend the policy without modifying the base system. Plus the stuff
has been very heavily tested and even supports X (as soon as the beta
X code gets improved and merged in the upstream X.org codebase).
The big problem here is the duplication. Say you have a locked-down
Apache configuration and you want to run 2 apache processes, one at
Secret and one at Top-Secret. Under your model you have to copy-
paste the policy and make sure to apply fixes/changes to both
places. Under SELinux, you can have processes as:
system_u:system_r:httpd_t:Secret:UFOSightings,AlienDissection
system_u:system_r:httpd_t:TopSecret:NukeTests
They can only read and write objects for which multiple conditions
are true: First, the object must match the Bell-Padula model with
respect to the sensitivities and categories
("Secret:UFOSightings,AlienDissection", etc) *and* it must also be
objects that httpd_t is allowed to read/write. That also includes
network traffic, and your firewall can appropriately label data over
a given IPsec link as one classification level while data over the
raw network is labeled as another. Oh, and you can tweak the MLS
constraints of the Bell-Padula model as necessary too.
This is exactly what my company does, but the ability to restrict
*exactly* what mechanisms are used is important. You restrict
against file-system access implicitly, whereas SELinux does it
explicitly:
allow foo_t foo_sock_t:socket { .... };
versus:
allow foo_t foo_log_t:file { ... };
With SELinux you can also allow your program to create files labelled
as "log files" in one directory in one type and "transfer files" in
another directory in a completely different type.
I'm proud to say that the software of the company I work for does not
need any extra privilege at all (aside from binding to ports <1024)
to run under SELinux with strict MLS. Under Trusted Solaris and such
we needed all sorts of dirty privilege hacks to relabel the files
consistently, but under SELinux the policy does all the relabeling
for us, we don't need to do a thing.
Cheers,
Kyle Moffett
-
