login
Search
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 -
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 -
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. -
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. -
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? -
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....
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> -
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
-
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: + ...
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 -
(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 :( -
Broaden the paravirt patching machinery?
J
-
Yup, that's essentially what we've been talking about. thanks, -chris -
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 -
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 -
Besides the 'feature' of inhibiting port binding, is not this task of blocking connections something for a firewall? -
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 -*- -
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 -
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 :-) -
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 -
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 -
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. -
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 -
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 -
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 -
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
-
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 -
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 -
Casey Schaufler casey@schaufler-ca.com -
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 -
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) -
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 -
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 -
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. -
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 ...
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 -
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 -
(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 -
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 ...
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 -
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 -
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 -
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 ...
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 -
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 -
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. -
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 -
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 -
<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);
-
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 -
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. -
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 -
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 -
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 -
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 -
- 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)
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 -
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 -
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
-
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. -
How often did this happen yet? -- Stefan Richter -=====-=-=== =-=- ==-== http://arcgraph.de/sr/ -
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 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/ -
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 -
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)
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 ...
As long as you're maintaining them proprely, I don't why. Xav -
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 -
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. -
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 -
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. -
[...] 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? -
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> -
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, ...
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATC |