Messages in this thread |  | | Date | Sun, 13 Apr 2008 18:41:19 -0700 | From | Crispin Cowan <> | 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
|  |