From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: util-linux: orphan
Date: Wed, 27 Dec 2006 20:42:43 UTC
Message-ID: <fa.IFUAbDhbYN2wFXSjv83g6uVXgPg@ifi.uio.no>

On Wed, Dec 27, 2006 at 08:18:24PM +0100, Karel Zak wrote:
>  Frankly, it wasn't always easy to use SeLinux in previous FC
>  releases, but there is huge progress and I think it's much better in
>  FC6.

I've never tried SELinux, but at one point there were all sorts of
horror stories that if you enabled SELinux, the moment you installed
any 3rd party software packages, whether it's Oracle or Websphere or
some other commercial application program, the application would break
because of all sorts of SELinux policy violations, and that it
required an SELinux wizard to configure SELinux policy to enable a 3rd
party application to actually work correctly.  Given that I tried
enabling SELinux, witnessed things break spectacularly and with no
hints about how to fix things, I've always had the attitude of "life
is too short to enable SELinux", and so my limited experience is
consistent with all of the horror stories that I've heard.

It sounds like SELinux has gotten better, according to your
description.  Will handle arbitrary 3rd party software without running
wild, or is it still the case that the moment you want anything other
than software that was shipped with the distribution, it's "abandon
all hope, all ye who enter here"?

						- Ted

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change
Date: Wed, 03 Jun 2009 16:48:28 UTC
Message-ID: <fa.bgPYsDCNKbAERs4PRgMD+aI9lXk@ifi.uio.no>

On Wed, 3 Jun 2009, Rik van Riel wrote:
>
> Would anybody paranoid run their system without SELinux?

You make two very fundamental mistakes.

The first is to assume that this is about "paranoid" people. Security is
_not_ about people who care deeply about security. It's about everybody.
Look at viruses and DDoS attacks - the "paranoid" people absolutely depend
on the _non_paranoid people being secure too!

The other mistake is to think that SELinux is sane, or should be the
default. It's a f*cking complex disaster, and makes performance plummet on
some things. I turn it off, and I know lots of other sane people do too.
So the !SElinux case really does need to work.

				Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change
Date: Wed, 03 Jun 2009 17:29:05 UTC
Message-ID: <fa.1jPzkn0cLdinl/MT4P643+SjhnE@ifi.uio.no>

On Wed, 3 Jun 2009, Eric Paris wrote:
>
> I am at least interested in hearing about the 'performance plummet.'

It's perhaps not so much SElinux itself, but the AUDIT support (which it
requires) that is really _very_ noticeable on microbenchmarks.

Last time I ran lmbench on a Fedora kernel it was horrible. Turning off
AUDIT (which also turns off SElinux) fixes it.

It may be crazy distro auditing rules or whatever, but that doesn't change
the basic issue.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Mon, 08 Mar 2010 18:09:50 UTC
Message-ID: <fa.4Suk0rmeb8jXWUMeVT1KxPhttkw@ifi.uio.no>

On Mon, 8 Mar 2010, Alan Cox wrote:
>
> Ingo - just about all the serious security work disagrees with you.
> Pathnames are references to objects and keep changing. What matters is
> the object itself. This is also how Unix has always worked

The thing is, that's simply not the whole truth. It's _part_ of the truth,
but there very much are pathname-based security in Unix too, including
very much traditionally.

Things like "/etc/passwd" really are about the _pathname_, not the inode.
It really is the _path_ that is special, because that is fundamentally the
thing you trust.

You can try to turn that into a content-based security issue by claiming
that it's about the "content of the '/etc' directory", and that is (along
with other tricks) obviously how a a content-based security model has to
work.

But it's not actually _true_ in any deeper sense. You're really just
trying to enforce a pathname-based model using a inode/content based
security hammer.

So that's an example of "if all you have is a hammer, everything looks
like a nail" issue. If all you have is a content/inode-based security, you
have to turn path-names into "directory inode" issues, and it's doable,
but it's really like trying to convince everybody that screws do not exist
because all you have is a hammer.

And when you base your security on inodes, you _do_ have problems with
things like /etc. Exactly because there are many different paths in that
directory, and they actually have _different_ security issues. A program
that is supposed to be able to edit/replace /etc/hosts is _not_ supposed
to be able to edit/replace /etc/passwd.

Notice how it's really fundamentally about the pathname? When you create a
new file and overwrite /etc/passwd with that file, the security rules
really do _not_ come from your newly created inode, they come from the
fact that you made the path "/etc/passwd" point to that inode.

And again - you can emulate this with the inode-based thing. Your hammer
does work, but it doesn't really invalidate the fact that the path really
is what is most fundamental in that case, because the pathname is
fundamentally the shared piece of information that different processes
work with.

