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 ]

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

-

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.

-

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

-

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.

-

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

-

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.

-

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

-

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

-

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

-

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 ?

-

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

-

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

-

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

-

Presumably his context can change within a login session?  If not, it's

indeed simply worthless, absolute paths or not.

-