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.

Smack uses extended attributes and
provides a set of general mount options, borrowing technics used
elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
a pseudo-filesystem smackfs that is used for manipulation of
system Smack attributes.

The patch, patches for ls and sshd, a README, a startup script,
and x86 binaries for ls and sshd are also available on

    http:/www.schaufler-ca.com

The patch has been tested with 2.6.22, 2.6.23-rc8, and
2.6.23-rc8-mm2. Development has been done using Fedora Core 7
in a virtual machine environment and on an old Sony laptop.

Smack provides mandatory access controls based on the label attached
to a task and the label attached to the object it is attempting to
access. Smack labels are deliberately short (1-23 characters) text
strings. Single character labels using special characters are reserved
for system use. The only operation applied to Smack labels is equality
comparison. No wildcards or expressions, regular or otherwise, are
used.

A file always gets the Smack label of the task that created it.

Smack defines and uses these labels:

    "*" - pronounced "star"
    "_" - pronounced "floor"
    "^" - pronounced "hat"
    "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
   is permitted.
3. A read or execute access requested on an object labeled "_"
   is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
   ...
[ message continues ]

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.  For another...  WTF is filesystem
making assumptions about the locations where the things are
mounted?  Hell, even if you override your tmp symlink, what
happens if we want it in two chroot jails with different layouts?

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

[ message continues ]

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


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

Because you throw "simple" out the window when you require userland

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
-

[ message continues ]

Of course you can mount it more than once.  Just bind the sucker and you


_What_ userland intervention?  Mounting stuff under /smack/tmp and not under
your /moldy?  Having /tmp replaced with symlink to /smack/tmp.link instead
of replacing it with a symlink to /smack/tmp?

Absolute paths in that kind of thing are _wrong_.  You know where the things
are on your fs.  You don't know if anything else will be visible, let alone
whether it will be at the same place in all chroots or namespaces.  And no,
you _can't_ make sure that fs is visible only in one place.  No fs can or
has any business even trying.
-

[ message continues ]

What I don't understand here is why we need the hacks when we already
support sufficient mount magic to give each login session its own
private /tmp ?
-

[ message continues ]

Presumably his context can change within a login session?  If not, it's
indeed simply worthless, absolute paths or not.
-

[ message continues ]

An embedded system that does not have user logins but that does
have applications that require separation, perhaps a moble communication
device with application download capability, is just one example
where the smack symlink implementation provides the required
function without requiring application support.
 

Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

I don't see what is such a problem here. For your mobile example you'd
give the application download side its own /tmp via mount.

Its actually better this is done in user space as its more flexible that
way and can be tuned arbitarily to meet interesting or bizarre real world
cases.

Alan
-

[ message continues ]

I admit to being impressed by the wide variety of mount options
currently available. In many cases this will be the best approach.
/tmp is a typical use for a smack symlink, but not the only one.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

Yes. By the way, there's nothing that really requires that you
use a /smack symlink if you don't want to. /tmp can still be a
real directory, a mount point, a symlink to /var/tmp, or whatever
else you want it to be if that suits your needs better. For the
simplest scenarios /tmp -> /smack/tmp -> /moldy/<label> has every


Is the objection that there is a default value coded in?


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

And your point is?  If you don't use it, you get exact same complexity


Right now the main objection is about your lack of ability to read.  Which
part of "it can be mounted in different chroots/namespaces, therefore
having absolute paths doesn't work" is too hard to understand?

No, it's not about having a default.  It's about keeping an absolute pathname
in virtual fs, having all instances autosoddingmatically sharing it _and_
having change attempt in any instance automatically affect all of them.
If you have that kind of sharing, don't pretend that your mechanism really
allows absolute pathnames.
-

[ message continues ]

Thank you for your patience. Let me see if I can get my point across.

The intended Smack scenario:

1. Create /moldy at "_"
2. For each label you care about
   2a. Create /moldy/<label>
   2b. Set the label of /moldy/<label> to <label>
3. ln -s /smack/tmp /tmp

All processes are now redirected into the appropriate place
regardless of how they come into being. It doesn't matter if
the "session" starts from busybox, login, sshd, xdm, crontab,

Are you suggesting that /smack/tmp.link below is a mount point,
and that appropriate directories get mounted there? 

1. Create /moldy at "_"
2. For each label you care about
   2a. Create /moldy/<label>
   2b. Set the label of /moldy/<label> to <label>
   2c. mount --bind /moldy/<label> /smack/tmp.link/<label>


It's the content of a symlink, and that can be just about anything
and is not required to point to anything, which is one reason why
I made that choice. If you don't have a /tmp, or can't write to the
/tmp that exists, or have a /tmp that's a dangling symlink under
any circumstances you may have an issue. That's true regardless of
the presence or absense of /smack. All of the traditional mechanisms


It's in a symlink on the filesystem, and it doesn't have to be an
absolute pathname, although since it's a symlink and the semantics
for a symlink allow that be be absolute, relative, or dangling I

Could allowing multiple distinct mounts and symlink assignments
of /smackfs address those issues? I think it would, but as you pointed
out earlier, my lack of ability to read may be clouding my understanding.

Thank you.


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

4. mount --bind /moldy /smack/tmp
or add
/moldy /smack/tmp none bind,rw 0 2
to /etc/fstab (same effect as (4))

Compare with your variant; the difference is in one argument of ln(1) and
one additional line in rc script or /etc/fstab.  Sorry, but I don't buy

It's not about symlink pointing to /smack/<something>; it's about the place
where /smack/<something> itself points to.  And _that_ can bloody well be
different in different chroots.

Look, if you allow to change where it goes, you certainly allow different
prefices on different boxen; moreover, admin can change it freely according
to his layout on given box.  OTOH, you _can't_ have it different in different
chroots and changing it in one will affect all of them.  See why that's a

Fixed-contents symlink (with or without variable tail - it's irrelevant
here) is a bloody wrong tool for that kind of fs for the reasons described
above.  And if you go for "prefix should point to location on the same fs"
you can trivially configure the rest in userland (one line describing a
binding), leaving the kernel-side stuff with something like "userland
can ask for a pair of symlink and directory, having symlink resolve
to directory + <label>" instead of your "userland can ask for a symlink
resolving to <prefix> + <label>".  And _that_ is chroot-neutral - you don't

... like that one.  Leave it to normal userland mechanisms; it's a matter
of a single line in whatever script you are using to set chroot up and it
involves _way_ fewer caveats.

That said, Alan's point still stands - if you don't get processes changing
context back and forth, you don't need anything at all - we already have
all we need for that kind of setups (and no, selinux is not involved ;-).
-

[ message continues ]

What I'm confused about is how that results in a process labeled "foo"
getting a different /tmp from a process labeled "bar".




I do not understand where the concept of Fixed-contents symlink
comes from. Yes, "tmp" is initialized to "/moldy/", but that can
be changed by writing to /smack/links. Please help me understand


Casey Schaufler
casey@schaufler-ca.com
-

[ message continues ]

My sign-off got lost when Casey smooshed the patch I sent him into the SMACK 
mega-patch so I'll throw it back in the thread for accounting purposes.

Signed-off-by: Paul Moore <paul.moore@hp.com>

As for SMACK's use of NetLabel - it looks fine to me, especially now that 
there is better preservation of the NetLabel/LSM boundary.  As has been 
discussed on the various lists during earlier revisions of the patch I 
believe there are still some optimizations that can be made regarding how 
SMACK uses NetLabel but that is something we can always work on at a later 
date.

Acked-by: Paul Moore <paul.moore@hp.com>

-- 
paul moore
linux security @ hp
-

[ message continues ]