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 linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
