Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE

people were ok with it (AppArmor), but I'm with you - I applied it, but

I'm also perfectly willing to unapply it if there actually are valid

out-of-tree users that people push for not merging.
So Í don't think this is settled in any way - please keep discussing, and

bringing it up. I'm definitely not in the camp that thinks that LSM needs

to be "controlled", but on the other hand, I'm also not going to undo that

commit unless there are good real arguments for undoing it (not just

theoretical ones).
For example, I do kind of see the point that a "real" security model might

want to be compiled-in, and not something you override from a module. Of

course, I'm personally trying to not use any modules at all, so I'm just

odd and contrary, so whatever..
Real usage scenarios with LSM modules, please speak up!
		Linus

-

To discuss how LSM should work, it would have been really helpful if the

OP had cc'd the LSM mailing list. I've cc'd the LSM list here ...
I did not speak up against this patch because it does not hurt AppArmor,

bad for Linux users.
The patch does have benefits, I just think those benefits are weak and

unimportant. It prohibits dynamic loading of security modules (you must

be compiled in) and prohibits unloading of security modules (because it

is unsafe, and potentially insecure). What makes these benefits weak and

unimportant is that you can have those benefits now without the patch by

just writing your module that way: if you think that a security module

should be compiled in and present when the kernel boots, and should

Why would you want to dynamically unload a module: because it is

convenient for debugging. Ok, so it is unsafe, and sometimes wedges your

kernel, which sometimes forces you to reboot. With this patch in place,

it forces you to *always* reboot when you want to try a hack to the module.
Why you would want to dynamically load a security module: because you

are an enterprise user, required to use a specific build of a kernel,

rather than compile your own kernel, but you also want to use (or even

try out) a security module that your enterprise's vendor of choice has

not chosen to bundle. In the current state, such a user can just go get

a module and use it. With this patch, such a user is just screwed, they

can't load and try the module without having to get into kernel building.
So the net impact of this patch is:
    * It takes a deployment practice (static compiled-in security) that

      is arguably good in many circumstances and makes it mandatory at

      all times.

    * It takes a development practice that is very convenient and

      slightly risky, and forces you into the pessimal inconvenient

      development practice at all times.

    * It prevents enterprise users, and in fact anyone who isn't

      comfortable compiling their own kernel, from ev...
[ message continues ]

The patch doesn't hurt AppArmor, but it's still a step in the wrong direction.
This is idiotic. Just because there is no safe way to unload SELinux
 - doesn't mean there is no safe way to unload other LSMs: if nothing

   but that, unloading is handy during development.
 - doesn't mean that module *loading* is unsafe. The patch removes module

   loading as well, which hurts more than removing module unloading.
LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM

loadable modules have been known to do lots of bad things, and yet nobody 
Non-trivial modules (i.e., practically everything beyond capabilities) become

effective only after loading policy, anyway. If you can load policy, you can

as well first load a security module without making the system insecure.
Thanks,

Andreas

-

Can you provide an example of a real LSM which can be safely unloaded and

also needs to be unloaded?
Why should we maintain infrastructure and extra complexity in the kernel

for theoretical or unknown modules ?
Linus has asked for any valid out of tree users who need a dynamic

interface to step forward.  Where are they?
As one of the people who actually maintains LSM (rather than simply

speculates about it), I object to maintaining infrastructure which, to the

best of my knowledge, is only used by out of tree, binary, broken junk.
If you recall, the original motivation for this patch was when the idea

of adding a new capability to control security model unload was raised.  
That is, new security infrastructure was being proposed merely to cater to

some other existing unnecessary security infrastructure.  So, rather than

doing that, I proposed removing the unnecessary infrastructure.
I agree with Linus: if you can demonstrate a valid, concrete use for

dynamic LSMs, then the infrastructure to support them can easily be

reinstated.
But until then, it seems both reasonable and in keeping with good kernel

development practices, to not maintain unused infrastructure.
- James

--

James Morris

<jmorris@namei.org>

-

I'd like to note that I asked people who were actually affected, and had

examples of their real-world use to step forward and explain their use,

and that I explicitly mentioned that this is something we can easily

re-visit.
But I also note that you did no such thing, neither has anybody else.
The fact is, security people *are* insane. You just argue all the time,

instead fo doing anything productive. So please don't include me in the Cc

on your insane arguments - instead do something productive and I'm

interested.
Ok? That was the whole point of LSM in the first place. I'm *not*

interested in getting roped into your insane arguments. I'm interested in

moving forward and having real examples of real use and code. Until then,

this issue is closed. I thought I had made that clear already, but

apparently not clear enough.
So I repeat: we can undo that commit, but I will damn well not care one

whit about yet another pointless security model flamewar.
		Linus

-

I do have a pseudo LSM called "multiadm" at

http://freshmeat.net/p/multiadm/ , quoting:
	The MultiAdmin security framework kernel module provides a means

	to have multiple "root" users with unique UIDs. This bypasses

	collation order problems with NSCD, allows you to have files

	with unique owners, and allows you to track the quota usage for

	every "real" user. It also implements a "sub-admin", a partially

	restricted root user who has full read-only access to most

	subsystems, but write rights only to a limited subset, for

	example writing to files or killing processes only of certain

	users.
The use case is so that profs (taking the role of sub-admins), can

operate on student's data/processes/etc. (quite often needed), but

without having the full root privileges.
Policy is dead simple since it is based on UIDs. The UID ranges can be

set on module load time or during runtime (sysfs params). This LSM is

basically grants extra rights unlike most other LSMs[1], which is why

modprobe makes much more sense here. (It also does not have to do any

security labelling that would require it to be loaded at boot time

already.)
[1] SELinux: What I remember from coker.com.au's selinux test machine,

everyone had UID 0 and instead had powers revoked.

-

Based on Linus' criteria, this appears to be a case for reverting the

static LSM patch.
Jan, I remember you posting this last year and IIRC, there were really

only coding style issues to be addressed.  There were some review queries

and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers --

certainly not now that security architecture and security model objections

are out of bounds.
So, I would suggest reposting the code for upstream inclusion, which

would be better at least in terms of upstream maintenance, as your code

will be visible in the tree.
- James

--

James Morris

<jmorris@namei.org>

-

[...]
I looked at commit 20510f2f4e2dabb0ff6c13901807627ec9452f98

[havenot done much kernel activity recently] where you

transform the security interface, and what I see is that

all the static inline functions are replaced by an extern one, with the

same content. That actually seems to include more performance hit

than the (un)registering fluff. Why is that, actually?

-

On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
I don't want to argue for or against the actual revert; however if Linus/James/Chris

decide to do a revert, I've made a patch to do that below
(doing a full git revert is tricky since it gets mixed up with various other cleanup

patches; even inside the original patch. I've done the relevant pieces by hand via a

selective patch -R and compile-tested it). In addition I've made the modularity a

Kconfig option, since it's clearly something that is contested and thus is justified

as a user compile time choice; people who don't want this (out of paranoia or otherwise)

can now decide to disable, while others who want to experiment or use out of tree

LSM modules, can select the KConfig option.
If it turns out that the above module becomes unmaintained and no longer usable, and no

other useful cases show up, we can always garbage collect this code in the future; it's

now low-overhead anyway for those who care, due to the KConfig option.
---
From: Arjan van de Ven <arjan@linux.intel.com>

Subject: revert the modular LSM patch
Since there is a real out of tree, non-racey modular LSM module,

add back the capability to have modular LSM modules as a config option.
(note that this patch fails checkpatch.pl in a few places, however

since this is just a reverse-patch of the original code, I don't

want to fix this in order to keep exact revert behavior)
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
diff -purN linux-2.6.23-git17/include/linux.org/security.h linux-2.6.23-git17/include/linux/security.h

--- linux-2.6.23-git17/include/linux.org/security.h	2007-10-21 10:35:49.000000000 +0200

