From: Casey Schaufler <casey@...>
Subject: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 29, 8:20 pm 2007




From: Andrew Morton <akpm@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 4:16 am 2007

On Sat, 29 Sep 2007 17:20:36 -0700 Casey Schaufler  wrote:
>

> Smack is the Simplified Mandatory Access Control Kernel.

>
I don't know enough about security even to be dangerous.  I went back and

reviewed the August thread from your version 1 submission and the message I

take away is that the code has been well-received and looks good when

considered on its own merits, but selinux could probably be configured to

do something sufficiently similar.
I'd have trouble declaring that "but" to be a reason to not merge smack.

I'm more thinking "let's merge it and see if people use it".
>

>  Documentation/Smack.txt       |  104 +

>  security/Kconfig              |    1

>  security/Makefile             |    2

>  security/smack/Kconfig        |   10

>  security/smack/Makefile       |    9

>  security/smack/smack.h        |  207 ++

>  security/smack/smack_access.c |  345 ++++

>  security/smack/smack_lsm.c    | 2685 ++++++++++++++++++++++++++++++++

>  security/smack/smackfs.c      | 1201 ++++++++++++++

>  9 files changed, 4564 insertions(+)
And that wonderful diffstat really is key to being able to do this.
My major non-technical concern is that Casey Schaufler might get hit by a

bus.  If this happens, we can remove the feature in three minutes (that

diffstat again), but that may not be feasible if people have come to rely

upon the feature.
otoh, if a significant number of people are using smack, presumably someone

else would step up to maintain smack post-bus.  The risk seems acceptable

to me.
My major technical concern is the apparent paucity of documentation.
So with the information which I presently have available to me, I'm

thinking that this should go into 2.6.24.
Is smack useful without a patched ls, sshd and init.d?  What is the status

of getting those userspace patches merged?  ie: do you know who to send the

diffs to, and are they likely to take them?
What other userspace tools are likely to need patching?
Notes on the code:
- Please run scripts/checkpatch.pl across the diff.  It generates 50-100

  warnings about minor stylistic matters, and those warnings all look legit

  to me.  (extern decls in C are my fave peeve).
- Smack.txt and the website seem a bit skimpy.  Is there enough

  documentation out there for someone to usefully (and, more importantly,

  safely) start using smack?
- In his review of version 1, Andi suggested that your ruleset traversal

  be protected by RCU.  But it seems that this wasn't done.  Were the races

  which he identified fixed by other means?  If so, what were they?
- hm, netlabels.  Who might be a suitable person to review that code?

  Seems that Paul Moore is the man.  Maybe he'd be interested in taking a

  look over it (please?)
- some parts of the code use the "smack_foo" naming convention and other

  parts use "smk_foo".  Seems odd.  Deliberate?
- According to git-log, you haven't merged any kernel code at all in at

  least 5.5 years.  This patch makes it look like you've been doing kernel

  full time for a decade.  That thing in my hand is a hat.
-



From: Andi Kleen <ak@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 4:42 am 2007

> - Smack.txt and the website seem a bit skimpy.  Is there enough

>   documentation out there for someone to usefully (and, more importantly,

>   safely) start using smack?
Yes that's the important thing.
> - In his review of version 1, Andi suggested that your ruleset traversal

>   be protected by RCU.  But it seems that this wasn't done.  Were the races

>   which he identified fixed by other means?  If so, what were they?
The issue was moot because rulesets never get removed in the current

implementation. I had missed that. If that ever changes RCU would be likely

needed though.
> - hm, netlabels.  Who might be a suitable person to review that code?

>   Seems that Paul Moore is the man.  Maybe he'd be interested in taking a

>   look over it (please?)
I personally consider these IP options it uses to be pretty useless. Who could

ever use that without cryptographic authentication? Clearly when they

were designed in the original IP spec long ago the designers didn't understand

network security very well because the whole field was at its infancy. And

CIPSO doesn't solve any of these fundamental issues.
It assumes a trusted network which is a very dangerous assumption.  I don't

think that was in the original patch I looked at, I surely would have