You end up making up new ideas to handle this: it's why traditional BSD
UNIX security has the setgid and sticky bit on directories, and it's also
obviously why selinux ends up having special rules for "link" and "rename"
etc - exactly so that you can emulate security that is really
fundamentally about the pathname.

In other words: it really _does_ make more sense to say "this process has
rights to overwrite the path '/etc/passwd'" than it does to try to label
the file. The _fundamental_ rule is about the pathname. The labeling comes
about BECAUSE YOU USED A HAMMER FOR A SCREW.

I really don't understand why some people are unable to admit this fact.

				Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Mon, 08 Mar 2010 19:34:52 UTC
Message-ID: <fa.TNO45lB8oEbKom6Ucbfs3p+dP+M@ifi.uio.no>

On Mon, 8 Mar 2010, Alan Cox wrote:
>
> man restorecond

I know. I also sometimes sit through minutes of "let's relabel the system,
because you've booted a kernel without selinux support".

			Linus

From: Ingo Molnar <mingo@elte.hu>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 07:30:17 UTC
Message-ID: <fa.pR30Jga0HOkHMA9gNwE6e3S4XcY@ifi.uio.no>

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 8 Mar 2010, Alan Cox wrote:
> >
> > man restorecond
>
> I know. I also sometimes sit through minutes of "let's relabel the system,
> because you've booted a kernel without selinux support".

I've had selinux relabeling wait times of an hour or two too, on a
sufficiently large filesystem.

I think this hurts security far more than anything else, because it causes
people to actually _turn off the whole thing_ - so we will have less and less
security in the end.

( To use the obligatory fire door analogy: we should prefer a one inch thick
  fire door that opens and closes fully automated to a five inches thick fire
  door that people keep always-open with a chair. )

	Ingo

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Mon, 08 Mar 2010 23:39:04 UTC
Message-ID: <fa.cQ6LCqwuoW38/1UJOSa3rkzJlB8@ifi.uio.no>

On Mon, 8 Mar 2010, Rik van Riel wrote:
>
> On the other hand, '/etc/shadow' has the opposite constraint,
> where the system will not trust most of the applications with
> the data from that file.

Umm. No.

/etc/shadow is in no way at all different from /etc/passwd. Both of them
have pathname-based security issues. The fact that both of them _also_
have content-based security issues is an independent issue that I just
assumed everybody would take for granted.

Clearly I assumed too much.

So I was assuming that everybody realized that the normal inode-based UNIX
security obviously means that you can only open /etc/passwd read-only as
any normal user (and not open /etc/shadow at all: but that is in _no_ way
different from /etc/passwd).

That's an example of non-pathname-based security, where you actually mark
the content itself restricted some way. It's very naturally done with
labels on the inode itself. It's what UNIX has _always_ done.

Nobody has ever suggested removing that. That would be crazy.

But that thing is _independent_ from the other totally unrelated issue,
namely the fact that "/etc/passwd" is a special name in the namespace. In
other words, there is "content security", but then there is also
"namespace security".

Of course, you can make /etc unwritable, and that is indeed the
traditional UNIX model of handling namespace security: by just
implementing it as "content security" of the directory.