+++ linux-2.6.23-git17/include/linux/security.h	2007-10-21 10:36:00.000000000 +0200

@@ -1178,6 +1178,10 @@ struct request_sock;

  * 	allow module stacking.

  * 	@name contains the name of the security module being stacked.

  * 	@ops contains a pointer to the struct security_operations of the module to stack.

+ * @unregister_security:

...
[ message continues ]

You also need to consider whether to allow capabilities to be built as an

unloadable module.  If not, then we don't need this hook added back into

SELinux.  Otherwise, if it is desired, you also need to reinstate

capability_exit and general modular bits for security/capability.c.
- James

--

James Morris

<jmorris@namei.org>

-

On Tue, 23 Oct 2007 14:56:52 +1000 (EST)
this just allows 3d party replacements of capability like functions;

there is no need/point to have the existing capability back as modular

to be honest.

-

Thanks Arjan.  I did not actually oppose making it non-modular, and

thought there was sufficient time for people to complain meaningfully

on that change.  I also think there's not a lot of value in the modular

interface, but it's very difficult to have rational discussions in this
Yes, and I think we can still improve performance although I can't see

anyway to help out the modular case, so I guess it will have to incur

the hit that's always been there.  I think your Kconfig option is a

decent compromise.
thanks,

-chris

-

Broaden the paravirt patching machinery?
    J

-

On Tue, 23 Oct 2007 17:31:28 -0700
so far I've something much simpler in mind, I have a first prototype

and it shows code that is pretty much optimal on modern cpus.
I hope to have something postable in a week or so

-

I currently have an LSM that only handles permissions for socket_bind

and socket_listen, I load it and then "capability" as secondary on

boot - but now I can't because the LSM framework is now just the LS

framework.
Why can't this "static LSM" change be a Kconfig option?

(I don't want to have to maintain my own reverted copy of security/,

or compile this into the kernel because then I can't ever modify and

reload it without rebooting.)
--

Simon Arlott

-

Hello.
I think there are two other problems regarding LSM.
(1) There is only one "struct security_ops" structure in the system.
(2) There is only one "void *security" field in "struct task_struct".
Years ago, there was only one MAC implementation (i.e. SELinux)

in the mainline kernel.

But now, there are many MAC (or access control/tracking) implementations

waiting for inclusion into the mainline kernel.

The competition for occupying "struct security_ops" has started.
My idea is that, why not create chains of "struct security_ops"

(i.e. linked list of "struct security_ops")

and allow choosing which chain to use for per a "struct task_struct" basis

(i.e. add "struct security_ops" to "struct task_struct").
TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use

"struct security_ops" since SELinux is occupying it.

Yes, there is secondary_ops in SELinux, but it doesn't help TOMOYO Linux

since SELinux is not calling secondary ops for operations TOMOYO Linux wants to control.

So, there is only one "struct security_ops" as a matter of practice.
At the same time, the competition for occupying "void *security" has started.
My idea is that, why not allow multiple "void *security" fields in "struct task_struct"?
TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use

"struct task_struct"->security field since SELinux is occupying it.

If TOMOYO Linux is permitted to add "void *" and "u32" to "struct task_struct",

SELinux and other LSM implementations can use "struct task_struct"->security field.
May be we should consider stackable LSM again?
Regards.
-

That idea was in the Stacker module, and it was tabled until there is

more than one upstream LSM. In particular, it requires 2 or more LSMs

that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux

are all exclusive of one another (in a running kernel) and real stacking

is still pending useful component intrusion prevention modules. Such

Just disable SELinux and load TOMOYO. Oh, you can't because someone has

made modules not be loadable :(  Hmmm, perhaps someone could fix that by

Exactly. Stacker was shelved, so to speak :) because of the lack of

in-kernel modules. Soon it will be time to reconsider that.
Crispin
--

Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin

CEO, Mercenary Linux		   http://mercenarylinux.com/

	       Itanium. Vista. GPLv3. Complexity at work
-

Let's start with the more important questions:
Did you submit your LSM for inclusion into the kernel?
If yes, why wasn't it accepted?
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

No, because the interface for configuring it would be rejected... I have

a /proc file which I write a binary configuration file to. This works

fine for me but it would take a lot of work to write a proper interface

- which I'm still not sure how to do*.
That doesn't solve the problem that it's no longer possible to reload LSM

modules to make changes at runtime. Why should I have to reboot to change

something from now on when it works ok? The reasoning seems to be based

