New stacker performance results

[s***@us.ibm.com]

Hi,

I've completed a set of stacker performance tests using our automated test
platform. The machine I'm using right now will go away soon, but we're
working on a set of (ppc64) partitions for selinux testing under the same
platform. I am reporting on one particular set of results, but if you
want anything changed - ie if you want profiling info - I should be able
to run more/new tests during the rest of this week at least.

I used a 2xamd64 machine with smp enabled, preemption disabled, running
fedora core 3 enforcing a custom dummy selinux policy. The kernel was
2.6.12-rc2. The sets of tests were run twice each on kernels with
selinux and capability enabled
and
stacker, selinux, and the stacking capability module enabled

Each of this was done once with two cpus, and once with "max_cpus=1"
specified on the command line.

Tests run were dbench, reaim, fsx-linux, and tbench. fsx-linux appears
to be purely a stability test, and all runs succeeded. Results for the
other benchmarks are included in this message.

In addition I also ran kernbench. For the 2-cpu results, these were
part of a run with profiling enabled (affecting performance). For the
1-cpu results, they were done along with the other benchmarks, without
profiling.

Following are the summarized results. Of course, 'nostack' refers to a
kernel compiled without stacker, and 'stack' refers to a kernel with
stacker. The 2-cpu results come first, followed by the 1-cpu results.

Finally, the stacking patches applied are the ones currently on
sf.net/projects/lsm-stacker in the stacking-patches.tar.gz file. The
file called 'series' lists the order in which they are applied.

thanks,
-serge

PS - I just need to add a bit of boot time checking for non-selinux
kernels to relabel filesystem after reboot, then will be ready to use
the test platform to do selinux vs non-selinux performance testing as
well. Our partitions will be 1, 4, 8, and 16 cpus providing for smp
testing as well - hopefully those will be ready by next week.


******************************************************************
******************************************************************
************************** SMP RESULTS **************************
******************************************************************
******************************************************************

******************************************************************
dbench:
******************************************************************
nostack:
4 clients started
2 59047 1315.65 MB/sec
0 62477 1296.84 MB/sec
Throughput 1296.79 MB/sec 4 procs

4 clients started
2 59162 1319.01 MB/sec
0 62477 1304.69 MB/sec
Throughput 1304.61 MB/sec 4 procs

stack:

4 clients started
2 59181 1320.55 MB/sec
0 62477 1264.77 MB/sec
Throughput 1264.72 MB/sec 4 procs

4 clients started
2 57840 1293.95 MB/sec
0 62477 1241.75 MB/sec
Throughput 1241.7 MB/sec 4 procs

******************************************************************
reaim
******************************************************************
nostack

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.05 0.02 0.01 122400.00 122400.00 0.00 0.00 100
3 0.05 0.04 0.04 367200.00 122400.00 0.01 20.41 79
5 0.07 0.06 0.07 437142.86 87428.57 0.01 12.90 87
7 0.11 0.08 0.11 389454.55 55636.36 0.02 23.15 76
9 0.13 0.10 0.13 423692.31 47076.92 0.02 22.96 77
Max Jobs per Minute 437142.86

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.06 0.01 0.01 102000.00 102000.00 0.00 0.00 100
3 0.06 0.04 0.04 306000.00 102000.00 0.01 26.73 73
5 0.07 0.06 0.07 437142.86 87428.57 0.01 14.29 85
7 0.11 0.09 0.09 389454.55 55636.36 0.01 14.66 85
9 0.14 0.10 0.13 393428.57 43714.29 0.02 19.57 80
Max Jobs per Minute 437142.86

stack

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.06 0.01 0.02 102000.00 102000.00 0.00 0.00 100
3 0.04 0.04 0.04 459000.00 153000.00 0.00 12.86 87
5 0.08 0.06 0.07 382500.00 76500.00 0.01 15.65 84
7 0.11 0.09 0.10 389454.55 55636.36 0.01 8.45 91
9 0.14 0.12 0.12 393428.57 43714.29 0.03 23.47 76
Max Jobs per Minute 459000.00

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.07 0.01 0.02 87428.57 87428.57 0.00 0.00 100
3 0.05 0.04 0.04 367200.00 122400.00 0.01 20.41 79
5 0.07 0.06 0.08 437142.86 87428.57 0.01 20.11 79
7 0.10 0.09 0.10 428400.00 61200.00 0.02 18.11 81
9 0.15 0.12 0.12 367200.00 40800.00 0.03 21.52 78
Max Jobs per Minute 437142.86


******************************************************************
tbench
******************************************************************
nostack

1 clients started
1 41049 236.11 MB/sec
0 62477 230.37 MB/sec
Throughput 230.368 MB/sec 1 procs

1 clients started
1 41418 236.52 MB/sec
0 62477 232.07 MB/sec
Throughput 232.068 MB/sec 1 procs

stack

1 clients started
1 41029 236.10 MB/sec
0 62477 230.75 MB/sec
Throughput 230.742 MB/sec 1 procs

1 clients started
1 41463 236.53 MB/sec
0 62477 231.87 MB/sec
Throughput 231.86 MB/sec 1 procs

******************************************************************
kernbench (different set of testruns)
******************************************************************
nostack (run 1)
169.13user 30.91system 1:40.91elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.55user 30.44system 1:40.81elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.36user 30.67system 1:40.86elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k

(run 2)
169.40user 30.39system 1:40.89elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.32user 30.44system 1:40.76elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.16user 30.59system 1:40.63elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k

sys average: 30.573333 stdev .178948

stack (run 1):
169.36user 31.18system 1:41.23elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.38user 31.34system 1:41.26elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.50user 31.09system 1:41.17elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k

(run 2)
169.32user 30.90system 1:40.91elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.12user 31.11system 1:40.93elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
169.25user 30.92system 1:40.87elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k

sys average: 31.090000 stdev .150555

******************************************************************
******************************************************************
************************* 1-cpu RESULTS *************************
******************************************************************
******************************************************************

(smp compiled in, but boot param "max_cpus=1" specified.)

******************************************************************
dbench:
******************************************************************
nostack

4 clients started
2 58485 1305.96 MB/sec
0 62477 1280.57 MB/sec
Throughput 1280.5 MB/sec 4 procs

4 clients started
2 55942 1253.94 MB/sec
0 62477 1189.63 MB/sec
Throughput 1189.58 MB/sec 4 procs

stack

4 clients started
2 54967 1233.77 MB/sec
0 62477 1157.91 MB/sec
Throughput 1157.87 MB/sec 4 procs

4 clients started
2 54330 1215.41 MB/sec
0 62477 1193.88 MB/sec
Throughput 1193.83 MB/sec 4 procs

******************************************************************
reaim
******************************************************************
nostack

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.06 0.01 0.01 102000.00 102000.00 0.00 0.00 100
3 0.06 0.04 0.04 306000.00 102000.00 0.01 35.36 64
5 0.08 0.06 0.07 382500.00 76500.00 0.01 21.19 78
7 0.09 0.09 0.09 476000.00 68000.00 0.02 24.81 75
9 0.14 0.12 0.12 393428.57 43714.29 0.02 22.38 77
Max Jobs per Minute 476000.00

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.06 0.02 0.01 102000.00 102000.00 0.00 0.00 100
3 0.05 0.03 0.04 367200.00 122400.00 0.00 10.88 89
5 0.08 0.05 0.08 382500.00 76500.00 0.01 21.40 78
7 0.11 0.09 0.09 389454.55 55636.36 0.01 11.17 88
9 0.14 0.11 0.12 393428.57 43714.29 0.02 18.07 81
Max Jobs per Minute 393428.57


stack

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.05 0.01 0.01 122400.00 122400.00 0.00 0.00 100
3 0.05 0.04 0.04 367200.00 122400.00 0.01 20.41 79
5 0.08 0.07 0.06 382500.00 76500.00 0.00 5.56 94
7 0.12 0.10 0.09 357000.00 51000.00 0.01 13.52 86
9 0.13 0.13 0.12 423692.31 47076.92 0.02 20.40 79
Max Jobs per Minute 423692.31

Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI
Forked Time SysTime UTime Minute Child Time Percent
1 0.06 0.02 0.02 102000.00 102000.00 0.00 0.00 100
3 0.05 0.04 0.04 367200.00 122400.00 0.01 20.41 79
5 0.08 0.07 0.06 382500.00 76500.00 0.01 18.81 81
7 0.11 0.10 0.09 389454.55 55636.36 0.01 7.73 92
9 0.14 0.11 0.13 393428.57 43714.29 0.02 18.07 81
Max Jobs per Minute 393428.57

******************************************************************
tbench
******************************************************************
nostack

1 clients started
1 41485 236.59 MB/sec
0 62477 232.49 MB/sec
Throughput 232.489 MB/sec 1 procs

1 clients started
1 42198 238.51 MB/sec
0 62477 235.67 MB/sec
Throughput 235.659 MB/sec 1 procs

stack

1 clients started
1 43927 250.33 MB/sec
0 62477 240.07 MB/sec
Throughput 240.061 MB/sec 1 procs

1 clients started
1 40385 233.38 MB/sec
0 62477 227.70 MB/sec
Throughput 227.694 MB/sec 1 procs

******************************************************************
kernbench (different set of testruns)
******************************************************************
nostack

169.07user 29.27system 1:39.99elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
168.83user 29.69system 1:40.10elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
168.84user 29.46system 1:40.07elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k

sys average: 29.473333 stdev 0.171723

stack

168.60user 29.42system 1:40.05elapsed 197%CPU (0avgtext+0avgdata 0maxresident)k
168.42user 29.52system 1:39.78elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k
168.85user 29.28system 1:39.87elapsed 198%CPU (0avgtext+0avgdata 0maxresident)k

sys average: 29.406667 stdev 0.098432

[Casey Schaufler]

Post by s***@us.ibm.com
Hi,
I've completed a set of stacker performance tests
using our automated test
platform. ...

Thank you very much for these well designed,
professionally presented benchmark results.


Casey Schaufler
***@schaufler-ca.com



Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.com/

[Stephen Smalley]

Post by s***@us.ibm.com
I've completed a set of stacker performance tests using our automated test
platform. The machine I'm using right now will go away soon, but we're
working on a set of (ppc64) partitions for selinux testing under the same
platform. I am reporting on one particular set of results, but if you
want anything changed - ie if you want profiling info - I should be able
to run more/new tests during the rest of this week at least.
I used a 2xamd64 machine with smp enabled, preemption disabled, running
fedora core 3 enforcing a custom dummy selinux policy. The kernel was
2.6.12-rc2. The sets of tests were run twice each on kernels with
selinux and capability enabled
and
stacker, selinux, and the stacking capability module enabled

Minor issue: It would be nice if we could ensure that capabilities and
cap_stack are not simultaneously enabled; after applying the patches and
performing a basic make menuconfig (which automatically selected stacker
and cap_stack since I had SELinux already enabled), I ended up with
stacker, selinux, capability, and cap_stack all enabled by accident.
Thus, I still ran into the inode_setxattr restrictions of capability and
the initial restorecon on /dev failed and the system didn't get very
far. Disabling capability worked much better, but I could easily see a
distributor accidentally enabling them both without thinking about it.

Stacker lacks a settime hook, possibly others but I didn't see any other
gaps. More generally, this adds another step in adding a new hook to
LSM that everyone needs to be aware of; possibly should be noted in
security.h. Would be useful to have a script for checking stacker hooks
against security.h or dummy module.

The stacker warnings about preventing unloading are amusing but have to
go, of course. Stacker should likely be displaying something upon
successful registration to indicate that it is the primary LSM.

I'd expect an objection ultimately to the limitation of getprocattr and
setprocattr to SELinux and the SELinux-specific handling in stacker,
although I'm certainly not excited about having to update userspace to
deal with multiple attributes via that interface.

An obvious concern is what open source modules are going to use this to
stack with SELinux. I see that the integrity measurement module has
been posted to lkml, but it only implements a handful of hooks and is
not an access control module. Which raises the question of whether it
should be using LSM or its own set of specialized measurement hooks.

Post by s***@us.ibm.com
Following are the summarized results. Of course, 'nostack' refers to a
kernel compiled without stacker, and 'stack' refers to a kernel with
stacker. The 2-cpu results come first, followed by the 1-cpu results.

One of my performance-related concerns is whether there is any impact on
scalability to large numbers of processors, as in KaiGai's earlier
testing for the AVC RCU work. I'd tend to not expect a significant
impact given the relatively lockless approach, but one never knows until
you see the data. Are you able to perform such testing, or perhaps
someone should ask KaiGai if he could repeat such testing with your
patches applied?

Post by s***@us.ibm.com
PS - I just need to add a bit of boot time checking for non-selinux
kernels to relabel filesystem after reboot, then will be ready to use
the test platform to do selinux vs non-selinux performance testing as
well. Our partitions will be 1, 4, 8, and 16 cpus providing for smp
testing as well - hopefully those will be ready by next week.

This sounds good.

[Serge E. Hallyn]

Quoting Stephen Smalley (***@tycho.nsa.gov):

Thanks for your comments, Stephen. All right on, of course.

Post by Stephen Smalley
Minor issue: It would be nice if we could ensure that capabilities and
cap_stack are not simultaneously enabled; after applying the patches and

True, I've done it too... I was hesitant about adding an 'unselect'
option to the Kconfig language, but it occurs to me using "depend on x=n"
should work.

Post by Stephen Smalley
Stacker lacks a settime hook, possibly others but I didn't see any other
gaps. More generally, this adds another step in adding a new hook to
LSM that everyone needs to be aware of; possibly should be noted in
security.h. Would be useful to have a script for checking stacker hooks
against security.h or dummy module.

On Friday I implemented a check when stacker is loaded, but that was
very unsatisfying. Only options at that point are crash the kernel
or print an error message and return -EINVAL, which is so early in the
boot process that I couldn't notice the error, and the kernel just
proceeded to load SELinux only.

