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...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: ...
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-ccj58/thkd.diff 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...
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 e