around a dislike of some out of tree modules. (Although it doesn't look

like there's appropriate locking around the register/unregister process.)
* (I've got a list of access rules which are scanned in order until one of

them matches, and an array of one bit for every port for per-port default

allow/deny - although the latter could be removed.

http://svn.lp0.eu/simon/portac/trunk/)
--

Simon Arlott

-

Generally, the goal is to get external modules included into the kernel.
You want to be able to have this functionality and you do not want to

use SELinux for it.
But instead of working on getting your code into the kernel you are

requesting that an API making it easier for you to maintain it

externally comes back.
There are other points in this thread that might or might not warrant

making LSM modular again, but even though it might sound harsh breaking

external modules and thereby making people aware that their code should 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

This argument seems to start from the assumption that any externally

maintained kernel code *can* get into the kernel, which doesn't stand

up to  reality. Once you admit that there is code which, for very good

reasons, won't ever be accepted into the mainline kernel tree, what you

are saying amounts to: "Code that isn't fit to be included in the

mainline kernel isn't fit to exist at all."
I'm not sure I can agree with that.
--=20

Tilman Schmidt                          E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=C3=B6ffnet mindestens haltbar bis: (siehe R=C3=BCckseite)

What kind of code is not accepted into the mainline kernel tree for good

reasons?  What are these reasons?  What specific code are you talking

about?
I'm trying to compile a list of all known external modules and drivers

and work to get them included in the main kernel tree to help prevent

these kinds of things.  If you know of any that are not on the list at:

	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers

please feel free to add them, or email me with the needed information

and I will add them to the list.
thanks,
greg k-h

-

quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
Provides a /dev/dsp style node for legacy applications that support

neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-cc...
Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after

5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )

-

(I think that should read "AND more than 2 channel sound")
Couldn't ALSA's OSS emulation be extended to support more than 2
It looks like this could be trivially fixed in a mergeable way.  That

LKML thread petered out before the problem was seriously analyzed.
Did you try the -Z flag of hdparm?
Lee

-

It is for programs that only give out 2 channels of audio data.

Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels,
IIRC, yes, been through all sorts of hdparm options. -Z did not help

at all, and -B only prolonged the delay from 5 to around 15 seconds.

I contacted Tosh Corp (before posting on lkml) and while they know of

the 'issue', I did not get a satisfactory answer (namely how to FIX

it), so I thought why spend time slapping if there's a workaround...
Causing a minimal head seek every now and then (4096 bytes per 3

seconds is a somewhat small block size with a not-too-low interval)

is a working workaround for now. The module code is not top notch,

but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the

same laptop.

-

- proprietary code

- unmaintained code

- code conflicting with existing kernel structure or policy

- code in which the concerned subsystem maintainers see no benefit

- code which its author is unable and/or unwilling to convert to

  kernel coding standards
The details vary, but the fundamental reason is always the same: to

maintain a sufficient level of code quality in the kernel. Point in

case, the recent discussion whether drivers not supporting
Some examples, in no particular order: Reiser4, AppArmor, VMware,

the staircase deadline scheduler, the first version of ser_gigaset,

the Matrox HAL module, SuSE's "taint extension". Yes, some of these

are in the kernel now, or have been superseded by other code that
That's certainly helpful, but I still think there will always be

a number of external modules that cannot be merged right now or at

all, and deliberately making life difficult for out-of-tree code

maintainers in order to coerce them into submitting their code for

inclusion in the kernel will not work, it'll only create bad

feelings.
Thanks,

Tilman
--=20

Tilman Schmidt                    E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

It's unclear whether distributing not GPL compatible modules is legal

at all.
And they are definitely not "very good reasons" for doing anything in 
Unmaintained code in the kernel has a realistic chance of being usable

for 5 years.
Unmaintained external code is quite likely to be unusable after
Let's fix the problems, not work around them.
There is a conflict between getting code included and ensuring some

minimum quality of the kernel, but in many cases we could try better.
And when there's a good reason for a kernel policy, then code that
That's their fault, and definitely not a "very good reason" for making 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

We're neither talking about distribution nor legal aspects, but

about existence. But anyway, you seem to agree with me that there
There is a big difference between "not doing anything to help"

and "actively doing something to make life difficult for". The

former is undoubtedly legitimate. It's the latter we're
Then why is "being unmaintained" being toted as an argument
That's certainly better, but not always possible. Do you

agree with me that if it isn't, then that's a very good
Correct. Again, you appear to agree with my statement that

for some code there are very good reasons not to include it
Putting aside the fruitless question of whose fault it is,

is it a "very good reason" for actively making life more

difficult for them than it is already, eg. by gratuitiously

breaking interfaces they rely on for no other "very good

reason" than to discourage out-of-tree development? In other

words, do you think it benefits the Linux community if you

discourage those programmers you've already scared away from

submitting their code to the kernel from continuing their

work off-tree, too? In summary, do you think the world would

be a better place if all the existing out-of-tree modules

just ceased to exist, without any replacement?
T.

-

Justifying anything with code with not GPL compatible licences has zero

relevance here.
And there's value in making life harder for such modules with

questionable legality. As an example, consider people who experienced

crashes of "the Linux kernel" caused by some binary-only driver.

Not that uncommon e.g. with some graphics drivers.

This harms the reputation of Linux as being stable.
The solution is not to support proprietary drivers, the solution is to 
But this does not result in any obligation of supporting low quality

external code that destabilizes the kernel of people using it.
If it's low quality code doing something useful - well, how many hundred 
With your "without any replacement" you needlessly excluded the

reasonable solution:
The solution is that someone other than the author either takes the

existing external code or rewrites it from scratch, submits it for

inclusion into the kernel, and maintains it there.
Let me repeat that Greg has said he has hundreds of volunteers for such 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

You are mixing up several distinct categories here: "out of tree"

!=3D "non-GPL" !=3D "proprietary" !=3D "of questionable legality" !=3D
So how do you propose to "get" those replacements? And what shall

?
No idea. Obviously not enough to actually solve the problem.
My "without any replacement" is just a description of reality.

All current external code I am aware of continues to exist only

because there is no in-kernel replacement.
Again: how do you propose to bring that solution of yours to pass,

how long do you think it will take, and what do you propose current

users of out-of-tree modules do in the meantime?
Without reasonable answers to these questions, your proposed
Even with hundreds of volunteers, your proposed solution of just

rewriting *all* external code in a way fit for inclusion into the

kernel is an unachievable goal. Just look at the list on

http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers

and try to answer why each of them is still out of tree.

Hint: In most cases it's neither out of malice nor stupidity on

the authors' part.
Of course in-tree code is always better than out-of-tree code. But

I maintain there will always be out-of-tree code (modules, drivers,

whatever) that fills a real need not (though hopefully, just not

yet) satisfied by any in-tree code. All I'm asking for is that you

take a pragmatic stance with regard to that: not going to any great

lengths to support it, but acknowledging its existence and

legitimacy - and not inciting to deliberately break it.
Thanks,

Tilman
--=20

Tilman Schmidt                          E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=C3=B6ffnet mindestens haltbar bis: (siehe R=C3=BCckseite)

"binary-only non-GPL out-of-tree module causes kernel crashes" is a

quite common pattern for some popular binary-only modules.
And noone except the vendor of this module can debug and fix it.
Include more than one binary-only module into your kernel and the number 
They should swamp the hardware vendors with requests for releasing

hardware specifications.
You list the drivers you currently have in mind at the Linux Driver 
You list the drivers you currently have in mind at the Linux Driver
Noone proposed to make the existance of out-of-tree modules completely

impossible - but it is a fact that derives directly from the Linux

kernel development model that thre's no stable API for out-of-tree

modules, and therefore each new kernel breaks many of them.
Once you accept this fundamental fact there's not much point in arguing 
There are different problems why different drivers are not (yet)

included in the kernel, but which ones don't have any possible solution?
And if you compare the numbers you'll see that Greg has on average a 
The most important question is still:
Why should there always be out-of-tree code that fills a real need not

satisfied by any in-tree code?
Not everything might have worked in an ideal way in the past, but let's 
cu

Adrian
[1] http://linuxdriverproject.org
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Common, yes. Popular, maybe. The only one, not. Taking that as reason

for breaking out-of-tree open source modules is throwing out the baby
They are doing that already. But somehow it fails to magically cause

open source drivers to spring into existence immediately. The crucial
Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
Exactly. Again, the problem is time. Deliberately breaking external

modules now and promising an in-tree alternative for later leaves

users out in the cold. That won't do much to improve the reputation
Granted. But that's not the point I was arguing anyway.
There is still a point in arguing that breaking out-of-tree modules

is not a goal. It's acceptable collateral damage if there is a good

reason for a change, but it doesn't by and in itself constitute such

a reason. That's why I'm taking exception with your statement in
Breaking external modules is *not* positive. It's acceptable, but

?
I'm convinced all of them have possible solutions. The challenge

is to turn a possible solution into an actual one. And again, the
Not every problem can be solved faster by throwing more people at

it. Take mISDN as an example. Its developers have stated the goal

of inclusion in the main kernel tree years ago and it's still not

there. Deliberately breaking this external module "to make people

aware that their code should get into the kernel" would only delay

this goal even more. But sending them a handful of new volunteers

now would probably constitute the proverbial "adding manpower to a
Because every in-tree code starts as out-of-tree code, so as long

as there's development at all there's always a certain amount of

code which isn't in-tree yet - or of which it isn't even sure yet

whether it will get in-tree.
HTH
--=20

Tilman Schmidt                          E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=C3=B6ffnet mindestens haltbar bis: (siehe R=C3=BCckseite)

I'm sure that the majority of Linux users would never acquire

the 4-board assembly that we use to acquire X-Ray data and

generate real-time images for the baggage scanners in use

at the world's major airports. That assembly, containing

numerous CPUs and other high-speed pipelined stuff would

cost the user about  US$100,000 so I'm pretty sure that

are not many takers so it is very unlikely that any modules

to support it would never get into the mainstream kernel.
If we can't build out-of-tree modules to support this stuff,

then we can't use Linux. Already, we've complied with the

GPL terms that we will give our module code to anybody,

even though it is useless without our hardware which I'm

certain they are not going to buy.
Linux is NOT just a desk-top OS. It has many other uses.

It should scare the hell out of everybody to know that

Windows CE is being used in Aircraft flight directors.

We need to maintain the viability of Linux in dedicated

or embedded operations so that it will eventually replace

such stuff. Over the years, there has been a continual

attempt to obfuscate Linux to make it more difficult to

use out-of-tree. Further, the continual internal changes,

which don't affect anything but compatibility and the

ability to compile (changes for the sake of changes),

has caused many engineers to lose all their hair. Stop!

This has gone far enough. Right now we cannot upgrade

past linux-2.6.16.24 just because some kernel hacker

decided so. This is bad, real bad.
Cheers,

Dick Johnson

Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).

My book : http://www.AbominableFirebug.com/

_
****************************************************************

The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation...
[ message continues ]

Of course it would be accepted, hell, we have a whole sub-architecture

with what, 3 users?  :)
So please submit patches for your drivers, and we will be glad to review

them.
thanks,
greg k-h

-

As long as you're maintaining them proprely, I don't why.
	Xav
-

