Date: Wed, 3 Oct 2007 10:21:08 -0700 (PDT)
From: Casey Schaufler <casey@schaufler-ca.com>
Reply-To: casey@schaufler-ca.com
Subject: Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel
To: Al Viro <viro@ftp.linux.org.uk>, Casey Schaufler <casey@schaufler-ca.com>
Cc: torvalds@osdl.org, linux-security-module@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org, paul.moore@hp.com
In-Reply-To: <20071003051254.GH8181@ftp.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <287091.73995.qm@web36604.mail.mud.yahoo.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3225
Lines: 83


--- Al Viro <viro@ftp.linux.org.uk> wrote:

> On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote:
> > 
> > From: Casey Schaufler <casey@schaufler-ca.com>
> > 
> > Smack is the Simplified Mandatory Access Control Kernel.
> > 
> > Smack implements mandatory access control (MAC) using labels
> > attached to tasks and data containers, including files, SVIPC,
> > and other tasks. Smack is a kernel based scheme that requires
> > an absolute minimum of application support and a very small
> > amount of configuration data.
> 
> I _really_ don't like what you are doing with these symlinks.


> For one thing, you have no exclusion between reading the list
> entries and modifying them.

That's easy enough to fix. I'll do it.

> For another...  WTF is filesystem
> making assumptions about the locations where the things are
> mounted?

I assume by this that you're objecting to the initialization of
/smack/tmp to point to /moldy/<label>.

Over the years I've seen a number of cases where failure to
set up /tmp result in unhappy consequences. If /tmp is anything
other than a real directory on the root filesystem it is important
that special care be taken for the case where things don't get
set up right for some reason. By including a specific, if perhaps
arbitrary, default it becomes easier to create a configuration
that survives the unexpected.

> Hell, even if you override your tmp symlink,

Which is something that I expect virtually everyone to do.

> what
> happens if we want it in two chroot jails with different layouts?

As you can only have /smack mounted once, this isn't an issue,
but it does present an interesting use case that brings the one
mount limitation into question. I'll add addressing this to the
short term todo list.

> I really don't get it; why not simply have something like
> /smack/tmp.link resolve to tmp/<label> and have userland bind or mount
> whatever you bloody like on /smack/tmp?

Because you throw "simple" out the window when you require userland
assistance to perform this function.

> No problems with absolute
> paths, can be used in chroot jails with whatever layouts, ditto for
> namespaces, etc. and both symlink and directory get created at
> the same time (by one name).  Hell, if you keep a reference
> to dentry of directory in the data associated with symlink,
> you can simply switch nd->dentry to that, drop the old one
> and grab the reference to page containing label and return
> it via nd_set_link().  No need to play with allocations, strcat,
> yadda, yadda.  readlink() can stuff the ->d_name of the same
> dentry plus / plus label directly into user buffer; again, no
> allocations needed and works fine anywhere.

I'm having some trouble seeing how the 60 lines of code in
smackfs dealing with symlinks would be improved by your suggestions.
I certainly don't see how requiring userland intervention would
do anything but make it bigger and less reliable.


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