Documentation.
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Kylene Hall <[email protected]>
---
Documentation/slim.txt | 136 +++++++++++++++++++++++++++++++++++++++
1 files changed, 136 insertions(+)
--- linux-2.6.18/Documentation/slim.txt 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.6.18-rc4/Documentation/slim.txt 2006-08-22 14:48:12.000000000 -0700
@@ -0,0 +1,136 @@
+Simple Linux Integrity Model (SLIM)
+
+SLIM is an LSM module which provides an enhanced low water-mark
+integrity and high water-mark secrecy mandatory access control
+model. It also is a consumer of the new integrity subsystem,
+using the integrity_verify_data(), integrity_verify_metadata(),
+and integrity_measure() calls to base mandatory access control
+decisions on the verified integrity status of the involved objects.
+SLIM is an extension of several prior models, including Biba[1],
+Lowmac[2], and Caernarvon[3], which provide excellent background.
+
+SLIM's specific model is:
+
+ All objects (files) are labeled with extended attributes to indicate:
+ Integrity Access Class (IAC)
+ (one of SYSTEM, USER, UNTRUSTED)
+ Secrecy Access Class (SAC)
+ (one of PUBLIC, USER, USER_SENSITIVE,
+ SYSTEM_SENSITIVE)
+
+ All processes inherit from their parents:
+ Integrity Read Access Class (IRAC)
+ Integrity Write/Execute Access Class (IWXAC)
+ Secrecy Write Access Class (SWAC)
+ Secrecy Read/Execute Access Class (SRXAC)
+
+ SLIM enforces the following Mandatory Access Control Rules:
+ Read:
+ IRAC(process) <= IAC(object)
+ SRXAC(process) >= SAC(object)
+ Write:
+ IWXAC(process) >= IAC(object)
+ SWAC(process) <= SAC(process)
+ Execute:
+ IWXAC(process) <= IAC(object)
+ SRXAC(process) >= SAC(object)
+
+In the low water-mark model, rather than blocking attempted
+reads of lower integrity objects, the reading process is demoted
+to the integrity level of the object, so that the read is allowed.
+In a Linux client, this provides a much more usable environment,
+in which applications run more transparently, while being demoted
+as needed to protect the integrity of the system.
+
+When the process is demoted, it may have objects open for write
+of now higher integrity level, and these objects have to have their
+write access revoked. This revocation of write privilege must
+occur for normal and mmap'ed file writes. Similarly, when reading
+an object of higher secrecy, the process is promoted to the higher
+secrecy level, and write access to now lower secrecy objects is revoked.
+
+SLIM performs a generic revocation operation, including revoking
+mmap and shared memory access. Note that during demotion or promotion
+of a process, SLIM needs only revoke write access to files with higher
+integrity, or lower secrecy.
+
+SLIM inherently deals with dynamic task labels, which is a feature
+not currently available in selinux. While it might be possible to
+add support for this to selinux, it would not appear to be simple,
+and it is not clear if the added complexity would be desirable
+just to support this one model.
+
+Comments on the model:
+
+Some of the prior comments questioned the usefulness of the
+low water-mark model itself. Two major questions raised concerned
+a potential progression of the entire system to a fully demoted
+state, and the security issues surrounding the guard processes.
+
+In normal operation, the system seems to stabilize with a roughly
+equal mixture of SYSTEM, USER, and UNTRUSTED processes. Most
+applications seem to do a fixed set of operations in a fixed domain,
+and stabilize at their appropriate level. Some applications, like
+firefox and evolution, which inherently deal with untrusted data,
+immediately go to the UNTRUSTED level, which is where they belong.
+In a couple of cases, including cups and Notes, the applications
+did not handle their demotions well, as they occurred well into their
+startup. For these applications, we simply force them to start up
+as UNTRUSTED, so demotion is not an issue. The one application type
+that does tend to get demoted over time is shells, such as bash.
+These are not problems, as new ones can be created with the
+windowing system, or with su, as needed. To help with the associated
+user interface issue, the user space package[4] README shows how to
+display the SLIM level in window titles, so it is always clear at
+what level the process is currently running.
+
+As for the issue of guard processes, SLIM defines three types of
+guard processes: Unlimited Guards, Limited Guards, and Untrusted
+Guards. Unlimited Guards are the most security sensitive, as they
+allow less trusted process to acquire a higher level of trust.
+On my current system there are two unlimited guards, passwd and
+userhelper. These two applications inherently have to be trusted
+this way regardless of the MAC model used. In SLIM, the policy
+clearly and simply labels them as having this level of trust.
+
+Limited Guards are programs which cannot give away higher
+trust, but which can keep their existing level despite reading
+less trusted data. On my system I have seven limited guards:
+yum, which is trusted to verify the signature on an (untrusted)
+downloaded RPM file, and to install it, login and sshd, which read
+untrusted user supplied login data, for authentication, dhclient
+which reads untrusted network data, and updates they system
+file /etc/resolv.conf, dbus-daemon, which accepts data from
+potentially untrusted processes, Xorg, which has to accept data
+from all Xwindow clients, regardless of level, and postfix which
+delivers untrusted mail. Again, these applications inherently
+must cross trust levels, and SLIM properly identifies them.
+
+As mentioned earlier, cupsd and Notes are applications which are
+always run directly in untrusted mode, regardless of the level of
+the invoking process.
+
+The bottom line is that SLIM guard programs inherently do security
+sensitive things, and have to be trusted. There are only a small
+number of them, and they are clearly identified by their labels.
+
+Userspace Tools:
+
+Papers and slides on SLIM, along with source code for the needed
+userspace tools, and installation instructions are available at:
+
+[4] http://www.research.ibm.com/gsal/tcpa
+
+References:
+
+[1 Biba]: K. J. Biba. “Integrity Considerations for Secure Computer Systems”
+Technical Report ESD-TR-76-372, USAF Electronic Systems Division, Hanscom Air
+Force Base, Bedford, Massachusetts, April 1977.
+
+[2 Lomac]: T. Fraser, "LOMAC: Low Water-Mark Integrity Protection for COTS
+Environments," Proceedings of the 2000 IEEE Symposium on Security and
+Privacy, Oakland, California, USA, 2000.
+
+[3 Caernarvon]: P. Karger, V. Austel, and D. Toll. “Using a Mandatory Secrecy
+and Integrity Policy on Smart Cards and Mobile Devices” EUROSMART Security
+Conference. 13-15 June 2000, Marseilles, France p. 134-148.
Hi!
> Documentation.
Thanks for it.
> +file /etc/resolv.conf, dbus-daemon, which accepts data from
> +potentially untrusted processes, Xorg, which has to accept data
> +from all Xwindow clients, regardless of level, and postfix which
> +delivers untrusted mail. Again, these applications inherently
> +must cross trust levels, and SLIM properly identifies them.
How is this supposed to work. Xorg was not designed to be security
barrier. So... your exploited evolution, but evolution is now
UNTRUSTED, so you can't do anything interesting... right?
Wrong. evolution can ask Xorg to simulate "rm -rf /" keypresses, and
send them to your shell in another window...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 2006-09-19 at 21:16 +0200, Pavel Machek wrote:
> Hi!
>
> > Documentation.
>
> Thanks for it.
>
> > +file /etc/resolv.conf, dbus-daemon, which accepts data from
> > +potentially untrusted processes, Xorg, which has to accept data
> > +from all Xwindow clients, regardless of level, and postfix which
> > +delivers untrusted mail. Again, these applications inherently
> > +must cross trust levels, and SLIM properly identifies them.
>
> How is this supposed to work. Xorg was not designed to be security
> barrier. So... your exploited evolution, but evolution is now
> UNTRUSTED, so you can't do anything interesting... right?
>
> Wrong. evolution can ask Xorg to simulate "rm -rf /" keypresses, and
> send them to your shell in another window...
On one hand, I thought that allowSendEvents and editresBlock
specifically blocked synthetic keypresses from shell windows like
xterm. On the other hand, I do agree that the X server
can provide dangerous communications between levels, and needs to
be fixed in some way. (dbus and Orbit have similar problems.)
Slim and selinux can control X access through socket labels, so there
are several options, based on your choice of policy:
- you can run in "single level at a time" mode, in which all processes
have to be at the same level, such as untrusted. This is safe, but
pretty unusable, as you have to have separate logins for each level.
- you can make the server a guard process, so that it can accept
connections from applications at any level. This is not generally
safe as you point out, but is transparent to the user, and works
for now.
- you can add the necessary MAC checks into the X server, so that
it enforces the local policy. This is safe, and convenient, but
requires some patches to the server. NSA has started this work
as part of LSM/selinux. See
http://www.nsa.gov/selinux/papers/x11/t1.html
The documentation should have explained we are doing the second,
temporarily, until the X (and dbus, and Orbit) hooks are available.
dave