[...]
You two are hypothesizing.
  - We (most of us) change APIs to improve the kernel.
  - We (most of us) contribute to the kernel as a program for people to

    run, not as a library for other projects to develop different or

    extended kernels¹ on top of it.
Actually, by providing the code under GPL, full read access to the SCM

for everybody, and public development mailinglists, we make life for

external projects who do their own drivers and kernels as easy as these

unconnected projects could wish for.²
-----

¹) Even distributors of Linux kernel packages are encouraged to stay

close to mainline and to feed their changes into mainline, IOW to take

part in the Linux kernel project.
²) Of course if such projects chose to become part of the Linux kernel

project, they would get to enjoy additional bonuses as outlined at the

end of stable_api_nonsense.txt.  Sure, becoming part of the project

involves to cooperate, and not everybody wants or can afford to do so.

--

Stefan Richter

-=====-=-=== =-=- ===--

http://arcgraph.de/sr/

-

No, we're not. We're discussing the very real issue of whether

LSM should be amputated in such a way as to make life difficult
That's good. If that was consensus then this discussion would

not be necessary. What I am protesting against is attempts to

change the API purposely to obstruct out-of-tree code. That is

not a way to improve the kernel.
--=20

Tilman Schmidt                          E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

I still believe you are.  From what I understood, the API change had

technical reasons.  (What I have read is that using security modules in

the form of loadable and unloadable kernel modules didn't make sense.)

--

Stefan Richter

-=====-=-=== =-=- ===--

http://arcgraph.de/sr/

-

The jury is still out on that, and it's not my area of expertise

anyway. But Adrian declared that making life more difficult for

out-of-tree module developers would in itself be a legitimate

reason for such a change, and that's what I'm disputing.
--=20

Tilman Schmidt                          E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

Stacking modules makes a lot of sense, it may be tricky to order sensibly,

now if you want the features of more than one LSM (including those being

added to the kernel), you need to *copy* the parts you want. Since you

can't use modules to load them, because that feature's been removed, you

need to maintain your own kernel tree for it or submit your changes which

will eventually end up with LSMs that all do the same thing...
This static LSM doesn't even make sense to me - what happens if I select

both SECURITY_CAPABILITIES and SECURITY_ROOTPLUG? I can't easily check

because I'm using 2.6.23 - so I can still reload my module while changing

it to have a better configuration interface. Kconfig doesn't look like it

will prevent it. Surely the options should be a multiple choice menu?
Adrian's mentioned people eager to write drivers - LSMs aren't drivers,

there's really nothing to work from except "security module that does X"

and for that people should develop what they want themselves.
There's no reason for out of tree *GPL* drivers to not exist, is there?

How much of the non-driver code that gets merged into the kernel exists

first as out of tree modules, rather than direct patches to the tree

itself? It was made much easier since 2.4 to compile a module out of tree

using a simple Makefile. (Perhaps that should be removed too?)
--

Simon Arlott

-

How often did this happen yet?

--

Stefan Richter

-=====-=-=== =-=- ==-==

http://arcgraph.de/sr/

-

Do you have examples of proof of this?  Read

Documentation/stable_api_nonsense.txt for how we already make

out-of-tree code developer's lives hell :)
thanks,
greg k-h

-

No proof in the legal, mathematical or scientific sense of the

term, but examples:
- at least one talented kernel developer giving up his work,

until then maintained out of tree, after submitting it for

inclusion in the kernel and taking the ensuing fla^Wdiscussion

on LKML (nothing extraordinary, just the usual lack of

courtesy and respect) too much to heart
- the furious flames on LKML each time someone dares posting

helpful information about getting non-GPL software working

again with the newest kernel version, which will certainly

never achieve inclusion of that software in the kernel but

definitely create bad feelings on both sides (righteous
Oh yes, that one. A key piece of evidence. Yes, I've read it,

though I sometimes wish I hadn't. Its very title supports my

observation on the creation of bad feelings, and the actual

text doesn't contradict it. (no ":)")
T.
-

There's one important point to note:
In a project of the size of the Linux kernel (at about 2000 distinct

people contributing code within one year) you will always lose

developers:
If you require too much from code for getting it included you lose some

of the people who develop code.
If you accept code of dubious quality you lose some of the people who

care about the quality of the kernel.
And if you add a stable API for modules with not GPL compatible licences

at least one untalented kernel developer (me) might give up his work.
If your goal is to please all developers you have a goal you can't

achieve.
The only reasonable way is to accept that whatever you do you'll lose

some people and go in the direction you consider the right one.
And the power of open source is that when an open source project gets

into a direction many people dislike they can simply fork it. Consider

e.g. XFree86->X.Org or NetBSD->OpenBSD. And that's nothing bad - either

the forks develop in different directions creating different useful 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

The change makes it much harder to develop in tree too. Also, this really

needs to be reverted and put in the feature removal schedule... unless

you intend to deliberately make all out of tree LSMs unusable with no

warning and no time to have them added to the kernel? We're already at

2.6.24-rc1.
--

Simon Arlott

-

Do I have to at least try to submit it to LKML first before it is

even considered for the OOT wiki page? :-)

-

No, you can go hide on your own, that's what the majority of projects on

that page have done :)
But of course, it would be good for you to at least submit it and get

feedback.  Or, if you don't want to do it, the linuxdriverproject

developers would be glad to help you out...
thanks,
greg k-h

-

SELinux couldn't do it when I wrote my own module, it may do now but I

haven't checked - that's also far too much extra configuration overhead
It's also much harder to maintain it internally too since it can no

longer be compiled as a module. If it were possible to have to make LSM

usable as a module but without secondary support, that would make

development easier - although secondary support is so trivial I doubt

it makes a difference to the possibility of allowing it to be compiled
You're only going to be forcing me to spend *my* time developing it into

something that could be accepted into the kernel when it works fine for

me already. Then I'd have to convince the LSM maintainer(s) that it

should be merged - this isn't like an external hardware driver where
--

Simon Arlott

-

Those proposing LSM modules over the past couple years have

been treated most harshly. I have personally taken the least

flak of anyone on my proposal, and at that there have been

times where I felt like pulling out the #5 clue stick and

taking a few swings. It's no wonder that people are afraid

to suggest a module. I didn't do it until I had combed through

the archives and prepared answers for the most common attacks.

I hope that Smack moving forward will defuse some of the bad

vibes that have clouded the LSM for so long. I don't blame

anyone who kept their module to themself given the hostility

which even successful products have encountered.
And don't give me the old "LKML is a tough crowd" feldercarb.

Security modules have been much worse. Innovation, even in

security, is a good thing and treating people harshly, even

"for their own good", is an impediment to innovation.
Casey Schaufler

casey@schaufler-ca.com

-

I agree that innovation is critical to the success of Linux, and security

is not immune to that.  The trouble is that most of the security modules

that have come forward have had some real serious shortcomings.  I do

believe it is prudent to keep in-tree security sensitive code under

high scrutiny because we do not want to create security holes by adding

problematic security code.
thanks,

-chris

-

I agree that security code does need to provide security. What we

need to get away from is the automatic attacks that are based on 20th

century computer system assumptions. Things like "name based access

control is rediculous", and "a module can't be any good if it doesn't

deal with all objects", or "the granularity isn't fine enough". Look

at TOMOYO. It's chuck full of good ideas. Why spend so much energy

badgering them about not dealing with sockets? How about helping the

AppArmor crew come up with acceptable implementations rather than

whinging about the evils of hard links? And maybe, just maybe, we can

get away from the inevitable claim that you could do that with a few

minutes work in SELinux policy, but only if you're a security

professional of course.
Sure, some LSM proposals will be lousy, and some really will be

better done as an SELinux policy module. Some will even have merit

but require unreasonable interface changes. As people who care