As you say I'll add a little script called from the makefile, and have
it run on both dummy and stacker.

Post by Stephen Smalley
The stacker warnings about preventing unloading are amusing but have to
go, of course. Stacker should likely be displaying something upon
successful registration to indicate that it is the primary LSM.

Will do.

Post by Stephen Smalley
I'd expect an objection ultimately to the limitation of getprocattr and
setprocattr to SELinux and the SELinux-specific handling in stacker,
although I'm certainly not excited about having to update userspace to
deal with multiple attributes via that interface.

Oh, as of very recently, I'm actually able to volunteer to do that :)
So I'll happily update whatever I can find, though I'm not sure where
all the patches should go and what all needs to be patched. Clearly
selinuxfs and procutils. I'll dig around.

(I had been considering just leaving procattr unaddressed, but was
told last friday that another module will in fact be able to make
good use of it)

Post by Stephen Smalley
An obvious concern is what open source modules are going to use this to
stack with SELinux. I see that the integrity measurement module has
been posted to lkml, but it only implements a handful of hooks and is
not an access control module. Which raises the question of whether it
should be using LSM or its own set of specialized measurement hooks.

I'm not very "in the loop", but I understand there is another similar
TPM based module which performs authorization, which should be released
soon. It actually consists of two modules and so uses stacker just by
itself. Of course there is digsig for people without TPMs. And
seclvl.

Post by Stephen Smalley
One of my performance-related concerns is whether there is any impact on
scalability to large numbers of processors, as in KaiGai's earlier
testing for the AVC RCU work. I'd tend to not expect a significant
impact given the relatively lockless approach, but one never knows until
you see the data. Are you able to perform such testing, or perhaps
someone should ask KaiGai if he could repeat such testing with your
patches applied?

I should be able to test on 16 cpus this week. If you'd prefer also
32-cpu, then I will mail KaiGai.

thanks,
-serge

[Stephen Smalley]

Post by Serge E. Hallyn
Oh, as of very recently, I'm actually able to volunteer to do that :)
So I'll happily update whatever I can find, though I'm not sure where
all the patches should go and what all needs to be patched. Clearly
selinuxfs and procutils. I'll dig around.

s/selinuxfs/libselinux, right?
Yes, libselinux and procps would definitely need to be
changed. /etc/rc.d/rc.sysinit on Fedora/RHEL is also directly
checking /proc/filesystems and /proc/self/attr/current to see whether
SELinux is enabled and a policy is loaded, but that could likely be
changed to use the selinuxenabled utility if it were moved to /sbin (so
that it is accessible when rc.sysinit is run even if /usr is a separate
partition).

The largest concern is backward compatibility, especially since FC3,
FC4, and RHEL4 will all have shipped with userlands that assume
that /proc/self/attr is the exclusive domain of SELinux. Or you'd have
to have a coordinated update to kernel and libselinux (and procps and
initscripts and whatever else).

Post by Serge E. Hallyn
(I had been considering just leaving procattr unaddressed, but was
told last friday that another module will in fact be able to make
good use of it)

An open source module?

Post by Serge E. Hallyn
I'm not very "in the loop", but I understand there is another similar
TPM based module which performs authorization, which should be released
soon. It actually consists of two modules and so uses stacker just by
itself. Of course there is digsig for people without TPMs. And
seclvl.

Not clear that any of these other than seclvl should be using LSM;
discussion on lkml for IMA suggests otherwise. No obvious value in
stacking seclvl with SELinux vs. configuring SELinux policy to impose
equivalent restrictions (but in a saner manner, since you can use policy
on a per-process level to deal with the exception cases where you have
to allow violations of the seclvl restrictions)?

[s***@us.ibm.com]

Post by Stephen Smalley

Post by Serge E. Hallyn
Oh, as of very recently, I'm actually able to volunteer to do that :)
So I'll happily update whatever I can find, though I'm not sure where
all the patches should go and what all needs to be patched. Clearly
selinuxfs and procutils. I'll dig around.

s/selinuxfs/libselinux, right?

Oops, yes.

Post by Stephen Smalley
The largest concern is backward compatibility, especially since FC3,
FC4, and RHEL4 will all have shipped with userlands that assume
that /proc/self/attr is the exclusive domain of SELinux. Or you'd have
to have a coordinated update to kernel and libselinux (and procps and
initscripts and whatever else).

We should be able to work around that in two ways. First, a boot time
argument to stacker could disable the new functionality.

Second, stacker could still know about selinux. In general, modules
read/write data as

module_name: data

But if stacker reads data not in that format from userspace, it sends it
to selinux. Stacker could write selinux's procattr info without a
leading "selinux: " if (a) a boot time arg tells it to, (b) a sysfs
directive tells it to, or (c) it has read data from selinux without the
leading "selinux: " before. I wonder whether, in case (c), we would
generally write to a procattr file before reading one...

Post by Stephen Smalley

Post by Serge E. Hallyn
(I had been considering just leaving procattr unaddressed, but was
told last friday that another module will in fact be able to make
good use of it)

An open source module?

Yes, I expect it to be GPL.

Post by Stephen Smalley
Not clear that any of these other than seclvl should be using LSM;
discussion on lkml for IMA suggests otherwise. No obvious value in

There are two reasons I'm still uncertain:

First, another very respected kernel developer's private auditfs
feedback included asking why the hooks which were next to LSM hooks
weren't using LSM. The answer in this case was that audit must always
run before an LSM. But that sounds to me like the issue for the ima
module itself is still open for debate.

Second, the other modules are in fact authorization modules, and so
could not use hooks which existed only for measurement.

Assuming the tpm authorization module was going to be an LSM, are
there reasons why it would not be useful with selinux? What about
digsig?

Post by Stephen Smalley
stacking seclvl with SELinux vs. configuring SELinux policy to impose
equivalent restrictions (but in a saner manner, since you can use policy
on a per-process level to deal with the exception cases where you have
to allow violations of the seclvl restrictions)?

Yes, I definately see your point about seclvl+selinux.

thanks,
-serge

[Stephen Smalley]

Post by s***@us.ibm.com
But if stacker reads data not in that format from userspace, it sends it
to selinux. Stacker could write selinux's procattr info without a
leading "selinux: " if (a) a boot time arg tells it to, (b) a sysfs
directive tells it to, or (c) it has read data from selinux without the
leading "selinux: " before. I wonder whether, in case (c), we would
generally write to a procattr file before reading one...

I don't think so; most programs precede SELinux-related processing by
checking is_selinux_enabled(), which both checks /proc/filesystems for
"selinuxfs" and checks /proc/self/attr/current for "kernel" (a hack to
see whether a policy has been loaded or whether we are still using the
initial SID strings). The other options still require explicit changes
in userspace to be coordinated with a kernel update for existing
releases to avoid breakage.

Post by s***@us.ibm.com
First, another very respected kernel developer's private auditfs
feedback included asking why the hooks which were next to LSM hooks
weren't using LSM. The answer in this case was that audit must always
run before an LSM. But that sounds to me like the issue for the ima
module itself is still open for debate.

I think that was just driven by not wanting to clutter the core kernel
with multiple hook calls at the same location. Note that it presumes
the same location is truly appropriate for the different purposes, which
is not always the case. But when it is the case, it can be addressed
by:
- calling a single static inline at that location that expands to one,
some, or none of the (security,audit,measure,verify) hooks depending on
kernel configuration, with a well-defined ordering among them, or
- creating a meta-hook infrastructure on which they all rely with a
common core of hooks shared by them, or
- using SELinux as the shared framework and directly integrating them
into it so that they can leverage its policy abstractions as well and
serve to reinforce the access controls rather than being redundant.

Post by s***@us.ibm.com
Second, the other modules are in fact authorization modules, and so
could not use hooks which existed only for measurement.
Assuming the tpm authorization module was going to be an LSM, are
there reasons why it would not be useful with selinux? What about
digsig?

It seems to me that they would be more useful as directly integrated
with and reinforcing MAC rather than operating in isolation or trying to
replicate functionality that is better provided by MAC. Using MAC for
integrity and confidentiality protection at runtime, reinforced using
cryptographic mechanisms to protect against bypass of the OS.

[James Morris]

Post by Stephen Smalley
- using SELinux as the shared framework and directly integrating them
into it so that they can leverage its policy abstractions as well and
serve to reinforce the access controls rather than being redundant.

Given that nobody has come up with an upstream alternative to SELinux
since the merging of LSM, this should certainly be considered.

In fact, there has recently been some discussion about removing LSM
completely and just using SELinux directly.


- James

[s***@us.ibm.com]

Post by James Morris

Post by Stephen Smalley
- using SELinux as the shared framework and directly integrating them
into it so that they can leverage its policy abstractions as well and
serve to reinforce the access controls rather than being redundant.

Given that nobody has come up with an upstream alternative to SELinux
since the merging of LSM, this should certainly be considered.

I wouldn't mind trying an implementation of digsig inside of selinux,
though I'm not sure when I would get the time. It should be quick,
though. And once that was in place, the TPM-based integrity
authorization module would be simple to convert.

But the fact remains that there are people who won't want to run
selinux. As we improve the selinux policy tools (and once this stacker
thing settles down I can finally get back to that!) that will diminish,
but in the meantime that is the situation. And so for now, it certainly
seems valid to run digsig+seclvl or seclvl+the tpm authorization module.

Post by James Morris
In fact, there has recently been some discussion about removing LSM
completely and just using SELinux directly.

Where was that? I'd like to see the discussion. Who knows, I may end
up agreeing. Or at least, I may end up agreeing that *eventually*
that's the place to go.

thanks,
-serge

[Crispin Cowan]

Post by James Morris
Given that nobody has come up with an upstream alternative to SELinux
since the merging of LSM, this should certainly be considered.
In fact, there has recently been some discussion about removing LSM
completely and just using SELinux directly.

A major design goal of LSM was that Linus does not have to choose which
security model to use, and does not have to maintain it. The lack of
modules *in Linus' tree* would seem to be evidence that this is working :)

As a supplier of a different security module than SELinux, I naturally
vehemently object to the suggestion of "just remove LSM and use SELinux
instead." That would be a huge step backwards. Linux is all about
choice, and LSM effectively provides for that choice. Sparing you all
the marketing hype, Immunix offers substantial advantages over SELinux
in many contexts, and LSM lets users make that choice.

Crispin

[James Morris]

Post by Crispin Cowan
As a supplier of a different security module than SELinux, I naturally
vehemently object to the suggestion of "just remove LSM and use SELinux
instead." That would be a huge step backwards. Linux is all about
choice, and LSM effectively provides for that choice.

In the years since LSM was included in the mainline kernel, SELinux has
been the only significant module implemented and also included in the
mainline kernel. So we have a generalized framework for one user,
SELinux, which itself is a generalized framework.

Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to. If you want them to care, for people to
fix bugs in it for free, and for more people to use it, then submit the
module for upstream inclusion. It seems rather strange that you haven't.

SELinux is limited by the LSM framework (which is sometimes good --
because it forces thinking in the general case -- but not always), and the
LSM framework itself is effectively not being used in the mainline kernel.

It's dead code, an unecesary abstraction layer between its one real user,
SELinux, and the core kernel.

Another isssue is that LSM is IMHO being increasingly mis-used as a way to
try and get rather arbitrary security code into the kernel, without due
justification, just because it has a few hooks in the right place, or
because S stands for security, or something.

This is an unfortunate side-effect of developing an infrastructure with
such weak semantics, and the initial grumblings from the core kernel
developers on this issue appear to have been on the money.

Developing infrastructure for imaginary users is always the wrong thing to
do. Historically, there were several potentially viable enhanced access
control models which may have become mainline LSMs, such as DTE, but
SELinux has supplanted all of them.

As for choice, your LSM module is not in the mainline kernel, so only
users of your particular kernel really get that choice. Why does LSM then
need to be in the upstream kernel? Why not just keep it in yours, to
support your out of tree security module. Why impose the burdens and
limitations of LSM on the upstream kernel, which effectively doesn't use
it? If you want LSM, feel free to keep it in your kernel and maintain it
yourself.

Alternatively, consider submitting your module upstream.


- James

[Crispin Cowan]

Post by James Morris

Post by Crispin Cowan
As a supplier of a different security module than SELinux, I naturally
vehemently object to the suggestion of "just remove LSM and use SELinux
instead." That would be a huge step backwards. Linux is all about
choice, and LSM effectively provides for that choice.

In the years since LSM was included in the mainline kernel, SELinux has
been the only significant module implemented and also included in the
mainline kernel. So we have a generalized framework for one user,
SELinux, which itself is a generalized framework.
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to. If you want them to care, for people to
fix bugs in it for free, and for more people to use it, then submit the
module for upstream inclusion. It seems rather strange that you haven't.

I find this to be a very odd perspective.

I think of LSM as an API. Its purpose is precisely to provide a layer of
abstraction so that kernel maintainers do *not* have to maintain the
modules. Linus said *very explicitly* that he did not want to maintain
security modules, and that was the point of LSM. I know of a large
number of LSM modules in development all over the place, and discounting
them just because they have not been imposed on the kernel community
seems arbitrary. So this "does not count" stuff sounds like a
contrivance to me.

I had *assumed* that the Linux kernel community was not interested in
maintaining and bugfixing my module, and so I deliberately avoided
submitting it as a courtesy. I similarly do not submit my applications
for mainline inclusion just because they use some Linux syscalls.

However, if mainstream kernel inclusion is required to "count" as a
user, then I'm happy to do that. The module code is GPL anyway, and
we'll start looking at what it will take to push it to mainstream. This
seems like a weird requirement to me, but if it is what's required, I
don't have a problem with it.

Crispin

[James Morris]

Post by Crispin Cowan

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to. If you want them to care, for people to
fix bugs in it for free, and for more people to use it, then submit the
module for upstream inclusion. It seems rather strange that you haven't.

