Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Thomas Bleher]

* Olivier Galibert <galibert@xxxxxxxxx> [2006-04-26 18:03]:
> On Wed, Apr 26, 2006 at 08:14:31AM -0400, Stephen Smalley wrote:
> > On Wed, 2006-04-26 at 00:26 +0200, Olivier Galibert wrote:
> > > On Tue, Apr 25, 2006 at 12:29:26PM -0400, Stephen Smalley wrote:
> > > > This generally indicates a problem in policy or the application that
> > > > needs to be fixed.  It doesn't mean that object labeling is itself
> > > > problematic, anymore than the existing owner and mode information in the
> > > > inode is inherently problematic.
> > > 
> > > Default owner and mode are handled by the kernel because otherwise it
> > > would indeed be inherently problematic.  Don't expect normal
> > > applications, editors or xml libraries to change from the normal
> > > open(fname, O_RDWR|O_CREAT|O_TRUNC, 0666).  SELinux is not, and will
> > > not, ever, be their problem.
> > 
> > First, default labeling is also handled by the kernel, as with default
> > owner and mode.  Files will be labeled in accordance with the policy
> > based on the label of the creating process, the label of a related
> > object (parent directory, to support inheritance properties when
> > appropriate), and policy rules.  But this is not always sufficient, any
> > more than default owner and mode is always sufficient for file creation.
> 
> And how do you plan to get correct default label without taking
> paths/names into account but only the parent directory, for these
> files created by the exact same text editor:
> - $HOME/.slrnrc
> - $HOME/.fetchmailrc
> - $HOME/.procmailrc
> - $HOME/todo.txt

How do you get correct mode and ownership? The kernel doesn't handle
that either. If you need something special, you use the tools to set it
(chmod, chgrp, ...). Ditto for SELinux.
Users already have to deal with that: fetchmail will fail to run if
~/.fetchmailrc has more permissions than 0600.

SELinux can make it even easier for you if you want: 
It has a database which stores the default labels for files. You can use
"restorecon $file" to set the default label for any file. You can also
change your editor so it queries this database and sets the right label
when saving a new file.
Fedora also just added restorecond, a small daemon which uses inotify to
watch certain paths and set the right label when the file or directory
is created. Reportedly it works very well, so you can do a
	mkdir public_html; ls -lZd public_html
and already see the right label on the file.

> > Second, the entire point of SELinux is to get MAC into the mainstream,
> > and it is enabled by default in Fedora.  Unless that changes, it should
> > gradually affect a change in the applications to adapt to the presence
> > of SELinux, just as they have gradually adapted to other changes in the
> > kernel.  Such change is always painful, but MAC is necessary as a
> > fundamental building block if we are going to ever have improved
> > security.  And not all applications have to change; many can just use
> > the default behaviors.
> 
> Something will have to tell the system that certain file names/paths
> are a-priori special, whether they exist or not.  And I *mean* file
> names, not objects.  And that won't happen reliably in userspace.

Well, then I don't understand your threat model. When I move files to
another place I certainly don't want the label to change. Imagine Linux
did this on file permissions and suddenly everyone could read your
passwords out of your .fetchmailrc.old which you saved there for backup.

> > Um, perhaps you could be more concrete?  Difficult to have a rational
> > discussion otherwise.  This division of "protecting application
> > behavior" vs. "protecting files" is arbitrary and meaningless.   
> 
> Well, take the example of .procmailrc.  It is a file that is taken
> into account if it exists, but doesn't have to exist.  It is a file
> which can be used to copy all the mail of one user to somewhere else,
> so it is very data-security sensitive.  So this is a file that may or
> may not exist, which should not be created by anybody else than the
> user itself (after all, you're into protecting from root too), and
> needs to be able to be created by a mac-unaware, user-preferred text
> editor and just work.  How do you expect to handle that reliably
> without path-based mechanisms in the kernel?

Users already set modes themselves (see .fetchmailrc, .ssh,
public_html), so I don't see a problem with them calling restorecon
(see above).

> You need path-based mechanisms to at least:
> - prevent/allow some specific names from being created in specific
>   conditions. 

I don't think that fits the Unix model. If you want that you should use
separate directories.
Giving untrusted programs write access to your homedir is a bad idea,
but even if you need to do that, SELinux can protect you. In this
specific example, procmail would simply not be allowed to read files
created by untrusted programs (e.g. your IRC client).

> - give correct default labels to new files
> 
> Object labelling won't help here simply because all of that happens on
> file creation.  And you need path-based mechanisms if you want to have
> any kind of decent problem tolerance.  Because at that point, SELinux
> having prevented me twice to log into my own system on the console
> with two different distributions for similar causes (labels lost), I
> won't trust it for any system I want to be able to access remotely
> with a decent chance of success in case of problems.

Certainly there are things which could be made better - both
documentation and userspace-tools. But I don't think it requires
changing the kernel mechanism.

Thomas

Attachment: signature.asc
Description: Digital signature