SLIM: documentation
RFC PATCH 8/8 SLIM: documentation
Documentation.
---Documentation/slim.txt | 69 +++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+)
Documentation/slim.txt +69 -0
@@ -0,0 +1,69 @@ +SLIM is an LSM module which provides an enhanced low water-mark +integrity and high water-mark secrecy mandatory access control +model. + +SLIM now 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. Read and execute permissions are blocked +as needed, not revoked. SLIM hopefully uses d_instantiate correctly now. + +SLIM inherently deals with dynamic 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 occured 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 +that does tend to get demoted over time are 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 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.
Hi!
Quoted 1 line
Documentation.
No, I still do not understand how this is supposed to work.
Documentation/slim.txt line 25
Quoted 2 lines
Documentation/slim.txt +2
-0+In normal operation, the system seems to stabilize with a roughly +equal mixture of SYSTEM, USER, and UNTRUSTED processes. Most
So you split processes to three classes (why three?), and automagically move them between classes based on some rules? (What rules?)
Like if I'm UNTRUSTED process, I may not read ~/.ssh/private_key? So files get this kind of labels, too? And it is "mozilla starts as a USER, but when it accesses first web page it becomes UNTRUSTED"?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote on 08/17/2006 07:02:14 PM:
Quoted 5 lines
Hi!
Quoted 1 line
Documentation.
No, I still do not understand how this is supposed to work.
Yes, the documentation definitely needs more work.
Quoted 10 lines
Documentation/slim.txt line 25
Quoted 2 lines
Documentation/slim.txt +2
-0+In normal operation, the system seems to stabilize with a roughly +equal mixture of SYSTEM, USER, and UNTRUSTED processes. MostSo you split processes to three classes (why three?), and automagically move them between classes based on some rules? (What rules?)
Like if I'm UNTRUSTED process, I may not read ~/.ssh/private_key? So files get this kind of labels, too? And it is "mozilla starts as a USER, but when it accesses first web page it becomes UNTRUSTED"?
Processes are not moved from one integrity level to another, but are demoted when they read from a lower integrity level object. By definition sockets, are defined as UNTRUSTED, so reading from a socket demotes the process to UNTRUSTED. (Secrecy is a separate attribute.) In the Mozilla example, /usr/bin/mozilla is defined as SYSTEM, preventing any process with lesser integrity from modifying it. 'level -s' displays the level of the current process or of a given file. For example,
[zohar@L3X098X ~]$ level -s /usr/bin/mozilla/usr/bin/mozilla
security.slim.level: SYSTEM PUBLIC
Both mozilla and firefox-bin are defined as SYSTEM, as soon as the firefox-bin process opens a socket, the process is demoted to UNTRUSTED.
I hope this answered some of your questions. We're working on more comprehensive documentation, which we'll post with the next release.
Mimi Zohar
Hi!
Quoted 24 lines
Quoted 10 lines
Documentation/slim.txt line 25
Quoted 2 lines
Documentation/slim.txt +2
-0+In normal operation, the system seems to stabilize with a roughly +equal mixture of SYSTEM, USER, and UNTRUSTED processes. MostSo you split processes to three classes (why three?), and automagically move them between classes based on some rules? (What rules?)
Like if I'm UNTRUSTED process, I may not read ~/.ssh/private_key? So files get this kind of labels, too? And it is "mozilla starts as a USER, but when it accesses first web page it becomes UNTRUSTED"?
Processes are not moved from one integrity level to another, but are demoted when they read from a lower integrity level object. By definition sockets, are defined as UNTRUSTED, so reading from a socket demotes the process to UNTRUSTED. (Secrecy is a separate attribute.) In the Mozilla example,
/usr/bin/mozillais defined as SYSTEM, preventing any process with lesser integrity from modifying it. 'level -s' displays the level of the current process or of a given file. For example,[zohar@L3X098X ~]$ level -s
/usr/bin/mozilla/usr/bin/mozilla
security.slim.level: SYSTEM PUBLIC
Quoted 7 lines
Both mozilla and firefox-bin are defined as SYSTEM, as soon as the firefox-bin process opens a socket, the process is demoted to UNTRUSTED.
I hope this answered some of your questions. We're working on more comprehensive documentation, which we'll post with the next release.
Do you have examples where this security model stops an attack?
Both my mail client and my mozilla will be UNTRUSTED (because of network connections, right?) -- so mozilla exploit will still be able t osee my mail? Not good. And ssh connects to the net, too, so it will not even protect my ~/.ssh/private_key ?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 34 lines · Pavel Machek
Hi!
Quoted 24 lines
Quoted 10 lines
Documentation/slim.txt line 25
Quoted 2 lines
Documentation/slim.txt +2
-0+In normal operation, the system seems to stabilize with a roughly +equal mixture of SYSTEM, USER, and UNTRUSTED processes. MostSo you split processes to three classes (why three?), and automagically move them between classes based on some rules? (What rules?)
Like if I'm UNTRUSTED process, I may not read ~/.ssh/private_key? So files get this kind of labels, too? And it is "mozilla starts as a USER, but when it accesses first web page it becomes UNTRUSTED"?
Processes are not moved from one integrity level to another, but are demoted when they read from a lower integrity level object. By definition sockets, are defined as UNTRUSTED, so reading from a socket demotes the process to UNTRUSTED. (Secrecy is a separate attribute.) In the Mozilla example,
/usr/bin/mozillais defined as SYSTEM, preventing any process with lesser integrity from modifying it. 'level -s' displays the level of the current process or of a given file. For example,[zohar@L3X098X ~]$ level -s
/usr/bin/mozilla/usr/bin/mozilla
security.slim.level: SYSTEM PUBLICQuoted 7 lines
Both mozilla and firefox-bin are defined as SYSTEM, as soon as the firefox-bin process opens a socket, the process is demoted to UNTRUSTED.
I hope this answered some of your questions. We're working on more comprehensive documentation, which we'll post with the next release.
Quoted 6 lines
Do you have examples where this security model stops an attack?
Both my mail client and my mozilla will be UNTRUSTED (because of network connections, right?) -- so mozilla exploit will still be able t osee my mail? Not good. And ssh connects to the net, too, so it will not even protect my ~/.ssh/private_key ?
I believe it will read your private_key while at a higher level, then will be demoted when it access the net.
Is that right?
-serge
Hi!
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
I hope this answered some of your questions. We're working on more comprehensive documentation, which we'll post with the next release.
Do you have examples where this security model stops an attack?
Both my mail client and my mozilla will be UNTRUSTED (because of network connections, right?) -- so mozilla exploit will still be able t osee my mail? Not good. And ssh connects to the net, too, so it will not even protect my ~/.ssh/private_key ?
Quoted 4 lines
I believe it will read your
private_keywhile at a higher level, then will be demoted when it access the net.Is that right?
Hmm.. you are the security expert here :-). But it still needs private key while accessing the net.. so even if it does read from ~/.ssh/private_key, first, what stops mozilla from waiting for ssh to start talking on the network, and then read the key from ssh's memory?
Do you have examples where this security model stops an attack?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 5 lines · Pavel Machek
Hmm.. you are the security expert here :-). But it still needs private key while accessing the net.. so even if it does read from ~/.ssh/private_key, first, what stops mozilla from waiting for ssh to start talking on the network, and then read the key from ssh's memory?
I think the only good way to protect a private key is not to let the application see it at all, either by pushing the signature operation into a wrapper, or into the kernel key ring, or even better, into a hardware token, such as a TPM. Secrecy is really hard. There are classes of software covert channels which have been proven to be undetectable, so if you let software (particularly a browser) see your private key, it may well not be your key any more.
Quoted 2 lines
Do you have examples where this security model stops an attack?
Pavel
The main goal of this model is to stop some of the most common real attacks on client machines, in particular the downloading and execution of malicious code, through a browser or email attachment. By making the email and browser applications run in an untrusted level, we can keep them from modifying user or system level files, and any files they create are labeled untrusted so that even system level processes can't accidentally invoke them at a trusted level. Also, we can control what applications are allowed to install packages, so that only signed packages (which are initially labeled as untrusted, since they came in over the net), are promoted and installed by the guard (e.g. rpm).
In one demo I like to run, I deliberately download a trojaned game, and run it both as a user and even as root/system. Since the game is labeled untrusted, it is invoked untrusted regardless of who runs it.
dave
Hi!
Quoted 5 lines
Quoted 1 line
Do you have examples where this security model stops an attack?
The main goal of this model is to stop some of the most common real attacks on client machines, in particular the downloading and execution of malicious code, through a browser or email attachment. By making
Well, I have seen those attacks on windows, but never on Linux. x bit seems to help here.
Quoted 3 lines
In one demo I like to run, I deliberately download a trojaned game, and run it both as a user and even as root/system. Since the game is labeled untrusted, it is invoked untrusted regardless of who runs it.
That's okay, but that game can still get your browsing habits, steal your credit card numbers, and probably get your ssh passwords.
...so it may not be so good demo after all...?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Crispin Cowan
Quoted 7 lines · Pavel Machek
Quoted 7 lines
The Windows problem is foolish users who download something shiny, such as enhanced emoticons or a keen password caching mechanism (e.g. Gator) or games (as in David's example) which turns out to be spyware. Under David's demo, you can download and run the spyware, but it doesn't get access to the critical system files that make spyware so difficult to remove.
Quoted 7 lines
Quoted 3 lines
Well, it gets access to my browser, which contains most of the stuff spyware is interested in, anyway.
It gets access to the data, but doesn't get to insert itself into important system files. An important attribute of spyware is that it is hard to remove, and this makes the "hard to remove" property much harder to achieve.
As I wrote in my previous email, yes, it makes it easier to remove.
Thinking about it, it may also make it hard to survive login/logout; which is actually good point.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
A message that is not in the archive (sent off-list or not yet received): OF47A7AF49.EC4403C3-ON852571DA.00818B73-852571DA.006C6E56@us.ibm.com
Hi!
Quoted 10 lines
Quoted 5 lines
But my ssh data can't be classified higher, because ssh interacts with network. Ouch.
You are right that this will make recovery from spyware attack easier, but...
Here you are raising concerns over secrecy, which is a totally separate issue from integrity. In order to protect the secrecy of files, you would distinguish PUBLIC files from USER-SENSITIVE/SYSTEM-SENSITIVE files.
So... will I be able to set ~/.ssh/private_key to USER-SENSITIVE and still use ssh to log in to remove machines? Will trojans coming from network be able to read that file?
I do not think see how that can work... because ssh accesses network, and needs to know my private_key.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 7 lines · Pavel Machek
So... will I be able to set ~/.ssh/private_key to USER-SENSITIVE and still use ssh to log in to remove machines? Will trojans coming from network be able to read that file?
I do not think see how that can work... because ssh accesses network, and needs to know my
private_key.
Pavel
In an earlier post, I briefly mentioned using restructuring or a TPM for the ssh case, but I didn't explain it well at all. I'll try to do better:
You are absolutely correct that with the existing ssh implementation, simply labeling an ssh private key as USER-SENSITIVE would be safe, but would prevent ssh from writing to the PUBLIC network, which would cause it to fail.
You could then make the ssh executable a secrecy guard, so that it could read the private keys, and still write to the PUBLIC network, but then, if the ssh process is compromised, the keys could be leaked. This is still much better than discretionary access control, as it prevents all other programs which are not explicitly labeled as a secrecy guard from giving the keys away, but by making ssh a guard, you are explicitly allowing it to access sensitive data and still talk on a public connection. This is the inherent behavior of any mandatory access control system; you label things and then either allow access, or not.
One approach is then to minimize the amount of code you have to trust, by restructuring the application. In the case of ssh, you could separate out the code that uses the private key to do the actual public key decryption into a small separate program, which has to be trusted, and keep the rest of ssh, which handles the bulk of the untrusted data, in a large untrusted program. Postfix (www.postfix.org) is an excellent example of restructuring a large monolithic program like sendmail, into small isolated components, for better security and robustness, and this application structuring complements MAC systems by reducing the trust granularities.
A better approach is to not let _any_ software see the private key, by using a hardware device, such as a TPM, to create the private key in the first place, and to do the actual public key operation.
(http://sourceforge.net/projects/trousers/ has open source applications and libraries for TPM based openssl and pkcs11 crypto.) Then, even if ssh is compromised, it can't give the private key away.
The bottom line is that mandatory access control helps significantly by preventing any other application from leaking the ssh keys, and by forcing you to designate ssh as trusted not to leak the keys. But once you designate ssh as trusted, then it is up to other security techniques, such as structuring, and hardware to protect the keys further.
dave
Quoted 1 line · On Thu, 17 Aug 2006 12:53:39 -0700 Kylene Jo Hall wrote:
Documentation.
Here are a few comments for you.
I'll look for the updates as well.
Documentation/slim.txt
Quoted 12 lines
Documentation/slim.txt| 69 ++++++++++++++++++++++++++++++++++++++
+ 1 files changed, 69 insertions(+)---
linux-2.6.18/Documentation/slim.txt1969-12-31
16:00:00.000000000 -0800 +++linux-2.6.18-rc4/Documentation/slim.txt2006-08-17
12:38:24.000000000 -0700 @@ -0,0 +1,69 @@Documentation/slim.txt +5
-0+SLIM is an LSM module which provides an enhanced low water-mark +integrity and high water-mark secrecy mandatory access control +model. + +SLIM now performs a generic revocation operation, including
Drop "now".
Quoted 5 lines
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. Read and execute permissions are blocked +as needed, not revoked. SLIM hopefully uses
d_instantiatecorrectly now. +
Drop "now".
Quoted 9 lines
Documentation/slim.txt +3
-0+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 fixeddomain, +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 occured well into their +startup. For these applications, we
occurred
Quoted 3 lines
simply force them to start up +as UNTRUSTED, so demotion is not an issue. The one application +that does tend to get demoted over time are shells, such as bash.
s/application/application area/ or /application type/ ?
Quoted 6 lines
+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 README shows how to +display the SLIM level in window titles, so it is always clear at +what level the process is currently running.
This is confusing to me. What README?
Quoted 1 line
+As mentioned earlier, cupsd and notes are applications which are
Notes (as used earlier)
Documentation/slim.txt line 65
Quoted 2 lines
Documentation/slim.txt +2
-0+always run directly in untrusted mode, regardless of the level of +the invoking process.
---
~Randy