I find this to be a very odd perspective.

I find it odd that you find it odd :-)

Post by Crispin Cowan
I think of LSM as an API. Its purpose is precisely to provide a layer of
abstraction so that kernel maintainers do *not* have to maintain the
modules. Linus said *very explicitly* that he did not want to maintain
security modules, and that was the point of LSM.

He wanted to avoid deciding on the "correct" access control model:
http://mail.wirex.com/pipermail/linux-security-module/2001-April/0005.html

(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

Post by Crispin Cowan
I know of a large number of LSM modules in development all over the
place, and discounting them just because they have not been imposed on
the kernel community seems arbitrary. So this "does not count" stuff
sounds like a contrivance to me.

This is fundamentally how Linux kernel development works. If you develop
code off in a corner and don't submit it to mainline, it's not part of
the mainline kernel.

Exactly like how this email is not part of Wikipedia.

Post by Crispin Cowan
I had *assumed* that the Linux kernel community was not interested in
maintaining and bugfixing my module, and so I deliberately avoided
submitting it as a courtesy.

That's a common misperception. By getting code included upstream, the
kernel developers are taking some responsibility for your code. If they
change something which affects your code, they'll then usually update
your code at the same time. More people will use it. You'll get more bug
reports and patches.

Post by Crispin Cowan
I similarly do not submit my applications for mainline inclusion just
because they use some Linux syscalls.

Please also refrain from submitting your keyboard and mouse, thanks.

Post by Crispin Cowan
However, if mainstream kernel inclusion is required to "count" as a
user, then I'm happy to do that. The module code is GPL anyway, and
we'll start looking at what it will take to push it to mainstream. This
seems like a weird requirement to me, but if it is what's required, I
don't have a problem with it.

Great.


- James

[Crispin Cowan]

Post by James Morris
http://mail.wirex.com/pipermail/linux-security-module/2001-April/0005.html

Indeed, choosing the "correct" module is very difficult, and may be
impossible, as different settings have different requirements.

Post by James Morris
(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

I argue that it definitely does not have such generality. A trivial
proof of that is that some setting may require a solution that is much
smaller (time, space, etc.) and thus SELinux would fail to qualify
precisely because of its generality.

LSM, in contrast, is at a lower level, and so can provide full
generality without bloat because it pushes the complexity to the module,
letting the user choose how much complexity they want to buy into.

Post by James Morris

Post by Crispin Cowan
I had *assumed* that the Linux kernel community was not interested in
maintaining and bugfixing my module, and so I deliberately avoided
submitting it as a courtesy.

That's a common misperception. By getting code included upstream, the
kernel developers are taking some responsibility for your code. If they
change something which affects your code, they'll then usually update
your code at the same time. More people will use it. You'll get more bug
reports and patches.

Ok. Sorry I misunderstood.

Post by James Morris

Post by Crispin Cowan
I similarly do not submit my applications for mainline inclusion just
because they use some Linux syscalls.

Please also refrain from submitting your keyboard and mouse, thanks.

:)

Post by James Morris

Post by Crispin Cowan
However, if mainstream kernel inclusion is required to "count" as a
user, then I'm happy to do that. The module code is GPL anyway, and
we'll start looking at what it will take to push it to mainstream. This
seems like a weird requirement to me, but if it is what's required, I
don't have a problem with it.

Great.

If that's what it takes to put this to rest, I'll concentrate on pushing
the code to mainstream instead of bitching about the limitations of SELinux.

Crispin

[Colin Walters]

Post by Crispin Cowan

Post by James Morris
(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

I argue that it definitely does not have such generality. A trivial
proof of that is that some setting may require a solution that is much
smaller (time, space, etc.) and thus SELinux would fail to qualify
precisely because of its generality.

This is a "proof"?

[Crispin Cowan]

Post by Colin Walters

Post by Crispin Cowan

Post by James Morris
(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

I argue that it definitely does not have such generality. A trivial
proof of that is that some setting may require a solution that is much
smaller (time, space, etc.) and thus SELinux would fail to qualify
precisely because of its generality.

This is a "proof"?

SELinux is big, slow, and complicated. Not everyone likes that. QED :)

Crispin

[Karl MacMillan]

-----Original Message-----
Sent: Wednesday, May 25, 2005 9:48 PM
To: Colin Walters
Subject: Re: New stacker performance results

Post by Colin Walters

Post by Crispin Cowan

Post by James Morris
(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

I argue that it definitely does not have such generality. A trivial
proof of that is that some setting may require a solution that is much
smaller (time, space, etc.) and thus SELinux would fail to qualify
precisely because of its generality.

This is a "proof"?

SELinux is big, slow, and complicated. Not everyone likes that. QED :)

Not to take this comment too seriously, but are you referring to the security
server currently provided by SELinux which implements TE or general framework
provided by SELinux (FLASK)? It doesn't seem like you are making that
distinction in your comments.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Crispin Cowan]

Post by Karl MacMillan

Post by Crispin Cowan
SELinux is big, slow, and complicated. Not everyone likes that. QED :)

Not to take this comment too seriously, but are you referring to the security
server currently provided by SELinux which implements TE or general framework
provided by SELinux (FLASK)? It doesn't seem like you are making that
distinction in your comments.

I have not done the detailed measurements to distinguish between the
FLASK layer and the TE layer. Most of the available information on
SELinux does not make such a distinction. The "big" comment is the size
of the module and the size of the set of associated utilities. The
"slow" comment is from SELinux's self-claimed overhead of 6-15% (Immunix
measures at 0-2%) as well as other anecdotal stories about poor
performance. The "complicated" remark comes from both the wide-spread
reputation that SELinux is very hard to use as well as direct
comparisons that we have done of trying to perform equivalent security
tasks with SELinux and Immunix.

Caveat: this "equivalent task" is to create a per-application policy,
what Red Hat calls the "targeted policy". Immunix was designed from the
outset to enforce a security model very similar to the targeted policy,
while SELinux is being pressed into service to do that. Conversely,
Immunix AppArmor was not designed to enforce anything like the SELinux
"strict policy", and making it do that would produce usability problems,
at the least.

All of which supports my point that there is more than one security
model that different users may want. LSM lets users choose the
appropriate model for them.

Crispin

[Karl MacMillan]

-----Original Message-----
Sent: Wednesday, May 25, 2005 10:30 PM
To: Karl MacMillan
Subject: Re: New stacker performance results

Post by Karl MacMillan

Post by Crispin Cowan
SELinux is big, slow, and complicated. Not everyone likes that. QED :)

Not to take this comment too seriously, but are you referring to the security
server currently provided by SELinux which implements TE or general framework
provided by SELinux (FLASK)? It doesn't seem like you are making that
distinction in your comments.

I have not done the detailed measurements to distinguish between the
FLASK layer and the TE layer. Most of the available information on
SELinux does not make such a distinction.

Just making certain that it was clear what we were discussing.

The "big" comment is the size
of the module and the size of the set of associated utilities.

Are you saying that the SELinux module has more code than is necessary to
implement its feature set? Is the "big" judgment in comparison to something
else, e.g. AppArmor? If so, does that size comparison really make sense based on
what the two modules implement?

Regardless, I'm not certain that the module size is necessarily important, only
the comprehensibility of the code, which in SELinux is quite good. I'm not
familiar with the AppArmor code so I can draw no conclusions.

Which utilities are you referring to? The required set of utilities is very
small and most are trivial.

The
"slow" comment is from SELinux's self-claimed overhead of 6-15% (Immunix
measures at 0-2%)

Are these benchmarks numbers comparable at all? Are they the same benchmarks?

Additionally, it is important to know whether what is being enforced is
equivalent. If SELinux is providing coverage of, say, a certain IPC mechanism
that AppArmor does not control at all then a comparison of IPC latency /
throughput from lmbench is not exactly useful (this is a contrived example -
what I have read about AppArmor leads me to believe that it lacks many of the
controls that SELinux provides but I do not know for sure).

If you want to make these assertions and have them be convincing, I suggest that
you provide enough detail to make them meaningful. Raw percentages with no other
context is hardly a meaningful comparison.

as well as other anecdotal stories about poor
performance.

This is even less useful than the raw percentages.

The "complicated" remark comes from both the wide-spread
reputation that SELinux is very hard to use as well as direct
comparisons that we have done of trying to perform equivalent security
tasks with SELinux and Immunix.

Well, this has been hashed to death many times in many places. The short answer
I have is that a) SELinux policy exposes the true complexities of the security
issues and b) is well suited to be generated from higher level abstractions that
hide some granularity where it is not needed.

SELinux provides the necessary controls required to implement a wide set of
security policies - I think that you would be hard pressed to create a language
with the expressive power that was more concise. When that flexibility is not
needed I think it is preferable to create abstractions above the current
language rather than starting from scratch. This last approach is just now
starting to be explored and I think that it will yield good results.

Caveat: this "equivalent task" is to create a per-application policy,
what Red Hat calls the "targeted policy". Immunix was designed from the
outset to enforce a security model very similar to the targeted policy,
while SELinux is being pressed into service to do that. Conversely,
Immunix AppArmor was not designed to enforce anything like the SELinux
"strict policy", and making it do that would produce usability problems,
at the least.
All of which supports my point that there is more than one security
model that different users may want. LSM lets users choose the
appropriate model for them.

This only supports your point if I accept that SELinux is "being pressed into
service to do that". There is nothing about the targeted policy that goes
against the core concepts of SELinux. In fact, I think the existence of the
targeted policy is a point in favor of the flexibility and generality of SELinux
policy.

BTW - I am not trying to argue for the removal of LSM, I'm simply trying to
accurately portray SELinux.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Crispin Cowan]

Post by Karl MacMillan

Post by Crispin Cowan
The "big" comment is the size
of the module and the size of the set of associated utilities.

Are you saying that the SELinux module has more code than is necessary to
implement its feature set? Is the "big" judgment in comparison to something
else, e.g. AppArmor? If so, does that size comparison really make sense based on
what the two modules implement?

I strongly believe that this is not the place to play "my module is
better than your module." I brought up the differences only to dispel
the claim that SELinux is so general that it can subsume all other
modules. If people stop arguing to remove LSM and replace it with
SELinux, then I will stop bitching about what I perceive are the
limitations of SELinux. At least here :)

Crispin

[Karl MacMillan]

-----Original Message-----
Sent: Wednesday, May 25, 2005 11:36 PM
To: Karl MacMillan
Subject: Re: New stacker performance results

Post by Karl MacMillan

Post by Crispin Cowan
The "big" comment is the size
of the module and the size of the set of associated utilities.

Are you saying that the SELinux module has more code than is necessary to
implement its feature set? Is the "big" judgment in comparison to something
else, e.g. AppArmor? If so, does that size comparison really make sense based

on

Post by Karl MacMillan
what the two modules implement?

I strongly believe that this is not the place to play "my module is
better than your module." I brought up the differences only to dispel
the claim that SELinux is so general that it can subsume all other
modules. If people stop arguing to remove LSM and replace it with
SELinux, then I will stop bitching about what I perceive are the
limitations of SELinux. At least here :)

Interesting . . . at no point did I say SELinux was better than anything or,
actually, argue for the removal of LSM.

Anyway, the point of this particular thread is about the generality of SELinux
and how that might influence a theoretical decision about the usefulness of LSM
- so it seems to me that the SELinux comments (both positive and negative) or on
topic.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Director of Software Engineering, Novell http://novell.com

[Crispin Cowan]

Post by Karl MacMillan

Post by Crispin Cowan
I strongly believe that this is not the place to play "my module is
better than your module." I brought up the differences only to dispel
the claim that SELinux is so general that it can subsume all other
modules. If people stop arguing to remove LSM and replace it with
SELinux, then I will stop bitching about what I perceive are the
limitations of SELinux. At least here :)

Interesting . . . at no point did I say SELinux was better than anything or,
actually, argue for the removal of LSM.

No, but other people did. As I said, I brought up the AppArmor/SELinux
comparison only to demonstrate that ditching LSM in favor of SELinux is
a bad idea.

Crispin

[Chris Wright]

Post by Crispin Cowan

Post by James Morris
http://mail.wirex.com/pipermail/linux-security-module/2001-April/0005.html

Indeed, choosing the "correct" module is very difficult, and may be
impossible, as different settings have different requirements.

Nit-pick...correct model.

And here, I completely agree. In fact, I suspect the SELinux guys agree
as well. I think Stephen and James are stating they've created someting
which can adapt to the requirements, and are simply questioning whether
SELinux can supplant LSM as the 'general mechanism.'

[Crispin Cowan]

Post by Chris Wright

Post by Crispin Cowan
Indeed, choosing the "correct" module is very difficult, and may be
impossible, as different settings have different requirements.

Nit-pick...correct model.

Sure, that is an old typo and thinko :)

Post by Chris Wright
And here, I completely agree. In fact, I suspect the SELinux guys agree
as well. I think Stephen and James are stating they've created someting
which can adapt to the requirements, and are simply questioning whether
SELinux can supplant LSM as the 'general mechanism.'

That is the notion that I take issue with.

I only said it once before, so for clarity: if having our module in-tree
is what matters, then I am happy to do it.

Crispin

[Stephen Smalley]

Post by Crispin Cowan
I only said it once before, so for clarity: if having our module in-tree
is what matters, then I am happy to do it.

That only makes sense if it can be used, i.e. the necessary userspace
tool for configuring it is also available. Is it still proprietary?

[James Morris]

Post by Crispin Cowan

Post by Chris Wright
And here, I completely agree. In fact, I suspect the SELinux guys agree
as well. I think Stephen and James are stating they've created someting
which can adapt to the requirements, and are simply questioning whether
SELinux can supplant LSM as the 'general mechanism.'

That is the notion that I take issue with.
I only said it once before, so for clarity: if having our module in-tree
is what matters, then I am happy to do it.

