linux-kernel - 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: <687382.36673.qm@web36604.mail.mud.yahoo.com>
Date:	Tue, 15 Apr 2008 09:32:53 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	casey@...aufler-ca.com, sds@...ho.nsa.gov, crispin@...spincowan.com
Cc:	serue@...ibm.com, matthew@....cx, 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
Subject: Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.


--- Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> wrote:

> Casey Schaufler wrote:
> > The question of protections on the object named /etc/passwd came
> > up time and time again. The notion that /etc/passwd could be a
> > symlink to /home/smalley/heeheehee really gave evaluators the
> > whillies. As did the chroot environment, where /roots/crispin/etc/passwd
> > could magicly become /etc/passwd.
>
> Why do people continue speaking symlinks and chroots?

Because on any given Linux system you could have an arbitrarily
large number of different things that might be accessed by the
name "/etc/passwd" and a different, but similarly large number
of names other than "/etc/passwd" that can be used to access them.

> To avoid the effect of symlinks and chroots, AppArmor and TOMOYO Linux
> derive pathnames from dentry and vfsmount.
> If /etc/passwd was a symlink, the derived pathname will be
> /home/smalley/heeheehee.
> If accessed from inside a chroot, the derived pathname will be
> /roots/crispin/etc/passwd.

Which doesn't hold up under hard links, which I had carefully
avoided and that both AppArmor and TOMOYO Linux have to place
restrictions on for the systems to make sense.

> It is true that namespace may differ between processes,
> but I think that that is the matter of how to restrict namespace manipulation
> operations.
> As I said, a system can't survive if namespace is madly manipulated.

That's hardly the viewpoint of those who would have every
user mount their own version of /tmp.

> To keep the system workable, /bin/ must be the directory for binary programs,
> /etc/ must be the directory for configuration files, and so on in all
> namespaces.

Only for general purpose shell access. General purpose shell access
is decreasing in popularity.

> It is true that the pathname may change while traversing up the
> dentry/vfsmount trees.
> But the change does not occur infinitely.
> As I said, a system can't survive if files and directories are madly renamed.
> The possible changes are bounded by the policy.
> 
> At least, I want people not to speak symlinks and chroots when talking about
> AppArmor and TOMOYO Linux.

The issues with links, symlinks, chroots and mounts in the
context of a name based access control scheme will always
need to be addressed, just as the issues of unlabeled filesystems
and /tmp will have to be in label based scheme.


Casey Schaufler
casey@...aufler-ca.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/