about security (y'all who are only from the LKML are excused) it

is our obligation to look beyond the preconceived notions of what

is and isn't secure. Security is subjective. It's how you feel

about it.
Casey Schaufler

casey@schaufler-ca.com

-

Casey,
Thank you introducing TOMOYO Linux. I really like your idea of

simplified MAC (and you work so hard!). I also find advantages

of AppArmor for distributing policies with less hustle. Finally

and most importantly, I respect SELinux as the first in-tree,

flexible and reliable security frame work and respect developers

involved.
As a project manager of TOMOYO Linux, I would like to

push it, of course. But I noticed, if each of LSM module

developer begin pushing their own code, that's not for the

sake of Linux and we may end up with chaos.
Instead of pushing TOMOYO Linux, I started developing

comparison chart of security-enhance Linux implementations.

The current version can be found in
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
I would like to receive feedbacks from Stephen, Crispin

(you already have a comparison, though :),

Casey and any people interested in. If possible,

I would like to include opinions from BSD people.
I would like LSM to be the result of common requirements.

"Common" means good in general, but not always for security

perspective. IMHO, I think it is possible for us to get to the

conclusion not to have a framework.
Cheers (and with love to Linux),

Toshiharu Harada
-

Smack Security Model: autolabel, as far as I can tell.

Smack Policy Generation: user - hand - and an editor

Apparmor tutorial (beats any FAQ at first):

	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi

-

I noticed the smell of danger in the naming of "Security Model".

Updated above two items. Thank you. :)
I'm not an optimist to believe we can reach the perfect

comparison. The purpose is to feed information, not to judge.

This might sound ironically, but I don't really think

we can *compare* them because they have different

theories/purposes/backgrounds. Some kind of forgiveness and

fuzziness are required.
As I don't want to steal everybody's bandwidth,

simple updates will be done silently. Your suggestions and

information will be greatly appreciated despite of

visible evidence.
Thank you.

Toshiharu Harada
-

Thanks for the high praise. Unfortunately that FTP site seems to not be

working. Some alternatives:
    * My personal copy of the above video

      http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi

    * Similar talk at linux.conf.au 2007

      http://youtube.com/watch?v=EgrfmSm0NWs

    * Similar talk at Defcon 2007

      http://video.google.com/videoplay?docid=-1731833784646588861&hl=en
Crispin
--

Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin

CEO, Mercenary Linux		   http://mercenarylinux.com/

	       Itanium. Vista. GPLv3. Complexity at work
-

[...]
Actually, if the selinux team would do the same [introductionary video],

I'd guess the hardness level commonly associated with selinux could be

relieved a bit.

-

<sarcasm>Hmm. So lets add automagic security module. It magically fixes

security holes, and you can feel good about it.</sarcasm>
							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Send patch.
--=20

Tilman Schmidt                          E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

Perfect security from threats that normally deliver via internet!

(And it is even one of these that benefit from being modular!)
#include <linux/kmod.h>

#include <linux/module.h>

#include <linux/netdevice.h>

#include <net/net_namespace.h>
static void cl(const char *name, const char *state)

{

	const char *args[] = {"ip", "link", "set", name, state, NULL};

	call_usermodehelper("/sbin/ip", (char **)args, NULL, UMH_NO_WAIT);

}  
int __init automagic_security_init(void)

{

	const struct net_device *dev;
	for_each_netdev(&init_net, dev)

		cl(dev->name, "down");
	return 0;

}
void __exit automagic_security_exit(void)

{

	const struct net_device *dev;   
	for_each_netdev(&init_net, dev)

		cl(dev->name, "up");
        return;

}
module_init(automagic_security_init);

module_exit(automagic_security_exit);

-

Key-based masterlocks are easily broken with freon, and their combo

locks are easily brute-forced in about ten minutes. Yet, I'll still

use them to lock up my bike and garage.
The idea that poor security is worse than no security is fallacious,
If security code actively *adds* holes, then that's obviously a deal breaker.

-

On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
The question is what the security threat is and the value of the secured
The common experience is, that common people just *feel* safer (just

because they have poor security).

With no security, they know that there is no security. With poor

security, they do not know (or can deny) that they have next to no real

security.

The prime example here is the usual (so-called) "personal firewall" on

Windows where people work normally as "administrator".
	Bernd

--

Firmix Software GmbH                   http://www.firmix.at/

mobil: +43 664 4416156                 fax: +43 1 7890849-55

          Embedded Linux Development and Services
-

Do you lock your bike up when you leave it lying around? My point is

that real security comes in layers, not one perfect solution that will
The fallacy here is to believe that just because they have no

security, that it will *in*any*way* change their behavior. I deal with

real users daily, and *they*don't*care*. Further, there's no level of

education that we can instill into the community to make them aware of

the issues and change their habits accordingly, because real users

don't have the background to understand those lessons.
While you can teach them that running an executable from someone they

haven't heard of is obviously bad, they don't know why downloading an

image is potentially dangerous, "it's an image, right?" "Well, there's

these things called buffer overflows..." <eyes glaze over>
Security is not an all or nothing game, it's layers. And we have to

make sure that the layers are usable without taking a course from the

NSA. I'd love to see a poll of the kernel development community to
So your argument is that if there weren't a personal firewall on

Windows, that a significant number of people would then not run as

Administrator? I beg to differ.
Ray

-

Of course not. "Security" as such is more than less "only" risk
If people don't care, they are pretty lost anyway.

That's actually the reason for all that security stuff that no one wants

but which stands in the way of all people just because of the "don't

care" faction (which by far the majority of all in any given area).

But there is that (also not too small) "I installed $PERSONAL_FIREWALL

and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in
And every layer/subsystem/area must be checked and seen independently of

others (or the dependency must be that strong that no one can work

around).
"selinux=0" on the kernel commandline is normal - no unknown people have

logins and so there was no reason to learn it. And against should it
No, how do you come to that conclusion?
People login as "Administrator" because they did it since DOS3.0.

People buy and install $PERSONAL_FIREWALL because some cheap PC tech

magazine had advertisements for them.

Next generation (or this generation?) viruses/malware will either

reconfigure $PERSONAL_FIREWALL silently (and if course only

temporarily).

And the vendor of $PERSONAL_FIREWALL writes into the manual (which no

one reads) or the EULA (which no one reads because it isn't relevant in

the first place) or some README (which no one finds) that one must not

login as "Administrator". But that just to keep the vict^Wbuyers to not

sue them. And working on Win* without being "Administrator" is a real

PITA - so the average user won't do it for long.
So apart from the personal feelings of that user I can't find any sign

of security.
BTW from a commercial viewpoint, the (so-called) "personal firewalls"

were probably one of the best ideas (and another major example that

technical expertise has nothing to do with sales success).
	Bernd

--

Firmix Software GmbH                   http://www.firmix.at/

mobil: +43 664 4416156                 fax: +43 1 7890849-55

          Embedded Linux Development and Services
-

On Thu, 25 Oct 2007 09:04:57 -0700
I absolutely agree it's a layer game.

HOWEVER, even in a layer game we need to have each layer to be

reasonably solid and not just fake security ("snakeoil").
So while I think it is entirely fair to judge a piece of software

against what it intends/claims to do, because other pieces in the layer

game will depend on it to function reasonably well. 
So most of the LSM fist-fights have been about disagreement of the

intent; and some about code not living up to its own intend, all mixed

up. Arguing about the intent is less productive imo (as long as it's at

least somewhat reasonable, intend like "I want to add rootkits" doesn't

count obviously), paying attention to check if the code lives up to its

stated intent/purpose on the other hand is immensely useful and needed;

for a given implementation it may mean reducing the scope of the intent

if the implementation just doesn't go as wide as originally thought, or

fixing some issues in the implementation to live up to the intent.

-

There is a ton of evidence both in computing and outside of it which

shows that poor security can be very much worse than no security at all.

In particular stuff which makes users think they are secure but is

worthless is very dangerous indeed.
When you know that security is limited you act appropriately, when you