It's what matters in terms of considering if LSM should remain to support
your module.

Whether SELinux should be adopted as the general access control framework
for Linux is another issue.


- James

[Chris Wright]

Post by James Morris

Post by Crispin Cowan

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to. If you want them to care, for people to
fix bugs in it for free, and for more people to use it, then submit the
module for upstream inclusion. It seems rather strange that you haven't.

I find this to be a very odd perspective.

I find it odd that you find it odd :-)

Post by Crispin Cowan
I think of LSM as an API. Its purpose is precisely to provide a layer of
abstraction so that kernel maintainers do *not* have to maintain the
modules. Linus said *very explicitly* that he did not want to maintain
security modules, and that was the point of LSM.

http://mail.wirex.com/pipermail/linux-security-module/2001-April/0005.html

Yes, it's not about maintainership, it's about picking the right access
control model. Security researchers can't even agree, and Linus simply
wants to push the decision off onto the folks who care about it.

Post by James Morris
(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

Hehe, clearly it wasn't or we wouldn't be where we are now. Recall, LSM
came out of rejecting SELinux.

[Stephen Smalley]

Post by Chris Wright

Post by James Morris
(I would argue that his "truly generic" requirement was fulfilled by
SELinux).

Hehe, clearly it wasn't or we wouldn't be where we are now. Recall, LSM
came out of rejecting SELinux.

I think that was more of a perception/communication problem than
anything else. Linus seemed to hear the SELinux talk at the 2001 Kernel
Summit as SELinux == TE rather than SELinux == flexible MAC architecture
that can support TE, MLS, and other models easily. No criticism
intended, likely just poor communication on our part, but it did seem
like a misunderstanding at the time.

[Chris Wright]

Post by Crispin Cowan

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to. If you want them to care, for people to
fix bugs in it for free, and for more people to use it, then submit the
module for upstream inclusion. It seems rather strange that you haven't.

I find this to be a very odd perspective.
I think of LSM as an API. Its purpose is precisely to provide a layer of
abstraction so that kernel maintainers do *not* have to maintain the
modules. Linus said *very explicitly* that he did not want to maintain
security modules, and that was the point of LSM. I know of a large
number of LSM modules in development all over the place, and discounting
them just because they have not been imposed on the kernel community
seems arbitrary. So this "does not count" stuff sounds like a
contrivance to me.
I had *assumed* that the Linux kernel community was not interested in
maintaining and bugfixing my module, and so I deliberately avoided
submitting it as a courtesy. I similarly do not submit my applications
for mainline inclusion just because they use some Linux syscalls.

OK. this is a major misconception. James did a good job of describing
the 'rules of the game,' but I'll reiterate.

Core kernel code is there to serve its users. The users are considered to
be those in-tree (and also those making a concerted effort to get there).

Post by Crispin Cowan
However, if mainstream kernel inclusion is required to "count" as a
user, then I'm happy to do that. The module code is GPL anyway, and
we'll start looking at what it will take to push it to mainstream. This
seems like a weird requirement to me, but if it is what's required, I
don't have a problem with it.

Put it this way...in-tree code has a say in the interfaces it uses, out
of tree code doesn't really have the same luxury. There's no such thing
as a stable internal kernel api. Being out of tree means you risk
losing a functional piece of an api simply because in-tree users no
longer needed it.

[Thomas Bleher]

* Crispin Cowan <***@novell.com> [2005-05-26 02:25]:
[... discussion about AppArmor and LSM...]

Post by Crispin Cowan
However, if mainstream kernel inclusion is required to "count" as a
user, then I'm happy to do that. The module code is GPL anyway, and
we'll start looking at what it will take to push it to mainstream. This
seems like a weird requirement to me, but if it is what's required, I
don't have a problem with it.

That's very nice to hear. Is the code available for download anywhere?
I'd like to look at it and browsed your site but couldn't find anything.

Thomas

[Stephen Smalley]

Post by Thomas Bleher
That's very nice to hear. Is the code available for download anywhere?
I'd like to look at it and browsed your site but couldn't find anything.

The subdomain kernel module is included in recent SuSE Linux kernel
source RPMs (both SL9.3 and SLES9, albeit with some differences). I
don't know about the userspace tools - they used to be proprietary I
believe.

[Chris Wright]

Post by James Morris
In the years since LSM was included in the mainline kernel, SELinux has
been the only significant module implemented and also included in the
mainline kernel. So we have a generalized framework for one user,
SELinux, which itself is a generalized framework.

Ahh, the irony ;-) Sounds like reiser4, in fact didn't they recommend
being the VFS (/me runs).

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to. If you want them to care, for people to
fix bugs in it for free, and for more people to use it, then submit the
module for upstream inclusion. It seems rather strange that you haven't.

This is actually quite important point that James makes. I disagree
that out of tree code counts for nothing (afterall even SELinux started
as out of tree code ;-), but it has a lot less to say on in tree
code/design/etc. Point being, you can't expect anything from the core
if you aren't giving anything back. And, in nearly all cases, the
process of submitting code improves the code.

Post by James Morris
SELinux is limited by the LSM framework (which is sometimes good --
because it forces thinking in the general case -- but not always), and the
LSM framework itself is effectively not being used in the mainline kernel.

Be specific, it will help make your point. As it is, it sounds quite
handwavy. Of course, it's not true that the LSM framework is not
being used. What's true is that it's a thin layer that provides only
the upcall mechanism for SELinux (from your perspective). But then,
that's all it's supposed to do, be an upcall mechanism.

Post by James Morris
It's dead code, an unecesary abstraction layer between its one real user,
SELinux, and the core kernel.

Hey, you keep forgetting about capabilities...

Post by James Morris
Another isssue is that LSM is IMHO being increasingly mis-used as a way to
try and get rather arbitrary security code into the kernel, without due
justification, just because it has a few hooks in the right place, or
because S stands for security, or something.
This is an unfortunate side-effect of developing an infrastructure with
such weak semantics, and the initial grumblings from the core kernel
developers on this issue appear to have been on the money.

Have to agree.

Post by James Morris
Developing infrastructure for imaginary users is always the wrong thing to
do. Historically, there were several potentially viable enhanced access
control models which may have become mainline LSMs, such as DTE, but
SELinux has supplanted all of them.

Developing infrastructure for real users makes sense. As you mention,
there are other security models besides SELinux that helped shape LSM.
What's sad is the lack of those in mainline.

Post by James Morris
As for choice, your LSM module is not in the mainline kernel, so only
users of your particular kernel really get that choice. Why does LSM then
need to be in the upstream kernel? Why not just keep it in yours, to
support your out of tree security module. Why impose the burdens and
limitations of LSM on the upstream kernel, which effectively doesn't use
it? If you want LSM, feel free to keep it in your kernel and maintain it
yourself.

What are these burdens and limitations you keep alluding to? They
should be addressed as technical issues.

[Stephen Smalley]

Post by Chris Wright
Ahh, the irony ;-) Sounds like reiser4, in fact didn't they recommend
being the VFS (/me runs).

One difference is that the VFS and numerous filesystem implementations
predated reiser4. In contrast, SELinux predated LSM, helped to drive
LSM's development, and is the only significant user of the hooks in the
kernel.

Post by Chris Wright
Hey, you keep forgetting about capabilities...

Likely because it isn't a compelling example. Capability bits are still
in the core kernel data structures, core kernel still directly tests
capability bits via cap_raised, capability/setuid evolution logic had to
be re-integrated to avoid races, capabilities was never an independent
access control model to start with, and it only needs a few hooks. And
despite the "modularization" of it, there has been no real
experimentation with alternatives/variants to the existing capability
logic.

[Bob Bennett]

Post by James Morris

Post by Stephen Smalley
- using SELinux as the shared framework and directly integrating them
into it so that they can leverage its policy abstractions as well and
serve to reinforce the access controls rather than being redundant.

Given that nobody has come up with an upstream alternative to SELinux
since the merging of LSM, this should certainly be considered.
In fact, there has recently been some discussion about removing LSM
completely and just using SELinux directly.

To remove LSM completely would be tragic. LSM, while not perfect,
provides a very nice means to develop an access control implementation
without creating a custom kernel. After all, isn't _choice_ what Linux
is all about? The architecture should allow alternative
implementations.

- Bob Bennett
Computer Associates

Post by James Morris
- James

[Greg KH]

Post by James Morris
Given that nobody has come up with an upstream alternative to SELinux
since the merging of LSM, this should certainly be considered.

Hm, what about root-plug? :)

Post by James Morris
In fact, there has recently been some discussion about removing LSM
completely and just using SELinux directly.

Hm, I must have missed that discussion. Any pointers to it?

thanks,

greg k-h

[James Morris]

Post by Greg KH
Hm, I must have missed that discussion. Any pointers to it?

Also answering Serge's query, it was not a public discussion, the issue
came up when I was talking to a couple of core kernel maintainers about an
LSM which was submitted a few weeks ago (from memory). They were also
concerned that SELinux is the only significant in-tree user of LSM and
that LSM is attracting some (IMHO) inappropriate code submissions into the
mainline kernel.


- James

[Crispin Cowan]

Post by James Morris
Also answering Serge's query, it was not a public discussion, the issue
came up when I was talking to a couple of core kernel maintainers about an
LSM which was submitted a few weeks ago (from memory). They were also
concerned that SELinux is the only significant in-tree user of LSM and
that LSM is attracting some (IMHO) inappropriate code submissions into the
mainline kernel.

What constitutes "inappropriate" here?

Crispin

[James Morris]

Post by Crispin Cowan
What constitutes "inappropriate" here?

In my view, LSM should be used for significantly enhancing access control
systems.

See:
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0300.html


- James

[Chris Wright]

Post by James Morris

Post by Crispin Cowan
What constitutes "inappropriate" here?

In my view, LSM should be used for significantly enhancing access control
systems.

LSM is an access control interface (yeah, James, I know, I'm preaching
to the choir). How you squint and draw a line for access control may
have some room for debate, but one classic example has been keeping
audit separate from access control.

[Tony Jones]

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to.

If I recall correctly LSM was created precisely because Linus didn't care
about security and didn't want to. In the context of this I don't understand
most of the above.

Post by James Morris
As for choice, your LSM module is not in the mainline kernel, so only
users of your particular kernel really get that choice. Why does LSM then
need to be in the upstream kernel? Why not just keep it in yours, to
support your out of tree security module. Why impose the burdens and
limitations of LSM on the upstream kernel.

a) Is LSM as it's currently defined a burden and limitation on the upstream
kernel? Serious question. I'm curious if it is actually viewed this way. I
can see that the interface doesn't let you easily do what you'd like (it
doesn't for us either) and that changes you would like expose a potential
additional burden and thus get rejected but this isn't the same thing.

b) LSM exists in the kernel to support a variety of modules which _users_ can
choose to load on their stock 2.6 kernel as they see fit. It is of
course hard to form any lucid argument once it's been decided that
maintainers are the only ones who count.

Thanks

Tony

[James Morris]

Post by Tony Jones

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to.

If I recall correctly LSM was created precisely because Linus didn't care
about security and didn't want to. In the context of this I don't understand
most of the above.

My reading is that he didn't want to have to choose the security model, to
paint Linux into a particular corner.

Post by Tony Jones

Post by James Morris
As for choice, your LSM module is not in the mainline kernel, so only
users of your particular kernel really get that choice. Why does LSM then
need to be in the upstream kernel? Why not just keep it in yours, to
support your out of tree security module. Why impose the burdens and
limitations of LSM on the upstream kernel.

a) Is LSM as it's currently defined a burden and limitation on the upstream
kernel? Serious question. I'm curious if it is actually viewed this way. I
can see that the interface doesn't let you easily do what you'd like (it
doesn't for us either) and that changes you would like expose a potential
additional burden and thus get rejected but this isn't the same thing.

It's a burden in that it needs to be taken into account by several core
and other kernel maintainers when they modify the kernel or review patches
which modify the kernel. If SELinux is to be the only user, then it's
difficult to justify the continued presence of the LSM code.

I'm not talking about the burden to SELinux developers of implementing and
upstreaming new LSM hooks if required (which, as I said, is even often
useful as it requires more generalized design).

Post by Tony Jones
b) LSM exists in the kernel to support a variety of modules which _users_ can
choose to load on their stock 2.6 kernel as they see fit. It is of
course hard to form any lucid argument once it's been decided that
maintainers are the only ones who count.

I don't understand the second sentence.


- James

[Tony Jones]

Post by James Morris
It's a burden in that it needs to be taken into account by several core
and other kernel maintainers when they modify the kernel or review patches
which modify the kernel. If SELinux is to be the only user, then it's
difficult to justify the continued presence of the LSM code.

But the LSM hooks aren't going to just dissapear. Under what you propose they
will be replaced by other SELinux specific calls. How does this change the
impact to core/other kernel maintainers when they make changes? They are
still going to be faced with making changes near call points whose purpose
they may not be overly familiar with. Are you saying that the issue is the
lack of availability of source for the LSM module? You've already said that as
far as they are concerned SELinux is the only LSM module that matters and it's
source is intree.

Thanks

Tony

[James Morris]

Post by Tony Jones

Post by James Morris
It's a burden in that it needs to be taken into account by several core
and other kernel maintainers when they modify the kernel or review patches
which modify the kernel. If SELinux is to be the only user, then it's
difficult to justify the continued presence of the LSM code.

But the LSM hooks aren't going to just dissapear. Under what you propose they
will be replaced by other SELinux specific calls. How does this change the
impact to core/other kernel maintainers when they make changes? They are
still going to be faced with making changes near call points whose purpose
they may not be overly familiar with.

That's a good point. Yes, the SELinux specific calls would still be
there.

The differences for cor maintainers would be:

a) Clearer semantics, i.e. being able to trace the flow directly into the
SELinux code and be able to see exactly what's happening.

b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many,
but not a large amount).

