lkml.org 
[lkml]   [2008]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
From
Date
Sorry for slow response.

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.

"No modifications" (i.e. "forbid modifications") and
"Allow modifications" (i.e. "don't forbid modifications") are incompatible
rules as long as the rules are described using pathnames but the judgment is
done using inodes (or labels).

If rules are described like "No modifications to passwd_t",
it is correct to deny modifications of the file when the file
with passwd_t was renamed or bind-mounted or hard-linked.
Those who want to do access restriction based on the entity of the file
prefer rules described using inodes (or labels).

If rules are described like "No modifications to /etc/passwd" and
"Allow modifications to /tmp/passwd", it is wrong to deny modifications of
the file when /etc/passwd was renamed or bind-mounted or hard-linked to
/tmp/passwd .
Those who want to do access restriction based on the location of the file
prefer rules described using pathnames.

SELinux and Smack are the former.
AppArmor and TOMOYO Linux are the latter.

> Is this workable?
I'm afraid it is unlikely.

Thank you.


\
 
 \ /
  Last update: 2008-04-11 16:15    [W:0.749 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site