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

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Matthew Wilcox (matthew@wil.cx):
> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
> > Matthew Wilcox wrote:
> > > When the rule is put in place, say "No modifications to /etc/passwd",
> > > look up the inode and major:minor of /etc/passwd.  If there's a rename,
> > > look up the new inode number.  If it's mounted elsewhere, it doesn't
> > > matter, they still can't modify it because it has the same
> > > major:minor:inode.
> > 
> > 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 the past, Crispin has given clear, concise explanations of a few of
the things pathname based access control in fact excels at.  Crispin,
can you recite those again so we can think constructively about which
(if any) of the currently considered options are or are not sufficient?

I.e. what would be a motivation for a rule like 'no modifications to
/etc/passwd', and what precisely would and would not be accepted ways to
get around it (and why)?

thanks,
-serge