I'd imagine that (a) would generally be seen now as a good thing, compared
to the case of no other in-tree LSM users.

Post by Tony Jones
Are you saying that the issue is the lack of availability of source for
the LSM module? You've already said that as far as they are concerned
SELinux is the only LSM module that matters and it's source is intree.

It's not about availability, it's about whether the code is part of
mainline. What's in mainline is the kernel. Out of tree kernel modules
are not part of the kernel.

Possibly there's some confusion because Linux does not have any real
kernel APIs (in the way that proprietary kernels do). It's a completely
different model.

The only guaranteed kernel interface is the syscall layer.


- James

[Tony Jones]

Post by James Morris

Post by Tony Jones
But the LSM hooks aren't going to just dissapear. Under what you propose they
will be replaced by other SELinux specific calls. How does this change the
impact to core/other kernel maintainers when they make changes? They are
still going to be faced with making changes near call points whose purpose
they may not be overly familiar with.

That's a good point. Yes, the SELinux specific calls would still be
there.
a) Clearer semantics, i.e. being able to trace the flow directly into the
SELinux code and be able to see exactly what's happening.

Sure, but the core developers have to work around such issues with VFS,
networking and many other function-pointer based interfaces.

I can read/understand what you are saying, that in your opinion only intree
LSM modules count and of those SELinux is the only one of any meaning and
therefore the cost of a function pointer interface is not acceptable since
there is only one true lsm module (again in your opinion).

Post by James Morris
Possibly there's some confusion because Linux does not have any real

I don't think there is confusion, just disagreement :-)
We don't agree over the purpose of the LSM interface. I don't agree that it's
purpose is to solely enable intree modules.

Post by James Morris
The only guaranteed kernel interface is the syscall layer.

What, SELinux can't replace it too. Kidding :-)

Tony

[Chris Wright]

Post by James Morris

Post by Tony Jones
But the LSM hooks aren't going to just dissapear. Under what you propose they
will be replaced by other SELinux specific calls. How does this change the
impact to core/other kernel maintainers when they make changes? They are
still going to be faced with making changes near call points whose purpose
they may not be overly familiar with.

That's a good point. Yes, the SELinux specific calls would still be
there.
a) Clearer semantics, i.e. being able to trace the flow directly into the
SELinux code and be able to see exactly what's happening.

I don't agree at all. If you can't follow a function pointer...
In fact, I don't even agree that that's the semantic issue. I think the
semantic issue is with the loose mechanism that information is passed
from core to security module. It errs on passing too much, and relies
on typeless data. If anything, the problem is the layer is too thin.

So perhaps here's where our opinions converge. Everybody wants to do
the same basic thing, control access between subject and object. Other
core subsystems do much more to enforce semantic rules, lifetime rules,
typed interfaces, cache maintainance, etc. on behalf of the users of the
subsystem. So, ideally what the access control module should see is only
the question we care about (does $subject get to take $action on $object).
Unfortunately, reality strikes when you want to have security model
specific ways to label $subject, interpret $action, and label $object).
SELinux has done a great job at make the access request generic through
the the avc. So, while you say drop LSM and just use SELinux, I would
say push avc into LSM...it's pretty simimlar in the end... Problem is,
you still have to deal with calling out to modules that want to do their
own label management, have their own policy language, etc. This is
where it starts to feel like you're just pushing the problem around.

Post by James Morris
b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many,
but not a large amount).

At any rate, neither of these (a, or b) are very strong reasoning for
removal. I'll listen to real ideas on how to improve the semantics of
core interfacing with security module (and no, I don't mean function
pointers, I mean real interface semantics).

[s***@us.ibm.com]

Post by Chris Wright
the same basic thing, control access between subject and object. Other
core subsystems do much more to enforce semantic rules, lifetime rules,
typed interfaces, cache maintainance, etc. on behalf of the users of the
subsystem. So, ideally what the access control module should see is only
the question we care about (does $subject get to take $action on $object).
Unfortunately, reality strikes when you want to have security model
specific ways to label $subject, interpret $action, and label $object).
SELinux has done a great job at make the access request generic through
the the avc. So, while you say drop LSM and just use SELinux, I would
say push avc into LSM...it's pretty simimlar in the end... Problem is,
you still have to deal with calling out to modules that want to do their
own label management, have their own policy language, etc. This is
where it starts to feel like you're just pushing the problem around.

Post by James Morris
b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many,
but not a large amount).

At any rate, neither of these (a, or b) are very strong reasoning for
removal. I'll listen to real ideas on how to improve the semantics of
core interfacing with security module (and no, I don't mean function
pointers, I mean real interface semantics).

So it sounds like what you'd like is something like:

1. split lsm hooks explicitly into state update (or labeling if you
prefer) hooks and authorization hooks

2. state update hooks still get the info they get now, ie inode, etc.

3. lsm provides some api for labeling objects inside the state update
hooks

4. the authorization hooks no longer send full inodes and task pointers,
but only send the labels which a module has assigned to those objects.

5. ... but the label data can still be structs etc (not just an integer
or char *). This could of course be abused by modules to just point
back to the inode and task, to bypass these controls...

6. modules can still be dynamically loaded

This would also mean that

7. The update hooks could become more general - not just for LSM, but
shared with audit and integrity measurement hooks.

Is that the kind of thing you're talking about, Chris?

thanks,
-serge

[James Morris]

Post by Chris Wright

Post by James Morris
a) Clearer semantics, i.e. being able to trace the flow directly into the
SELinux code and be able to see exactly what's happening.

I don't agree at all. If you can't follow a function pointer...

I wasn't talking about being able to follow a function pointer, but about
being able to see what's happening and not guess at the possible
semantics.

Post by Chris Wright

Post by James Morris
b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many,
but not a large amount).

At any rate, neither of these (a, or b) are very strong reasoning for
removal. I'll listen to real ideas on how to improve the semantics of
core interfacing with security module (and no, I don't mean function
pointers, I mean real interface semantics).

This is not the entire reasoning for removal, I was specifically
addressing burden on core kernel maintainers.

There's also issues of inappropriate LSMs being submitted, having an
essentially unused infrastructure in the kernel at all, and forcing
SELinux to always use a generic infrastructure when it's not always the
best way.


- James

[Chris Wright]

Post by James Morris

Post by Tony Jones

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to.

If I recall correctly LSM was created precisely because Linus didn't care
about security and didn't want to. In the context of this I don't understand
most of the above.

Yup, more or less.

Post by James Morris
My reading is that he didn't want to have to choose the security model, to
paint Linux into a particular corner.

More like to keep the other 9 people from complainingly ad nauseum, when
chosing only 1 out of 10.

[Chris Wright]

Post by Tony Jones

Post by James Morris
Note: out of tree kernel code does not count for anything. It's not
really part of the Linux kernel. Mainline maintainers don't care about it
and should not be expected to.

If I recall correctly LSM was created precisely because Linus didn't care
about security and didn't want to. In the context of this I don't understand
most of the above.

Well, there are two (nearly orthogonal) points. 1) kernel development
favors in-tree code over out-of-tree code, always. 2) LSM is there
because Linus got requests from various projects to be _the_ advanced
access control project in mainline Linux. His rule of thumb is to push
back on the people who care to come up with a solution when there's
competing interests.

So it's not really a question of who wants to maintain it. Code in
mainline comes with a maintainer (the submitter). The bonus to being
in mainline is that code will be taken into account as api's evolve
(which is always happening).

Post by Tony Jones

Post by James Morris
As for choice, your LSM module is not in the mainline kernel, so only
users of your particular kernel really get that choice. Why does LSM then
need to be in the upstream kernel? Why not just keep it in yours, to
support your out of tree security module. Why impose the burdens and
limitations of LSM on the upstream kernel.

a) Is LSM as it's currently defined a burden and limitation on the upstream
kernel? Serious question. I'm curious if it is actually viewed this way. I
can see that the interface doesn't let you easily do what you'd like (it
doesn't for us either) and that changes you would like expose a potential
additional burden and thus get rejected but this isn't the same thing.

No, I don't see it as a burden at all.

Post by Tony Jones
b) LSM exists in the kernel to support a variety of modules which _users_ can
choose to load on their stock 2.6 kernel as they see fit. It is of
course hard to form any lucid argument once it's been decided that
maintainers are the only ones who count.

No, there's two different maintainers involved here. One maintains
some core subsystem, another maintains some user of that subsystem.
What's at issue here is that maintainers of out-of-tree code typically
get much less sympathy from maintainers of in-tree core code. In other
words, infrastructure is not created to support out-of-tree users.

[Chris Wright]

Post by James Morris

Post by Stephen Smalley
- using SELinux as the shared framework and directly integrating them
into it so that they can leverage its policy abstractions as well and
serve to reinforce the access controls rather than being redundant.

Given that nobody has come up with an upstream alternative to SELinux
since the merging of LSM, this should certainly be considered.
In fact, there has recently been some discussion about removing LSM
completely and just using SELinux directly.

Yes, it was in the context of lack of meaningful in-tree modules.
A context which is certainly important. However, there's enough activity
in the area that dropping LSM would be a step backwards.

[s***@us.ibm.com]

Quoting Stephen Smalley (***@tycho.nsa.gov):

Most of your comments are addressed in the new tarball on
www.sf.net/lsm-stacker.

