Documentation.
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Kylene Hall <[email protected]>
---
Documentation/slim.txt | 69 +++++++++++++++++++++++++++++++++++++++
1 files changed, 69 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-17 12:38:24.000000000 -0700
@@ -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!
> Documentation.
No, I still do not understand how this is supposed to work.
> +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
--
(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:
> Hi!
>
> > Documentation.
>
> No, I still do not understand how this is supposed to work.
Yes, the documentation definitely needs more work.
> > +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"?
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
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 | 69 ++++++++++++++++++++++++++++++++++++++
> + 1 files changed, 69 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-17
> 12:38:24.000000000 -0700 @@ -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
Drop "now".
> 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. +
Drop "now".
> +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
occurred
> 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/ ?
> +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?
> +As mentioned earlier, cupsd and notes are applications which are
Notes (as used earlier)
> +always run directly in untrusted mode, regardless of the level of
> +the invoking process.
---
~Randy
Hi!
> > > +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"?
>
> 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.
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoting Pavel Machek ([email protected]):
> Hi!
>
> > > > +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"?
> >
> > 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.
>
> 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!
> > > 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 ?
>
> 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?
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, 2006-08-24 at 15:11 +0200, Pavel Machek wrote:
> 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.
> 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!
> > 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.
> 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed 2006-08-30 16:11:42, Crispin Cowan wrote:
> Pavel Machek wrote:
> >> 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.
> >>
> > 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, 2006-08-31 at 01:46 +0200, Pavel Machek wrote:
> 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
(http://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