Re: Upstream first policy

[Casey Schaufler]

Linus Torvalds wrote:
> 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
>   

And if you really want to get down to brass tacks it wouldn't hurt
if either camp dusted off their faded copy of the DoD Orange Book
and read a few verses. The access control requirements are stated
in terms of objects but the audit requirements clearly want pathnames.
The security modelers were nuts to protect objects (inodes) but the
accountability fiends insisted on human readable identifiers (pathnames).
The early evaluations (a decade before Linux headed for the Common
Criteria) of Unix systems got bogged down for months at a time while
the needs of objects battled with the needs of accountability.

In the end neither side is right. There are useful things that you
can do with either, but as everyone and his demented gerbil has
pointed out, no one has the True Security Solution. Not even SELinux,
which violates some pretty fundamental security principles
(see: "small enough to be analyzed") in actual deployment. TOMOYO
violates "non-circumventable", just in case anyone thinks I'm
picking on someone. Heck, even Smack isn't perfect, although I will
leave it to others to autoclave that puppy.

Those of you who say we ought to come up with a single framework
that we can use to Do The Right Thing haven't been reading the code.
We have such a framework in the LSM. Sure it's mildly hackish, but
it has only been "open" to new modules for a couple years now, and
security development tends to be slow, with no hardware and blessed
little money behind it. How many file systems went into the VFS
before it got clean enough to talk about in public?

Further, we can polish the filesystem apple until the seeds show
and still never get anywhere near where the modern security issues
reside. Right, networking. Without a security model for that we can
debate how we want our eggs cracked and get just as close to a "real"
solution as we will with the inode/pathname debate.


> --
> 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/
>
>
>   

--
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/