Post by Stephen Smalley
Minor issue: It would be nice if we could ensure that capabilities and
cap_stack are not simultaneously enabled; after applying the patches and
performing a basic make menuconfig (which automatically selected stacker

The attached patch (stacker-only-one-cap.patch) prevents capability.ko
from being selected when selinux and/or cap_stack are selected.

Part of me still prefers to implement 'unselect'. But I suspect that
it is preferred I make do with what is available.

Post by Stephen Smalley
Stacker lacks a settime hook, possibly others but I didn't see any other
gaps. More generally, this adds another step in adding a new hook to

Thanks - I sure hope I had it at one point, and wonder where it went...
At any rate there is now a settime hook.

Post by Stephen Smalley
LSM that everyone needs to be aware of; possibly should be noted in
security.h. Would be useful to have a script for checking stacker hooks
against security.h or dummy module.

Both are now in the sf.net patches, and in the attached
stack-dummy-verify.patch.

Post by Stephen Smalley
The stacker warnings about preventing unloading are amusing but have to
go, of course. Stacker should likely be displaying something upon
successful registration to indicate that it is the primary LSM.

Done.

Post by Stephen Smalley
I'd expect an objection ultimately to the limitation of getprocattr and
setprocattr to SELinux and the SELinux-specific handling in stacker,
although I'm certainly not excited about having to update userspace to
deal with multiple attributes via that interface.

...

Post by Stephen Smalley
One of my performance-related concerns is whether there is any impact on
scalability to large numbers of processors, as in KaiGai's earlier
testing for the AVC RCU work. I'd tend to not expect a significant
impact given the relatively lockless approach, but one never knows until
you see the data. Are you able to perform such testing, or perhaps
someone should ask KaiGai if he could repeat such testing with your
patches applied?

I will start now on the 16-cpu test system. Once that's going, I'll
start addressing procattr.

thanks,
-serge

[David A. Wheeler]

Thanks so much for these very nice performance results!
I feel vindicated in my original assertion about stacking
(that with a careful lockless approach, the overhead shouldn't be bad).

These performance results seem to suggest that the stacking overhead
is relatively small, in many cases negligeable. And it's
only paid by those who choose to use stacking anyway.
A delightful result!!

My thanks to those who continued the stacking work & turned it
into something actually useful.

--- David A. Wheeler

[Casey Schaufler]

Post by James Morris
In fact, there has recently been some discussion
about removing LSM
completely and just using SELinux directly.

In the Unix Era we made our share of mistakes,
especially with add on module interfaces and
extreme security implementations. STREAMS modules
and Information labels come to mind as prime
examples. I can think of no instance where the
two types of facilities were combined into the
same blunder.

SELinux is a poor choice for a general framework.
While Type Enforcement may be used to implement
many interesting policies it is far from universal.
SELinux is not a lightweight implementation, and
would be overkill if all you wanted was a minor
policy such as time-of-day access restrictions.
SELinux associates rights and privileges with
programs, a paradighm that has it's detractors.
But the most important problem that I see from
here is that nowhere is there a complete and
accurate description of how, *in general* one
would go about creating an arbitrary and
complete policy using SELinux.



Casey Schaufler
***@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[V***@vt.edu]

Post by Casey Schaufler
here is that nowhere is there a complete and
accurate description of how, *in general* one
would go about creating an arbitrary and
complete policy using SELinux.

Real-life example: There are many sites who do *not* necessarily need a
full-blown SELinux, but *do* want to express a policy that basically boils down
to "A chroot'ed process is not allowed to XYZ".

It appears the only way to do this inside SELinux is to define a special
chrooted_exec_t and force an auto_trans on exec. And in general, it's very
hard to write a predicate that says "A process in condition/state X" - one has
to enumerate all the possible binaries and create a separate
"might_do_x_exec_t" (particularly interesting if you have binaries that might
do X if run one way, but not another (think anything that behaves differently
if launched from Cron) and start writing policy. And if a given process might
end up in X *or* Y *or* Z, things start getting very ugly...

[Stephen Smalley]

Post by V***@vt.edu
Real-life example: There are many sites who do *not* necessarily need a
full-blown SELinux, but *do* want to express a policy that basically boils down
to "A chroot'ed process is not allowed to XYZ".
It appears the only way to do this inside SELinux is to define a special
chrooted_exec_t and force an auto_trans on exec. And in general, it's very
hard to write a predicate that says "A process in condition/state X" - one has
to enumerate all the possible binaries and create a separate
"might_do_x_exec_t" (particularly interesting if you have binaries that might
do X if run one way, but not another (think anything that behaves differently
if launched from Cron) and start writing policy. And if a given process might
end up in X *or* Y *or* Z, things start getting very ugly...

The difficulties in creating an effective jail have nothing to do with
SELinux per se, and trying to do one without the full range of control
offered by SELinux is likely to expose you to holes.

[Stephen Smalley]

Post by Stephen Smalley

Post by V***@vt.edu
Real-life example: There are many sites who do *not* necessarily need a
full-blown SELinux, but *do* want to express a policy that basically boils down
to "A chroot'ed process is not allowed to XYZ".
It appears the only way to do this inside SELinux is to define a special
chrooted_exec_t and force an auto_trans on exec. And in general, it's very
hard to write a predicate that says "A process in condition/state X" - one has
to enumerate all the possible binaries and create a separate
"might_do_x_exec_t" (particularly interesting if you have binaries that might
do X if run one way, but not another (think anything that behaves differently
if launched from Cron) and start writing policy. And if a given process might
end up in X *or* Y *or* Z, things start getting very ugly...

The difficulties in creating an effective jail have nothing to do with
SELinux per se, and trying to do one without the full range of control
offered by SELinux is likely to expose you to holes.

BTW, SELinux does support dynamic context transitions these days via
setcon(3). Not that that I'd recommend using it over exec-based
transitions, mind you, but it does exist.

[V***@vt.edu]

Post by Stephen Smalley
BTW, SELinux does support dynamic context transitions these days via
setcon(3). Not that that I'd recommend using it over exec-based
transitions, mind you, but it does exist.

That *does* solve half the chroot problem. Still gotta write policy, but
at least you're only having to add one setcon() call to /sbin/chroot rather
than having to make sure that you relabel every binary that gets put into
the chroot jail.... :)

[Stephen Smalley]

Post by Stephen Smalley
BTW, SELinux does support dynamic context transitions these days via
setcon(3). Not that that I'd recommend using it over exec-based
transitions, mind you, but it does exist.

Also, there is runcon(1) if you just want to launch a given program in a
particular domain in one instance (e.g. for the chroot'ed environment)
while not having it run in that domain in other cases.

[V***@vt.edu]

Post by Stephen Smalley
The difficulties in creating an effective jail have nothing to do with
SELinux per se, and trying to do one without the full range of control
offered by SELinux is likely to expose you to holes.

Right. The point was that even if you *are* using SELinux, trying to
satisfy a security policy that says "A chrooted process may not..."
is difficult.

(And before you say "such a rule is silly", note that quite often, we're
not given a *choice* - sometimes we're given a rule and told "implement it"...)

[Stephen Smalley]

Post by V***@vt.edu

Post by Stephen Smalley
The difficulties in creating an effective jail have nothing to do with
SELinux per se, and trying to do one without the full range of control
offered by SELinux is likely to expose you to holes.

Right. The point was that even if you *are* using SELinux, trying to
satisfy a security policy that says "A chrooted process may not..."
is difficult.

Yes, but with SELinux, you have a chance at doing it because you have
comprehensive controls and you can apply a tool like apol to check
whether said process can ultimately reach a given state. If you choose
to implement your own little security module from scratch, you are much
less likely to hit the mark.

[Colin Walters]

Post by V***@vt.edu

Post by Stephen Smalley
The difficulties in creating an effective jail have nothing to do with
SELinux per se, and trying to do one without the full range of control
offered by SELinux is likely to expose you to holes.

Right. The point was that even if you *are* using SELinux, trying to
satisfy a security policy that says "A chrooted process may not..."
is difficult.

Why would your security policy specify implementation details like
chroot? A more sensible security policy would be something like "BIND
cannot affect the PostgreSQL server". With SELinux you can analyze all
the information flow from named_t to postgresql_t. With a chroot you
have no such guarantees. Your security goals should drive your
implementation choices, not the other way around.

[V***@vt.edu]

Post by Colin Walters
Why would your security policy specify implementation details like
chroot? A more sensible security policy would be something like "BIND
cannot affect the PostgreSQL server".

You weren't paying attention - I *granted* it was a silly rule. But every once
in a while, somebody screws up and lets the auditors get access to some 8x11
color glossy, and once that happens there's no shifting it. ;)

The point is that SELinux is able to do a very good job at controlling access
via a model where everything is *labelled*. It however does a *very* poor
job of making decisions based on *state* - are we chrooted? Are we this,
are we that?

Post by Colin Walters
With SELinux you can analyze all
the information flow from named_t to postgresql_t. With a chroot you
have no such guarantees. Your security goals should drive your
implementation choices, not the other way around.

A good while ago, I was discussing an LSM based on the OpenWall patches, and
the reasonable security goal of "don't follow a possibly hostile symlink". In
order to actually do it, you'd basically have to use the 'strict' policy,
give each user their own $USER_u - and then you could add the 5-6 lines of
policy that did the same as a 15-line LSM exit. Except the SELinux one
will have chewed up some 20M worth of avc_node slab entries (which makes a
noticeable difference if you're trying to secure an older box that only has
128M or 256M installed).

No, saying "get newer hardware" isn't an option, unless you're going to pay for
upgrading the entire lab full of machines. Also remember that I do *NOT* need
"perfect security even in the face of some 0-day nobody's ever seen before". I
need to prevent "student A uses 2-decade-old-trick to hose student B". I can't
*justify* spending all the resources to do a totally bulletproof setup. I however
can't justify not doing anything at all....

And yes, I *KNOW* the Right Answer there is "Use some other LSM that meets the
goals needed". The point is that there *DO* exist *real world* security issues
that the SELinux model is not all that well suited for.

[Crispin Cowan]

Post by V***@vt.edu
And yes, I *KNOW* the Right Answer there is "Use some other LSM that meets the
goals needed". The point is that there *DO* exist *real world* security issues
that the SELinux model is not all that well suited for.

Very well said.

The above is the main reason to keep LSM and not replace it with
SELinux. The details are an enumeration of the cases where an LSM of
some variety will do a better job than an SELinux policy.

Crispin

[Colin Walters]

Post by V***@vt.edu

Post by Colin Walters
Why would your security policy specify implementation details like
chroot? A more sensible security policy would be something like "BIND
cannot affect the PostgreSQL server".

You weren't paying attention - I *granted* it was a silly rule. But every once
in a while, somebody screws up and lets the auditors get access to some 8x11
color glossy, and once that happens there's no shifting it. ;)

Errr...if your "auditor" specifies that you need "chroot" without
understanding the issues, then just use SELinux, and tell them you're
using "chroot". Moreover, why would you even let your organization be
audited by someone so clueless in the first place?

Post by V***@vt.edu
The point is that SELinux is able to do a very good job at controlling access
via a model where everything is *labelled*.

Yes. And it provides plenty of tools for labeling; from fine-grained
xattrs on files to giving all files on a particular mount the same
label. What's the big deal?

Post by V***@vt.edu
It however does a *very* poor
job of making decisions based on *state* - are we chrooted? Are we this,
are we that?

Now that we have SELinux, using chroot for security is obsolete. There
is one other use of chroot - virtualization. But we have Xen for that
now.

So what other interesting "state" types are there?

Post by V***@vt.edu
A good while ago, I was discussing an LSM based on the OpenWall patches, and
the reasonable security goal of "don't follow a possibly hostile symlink".

I remember it well. I had a sense of deja vu when you posted; again you
were focusing on implementation details and not goals.

Post by V***@vt.edu
In
order to actually do it, you'd basically have to use the 'strict' policy,
give each user their own $USER_u - and then you could add the 5-6 lines of
policy that did the same as a 15-line LSM exit. Except the SELinux one
will have chewed up some 20M worth of avc_node slab entries (which makes a
noticeable difference if you're trying to secure an older box that only has
128M or 256M installed).

What you are forgetting is that I provided a solution for the policy
size: use the constraints. Thomas Bleher even tested it and found it
worked, IIRC.

Post by V***@vt.edu
And yes, I *KNOW* the Right Answer there is "Use some other LSM that meets the
goals needed".

Nope - we showed in that case SELinux did work, and quite elegantly too.

Post by V***@vt.edu
The point is that there *DO* exist *real world* security issues
that the SELinux model is not all that well suited for.

Since we've discounted chroot, I'm awaiting more "*real world*"
examples...

[Crispin Cowan]

Post by Colin Walters

Post by V***@vt.edu
The point is that SELinux is able to do a very good job at controlling access
via a model where everything is *labelled*.

Yes. And it provides plenty of tools for labeling; from fine-grained
xattrs on files to giving all files on a particular mount the same
label. What's the big deal?

The big deal from my perspective is that some of us believe that
label-based access control in itself is a defect, and there are other
ways to do it that are more effective. The SELinux procedure to build a
policy to contain an application is 17 steps long (literally) and the
corresponding Immunix process is 3 steps long, and the steps are easier.

But "easier" is a subjective opinion, and I don't particularly want to
engage in SELinux bashing. It has its strengths. The claim is just that
there are alternatives that have their strengths too. LSM currently lets
the user make that choice. Forcing everyone to cram their ideas through
the SELinux model would severely compromise that.

So there are SEVERE disadvantages to removing LSM and forcing everyone
to just use SELinux. What are the advantages? I mean, other than
excluding all those annoying counter-revolutionary upstarts? :)

Crispin

[Colin Walters]

Post by Crispin Cowan
So there are SEVERE disadvantages to removing LSM and forcing everyone
to just use SELinux. What are the advantages? I mean, other than
excluding all those annoying counter-revolutionary upstarts? :)

I think there's two strongly related but still separate issues here:

1) Whether SELinux can express other access control LSM modules
2) Should LSM be removed in favor SELinux API calls, and out-of-tree
modules can patch the kernel (as many do).

My interest in this discussion is 1), which came up because of 2). So
far I have not yet seen an actual access control LSM which isn't better
expressed in SELinux policy.

Post by Crispin Cowan
The big deal from my perspective is that some of us believe that
label-based access control in itself is a defect, and there are other
ways to do it that are more effective. The SELinux procedure to build a
policy to contain an application is 17 steps long (literally) and the
corresponding Immunix process is 3 steps long, and the steps are easier.

I have written a number of SELinux policies from scratch and I certainly
don't recall ticking off 17 checkboxes as I wrote them. The time taken
wildly varied, in fact; for some applications like jabberd, writing the
policy took all of maybe 10 minutes including testing. For others like
Spamassassin, I wrestled for hours with the issues such as the various
configurations (spamd versus spamc, etc) and other programs involved
(the MTA, procmail, etc).

So I'm extremely skeptical of this comparison, at least if you are
making any claim about the security equivalence of the policies.

Post by Crispin Cowan
But "easier" is a subjective opinion, and I don't particularly want to
engage in SELinux bashing. It has its strengths. The claim is just that
there are alternatives that have their strengths too.

I understand the claim. It's difficult to discuss though when there
appears to be little in the way of online technical documentation for
Immunix (as opposed to marketing material), and source code does not
appear to be available.

[Karl MacMillan]

-----Original Message-----
Sent: Wednesday, May 25, 2005 8:27 PM
To: Crispin Cowan
Subject: Re: New stacker performance results

Post by Crispin Cowan
So there are SEVERE disadvantages to removing LSM and forcing everyone
to just use SELinux. What are the advantages? I mean, other than
excluding all those annoying counter-revolutionary upstarts? :)

1) Whether SELinux can express other access control LSM modules
2) Should LSM be removed in favor SELinux API calls, and out-of-tree
modules can patch the kernel (as many do).
My interest in this discussion is 1), which came up because of 2). So
far I have not yet seen an actual access control LSM which isn't better
expressed in SELinux policy.

Post by Crispin Cowan
The big deal from my perspective is that some of us believe that
label-based access control in itself is a defect, and there are other
ways to do it that are more effective. The SELinux procedure to build a
policy to contain an application is 17 steps long (literally) and the
corresponding Immunix process is 3 steps long, and the steps are easier.

I have written a number of SELinux policies from scratch and I certainly
don't recall ticking off 17 checkboxes as I wrote them.

I always use all 17 steps mandated by the NSA . . .

The time taken
wildly varied, in fact; for some applications like jabberd, writing the
policy took all of maybe 10 minutes including testing. For others like
Spamassassin, I wrestled for hours with the issues such as the various
configurations (spamd versus spamc, etc) and other programs involved
(the MTA, procmail, etc).

And I would argue that the additional time and complexity reflected not inherent
complexity in the SELinux policy language, but the real complexity of the
software you were trying to secure. More often than not SELinux is simply
exposing the real challenges in securing complex software on a complex operating
system.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

So I'm extremely skeptical of this comparison, at least if you are
making any claim about the security equivalence of the policies.

Post by Crispin Cowan
But "easier" is a subjective opinion, and I don't particularly want to
engage in SELinux bashing. It has its strengths. The claim is just that
there are alternatives that have their strengths too.

I understand the claim. It's difficult to discuss though when there
appears to be little in the way of online technical documentation for
Immunix (as opposed to marketing material), and source code does not
appear to be available.

[Colin Walters]

Post by Karl MacMillan
And I would argue that the additional time and complexity reflected not inherent
complexity in the SELinux policy language, but the real complexity of the
software you were trying to secure.

Definitely, that was the point I was trying to make; saying there are
always "17 steps" to developing a policy is rather meaningless. It's
like saying with Java there are "23 steps" to developing a program and
with Python there are "39 steps".

[Serge E. Hallyn]

Post by Colin Walters
1) Whether SELinux can express other access control LSM modules
2) Should LSM be removed in favor SELinux API calls, and out-of-tree
modules can patch the kernel (as many do).
My interest in this discussion is 1), which came up because of 2). So
far I have not yet seen an actual access control LSM which isn't better
expressed in SELinux policy.

A few years ago, while I was still working on DTE, I was contacted by
someone who ran a large web-cgi farm. He wanted to know whether DTE
could be used to satisfy his security goals. In particular, he had 100k
users who could use a few global cgi scripts, but once they ran cgi
scripts under their own directory, those scripts should only be able to
access files under their own home directory, with a few predefined
exceptions. In addition it shouldn't be "hard" to add or remove users.

