Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan <crispin@crispincowan.com>]

Matthew Wilcox wrote:
> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
>   
>> If write access is denied because of a rule "No modifications to /etc/passwd",
>> a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
>> "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
>> "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
>>     
> That's a fundamental limitation of pathname-based security though.
> If the same file exists in two places, you have to resolve the question
> of which rule overrides the other.
>
> In my role as a sysadmin, I would consider it a flaw if someone could
> edit a file I'd marked uneditable -- simply by creating a hard-link to it.
> If we look at existing systems, such as the immutable bit, those apply to
> inodes, not to paths, so they can't be evaded.  If a system such as TOMOYA
> allows evasion this easily, then it doesn't seem like an improvement.
>   
You are discussing a straw-man, because AppArmor (and I think TOMOYO) do 
not operate that way.

It is not, and never has been, "mark /etc/passwd not writable". Please 
delete this broken concept from the discussion.

Rather, it is "can write to /tmp/ntpd/*". You *grant* permissions. You 
do *not* throw deny rules.

So if you grant write access to /tmp/mumble/barf you should expect it to 
always be accessible, regardless of whether someone creates an alias for it.

Please re-consider the rest of your analysis, because it doesn't work if 
there are only "allow" rules and no "deny" rules. You are correct that a 
pathname-based deny rule is trivially bypassable, that's why there 
aren't any :)

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
Botnets are the only commercially viable utility computing market