believe security is good but it is not you take inappropriate risks and

get badly burned.
Alan

-

The "bad security is worse than no security" idea comes exactly from

what Alan says above: it happens when the security is not as good as you

think it is, and so you don't take adequate precautions.
Using the ongoing bicycle lock example, the discovery a few years ago

that a certain model of Kryptonite bike lock could be picked with a

simple pen made the security on this otherwise very sturdy lock become

abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987
Conversely, the case can also be made that "weak security is better than

no security". It is better to secure your bike with a $10 lock than no

lock. If someone insists on only "high" security bike locks that cost

$1000 and weigh 30 lbs, then most people will choose to not lock their

bikes, or skip biking all together.
IMHO, much of the criticism leveled at proposed LSMs has been of the

latter kind, or worse. That the security of the proposed LSM does not

meet some particular use case does not make it "bad", it makes it not

for that use case.
To reject an LSM for providing "bad" security, IMHO you should have to

show how it is possible to subvert the self-stated goals of that LSM.

Complaints that the LSM fails to meet some goal outside of its stated

purpose is irrelevant. Conjecture that it probably can be violated

because of $contrivance is just so much FUD.
Exception: it is valid to say that the self-stated goal is too narrow to

be useful. But IMHO that bar of "too narrow" should be very, very low.

Defenses against specific modes of attack would be a fine thing to build

up in the library of LSMs, especially if we got a decent stacking module

so that they could be composed.
Crispin
--

Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin

CEO, Mercenary Linux		   http://mercenarylinux.com/

	       Itanium. Vista. GPLv3. Complexity at work
-

On Sun, 28 Oct 2007 15:08:56 -0700
exactly; this is why I've been pushing recently for each new LSM to at

least document and make explicit what it tries to protect / protect

against (threat model and defense model in traditional security terms).

Without such an explicit description it's both impossible to

"neutrally" review a proposed LSM towards its goals, and it ends up as

a result with people making assumptions and attacking the model because
again I agree pretty much; I do want to reserve some minimum "common

sense" bar because people may (and probably will) do silly things withs

LSMs that are really not the right thing to do objectively.
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

-

LSM is providing bad security on two fronts.
Number 1 LSM are speeding effort to create features.  Apparmor and

Selinux both provide file access filtering from applications.  Yet

they double up the code to do it.   So they cannot be used with each

other without doubling up hooks.  Then other LSM are creating there

own sections of code to do the same thing.   Simple rule more code

more risk of bugs since it will be less audited.  Duplication defense

features is really bad for security.  Some how code sharing has to be

got into LSM construction.
Number 2 The critical bit LSM stop at the edges of applications.   Now

without overlapping my hooks with existing LSMs I cannot create

application level protections.  Overlapping hooks will cause speed

loss.
LSM is set to protect the application. But inside the application

there will be sections that need the access rights and others that

don't.  Now a exploit in any section of the application under LSM gets

the LSM assigned rights.   With application level this can be done a

few ways extension to elf that is create by the complier and api calls

lowering access functions of current thread or for a starting thread.

If you exploit a section of the code without access to disk network

access and so on and without the right to call any function that does

that.   What have you exploited.   Minor data damage compared to

complete data that the application have access to being stolen as what

is the case with LSM at moment.  Basically LSM prevent taking control

of the complete system but don't help to stop peoples private data

from being stolen.  Both are bad to happen to a person.
LSM design is there to help security development not get in its way or

to cause bitrot.  Currently LSM design is causing major risk bitrot in

duplicated code.
Reading and processing configuration files should be independent to

the protection methods.   Hopefully designed to be able to run user

mode to test if the new profile for a application is safe to add

befor...
[ message continues ]

Once you have stacking then it actually at times will make sense to have

security modules that do one very precise thing and do it well.
Alan

-

(finally starting to make headway through this thread over a month late)
Hey - I thought it was the other way around?  :)
-serge

-

(So, I take it that you *don't* lock your bike up, as poor security is

worse than none?)
While I believe you, I'd love to see references as it doesn't match my
'Inappropriate risks' nowadays is surfing the web and opening up mail

attachments that claim to be movies of dancing bears. I'd argue that

users have a reasonable expectation that these are things that should

'just work,' and be safe, much as normal humans have an expectation

that their car isn't going to explode when they turn the ignition.
Perfect is the enemy of good, or words to that effect, right? My point

is that requiring perfection out of a security framework is a bar

that's going to be awfully difficult to reach (and when it supposedly

has been achieved, as in SELinux, mere mortals find it too troublesome

to run with as it's far too difficult to configure). Security can and

should be done in layers, and what one may miss, another may catch.
Ray

-

I do lock my bike with combination lock I found somewhere and cracked

in five minutes... sometimes.
But do you suggest that I use paper tape to 'lock' my bike to

streetlight? You just said that poor security is better than none,

right?
							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

I think you may be misinterpreting the word "poor" here.
Many people in this thread consider a security solution "poor" because it's

not "complete" or "perfect": it may work against attack ABC but not attack

XYZ. The defendants say that XYZ isn't possible in the environment that it's

supposed to be used, or XYZ may be too expensive to be worth implementing,

or they just are rare enough to be ignored. Heck, all security solutions

could be broke given physical access.
Implementing a security solution has a cost. Bypassing it also has a cost.

Sometimes it's economy, not technique, decides whether a particular security

solution is a good one.
Locks are a good example for this. It has a low cost/effect ratio, and very

easy to use. Is it 100% safe? Definitely not. People lock their bikes to a

tree when they enter a supermarket because it's reasonably safe. But leaving

their bikes like that over a few nights on a downtown street? Probably not a

good idea. Don't assume all people are idiots who do not know that (ok, some

people are, so the lock's manual states "it can be bypassed by a skilled

thief").
But what tapes are good for? I don't know what kind of value it adds to the
-

-

On the contrary because I know it is not secure I would
a) Insure it

b) Not waste vast amounts of money on a useless expensive lock

c) Make sure the bike looked not worth stealing

d) Take the saddle with me
(or the software versions of that
a) Keep backups

b) Not waste vast amounts of money on bogus security software

c) Keep the system looking uninteresting
Yes and its very clear from the things said by politicians that if the

computer software people don't do this soon, the legislators will make

very sure they do by stripping away all the techniques used to hide from
Absolutely - but those layers should do whatever they do *right* and

really do it, whether they are complex whole system controls like SELinux

or simple network security tools.
Alan

-

and the unsurance company would have a clause in the policy that wouldn't

cover you unless you used a lock, becouse they recognise that while it

wouldn't stop everyone there is a large group of potential thieves that it 
who said the lock was expensive? and while you are not willing to spend

money on a lock you are willing to spend (much more) money on an insurance

policy.
-

Ok lets get to a good point.
Lets define a key bit.   What is a good software security lock?
My define is that its available to be used everywhere its needed and

when ever its need without flaw.
This is where most LSM fall in a heap.  Because you have to have the

LSM loaded to have its security features and cannot always be mixed

with other LSM it failes the when ever it is needed test.
On top of this most LSM features don't provide any form of direct

control to non admin users or applications to lower there access

rights.  So it also fails to be used everywhere its needed.
Since the LSM design itself is flawed in my eyes.   These flaws make

it hard for LSM to share tech advantages with each other.   LSM are

very much like putting a lock threw the front wheel of a bike.   So

the thief removes the front wheel and walks off with the rest of the

bike.  The critical data is in the user accounts.
The big thing with most LSM how do they handle security inside a

application on a thread by thread base.  They don't reason it gets too

compex without known the internals of the application.
We are talking security here and design of LSM's are not offering the

option max security.
Max security has to get down to a single thread inside a application

with all the security blocking features LSM's offer.  Reason a flaw in

that thread could be made completely harmless even that the other

threads in the application has complete system rights.
Idea of Max is to keep application flaws to as minor security flaw as

