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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 13 Apr 2008 11:36:58 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	paul.moore@...com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, takedakn@...data.co.jp,
	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
	crispin@...spincowan.com
Subject: Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

Quoting Matthew Wilcox (matthew@....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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html