objected to it.
Perhaps take the network part out? I guess SMACK would be useful

locally even without questionable network support.
-Andi

-



From: Joshua Brindle <method@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 1:29 pm 2007

Andi Kleen wrote:

>> - hm, netlabels.  Who might be a suitable person to review that code?

>>   Seems that Paul Moore is the man.  Maybe he'd be interested in taking a

>>   look over it (please?)

>>

>

> I personally consider these IP options it uses to be pretty useless. Who could

> ever use that without cryptographic authentication? Clearly when they

> were designed in the original IP spec long ago the designers didn't understand

> network security very well because the whole field was at its infancy. And

> CIPSO doesn't solve any of these fundamental issues.

>

> It assumes a trusted network which is a very dangerous assumption.  I don't

> think that was in the original patch I looked at, I surely would have

> objected to it.

>

> Perhaps take the network part out? I guess SMACK would be useful

> locally even without questionable network support.

>   
CIPSO is supported on SELinux as well. It certainly has uses where IPSec

is excessive. One example is someone I talked to recently that basically

has a set of blade systems connected with a high speed backplane that

looks like a network interface. CIPSO is useful in this case because

they can't afford the overhead of IPSec but need to transfer the level

of the connection to the other machines. The backplane is a trusted

network and that isn't a dangerous assumption in this case.
CIPSO also lets systems like SELinux and SMACK talk to other trusted

systems (eg., trusted solaris) in a way they understand. I don't

regularly support CIPSO as I believe IPSec labeling is more useful in

more situations but that doesn't mean CIPSO is never useful.
-



From: Andi Kleen <ak@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 1:39 pm 2007

> CIPSO is supported on SELinux as well.
That's no reason to extend that design mistake.
> It certainly has uses where IPSec

> is excessive. One example is someone I talked to recently that basically

> has a set of blade systems connected with a high speed backplane that

> looks like a network interface. CIPSO is useful in this case because

> they can't afford the overhead of IPSec but need to transfer the level

> of the connection to the other machines. The backplane is a trusted

> network and that isn't a dangerous assumption in this case.
If one of the boxes gets broken in all are compromised this way? 
> CIPSO also lets systems like SELinux and SMACK talk to other trusted

> systems (eg., trusted solaris) in a way they understand. 
Perhaps, but is the result secure? I have severe doubts.
> I don't

> regularly support CIPSO as I believe IPSec labeling is more useful in

> more situations but that doesn't mean CIPSO is never useful.
Security that isn't secure is not really useful. You might as well not

bother.
-Andi
-



From: Theodore Tso <tytso@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 3:07 pm 2007

On Sun, Sep 30, 2007 at 07:39:57PM +0200, Andi Kleen wrote:

> > CIPSO also lets systems like SELinux and SMACK talk to other trusted

> > systems (eg., trusted solaris) in a way they understand.

>

> Perhaps, but is the result secure? I have severe doubts.
As always, it depends on your environment.  There are people who are

using Linux systems where trusting the network makes sense.  For

example, if you're on a battleship, say, or all of the machines are in

a cluster which is inside a Tempest-shielded machine room with a

massive combination lock that you might find on a bank vault, or if

you're environment where network cables are protected by pressurized

pipes (so any attempt to tamper with or tap the cables causes a

pressure drop which sets off the alarm which summons the Marines armed

with M-16's...).
(I've been inside classified machine rooms, which is why my laptop has

the 'Unclassified' label on it; it's needed so people can easily

eyeball it and know that I'm not allowed to connect it to any of the

classified networks.  And those are just the less serious machine

rooms.  In the really serious classified areas with the bank

vault-like doors, and the copper-tinted windows, I'm not allowed to

bring in an unclassified laptop at all --- and yes, Linux is being

used in such environments.  And yes, they do sometimes use IPSO and/or

CIPSO.)
> Security that isn't secure is not really useful. You might as well not

> bother.
There are different kinds of security.  Not all of them involve

cryptography and IPSEC.  Some of them involve armed soldiers and air

gap firewalls.  :-)
Yes, normally the network is outside the Trusted Computing Base (TCB),

