Re: Upstream first policy

[Eric Paris]

On Mon, Mar 8, 2010 at 5:12 PM, Ulrich Drepper <drepper@xxxxxxxxx> wrote:
> On Mon, Mar 8, 2010 at 10:08, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> 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.
>
> This is not a fundamental problem.  It's rather a detail of the
> current policies and legacy apps.
>
> I think I would like to see /etc/passwd to also get a file type like
> /etc/shadow.  This is I think today not done because of the work
> involved and the perceived lower severity because passwords are in
> /etc/shadow.
>
> So let's talk about /etc/shadow.  If somehow the file is removed and
> somebody creates a new file that file won't automatically get the
> right label.  This means that code reading the file then could be
> prevented from doing this with appropriate policy rules.  Here the
> filename is not sufficient for access.  You also need the label and
> that you won't get without subverting the system.  With filename based
> mechanisms this isn't the case: once the file is compromised the
> attack succeeded.
>
> Yes, the current situation isn't optimal.  We have to make the
> policies more complicated and we have to get rid of restorecond (at
> least for most cases).  But there is no fundamental problem with
> labels while filename-based mechanisms provide no security
> improvement.

At the moment the default label of a new file is created based on the
label of the creating process and the label of the parent directory.
It's certainly not impossible that a third factor could be added 'the
last component of the pathname of the new inode' to the decision
matrix.  Doing so would eliminate the need for restorecond in most (or
maybe all) situations while maintaining the useful security principles
of label based enforcement.  It actually has been suggested and
implemented, but as I recall we were told it violated some VFS rules
to pass the information we passed where we passed it and it was
abandoned.

*tongue in cheek* if TOMOYO and AppArmour can do thing which the VFS
maintainer say is wrong and unacceptable merely by sending them to the
security maintainer instead I guess SELinux can do that as well!

answering a different post in the same email: I accept "THERE ARE
DIFFERENT CASES."  You go on to say "So I'm not suggesting we
_replace_ content-based security with pathname-based security. I'm
just saying that pathnames actually do matter for security, and that
they are an independent issue."  But what you are suggesting is
EXACTLY that our users should _replace_ content-based security with
pathname-based security when they have to boot with security=TOMOYO
instead of security=SMACK.  Rather than finding a flexible framework,
finding problems or inadequacies in that framework, and solving those
problems you instead force our users to have to choose between LSMs
which are either A) secueable but non-intuitive or B) not securable
but known to be 'easier'.

I think the inode based security view as a hammer might not be all
that bad.  It works really well on nails (you know the truely hard
well researched security questions) and it can beat screws into a
piece of wood as well (although sometimes the wood cracks).  Calling
pathname based security a screwdriver fits too, it can put the screws
in but we know there are a lot of nails out there which it can't ever
deal with.

Personally I think we should all get together and agree on a framework
and fix the framework to meet all of the needs and look like a swiss
army hammer driver drill thing rather than having 4 options, none of
which meet all the needs, and then forcing our uneducated users to
choose between them.  But, hey, we all know that isn't going to happen
so I'll just go back to happy go lucky dream land where Linus is not
running around naked with a chain saw.

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/