Our native POSIX security mechanisms are file-centric: they treat
permissions to be file properties. But consider the following
security policies:
processes running the /usr/sbin/httpd binary
and their child processes can:
open TCP port 80 and accept connections
read files matching /lib/lib*.so and /usr/lib/lib*.so
read files in the /home/httpd directory
create, read, and write in the /var/log/httpd directory
and that is all.
processes running /usr/lib/netscape/netscape-communicator
and their children can:
connect to other machines' ports 20, 21, 25, and 80
connect to my machine on port 53
read files matching /lib/lib*.so, /usr/lib/lib*.so,
and /usr/X11R6/lib/lib*.so
read files in the /usr/lib/netscape directory
create, read, and write in my ~/.netscape
create, read, and write in my ~/downloads
and that is all.
The attraction of defining and enforcing such policies is obvious.
Here our system no longer depends on the integrity of the Apache
binary, nor is our account vulnerable to a flaw somewhere in 13MB of
Netscape Communicator code. If Apache is compromised or Netscape
ingests a disagreeable Java applet, only a denial of service can be
achieved - by filling the file systems Netscape can write files to, or
by altering Apache to serve obscene pages.
Neither traditional users and groups, nor even the long-awaited ACLs,
can really enforce the above policies. Granted, daemons like Apache
can be given their own accounts; groups could be created for each set
of libraries, and daemons and applications run through wrappers which
make them members of those groups; we could make Communicator set-UID
`nobody', set-GID `netscape', and users could chgid(1) the files and
directories they wanted Netscape to see. But such machinations would
not avoid the most significant detractions of the current security
mechanisms:
* No central policy control
Security policy enforcement depends on tens of thousands of
owner, group, and ACL settings across entire file systems.
Merely implementing the policy would involve something like
doing a find(1) on the entire directory tree, changing
attributes as it went. The statement of policy would be
divorced from its implementation, and a modification of the
policy would require another recursive installation scan.
* Difficult policy maintenance
Of course files are created, destroyed, and move around on
typical multiuser systems. This has the potential to quickly
erode policy enforcement based on file attributes. The policy
must be periodically reinstalled (again through recursive
permission checks), and we may not be able to guarantee
continuous enforcement - thus making the policy a slipshod
deterrent rather than offering true security.
* Lack of auditing capability
If Apache or Netscape attempt to violate their security
policies, we will want to be notified! But if the policies
are implemented with user/group or ACL permissions, then
access will simply be denied without any record that the
application behaved erroneously.
Of course, we will want the ability to tell the system to
ignore certain infractions once we figure out they are benign.
But first-time violations should always be of interest since
they may indicate that the program has been compromised.
Of course, you may find my sample policies unreasonable. You could
object to protecting files based on their location and name: if the
information in a file is worth protecting, then aren't traditional
permissions - that stay with a file through moves and renaming - quite
important after all? And my policies may not really describe how
Apahce and Netscape behave anyway. ... But such objections would miss
my point: that there exist quite reasonable policies that cannot be
expressed under Linux. The purpose of the Apace/Netscape example was
to suggest the sort of controls that might enjoy widespread use by
normal Linux users like us if they were available.
A *real* security policy rule used by a government or corporate entity
would look more like:
A top-secret process can read files labelled unclassified,
classified, secret, or top-secret.
Once a process reads from a secure file, it is automatically
disabled from writing to any lower-class files for the rest of
its execution.
A process that has read from a secure file cannot send data to
another process with a lower level of classification.
Note the last two rules in particular: they are extremely important
for guaranteeing that automated processes do not make classified
material available at lower classifications; they require dynamic
control over process and file permissions; and we cannot even come
close to specifying them under Linux today!
Of course I am not suggesting that Linux needs secret and top-secret
files; rather, there needs to be some efficient and uniform mechanism
through which organizations that need this kind of policy, or any
other kind of policy, can add their policy logic to Linux without
making a mess of things.
I have seen projects underway both in the United States and abroad to
enable more flexible policies under Linux, among them:
http://www.rsbac.de/rsbac/
http://www.cs.utah.edu/flux/fluke/html/linux.html
Since these abilities are crucial to many large users of operating
systems, it will benefit the Linux operating system for the kernel
community to go ahead and thrash out the best and most flexible way
for such extensions to be incorporated.
-- Brandon Craig Rhodes http://www.rhodesmill.org/brandon Georgia Tech Information Security Center brandon@rhodesmill.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/