The sgid and sticky bits can be used to further try to make it more
fine-grained (exactly because it is _not_ sufficient to say "you can't
read or write this directory" on a whole-directory basis), and obviously
SELinux has extensions of its own too.

Can you really not see the difference between security of naming things
certain things (like "/etc/passwd") - pathname based issues - and the
separate security of limiting access to any named device - actual markings
on the inode itself?

				Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 00:12:15 UTC
Message-ID: <fa.at5yJ1OSiVSrxsEGHZlIQoqM3QY@ifi.uio.no>

On Mon, 8 Mar 2010, Rik van Riel wrote:
>
> > But that thing is _independent_ from the other totally unrelated issue,
> > namely the fact that "/etc/passwd" is a special name in the namespace. In
> > other words, there is "content security", but then there is also
> > "namespace security".
>
> ... what exactly does the namespace security protect against?
>
> What is the threat model that the namespace security protects
> against, which is not protected by the content based security?

Umm? Seriously?

What is _any_ security all about? You try to limit the opportunity for
damage, accidental or not.

So let's take a trivial example. Let's say that you are root, and you edit
/etc/shadow by hand. I've done it, you've probably done it, it's not
rocket science. Now, you do it using any random editor, and most likely
it's going to write the new file into a temp-file, and then rename that
temp-file over the old file (perhaps creating a backup of the old file
depending on editor and settings).

Now, think about what that implies for a moment. Especially consider the
case that there were ACL's ("inode-based security") on the old /etc/passwd
or /etc/shadow file that got moved away as a backup. What happened to
those ACL's when you edited the file using a random editor?

Now, do you see what the difference between pathname-based and inode-based
security is? Do you realize how if anybody wants to track accesses to
/etc/shadow, they are not going to be interested in the _old_ backup copy
of /etc/shadow?

				Linus

From: Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 00:16:23 UTC
Message-ID: <fa.bIhZ54xQZSHMonH5UP8av+q40OE@ifi.uio.no>

On Mon, Mar 08, 2010 at 03:37:38PM -0800, Linus Torvalds wrote:

> Of course, you can make /etc unwritable, and that is indeed the
> traditional UNIX model of handling namespace security: by just
> implementing it as "content security" of the directory.
>
> The sgid and sticky bits can be used to further try to make it more
> fine-grained (exactly because it is _not_ sufficient to say "you can't
> read or write this directory" on a whole-directory basis), and obviously
> SELinux has extensions of its own too.

But that's not what the apparmor et.al. are doing.  If you want (and that's
not obviously a good thing) fine-grained access control for directory
entries, it would at least make some sense.  Prohibitively pricy, probably,
but that's a separate story.  But they are *NOT* protecting /foo/bar directory
entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards
root.

And if you *do* protect each ancestor and try to keep granularity, you'll
end up with complexity from hell.

From: Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 00:49:00 UTC
Message-ID: <fa.mKU2RqrsGzZ7YHZifo29lWDpv0I@ifi.uio.no>

On Tue, Mar 09, 2010 at 12:15:54AM +0000, Al Viro wrote:
> On Mon, Mar 08, 2010 at 03:37:38PM -0800, Linus Torvalds wrote:
>
> > Of course, you can make /etc unwritable, and that is indeed the
> > traditional UNIX model of handling namespace security: by just
> > implementing it as "content security" of the directory.
> >
> > The sgid and sticky bits can be used to further try to make it more
> > fine-grained (exactly because it is _not_ sufficient to say "you can't
> > read or write this directory" on a whole-directory basis), and obviously
> > SELinux has extensions of its own too.
>
> But that's not what the apparmor et.al. are doing.  If you want (and that's
> not obviously a good thing) fine-grained access control for directory
> entries, it would at least make some sense.  Prohibitively pricy, probably,
> but that's a separate story.  But they are *NOT* protecting /foo/bar directory
> entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards
> root.
>
> And if you *do* protect each ancestor and try to keep granularity, you'll
> end up with complexity from hell.

BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_
sadistic), you'll see how seriously do they take pathname-based *anything*.
LSM hooks for namespace operations (you know, mount, umount) are lousy, but
they exist.  Not used by apparmor.

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 01:50:28 UTC
Message-ID: <fa.u1xfnlzBdtt92fTHu/GLp6OEwnw@ifi.uio.no>

On Tue, 9 Mar 2010, Al Viro wrote:
>
> BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_
> sadistic), you'll see how seriously do they take pathname-based *anything*.
> LSM hooks for namespace operations (you know, mount, umount) are lousy, but
> they exist.  Not used by apparmor.

That's a good point, btw, and shows one conceptual difference between
content-based and pathname-based rules.

For example, if you want to log any changes to "/etc/passwd" (which is
something pretty reasonable to do at least conceptually), what about doing
a bind mount on top of that file?

That bind mount doesn't actually change the underlying file in any way. It
doesn't even really _access_ it. From a content standpoint of the
filesystem that contains the file, it's a total no-op.

But from an attack standpoint, you don't actually care, because nobody
cares about the inode that used to be the contents of "/etc/passwd": all
anybody _really_ cares about is "could somebody change what happens to the
_name_ '/etc/passwd'".

But yeah, it's easy to overlook namespace changes when the obvious
operations are read/write/unlink/rename. And I'm not at all surprised that
people do.

			Linus

From: Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 02:06:01 UTC
Message-ID: <fa.LHtkikz6OQxXpO6u8oDD/yBypqM@ifi.uio.no>

On Mon, Mar 08, 2010 at 05:49:10PM -0800, Linus Torvalds wrote:

> That's a good point, btw, and shows one conceptual difference between
> content-based and pathname-based rules.
>
> For example, if you want to log any changes to "/etc/passwd" (which is
> something pretty reasonable to do at least conceptually), what about doing
> a bind mount on top of that file?

Doesn't have to be a binding over /etc/passwd, BTW.  /etc as a mountpoint will
serve just as well.

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Upstream first policy
Date: Tue, 09 Mar 2010 02:19:14 UTC
Message-ID: <fa.m9mCu3Y0J4VwJw3e4nfRSBPtHMc@ifi.uio.no>

On Tue, 9 Mar 2010, Al Viro wrote:
>
> Doesn't have to be a binding over /etc/passwd, BTW.  /etc as a mountpoint will
> serve just as well.

I agree. But I think more people are aware of a regular directory mount
than about the ability to just mount a single file. So from a sneakyness
standpoint, I like the "oh, btw, I just took over just the one file I care
about" rather than trying to hide the whole directory.

Doesn't matter conceptually, though.

		Linus