To express this in TE would require a very large policy, with policy
reloads for user add/remove. In contrast, a very simple LSM (dirjail)
was able to express the policy efficiently.

To take away this kind of flexibility from people actually trying to
install real systems should not be done lightly.

-serge

[Karl MacMillan]

-----Original Message-----
Sent: Wednesday, May 25, 2005 10:39 PM
To: Colin Walters
Subject: Re: New stacker performance results

Post by Colin Walters
1) Whether SELinux can express other access control LSM modules
2) Should LSM be removed in favor SELinux API calls, and out-of-tree
modules can patch the kernel (as many do).
My interest in this discussion is 1), which came up because of 2). So
far I have not yet seen an actual access control LSM which isn't better
expressed in SELinux policy.

A few years ago, while I was still working on DTE, I was contacted by
someone who ran a large web-cgi farm. He wanted to know whether DTE
could be used to satisfy his security goals. In particular, he had 100k
users who could use a few global cgi scripts, but once they ran cgi
scripts under their own directory, those scripts should only be able to
access files under their own home directory, with a few predefined
exceptions. In addition it shouldn't be "hard" to add or remove users.
To express this in TE would require a very large policy, with policy
reloads for user add/remove. In contrast, a very simple LSM (dirjail)
was able to express the policy efficiently.

This could be done with a single constraint as Colin mentioned elsewhere in this
thread. Is the policy reload really a problem?

To take away this kind of flexibility from people actually trying to
install real systems should not be done lightly.

I understand the argument as:

a) TE / current SELinux policy language can be used to express many security
goals and is a good choice as a general purpose language.
b) If TE is not appropriate other policy models can be implemented as new
security servers.

So no one is, I think, really arguing for limiting flexibility - this is more
about implementation strategy.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

-serge

[s***@us.ibm.com]

Post by Karl MacMillan

Post by Serge E. Hallyn
A few years ago, while I was still working on DTE, I was contacted by
someone who ran a large web-cgi farm. He wanted to know whether DTE
could be used to satisfy his security goals. In particular, he had 100k
users who could use a few global cgi scripts, but once they ran cgi
scripts under their own directory, those scripts should only be able to
access files under their own home directory, with a few predefined
exceptions. In addition it shouldn't be "hard" to add or remove users.
To express this in TE would require a very large policy, with policy
reloads for user add/remove. In contrast, a very simple LSM (dirjail)
was able to express the policy efficiently.

This could be done with a single constraint as Colin mentioned elsewhere in this
thread.

I assume you're suggesting a constraint on u1!=u2. (which would
still require 100k selinux users... you'd know better than I how
much space that takes, I haven't looked)

I don't think that could work. All the user directories were
nfs-mounted and owned by the same uid/gid.

Post by Karl MacMillan
Is the policy reload really a problem?

I assume it was. After I explained the lsm I had in mind, the guy
decided he wanted to roll his own. (Don't we all :) So I have no
idea what he ended up doing or how the situation has changed.

Post by Karl MacMillan

Post by Serge E. Hallyn
To take away this kind of flexibility from people actually trying to
install real systems should not be done lightly.

a) TE / current SELinux policy language can be used to express many security
goals and is a good choice as a general purpose language.

I don't argue this.

Though many people do. (And please don't disregard that - I also
consider vi a very good editor, but we can't force people to use it
just because it has all the features one might need)

Post by Karl MacMillan
b) If TE is not appropriate other policy models can be implemented as new
security servers.

Sure, they can. Or, they can be implemented as LSMs. We could also
implement RSBAC as a security server under selinux under LSM. Then
we could say that because you can implement jail under RSBAC, you
should never do it under selinux or as an LSM.

Post by Karl MacMillan
So no one is, I think, really arguing for limiting flexibility - this is more
about implementation strategy.

I understand. And I think there will be far less resistance to that
once (a) someone implements alternate (or stackable :) security
servers other than MLS (which isn't really an alternate ss) and/or
(b) some of the improved policy tools finally come to be.

-serge

[Stephen Smalley]

Post by Serge E. Hallyn
A few years ago, while I was still working on DTE, I was contacted by
someone who ran a large web-cgi farm. He wanted to know whether DTE
could be used to satisfy his security goals. In particular, he had 100k
users who could use a few global cgi scripts, but once they ran cgi
scripts under their own directory, those scripts should only be able to
access files under their own home directory, with a few predefined
exceptions. In addition it shouldn't be "hard" to add or remove users.
To express this in TE would require a very large policy, with policy
reloads for user add/remove.

I'm not clear I understand why. SELinux constraints on the user
identities or DAC could cover the user-based restrictions, with just a
few types and TE rules to deal with the notions of global cgi scripts
vs. others. As far as adding and removing users goes, policy reload is
necessary, but adding/removing users has become much simpler in FC4
via /etc/selinux/strict/users/local.users; you no longer need to rebuild
the binary policy file. And the binary policy module work will allow
other kinds of customizations more easily on end systems.

Post by Serge E. Hallyn
To take away this kind of flexibility from people actually trying to
install real systems should not be done lightly.

I think this is a misunderstanding; there is no loss in freedom; you are
still free to patch the kernel to do what you wish, and in fact, you
could just as easily patch SELinux to call your own hooks on entry to
its hook functions if you wanted to avoid trying to track the core
kernel changes. It is just a question of whether the core kernel itself
needs to directly provide support for out-of-tree LSMs.

[V***@vt.edu]

Post by Colin Walters
Errr...if your "auditor" specifies that you need "chroot" without
understanding the issues, then just use SELinux, and tell them you're
using "chroot". Moreover, why would you even let your organization be
audited by someone so clueless in the first place?

When you're a state agency, you get audited by whoever shows up from the state
capitol. We don't get the luxury of choosing who. And when you're a 3 hour
drive from the capitol, you *know* that the auditor who shows up either (a)
likes being in the mountains a *lot*, or (b) is the junior staffer and got last
choice. (To be fair, we probably get the second to last choice. Somebody has
to get stuck with doing audits in Grundy(*), or in Floyd County (motto: "still
waiting for the county's second traffic light")

(And you there smirking in the corner - being a .com doesn't let you off the
hook. You know *damned* well that there's plenty of publicly traded corporations
that have signed auditing contracts with a Big 5^H4, and had a clueless bozo
show up...)

Post by Colin Walters

Post by V***@vt.edu
order to actually do it, you'd basically have to use the 'strict' policy,
give each user their own $USER_u - and then you could add the 5-6 lines of
policy that did the same as a 15-line LSM exit. Except the SELinux one
will have chewed up some 20M worth of avc_node slab entries (which makes a
noticeable difference if you're trying to secure an older box that only has
128M or 256M installed).

What you are forgetting is that I provided a solution for the policy
size: use the constraints. Thomas Bleher even tested it and found it
worked, IIRC.

Hmm.. I *must* have blinked. Where did he get it to where the memory usage was
the same as my 10 lines of C?

int vtkit_follow_link (struct dentry *dentry, struct nameidata *nd)
{
struct inode *i_target = dentry->d_inode;
struct inode *i_parent = dentry->d_parent->d_inode;

if ((i_parent->i_mode & S_ISVTX) && (i_parent->i_mode & S_IWOTH) &&
(i_parent->i_uid != i_target->i_uid) &&
(current->fsuid != i_target->i_uid)) {
return -EPERM;
}
return 0;
}

I'd *love* to see you get an SELinux-based solution that can get anywhere
near that for speed, slab usage, or stack usage. ;)

Post by Colin Walters
Nope - we showed in that case SELinux did work, and quite elegantly too.

Yes, the constraints solution was indeed elegant, and very nice *if you were
using SELinux already*. But it's far from the most efficient way.

Post by Colin Walters

Post by V***@vt.edu
The point is that there *DO* exist *real world* security issues
that the SELinux model is not all that well suited for.

Since we've discounted chroot, I'm awaiting more "*real world*"
examples...

I have become firmly convinced that *some* people have spent *so* much time
designing ultra-secure systems suitable for protecting data worth multiple
millions of dollars that they have *totally* forgotten that *some* of us don't
have multi-million dollar secrets to protect from world-class attackers hired
by The Other Side.

I have to protect one undergrad from another, on an older Dell system that has
a 700mz processor and 128M of memory. And at 128M, the fact that you *could*
trim SELinux from 17M of slab space down to 8M still doesn't compare well with
another "good enough" solution that gets the job done in under 1K. The less
that 'Disk Active' LED goes on, the happier we all are... ;) I don't need
perfect security - I only need it to be hard enough so that instead of trying
to steal a homework solution, they decide to bribe somebody down the dormitory
hall to do it for them. I only need it to be hard enough so that instead of
trying to mess up another student's project, they decide to find some easier
way to make their victim's life difficult - if the attacker decides to penny
the victim into their dorm room instead (the cost of *that* attack being all of
3-5 cents plus a blunt object suitable for pounding), my security has suceeded.

I don't need to deploy $100,000,000 security.
I need to deploy $100 security.

And anybody who has trouble with that concept should carve out a large chunk of
time this weekend and (re-)read Schneier's "Secrets and Lies".....

(*) Grundy: http://maps.google.com/maps?q=grundy+virginia&spn=0.106445,0.128299&hl=en
Keep zooming out. You'll find civilization on there... eventually. By the time
you've zoomed out enough to find a city the size of Columbus, Ohio on the map, you
have portions of 11 states showing. Yes, there's places that remote east of the
Mississippi ;)

[Colin Walters]

Post by V***@vt.edu
When you're a state agency, you get audited by whoever shows up from the state
capitol. We don't get the luxury of choosing who.

And these auditors would actually mandate you use "chroot"? Just like
that? I'm sure if they questioned you about it you could describe how
SELinux replaces it.

Post by V***@vt.edu
I'd *love* to see you get an SELinux-based solution that can get anywhere
near that for speed, slab usage, or stack usage. ;)

You could write vtkit_follow_link in i386 assembler too...the question
is, was the SELinux-based solution actually a bottleneck for system
performance?

Post by V***@vt.edu
I have to protect one undergrad from another, on an older Dell system that has
a 700mz processor and 128M of memory. And at 128M, the fact that you *could*
trim SELinux from 17M of slab space down to 8M still doesn't compare well with
another "good enough" solution that gets the job done in under 1K.

