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]

Message-ID: <4802B63F.2010804@crispincowan.com>
Date:	Sun, 13 Apr 2008 18:41:19 -0700
From:	Crispin Cowan <crispin@...spincowan.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
Subject: Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

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

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