they could have been.   Ie Hopefully no risk because the flaw happened

in a section of code with no rights.
This is virtually imposable for any form of profiling creating

security to ever do(LSM profile based security).  What is needed is

application controlled security with profile based security as fail

back.  I know this means ripping your LSM parts apart and designing in

application controls.  Allowing features to be shared between LSM and

even to be there when the LSM ...
[ message continues ]

there is also pleanty of evidence that you don't have to be perfect to be

good enough.
in addition security is useually traded off for something else

(useability, administrative effort, money, etc) and depending on what's 
This is very true, but the solution isn't to try and eliminate everything

other then perfect security, it's to properly document the limitations of

various options and educate people about them.
David Lang

-

I have different deal breakers.
If a LSM is something simple/commonly required it should be made like

posix file capability's provided to all to use.   Sorry to say I see

the file protection in apparmor as something everyone should be able

to use at will like posix file capability's.  All enforcement features

should be common.
I see a LSM as a director commander its reason for existence is to

read security configs and hand them permissions and respond to

problems.   Any enforcement should be default in kernel.
So LSM could be roll based, mac or any other model.  Current problem

enforcement and guiding are mixed up in one block.  So evolution is

not happening.
The enforcing bits of LSM's should be a simple no brainier addons to

the Linux kernel.  The problem is at moment they are mixed up with Mac

....  A security model to use has to be picked to suit job.   Role

Based can be Better than Mac and Mac can be better than Role based.

It all depends on what you are defending.
Thing common all need to protect suid, file access, network access...

The bits you need to defend don't change if or if not you are running

a LSM.  So why are these bits bottled up inside LSM forcing people to

choose the wrong security model for there task to get protection at

times.
There can never be one LSM to do every job.   But the big but all the

common bits to protect every job could be in kernel.  Only thing

missing is the director.
This is exactly the same problem Virtual Server solutions had when

then wanted to get into the kernel.   At least the Virtual Server

solutions were not as pig headed as some of the LSM guys about it.

Where its all in or not in at all.   Little bits into kernel is better

than nothing.
Really this will sound bad if I had my way I would kick all LSM's out

of the main kernel tree until they learn to work with each other to

share bits.  We don't need 10 copies of protect files from access.  Or

10 copies of limit what .so a application and interface with and so

on.
...
[ message continues ]

What I'm giving you is "Linus has decreed there can be LSMs other than

SELinux."
Getting LSMs included should no longer be harder than for other

parts of the kernel.
And don't get me wrong, I'm not saying my point should decide this

discussion. It's simply the point that making it harder for external 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Well, despite my heart-felt feelings that we should support different

people in trying out different things, one of the issues is also that I'm

obviously not myself a security person. I can "decree" all I want, but in

the end, I really want the people *involved* to merge security stuff. 
Right now Chris Wrigt is the documented maintainer for LSM, and quite

frankly, I do not want to take it over. I really really really hope that

people that are interested in security can work this thing out, and my

only requirement is that it doesn't end up being any kind of force-feeding

of opinions and ideas, since clearly there is tons of room for

disagreement in the area..
Do other people want to stand up and be "LSM maintainers" in the sense

that they also end up being informed members who can also stand up for new

modules and help merge them, rather than just push the existing one(s)?

Chris? Casey? Crispin?
[ Ie there's the "core LSM hooks" on one side, but there's also the "what

  modules make any sense at all to merge?" on the other, and I really

  don't have the expertise to make any sensible judgements except for the

  pure "process" judgement that we should not hardcode things to just one

  module! ]
		Linus

-

Stephen and James, despite their clear bias towards SELinux, do try to

give good feedback.  But you are right, there's not enough active help

for people trying to make a contribution to get their code in shape.

Many of the modules that come along have been misguided conceptually,

but I think that e.g. apparmor, tomoyo, smack could use that kind

of constructive help to get into final mergable shape.  Personally,

I haven't spent nearly enough time reviewing those, my apologies to

those developers.  So, yes, help is welcome.
thanks,

-chris

-

Yes, TOMOYO Linux is committed to help.

I mean, please count me in.
PS

Chris, I've been waiting for your comments for our code. :)
Regards,

Toshiharu Harada
-

On Wed, 24 Oct 2007 17:41:28 -0700
I'll be happy to help out; I'd consider my self neutral in this space

not having worked with any of the LSM out there. I do think we need to

be somewhat critical to what we accept; we should at least be able to

filter out "pretend security" somehow. (this is not the same as saying

that you're bad if you only provide a limited security, in the

contrary, I strongly believe in simple pieces. What I mean is that we

should be critical to things that appear/claim to be strong but are

not).
Secondly, we should make sure that no new holes are added (the original

SMACK series suffered from this, Al Viro helped getting that reviewed

bigtime).
In addition we probably should strive to getting some sort of rough

"this is sort of where we draw the line" guideline set up, just to keep

things more objective.
(Oh and of course, if a security module is deeply involved in another

kernel subsystem, say networking or the VFS, very obviously we should

consult and listen to the respective maintainers of that subsystem; LSM

is not there to be a big hook to bypass the process of well maintained

subsystems)
-

Casey Schaufler

casey@schaufler-ca.com

-

Besides the 'feature' of inhibiting port binding,

is not this task of blocking connections something for a firewall?

-

So now you are criticizing his module. Arguing about the merits of

security semantics. This is exactly why Linus wanted LSM, so we don't

have to have these kinds of discussions, at least not on LKML :)
It seems to me that LSM used to be an open API. Anyone could code to it,

so you could at least try to ship a module that will load into a major

vendor's stock kernel for an important release.
Now with this change, it is effectively a closed API. You can only load

the modules that the distro vendor shipped to you. If you want

*anything* other than what RH or Novell or Canonical or Mandriva etc.

says you should want, then you have to hack the source code for your kernel.
Open source is great, and it is wonderful that you *can* hack the source

if you need to, but demanding that end users patch their source code

when all they want to do is load a module is really, really sad.
Please revert this patch. Its benefits are no where near its costs.
Crispin
--

Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/

	       Itanium. Vista. GPLv3. Complexity at work
-

This was a question. I was perfectly aware that iptables alone

does not prohibit binding, and there are reasons to inhibit binding.
But sometimes, a coder does not know where to start - chances are,

that someone else wanting to do bind(2) inhibiting is doing it

with a syscall table change. Or coder did not notice that a firewall

is sufficient for the task to be achieved (which is not always the

case - hence the question).

-

I have written Smack.

I need an LSM infrastructure.

I would prefer the old dynamic version.

I no trouble with the static version.
I think that a dynamic version is more useful, but I didn't want

what I'm doing to have it as a dependency, so I made sure that

it isn't. The debate about the inclusion of Smack can remain

blissfully separate from the dynamic/static LSM debate. This is

by design.
I have had a couple people suggest changes to Smack that would be

very elegently handled as stacked modules. These include "owned"

ports and additional uid restrictions. Since Smack is a MAC module

these other security features are not really appropriate to include

(if you want the Security Monolith there is SELinux) in it, but

certainly make sense to combine with it.
A stacker that does not require module participation could be quite

interesting. In the old day I felt that a security solution had to

include all aspects of control, but today I see the value provided

by independent mechanisms such as IPtables.
Casey Schaufler

casey@schaufler-ca.com

-

The firewall blocks incoming connections where appropriate, yes, but it

doesn't stop one user binding to a port that another user expected to be able

to use. "Ownership" of ports (1-1023) shouldn't be something only root (via

CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports

below 1024 and it's useful to be able to prevent users from binding to them

too.
--

Simon Arlott

-

Indeed.
There has been a feature in the security framework that probably did

not get much attention. It looks like YAGNI first, but on a closer look,

it becomes useful pretty quick - secondary_register.
As more and more simple LSM plugins pop up, stacking/chaining by means

of secondary_register becomes attractive again, especially if these LSMs

