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: <200804112312.HGE69734.LFOOHQOSFFMJtV@I-love.SAKURA.ne.jp>
Date:	Fri, 11 Apr 2008 23:12:27 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	matthew@....cx
Cc:	paul.moore@...com, penguin-kernel@...ove.SAKURA.ne.jp,
	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.

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