Ok, this is a more reasonable argument. Does the strict policy really
require 17M of kernel memory (that's nonpageable?). Stephen/James, is
there a way SELinux memory usage could be reduced for relatively simple
policies like this? Besides older machines, once Xen is widely deployed
it will be valuable to reduce kernel memory usage so that more virtual
instances can be deployed on the same machine.

[James Morris]

Post by Colin Walters
Ok, this is a more reasonable argument. Does the strict policy really
require 17M of kernel memory (that's nonpageable?).

It's a lot, not sure if it's quite 17, ISTR about 12 (on 32-bit).

Post by Colin Walters
Stephen/James, is there a way SELinux memory usage could be reduced for
relatively simple policies like this? Besides older machines, once Xen
is widely deployed it will be valuable to reduce kernel memory usage so
that more virtual instances can be deployed on the same machine.

Binary policy could help, although the underlying strategy may
need to be revised.

I'm sure it's possible; the rules look highly compressable (bzip can
compress the binary policy by an order of magnitude), and the typical
active set of rules is usually very small, perhaps 60 or so for a typical
workload, if that.

So, we could look at using a compressed policy database, which would slow
down AVC misses, which are typically infrequent. Even if that was a
problem, we could provide another cache level between the compressed
security database and the AVC. Or something.


- James

[V***@vt.edu]

Post by Colin Walters
You could write vtkit_follow_link in i386 assembler too...the question
is, was the SELinux-based solution actually a bottleneck for system
performance?

On a 128M (or even 256M - I can feel it on my laptop), it *is* an issue, mostly
due to total memory footprint..

Post by Colin Walters
Ok, this is a more reasonable argument. Does the strict policy really
require 17M of kernel memory (that's nonpageable?). Stephen/James, is
there a way SELinux memory usage could be reduced for relatively simple
policies like this? Besides older machines, once Xen is widely deployed
it will be valuable to reduce kernel memory usage so that more virtual
instances can be deployed on the same machine.

% head /proc/slabinfo
slabinfo - version: 2.1 (statistics)
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> : globalstat <listallocs> <maxobjs> <grown> <reaped> <error> <maxfreeable> <nodeallocs> <remotefrees> : cpustat <allochit> <allocmiss> <freehit> <freemiss>
avtab_node 404908 404964 44 84 1 : tunables 32 16 0 : slabdata 4821 4821 0 : globalstat 404912 404912 4821 0 0 0 0 0 : cpustat 375986 28922 0 0

4,821 4K slab pages. Just shy of 20M. That's with the Fedora RPM
selinux-policy-strict-1.23.14-2 and only two different user_u defined. The
'targeted' policy is a lot smaller, but you really can't do it easily with the
'targeted' policy because that dumps everything into unconfined_t. You probably
can heave everything over the side and do up a custom policy that takes
a lot less - but it's *still* going to be more heavyweight.

Which was my point - the fact that you *could* coerce it into an SELinux policy
doesn't mean that it's necessarily the best or most efficient way to solve the
problem.

Another issue with doing this in an SELinux-only solution is the maintenance cost
if you want to deploy this alongside current policy - right now, it's a lot harder
to run "strict policy with 3-5 minor changes" than it should be (which is a known
issue, related to "programs/RPMs ship their own incremental policy").

[Colin Walters]

Post by V***@vt.edu
4,821 4K slab pages. Just shy of 20M. That's with the Fedora RPM
selinux-policy-strict-1.23.14-2 and only two different user_u defined.

This will all get a lot better at a fundamental level once the Tresys
binary modules land, as then we can have a base binary policy module
installed with Fedora and dynamically load application policy only once
their associated packages are installed, in addition to easily letting
the administrator add their own policy.

However it's certainly feasible today to install policy-sources and
apply rm -f to unneeded .te files. If you have the technical ability to
write a custom LSM, I don't see how this should be a problem.

Post by V***@vt.edu
The
'targeted' policy is a lot smaller, but you really can't do it easily with the
'targeted' policy because that dumps everything into unconfined_t. You probably
can heave everything over the side and do up a custom policy that takes
a lot less - but it's *still* going to be more heavyweight.

More heavyweight, sure - but after removing a lot of unnecessary .te
files, would it still have an important impact on system performance?
My guess is that you could get the strict policy down to one or two
megabytes or less (i.e. not a significant impact on performance), and in
that case you meet the original security goal, and could easily add
additional security using the same framework (e.g. you could define a
real full_user_role() for one or two users which warranted it).

Post by V***@vt.edu
Another issue with doing this in an SELinux-only solution is the maintenance cost
if you want to deploy this alongside current policy - right now, it's a lot harder
to run "strict policy with 3-5 minor changes" than it should be (which is a known
issue, related to "programs/RPMs ship their own incremental policy").

You are right there - but that's in the process of being fixed, should
land in the next month or two.

[Stephen Smalley]

Post by Casey Schaufler
In the Unix Era we made our share of mistakes,
especially with add on module interfaces and
extreme security implementations. STREAMS modules
and Information labels come to mind as prime
examples. I can think of no instance where the
two types of facilities were combined into the
same blunder.

I'm not sure I follow your meaning above; it almost sounds like an
indictment of LSM, which is a module interface for security
implementations, not SELinux, which is a particular security
implementation that presently leverages LSM but was originally
implemented as a direct kernel patch that involved no kernel module at
all. Even now, SELinux is not truly a kernel module; it has to be
built-in to be used, and is tightly coupled to the core kernel since it
implements the full range of LSM hooks (not necessarily every individual
LSM hook, but a fairly sweeping set covering all kernel subsystems).

Post by Casey Schaufler
SELinux is a poor choice for a general framework.

Flask/SELinux was designed as a flexible MAC framework. Feel free to
suggest your own, but be ready to provide supporting documentation of
how it has been analyzed for its ability to represent a wide spectrum of
security models. Such analysis has been done and is available in
publically available reports for SELinux.

Post by Casey Schaufler
While Type Enforcement may be used to implement
many interesting policies it is far from universal.

SELinux isn't limited to TE, although it is certainly a useful building
block security model.

Post by Casey Schaufler
SELinux is not a lightweight implementation, and
would be overkill if all you wanted was a minor
policy such as time-of-day access restrictions.

Time-of-day restrictions can be implemented via the conditional policy
support in SELinux. More generally, if there is a security model that
is useful that cannot be presently expressed via SELinux, extending
SELinux to support it should be more straightforward than having to
implement an entirely new security module from scratch.

Post by Casey Schaufler
SELinux associates rights and privileges with
programs, a paradighm that has it's detractors.

Aside from the fact that such detractors are wrong, SELinux doesn't
force this paradigm, it just allows it. One can certainly write a TE
policy that only assigns rights to users and does not distinguish
programs at all.

Post by Casey Schaufler
But the most important problem that I see from
here is that nowhere is there a complete and
accurate description of how, *in general* one
would go about creating an arbitrary and
complete policy using SELinux.

Sorry, a "complete" description of how "in general" one might create an
"arbitrary" policy? The assumptions force the conclusion.

[Casey Schaufler]

I'm not sure I follow your meaning above ...

The introductory paragraph is used in this case
to set the stage for the upcoming argument.

Feel free to
suggest your own, but be ready to provide supporting
documentation of
how it has been analyzed for its ability to
represent a wide spectrum of
security models. Such analysis has been done and is
available in
publicly available reports for SELinux.

I refer you to the message archives for this list.
Look up "authoritative hooks".

... extending
SELinux to support it should be more straightforward
than having to
implement an entirely new security module from
scratch.

Perhaps. I understand the general notion that
it's easier to write in PERL than C. Does that
mean the overhead of PERL is worth the cost?
I suggest that in many cases it is not.

Post by Casey Schaufler
SELinux associates rights and privileges with
programs, a paradigm that has it's detractors.

Aside from the fact that such detractors are wrong,

Bah! (Waves paw)

Sorry, a "complete" description of how "in general"
one might create an
"arbitrary" policy? The assumptions force the
conclusion.

Ah, but such is nonetheless necessary. For LSM
the complete, general, and arbitrary description
is not only possible, but reasonably strait forward.
(No, I do not intend to write it. Had LSM gone with
Authoritative hook I'd already have provided it.)
LSM does have limitations (e.g. replacing mode bits)
but they are readily identified.

For SELinux I expect no less if y'all want it to
replace LSM as the "general" advanced security
interface.

And playing with words doesn't make the issue
go away. The fact that the problem is hard does
not entitle you to an "easy button".


Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[Stephen Smalley]

Post by Casey Schaufler
The introductory paragraph is used in this case
to set the stage for the upcoming argument.

Except that it wasn't supportive of the upcoming argument AFAICS, i.e.
combining add-on modules with security implementations considered
harmful. With which I would agree. A robust security implementation by
nature has to be tightly integrated into the kernel, and userspace can't
cope with arbitrary security models being plugged into the kernel.

Post by Casey Schaufler
I refer you to the message archives for this list.
Look up "authoritative hooks".

The hooks, whether authoritative or restrictive, are only a small part
of the security implementation; they just expose the kernel abstractions
and operations to the security module. You still have to implement a
real security architecture in the "module", which is what Flask/SELinux
provides.

Post by Casey Schaufler
Perhaps. I understand the general notion that
it's easier to write in PERL than C. Does that
mean the overhead of PERL is worth the cost?
I suggest that in many cases it is not.

If you weren't going to leverage anything provided to you by the perl
runtime, then that would make sense. But you are going to have to
reinvent a lot of what SELinux already does to implement any access
control scheme.

Post by Casey Schaufler
Ah, but such is nonetheless necessary. For LSM
the complete, general, and arbitrary description
is not only possible, but reasonably strait forward.

Nonsense, LSM cannot express arbitrary policies; it is limited by its
interface (the set of hooks, their interfaces, and their placement).
Nor would such an ability be desirable. Flask/SELinux can express a
wide range of well-defined security models.

Post by Casey Schaufler
(No, I do not intend to write it. Had LSM gone with
Authoritative hook I'd already have provided it.)

Right. Pass the pipe, please.

Post by Casey Schaufler
For SELinux I expect no less if y'all want it to
replace LSM as the "general" advanced security
interface.

Then you don't understand at all. Generality for the sake of generality
is not desirable and is particularly not well received in the kernel -
see SubmittingPatches #4.

[Casey Schaufler]

Post by Stephen Smalley
Yes, but with SELinux, you have a chance at doing it
because you have
comprehensive controls and you can apply a tool like
apol to check
whether said process can ultimately reach a given
state. If you choose
to implement your own little security module from
scratch, you are much
less likely to hit the mark.

Now that's an assertion I'd like to see you back up!
Especially since you've already said that it's
impossible to describe how you might create such
a policy in SELinux.


Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[Stephen Smalley]

Post by Casey Schaufler
Now that's an assertion I'd like to see you back up!
Especially since you've already said that it's
impossible to describe how you might create such
a policy in SELinux.

I said that it is impossible to describe "in general" how one might
create an "arbitrary" policy in SELinux. Or in anything else, for that
matter.

Defining a domain in SELinux is pretty straightforward, and using apol
to check potential domain transitions and information flows from a
domain is likewise straightforward.

[Casey Schaufler]

On Wed, 2005-05-25 at 10:29 -0700, Casey Schaufler

Post by Casey Schaufler
The introductory paragraph is used in this case
to set the stage for the upcoming argument.

Except that it wasn't supportive of the upcoming
argument AFAICS, i.e.
combining add-on modules with security
implementations considered
harmful. With which I would agree. A robust
security implementation by
nature has to be tightly integrated into the kernel,
and userspace can't
cope with arbitrary security models being plugged
into the kernel.

But... but... Then, you go on to extoll the
virtues of SELinux as a mechanism to implement
that very thing!

Post by Casey Schaufler
I refer you to the message archives for this list.
Look up "authoritative hooks".

The hooks, whether authoritative or restrictive, are
only a small part
of the security implementation; they just expose the
kernel abstractions
and operations to the security module. You still
have to implement a
real security architecture in the "module", which is
what Flask/SELinux
provides.

See?!?

Post by Casey Schaufler
Perhaps. I understand the general notion that
it's easier to write in PERL than C. Does that
mean the overhead of PERL is worth the cost?
I suggest that in many cases it is not.

If you weren't going to leverage anything provided
to you by the perl
runtime, then that would make sense. But you are
going to have to
reinvent a lot of what SELinux already does to
implement any access
control scheme.

No. You are going to have to do what your policy
requires. You may well not need all the tools
and utilities required by SELinux.

Post by Casey Schaufler
Ah, but such is nonetheless necessary. For LSM
the complete, general, and arbitrary description
is not only possible, but reasonably strait

forward.
Nonsense, LSM cannot express arbitrary policies; it
is limited by its
interface (the set of hooks, their interfaces, and
their placement).

In this, I disagree, having used similar mechanisms
elsewhere to do whatever I <adjective> well pleased.

Nor would such an ability be desirable.

Bah! (Waves paw)

Flask/SELinux can express a
wide range of well-defined security models.

Yes, we know.

Post by Casey Schaufler
(No, I do not intend to write it. Had LSM gone

with

Post by Casey Schaufler
Authoritative hook I'd already have provided it.)

Right. Pass the pipe, please.

Ooh! Ooh! Thems fight'n words!
I'll buy you a beer instead. Then we can
really get the debate flowing...
"Type Enforcement!"
"Authoritative Hooks!"
....

Post by Casey Schaufler
For SELinux I expect no less if y'all want it to
replace LSM as the "general" advanced security
interface.

Then you don't understand at all. Generality for
the sake of generality
is not desirable and is particularly not well
received in the kernel -
see SubmittingPatches #4.

SELinux should replace LSM because it's NOT general?

EGADS
Concept fails the principle of least
astonishment.



Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[Casey Schaufler]

Post by Crispin Cowan
So there are SEVERE disadvantages to removing LSM
and forcing everyone
to just use SELinux. What are the advantages? I
mean, other than
excluding all those annoying counter-revolutionary
upstarts? :)

Crispin, you need to put on your conspiracy hat!
Obviously, the NSA wants you to run SELinux.
Coincidence? I don't think so!

(For those who don't know me, I'm kidding!)


Casey Schaufler
***@schaufler-ca.com



__________________________________
Discover Yahoo!
Stay in touch with email, IM, photo sharing and more. Check it out!
http://discover.yahoo.com/stayintouch.html

[Casey Schaufler]

Post by James Morris

Post by Crispin Cowan
What constitutes "inappropriate" here?

In my view, LSM should be used for significantly
enhancing access control
systems.

http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0300.html

Post by James Morris
One of the reasons I would put forward for this
is that it can be dangerous to allow the user to
arbitrarily compose security modules.

Not to throw gasoline on the fire (Oh jiminies,
why not) but this is exactly what SELinux claims
as it's primary value, that the end user can
script her very own security policy.

Yes, it would be dangerous. That's why the
LSM hooks are restrictive, not authoritative.



Casey Schaufler
***@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Karl MacMillan]

-----Original Message-----
Sent: Wednesday, May 25, 2005 9:01 PM
Subject: Re: New stacker performance results

Post by James Morris

Post by Crispin Cowan
What constitutes "inappropriate" here?

In my view, LSM should be used for significantly
enhancing access control
systems.

http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0300.html

Post by James Morris
One of the reasons I would put forward for this
is that it can be dangerous to allow the user to
arbitrarily compose security modules.

Not to throw gasoline on the fire (Oh jiminies,
why not) but this is exactly what SELinux claims
as it's primary value, that the end user can
script her very own security policy.

Composing security modules - i.e. security mechanisms - is vastly different than
configuring a single, coherent security mechanism with a security policy. In the
first case the semantics are difficult if not impossible to determine. In the
latter the semantics are well defined.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

Yes, it would be dangerous. That's why the
LSM hooks are restrictive, not authoritative.
Casey Schaufler
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Casey Schaufler]

...How you squint and draw a line for
access control may
have some room for debate, but one classic example
has been keeping
audit separate from access control.

This was in fact a primary topic in the early
days of LSM, my group wanted to use LSM for
audit. The seperation of access control from
audit allows the existing restrictive hooks
scheme. Of course, we wanted to use LSM (and
submitted the Bumper Patch) because the
prevailing attitude of the day was that audit
was NEVER going to be allowed in the main line,
ever, under any circumstances.

Ah, times change.


Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[Casey Schaufler]

Post by Stephen Smalley
SELinux == flexible MAC architecture

OKay, since no one else has, I'll bit on this one.

I accept your assertion that SELinux is a
flexible MAC architecture. I've understood
that since I first saw it in the basement
room with the flashing red light in 1999.

Not all security policies are Mandatory.
There is value in descretionary policies
as well. Name one? Supervisor sign-off,
dual authorization, program access lists,
to name three. Now, I fully expect to hear
that:
1. These could be implemented as
Mandatory policies
2. No one has ever implemented any
of these policies
3. If they did, SELinux would do it
better.


Casey Schaufler
***@schaufler-ca.com



__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[Casey Schaufler]

Post by Chris Wright
I'll listen to real ideas on how to
improve the semantics of
core interfacing with security module (and no, I
don't mean function
pointers, I mean real interface semantics).

What! Do a design?

I think that's an outstanding idea. No dates
committed (I may land a paying job here soon)
but I will be looking into it.


Casey Schaufler
***@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com