target different actions. This is probably the most useful thing why

the LSM interface should remain modular:
# Secure my files

modprobe apparmor

# -*- assuming apparmor implemented secondaries -*-

# Secure my ports

modprobe portac

# More rights to users

modprobe multiadm

# -*- whatever else comes along -*-

-

I agree that it can cause problems, but it's up to the modules themselves

to determine how to combine permissions with their immediate secondary

module.
Instead we now have a static LSM where combining features from one module

means duplicating it in another - then when two modules contain most of

the other's code, but perhaps vastly different configuration mechanisms,

someone will propose removing one of the two...
--

Simon Arlott

-

This branch of the tree seems to have gone in a direction similar to the

stackable netfilter like architecture that was suggested by someone last
-

Of course, the example I gave assumed that each LSM had disjunctive

features. Apparmor is primarily known for blocking file access,

and portac for blocking bind(2). If one of these gets additionaly

functionality, it would be nice that code gets combined so that

tracking down the piece of code that caused a particular syscall to
I agree - if one does not get the magic behind LSM stacking, s/he

should not use it, or learn to use it.

However, if you grasp how it works (probably even easier to learn

than figuring out how to selinux), one should know that a pam_deny.so

even after a pam_permit.so will lock you down. Yeah, it's like PAM

stacking.

-

The scariest thing to consider is programs which don't appropriately

handle failure.  So I don't know, maybe the system runs a remote logger

to which the multiadm policy gives some extra privs, but now the portac

module prevents it from sending its data.  And maybe, since the authors

never saw this failure as possible, the program happens to dump

sensitive data in a public readable place.  I *could* be more vague but

it'd be tough :)  But you get the idea.
Or, a better example, a privileged program reads some sensitive data -

as allowed by multiadm, writes it to a file, but apparmor prevented it

from chowning the file to the right user before writing, the program

kept writing anyway, and now the calling user hallyn, rather than the

privileged user sensitive_log_t, owns the file.
I ran into examples of this with the stacker module.  For instance

suddenly the capability module had to be changed so that it would allow

selinux xattrs to be written - leaving that arbitration to selinux.

That hadn't been necessary before since selinux simply didn't explicitly

call the secondary->inode_setxattr() hook.
Note I'm not arguing for or against, only arguing for caution :)
-serge

-

Well, there *was* that problem with sendmail where it did not

properly check the result of setuid() and just assumed it had

succeeded.  So instead of running as "smtpd" it was running as

"root".   Not a happy memory.
Cheers,

Kyle Moffett
-

this sort of problem is possible with just a single LSM.
remember that unix doesn't try to make it impossible for the system owner

to hang himself, becouse there are many other cases where the rope is used

productivly. don't let the possibility that things can be done wrong

prevent other people from being creative in ways that you never thought

of.
David Lang

-

Interesting find, I should pay attention to that :-)
But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call

the next LSM's function. No one (just a minimal grep in

linux-2.6/security/) besides SELinux does that today. So

while you could load AppArmor ontop of MultiAdm, it would never

be invoked. This is what is known as "sufficient" in PAM parlance.

SELinux OTOH is in "required" mode [again PAM-speak].

-

True but if we are talking about a true stackable architecture calling

down to your lower component shouldn't be an option it should be a

requirement of the semantics. I would hate to think some module which is

a subset of the restrictiveness of another could override it because its

"sufficient". If that was the case I could load in a module which just

returns 0 for everything and make it "sufficient" bypassing every other

module. This also introduces ordering dependencies. If you install

MultiAdm before AppArmor or SELinux and make it "sufficient" then you

defeated the point of having AppArmor or SELinux installed in the first

place. 
-

If I had to run mtadm and aa alongside each other, I would put aa

into the "secondary" LSM slot.
A number of people have said by now that LSM is supposed to be a

restrict-my-rights block of code. As such, I would put the special,

tiny, give-me-rights code at the front so that it be executed first.

This is what would be intended with mtadm. It really just gives you a

few caps when switching to UID 900 (or whatever), just as Linux

traditionally gives you full caps when switching to UID 0 (e.g. by

executing setuid files). From there on, it is just restrictions, and

the order in which LSMs restrict your actions is probably not so

important as long as they do restrict it.
Thankfully, Linux capabilities are so strangely designed that they

actually become useful - they give you so much power that you _can_

only restrict things afterwards again :-)

-

Yup, that's essentially what we've been talking about.
thanks,

-chris

-

(Un)registering security modules is a one-time hit. You do not load

and unload modules on a per-minute basis outside debugging.

-

I'm referring to the hit for indirect calls

-

Indeed, I just seen that. Not too nice :(

-

If you take it that strictly, the in-kernel root_plug LSM could have

been considered enough reason for reverting...
The interesting question is IMHO still:
Were Greg and Jan the only people to write such LSMs, or how many

non-abusive users that make sense as modules do really exist after

5 years?
Either you can count such real-world users with your fingers or there's

a reason why these modules didn't get included.
IOW:

Either the API has proven to not attract enough modular users or we are

having a to-be-fixed problem with getting the LSMs submitted and 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

But his is against LSM design (and first agreements about LSM):

LSM can deny rights, but it should not give extra permissions

or bypass standard unix permissions.
ciao

	cate

-

It is just not feasible to add ACLs to all million files in /home,

also because ACLs are limited to around 25 entries.

And it is obvious I do not want <prof> to have UID 0, because

then you cannot distinguish who created what file.

So the requirement to the task is to have unique UIDs.

The next logical step would be to give capabilities to those UIDs.
*Is that wrong*? Who says that only UID 0 is allowed to have

all 31 capability bits turned on, and that all non-UID 0 users

need to have all 31 capability bits turned off?
So, we give caps to the subadmins (which is IMHO a natural task),

and then, as per LSM design (wonder where that is written) deny

some of the rights that the capabilities raised for subadmins grant,

because that is obviously too much.

-

Once the per-process capability bounding set is accepted

(http://lkml.org/lkml/2007/10/3/315) you will be able to do something

like:
	1. Create user 'jdoe' with uid 0

	2. write a pam module which, when jdoe logs in, takes

	   CAP_NET_ADMIN out of his capability bounding set

	3. Now jdoe can log in with the kind of capabilities subset

	   you describe.
It's not a perfect solution, since it doesn't allow jdoe any way at all

to directly execute a file with more caps (setuid and file capabilities

are subject to the capbound).  So there is certainly still a place for

multiadm.
-serge

-

It is not that easy.

CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security

checks in kernel code, and then the detailed implementation of

limitation is done inside multiadm.
A normal user can execute suid binaries today, and so can s/he with mtadm.

I do not see where that will change - it does not need any caps atm.

-

Nope, but it's related, and as I pointed out below it fits in pretty
And he will still be able to *run* the suid binary, but if cap_bound is

reduced he won't be able to use capabilities taken out of the bounding

set, multiadm loaded or not.
-serge

-

I am willing to bet that there's still a *lot* of unaudited set[ug]id code

out there that's vulnerable to the same sorts of attacks as the one that

hit Sendmail a few back.  As such, I have to agree with your original

post of the patch that CAP_SYS_ADMIN should be required to lower the set,

as there's just too much danger of an exploit if users can create their

own reduced-set processes.
I'm debating whether we should have a printk if we detect that a removed

capability caused an -EPERM.  Yes, it can be used to spam the logs.  On the

other hand, I as the sysadmin would like to know if it's happening. Looks like

time for a sysctl or something....

Nothing wrong.  I only said that it was against (IIRC) the

principle of LSM in kernel (we should only remove capacities).

I've nothing against the changing the design or rules.

It was only a commentary, to be sure that we know what we do ;-)
ciao

	cate

-

Leave my capacitance alone! :)

[i hope you get the joke]
Anyway - I see your point. But what would give the user the capabilities

in the first place, if not a security module that implements this-and-that

capability-raising scheme?

-