but a cluster of Linux machines in a rack is roughly the same size of

a huge Unix server tens year ago --- and it's not like Ethernet is any

more secure than the PCI bus.  So why do we consider communications

across a PCI bus secure even though they aren't encrypted?  Why,

because normally we assume the PCI bus is inside the trust boundary,

and so we don't worry about bad guys tapping communications between

the CPU and the hard drive on the PCI bus.
But these days, it is obviously possible to create clusters where

certain network interfaces are only connected to machines contained

completely inside the trust boundary, just like a PCI bus in a

traditional server.  So don't be so quick to dismiss something like

CIPSO out of hand, just because it doesn't use IPSEC.
Regards,
	   	   		      	       - Ted

-



From: Andi Kleen <ak@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 4:05 pm 2007

> Yes, normally the network is outside the Trusted Computing Base (TCB),
Normally as in the 99.99999% case.
> but a cluster of Linux machines in a rack is roughly the same size of

> a huge Unix server tens year ago --- and it's not like Ethernet is any

> more secure than the PCI bus.  
PCI busses normally don't have routers to networks outside the box connected

to them. 
> So don't be so quick to dismiss something like

> CIPSO out of hand, just because it doesn't use IPSEC.
With your argumentation we could also just disable all security

in these situations (as in null LSM to save some overhead); after all these

systems are protected by armed guards.  If someone gets past the guards

they could connect their laptop to the network and fake all the "secured"

packets. If you assume that won't happen why do you need computer security at all?
Anyways; if someone wants to cripple their security for some

performance this way they can surely do this; but i don't think we should

offer it as a default configuration option (just as we don't have a

CONFIG_NULL_LSM even though there are undoubtedly systems that don't

care about permission checking[1]) 
-Andi
[1] I bet I gave the linux-tiny crowd an idea now ;-)
-



From: Theodore Tso <tytso@...>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Sep 30, 4:22 pm 2007

On Sun, Sep 30, 2007 at 10:05:57PM +0200, Andi Kleen wrote:

> > but a cluster of Linux machines in a rack is roughly the same size of

> > a huge Unix server tens year ago --- and it's not like Ethernet is any

> > more secure than the PCI bus.

>

> PCI busses normally don't have routers to networks outside the box connected

> to them. 
The whole *point* is that the routers are interconnecting boxes inside

the cluster, and none of them connect to the outside world.  It's no

different than a SCSI cable connecting to JBOD in a separate box, or a

Fiber Channel router connected to a SAN network connecting to a

storrage array.  The SCSI or FC buses aren't encrypted either, and the

in the Fiber channel case we have a router --- yet people aren't

stressing out that we're not encrpying the traffic over the Storage

Area Network?  Why?  Because it's understood the network stays inside

the machine room.  The same thing can true for Ethernet --- think

iSCSI, for example.
> > So don't be so quick to dismiss something like

> > CIPSO out of hand, just because it doesn't use IPSEC.

>

> With your argumentation we could also just disable all security

> in these situations (as in null LSM to save some overhead); after all these

> systems are protected by armed guards.  If someone gets past the guards

> they could connect their laptop to the network and fake all the "secured"

> packets. If you assume that won't happen why do you need computer security at all?
If you get past all of the guards, you can usually reboot in single

user mode, and get root anyway.  If you have physical access to the

computer, you're generally doomed anyway, unless you are willing to

pay the cost of encrypting everything on every single disk platter.

(And yes, in the more paranoid environments, where it's too expensive

to have 7x24 armed guards, maybe that makes sense.)
The point of something like CIPSO is because you want to label the

packets so the otherside knows how they should be treated.  We don't

encrypt unix permission bits on most on-disk filesystems, either.  Yet

I haven't heard people saying that just because someone could break

into a machine room, disconnect the JBOD from the computer, hook up

the JBOD to their laptop, and futz with the Unix permission bits,

rehook up the JBOD and reboot, that Unix permission bits are useless,

and we should leave all files at mode 777 --- since clearly we're not

secure against someone who can break into the machine room.....  
I *hope* that sounds absurd, right?
					- Ted
-