From: Casey Schaufler <casey@schaufler-ca.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
casey@schaufler-ca.com, sds@tycho.nsa.gov,
crispin@crispincowan.com
Cc: serue@us.ibm.com, matthew@wil.cx, paul.moore@hp.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, takedakn@nttdata.co.jp,
linux-fsdevel@vger.kernel.org
Subject: Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.
Date: Tue, 15 Apr 2008 09:32:53 -0700 (PDT) [thread overview]
Message-ID: <687382.36673.qm@web36604.mail.mud.yahoo.com> (raw)
In-Reply-To: <200804152014.IAB35427.tFLHSMOQOFOFJV@I-love.SAKURA.ne.jp>
--- Tetsuo Handa <penguin-kernel@I-love.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@schaufler-ca.com
next prev parent reply other threads:[~2008-04-15 16:33 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 12:22 [TOMOYO #7 00/30] TOMOYO Linux 1.6.0 released Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 01/30] TOMOYO Linux documentation Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 02/30] Internal functions prototypes for SAKURA and TOMOYO Tetsuo Handa
2008-04-04 15:29 ` Daniel Walker
2008-04-07 13:56 ` [TOMOYO #7 02/30] Internal functions prototypes for SAKURA andTOMOYO Tetsuo Handa
2008-04-07 15:24 ` Daniel Walker
2008-04-04 12:22 ` [TOMOYO #7 03/30] Constants for /proc/ccs/ interface Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 04/30] Prototypes of realpath Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 05/30] External functions prototypes for SAKURA Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 06/30] External functions prototypes for TOMOYO Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 07/30] Some wrapper functions for socket operation Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 08/30] Some of permission checks from VFS helper functions Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 09/30] Access control part of tamper-proof device filesystem Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 10/30] Common functions for SAKURA and TOMOYO Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 11/30] /proc/ccs/ interface for policy management Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 12/30] Memory and pathname management functions Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 13/30] mount restriction part Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 14/30] Shadow mount prevention part Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 15/30] Automatic bind port selection control part Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 16/30] Unmount restriction part Tetsuo Handa
2008-04-04 12:22 ` [TOMOYO #7 17/30] chroot " Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 18/30] pivot_root " Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 19/30] Auditing functions for TOMOYO Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 20/30] Socket operation restriction part Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 21/30] Capability " Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 22/30] Conditional ACL support functions Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 23/30] argvrestriction part Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 24/30] File operation restriction part Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 25/30] Signal " Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 26/30] Domain transition handler Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 27/30] Environment variable restriction part Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 28/30] Filesystem part of tamper-proof device filesystem Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 29/30] Kconfig and Makefile Tetsuo Handa
2008-04-04 12:23 ` [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO Tetsuo Handa
2008-04-04 16:29 ` Daniel Walker
2008-04-07 13:56 ` Tetsuo Handa
2008-04-07 15:39 ` Daniel Walker
2008-04-07 15:40 ` Paul Moore
2008-04-07 22:57 ` Casey Schaufler
2008-04-09 8:37 ` Toshiharu Harada
2008-04-09 12:49 ` Stephen Smalley
2008-04-10 5:57 ` Toshiharu Harada
2008-04-10 12:51 ` Stephen Smalley
2008-04-11 11:48 ` Toshiharu Harada
2008-04-09 13:11 ` Matthew Wilcox
2008-04-09 13:26 ` Stephen Smalley
2008-04-11 14:12 ` Tetsuo Handa
2008-04-11 14:30 ` Matthew Wilcox
2008-04-12 11:33 ` Tetsuo Handa
2008-04-13 16:36 ` Serge E. Hallyn
2008-04-14 2:05 ` Crispin Cowan
2008-04-14 14:17 ` Stephen Smalley
2008-04-14 17:05 ` Casey Schaufler
2008-04-15 11:14 ` Tetsuo Handa
2008-04-15 16:32 ` Casey Schaufler [this message]
2008-04-17 7:24 ` Crispin Cowan
2008-04-16 19:13 ` Pavel Machek
2008-04-17 11:58 ` Tetsuo Handa
2008-04-17 17:46 ` Pavel Machek
2008-04-18 13:21 ` Serge E. Hallyn
2008-04-15 4:59 ` Crispin Cowan
2008-04-16 16:31 ` Stephen Smalley
2008-04-17 7:49 ` Crispin Cowan
2008-04-17 8:45 ` Jamie Lokier
2008-04-17 12:42 ` Stephen Smalley
2008-04-15 13:00 ` Toshiharu Harada
2008-04-14 1:41 ` Crispin Cowan
2008-04-14 13:48 ` Matthew Wilcox
2008-04-15 3:21 ` Crispin Cowan
2008-04-15 4:57 ` Al Viro
2008-04-09 13:22 ` Serge E. Hallyn
2008-04-11 3:57 ` Toshiharu Harada
2008-04-24 5:28 ` [TOMOYO #7 00/30] TOMOYO Linux 1.6.0 released Toshiharu Harada
2008-04-24 14:48 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=687382.36673.qm@web36604.mail.mud.yahoo.com \
--to=casey@schaufler-ca.com \
--cc=akpm@linux-foundation.org \
--cc=crispin@crispincowan.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=paul.moore@hp.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
--cc=takedakn@nttdata.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox