Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): > On Wed, 27 Jun 2007, Serge E. Hallyn wrote: > > > Patch tests fine for me for expected capability behavior with lsm=n, > > lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. > > > > So while I'm opposed to the patch, it appears to be safe. > > I've also tested a bunch of scenarios: allmodconfig, lsm=y,cap=n, > selinux=y,cap=n etc. I was wondering about the uninlining of all those functions, so did a set of performance runs. Found no statistically relevant change in dbench, tbench, or reaim. (tried to run kernbench too but the benchmark failed somewhere and i didn't care enough to look into it) -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Wed, 27 Jun 2007, Serge E. Hallyn wrote: > Patch tests fine for me for expected capability behavior with lsm=n, > lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. > > So while I'm opposed to the patch, it appears to be safe. I've also tested a bunch of scenarios: allmodconfig, lsm=y,cap=n, selinux=y,cap=n etc. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > Quoting James Morris ([EMAIL PROTECTED]): > > On Wed, 27 Jun 2007, Serge E. Hallyn wrote: > > > > > Quoting Kyle Moffett ([EMAIL PROTECTED]): > > > > This whole discussion boils down to 2 points: > > > > > > Yes it can, but not the two you list. > > > > > > > 1) As currently implemented, no LSM may be safely rmmod-ed > > > > > > That's not the rationale for the patch, it's just some talking point you > > > picked up. The rationale for the patch is to prevent abuse. > > > > This is not correct. Reducing API abuse is simply a bonus. > > > > The rationale for the patch is to remove unneeded infrastructure which > > complicates security by introducing the idea that the security module can > > be removed at all. > > > > It was in response to your very own posting about the new capabilities > > code which would need to take this into account. > > It's (IMO) by far not the optimal "solution" :) If it is felt a > solution is really needed, re-introduction of a > security_ops->module_exit hook and introduction of CAP_SYS_CAPDISABLE > would be better. > > But I'm well aware there are far too many (separate and not so separate) > agendas driving this, and have no expectations of being able to stop it. > > James, FWIW, I'm sorry I haven't had a chance to actually test the > patch. I'll try to get around to that today or at least this week. Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe. thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): > On Wed, 27 Jun 2007, Serge E. Hallyn wrote: > > > Quoting Kyle Moffett ([EMAIL PROTECTED]): > > > This whole discussion boils down to 2 points: > > > > Yes it can, but not the two you list. > > > > > 1) As currently implemented, no LSM may be safely rmmod-ed > > > > That's not the rationale for the patch, it's just some talking point you > > picked up. The rationale for the patch is to prevent abuse. > > This is not correct. Reducing API abuse is simply a bonus. > > The rationale for the patch is to remove unneeded infrastructure which > complicates security by introducing the idea that the security module can > be removed at all. > > It was in response to your very own posting about the new capabilities > code which would need to take this into account. It's (IMO) by far not the optimal "solution" :) If it is felt a solution is really needed, re-introduction of a security_ops->module_exit hook and introduction of CAP_SYS_CAPDISABLE would be better. But I'm well aware there are far too many (separate and not so separate) agendas driving this, and have no expectations of being able to stop it. James, FWIW, I'm sorry I haven't had a chance to actually test the patch. I'll try to get around to that today or at least this week. -serge > Recall: > > On Sun, 24 Jun 2007, Serge E. Hallyn wrote: > > > > 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate > > > whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is > > > way too overloaded and this functionality is special. > > > > The functionality is special, but someone with CAP_SYS_ADMIN can always > > unload the capability module and create the security.capability xattr > > using the dummy module. > > > > If we do add this cap, do we want to make it apply to all security.* > > xattrs? > > The underlying issue here is the notion of security mechanisms which are > built as loadable modules. It's not useful for any in-tree users, and > introduces several unnecessary problems which then need to be addressed. > > A better approach would be to make LSM a statically linked interface. > > This would also allow us to unexport the LSM symbols and reduce the API > abuse by third-party modules. > > > > - James > -- > James Morris > <[EMAIL PROTECTED]> > - > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Wed, 27 Jun 2007, Serge E. Hallyn wrote: > Quoting Kyle Moffett ([EMAIL PROTECTED]): > > This whole discussion boils down to 2 points: > > Yes it can, but not the two you list. > > > 1) As currently implemented, no LSM may be safely rmmod-ed > > That's not the rationale for the patch, it's just some talking point you > picked up. The rationale for the patch is to prevent abuse. This is not correct. Reducing API abuse is simply a bonus. The rationale for the patch is to remove unneeded infrastructure which complicates security by introducing the idea that the security module can be removed at all. It was in response to your very own posting about the new capabilities code which would need to take this into account. Recall: On Sun, 24 Jun 2007, Serge E. Hallyn wrote: > > 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate > > whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is > > way too overloaded and this functionality is special. > > The functionality is special, but someone with CAP_SYS_ADMIN can always > unload the capability module and create the security.capability xattr > using the dummy module. > > If we do add this cap, do we want to make it apply to all security.* > xattrs? The underlying issue here is the notion of security mechanisms which are built as loadable modules. It's not useful for any in-tree users, and introduces several unnecessary problems which then need to be addressed. A better approach would be to make LSM a statically linked interface. This would also allow us to unexport the LSM symbols and reduce the API abuse by third-party modules. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Kyle Moffett ([EMAIL PROTECTED]): > This whole discussion boils down to 2 points: Yes it can, but not the two you list. > 1) As currently implemented, no LSM may be safely rmmod-ed That's not the rationale for the patch, it's just some talking point you picked up. The rationale for the patch is to prevent abuse. So point 1 is 1) Is the LSM infrastructure being abused, and how detrimental is that abuse As has come up, the abuse comes in two forms, and people seem to want to blur the two forms to make it seem especially relevant and heinous... > 2) Someone has submitted a patch which fixes that problem (you > can't rmmod them at all, so no crashes) 2) Is the loss of flexibility in the LSM framework a worthwhile tradoff against the abuse prevention. Clearly I and a very few others feel no, and a very vocal set (which sure sounds like a majority) says yes. Now quit trying to give technical justifications for something which is technical only insofar as it is a technical roadblock to prevent a legal problem. > If you really want to do modular LSMs, then you need to submit a > patch which fixes all the race conditions in LSM removal *without* LSM is an infrastructure. It's up to the modules to provide that, and it can be done. DTE used to do it. Dirjail used to do it. Capability does it. And since LSM won't be modular anymore it doesn't matter. > adding much extra overhead. I'm sure if your solutions works then > everyone will be much more open to modular LSMs. I said this before: Another blatant lie, not unlike "come to the table to upstream your LSM, and we'll help you, honest." (The funny thing about that is, I actually like SELinux, more than the alternatives in general. I just can't stand the attitudes voice by much of its camp.) -serge PS - should we rename 'LSM' to 'LSI' - linux security infrastructure? Calling it LSM now is kind of moronic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Kyle Moffett ([EMAIL PROTECTED]): This whole discussion boils down to 2 points: Yes it can, but not the two you list. 1) As currently implemented, no LSM may be safely rmmod-ed That's not the rationale for the patch, it's just some talking point you picked up. The rationale for the patch is to prevent abuse. So point 1 is 1) Is the LSM infrastructure being abused, and how detrimental is that abuse As has come up, the abuse comes in two forms, and people seem to want to blur the two forms to make it seem especially relevant and heinous... 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) 2) Is the loss of flexibility in the LSM framework a worthwhile tradoff against the abuse prevention. Clearly I and a very few others feel no, and a very vocal set (which sure sounds like a majority) says yes. Now quit trying to give technical justifications for something which is technical only insofar as it is a technical roadblock to prevent a legal problem. If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* LSM is an infrastructure. It's up to the modules to provide that, and it can be done. DTE used to do it. Dirjail used to do it. Capability does it. And since LSM won't be modular anymore it doesn't matter. adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. I said this before: Another blatant lie, not unlike come to the table to upstream your LSM, and we'll help you, honest. (The funny thing about that is, I actually like SELinux, more than the alternatives in general. I just can't stand the attitudes voice by much of its camp.) -serge PS - should we rename 'LSM' to 'LSI' - linux security infrastructure? Calling it LSM now is kind of moronic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Quoting Kyle Moffett ([EMAIL PROTECTED]): This whole discussion boils down to 2 points: Yes it can, but not the two you list. 1) As currently implemented, no LSM may be safely rmmod-ed That's not the rationale for the patch, it's just some talking point you picked up. The rationale for the patch is to prevent abuse. This is not correct. Reducing API abuse is simply a bonus. The rationale for the patch is to remove unneeded infrastructure which complicates security by introducing the idea that the security module can be removed at all. It was in response to your very own posting about the new capabilities code which would need to take this into account. Recall: On Sun, 24 Jun 2007, Serge E. Hallyn wrote: 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is way too overloaded and this functionality is special. The functionality is special, but someone with CAP_SYS_ADMIN can always unload the capability module and create the security.capability xattr using the dummy module. If we do add this cap, do we want to make it apply to all security.* xattrs? The underlying issue here is the notion of security mechanisms which are built as loadable modules. It's not useful for any in-tree users, and introduces several unnecessary problems which then need to be addressed. A better approach would be to make LSM a statically linked interface. This would also allow us to unexport the LSM symbols and reduce the API abuse by third-party modules. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Quoting Kyle Moffett ([EMAIL PROTECTED]): This whole discussion boils down to 2 points: Yes it can, but not the two you list. 1) As currently implemented, no LSM may be safely rmmod-ed That's not the rationale for the patch, it's just some talking point you picked up. The rationale for the patch is to prevent abuse. This is not correct. Reducing API abuse is simply a bonus. The rationale for the patch is to remove unneeded infrastructure which complicates security by introducing the idea that the security module can be removed at all. It was in response to your very own posting about the new capabilities code which would need to take this into account. It's (IMO) by far not the optimal solution :) If it is felt a solution is really needed, re-introduction of a security_ops-module_exit hook and introduction of CAP_SYS_CAPDISABLE would be better. But I'm well aware there are far too many (separate and not so separate) agendas driving this, and have no expectations of being able to stop it. James, FWIW, I'm sorry I haven't had a chance to actually test the patch. I'll try to get around to that today or at least this week. -serge Recall: On Sun, 24 Jun 2007, Serge E. Hallyn wrote: 2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is way too overloaded and this functionality is special. The functionality is special, but someone with CAP_SYS_ADMIN can always unload the capability module and create the security.capability xattr using the dummy module. If we do add this cap, do we want to make it apply to all security.* xattrs? The underlying issue here is the notion of security mechanisms which are built as loadable modules. It's not useful for any in-tree users, and introduces several unnecessary problems which then need to be addressed. A better approach would be to make LSM a statically linked interface. This would also allow us to unexport the LSM symbols and reduce the API abuse by third-party modules. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Serge E. Hallyn ([EMAIL PROTECTED]): Quoting James Morris ([EMAIL PROTECTED]): On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Quoting Kyle Moffett ([EMAIL PROTECTED]): This whole discussion boils down to 2 points: Yes it can, but not the two you list. 1) As currently implemented, no LSM may be safely rmmod-ed That's not the rationale for the patch, it's just some talking point you picked up. The rationale for the patch is to prevent abuse. This is not correct. Reducing API abuse is simply a bonus. The rationale for the patch is to remove unneeded infrastructure which complicates security by introducing the idea that the security module can be removed at all. It was in response to your very own posting about the new capabilities code which would need to take this into account. It's (IMO) by far not the optimal solution :) If it is felt a solution is really needed, re-introduction of a security_ops-module_exit hook and introduction of CAP_SYS_CAPDISABLE would be better. But I'm well aware there are far too many (separate and not so separate) agendas driving this, and have no expectations of being able to stop it. James, FWIW, I'm sorry I haven't had a chance to actually test the patch. I'll try to get around to that today or at least this week. Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe. thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe. I've also tested a bunch of scenarios: allmodconfig, lsm=y,cap=n, selinux=y,cap=n etc. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe. I've also tested a bunch of scenarios: allmodconfig, lsm=y,cap=n, selinux=y,cap=n etc. I was wondering about the uninlining of all those functions, so did a set of performance runs. Found no statistically relevant change in dbench, tbench, or reaim. (tried to run kernbench too but the benchmark failed somewhere and i didn't care enough to look into it) -serge - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
* Crispin Cowan ([EMAIL PROTECTED]) wrote: > and simple LSMs that can be > unloaded safely can permit it. there are none, and making the above possible is prohibitively expensive. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Jun 26, 2007, at 20:57:53, Crispin Cowan wrote: Kyle Moffett wrote: Let's go over the differences between "my fs" and "my LSM", and the similarities between "my VM" and "my LSM": Filesystems don't get hooked from virtually every userspace-initiated operation, whereas both VMs and LSMs do. VMs and LSMs attach anonymous state data to a large percentage of the allocated objects in the system, whereas filesystems allocate their own independent datastructure and use that. Would you want to "rmmod ext3" and then "modprobe ext2" while you have an ext2-as-ext3 filesystem *mounted*??? If you want a good analogy, that's a better one than the "my fs can't be a module" crap. This whole discussion boils down to 2 points: 1) As currently implemented, no LSM may be safely rmmod-ed 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module. You must have missed this in my emails: 2) When you "modprobe my_custom_security_module", how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? This isn't even solvable the same way the "rmmod" problem is, since most of that isn't even accessible without iterating over the ENTIRE dcache, icache, every process, every process' file-descriptors, every socket, every unix socket, every anonymous socket, every SYSV shm object, every currently-in-process packet. I'd argue that security-module-insertion is actually MORE complicated than removal. Here's one example: TOMOYO cares about the process execution tree, but you can't penalize the no-LSM case by a percent or two to add that kind of data. When TOMOYO is loaded, it wants to do access control based on process execution trees for which data DOES NOT EXIST!!! Not only that, but the processes which originally ran the one you care about (and which you'd need to recreate that data) may have exited anywhere from seconds to years before. It is fundamentally IMPOSSIBLE to recreate that data, even if you could solve the problems of how to do it while the system is running without racing with existing process operations. Imagine a process which hasn't had security data tagged to it yet which opens thousands of FIFOs per second, waits for your tagging code to assign security data to them in the filesystem, and then removes them; if you did it right you could prevent the code from EVER completely tagging every object (even assuming you could recreate enough information). Such a need to add extra security data to multiple classes of objects is *fundamental* to any security module (isn't that the whole point?) As such, you can't just "modprobe" one and expect it to work. That's like mounting an ext2 filesystem, and then later trying to "modprobe ext3" and dynamically switch to the ext3 code and enable journalling all at once ON THE MOUNTED FILESYSTEM!!! Sure, theoretically it *could* be done, but the code complexity is hardly worth it (plus nobody has yet even tried posting patches to make it happen). Consider the use case of joe admin who is running enterprise- supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Flatly impossible. You simply cannot "load" a security module and hope to provide any useful information about the system's present state. If you want comprehensive security it has to be there before a single byte of userspace code is executed. SELinux sort-of handles unlabelled objects by treating them with a small set of initial "types", but that's only enough to get the system up enough to actually relabel objects with type-transitions (after init loads the selinux policy it reexecs itself, before doing anything else). So to solve the problem James & Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. An LSM simple enough to unload would be too simple for anybody to want to load in the first place (even capabilities can have this
Re: [PATCH try #2] security: Convert LSM into a static interface
Kyle Moffett wrote: > Let's go over the differences between "my fs" and "my LSM", and the > similarities between "my VM" and "my LSM": Filesystems don't get > hooked from virtually every userspace-initiated operation, whereas > both VMs and LSMs do. VMs and LSMs attach anonymous state data to a > large percentage of the allocated objects in the system, whereas > filesystems allocate their own independent datastructure and use > that. Would you want to "rmmod ext3" and then "modprobe ext2" while > you have an ext2-as-ext3 filesystem *mounted*??? If you want a good > analogy, that's a better one than the "my fs can't be a module" crap. > > This whole discussion boils down to 2 points: > 1) As currently implemented, no LSM may be safely rmmod-ed > 2) Someone has submitted a patch which fixes that problem (you can't > rmmod them at all, so no crashes) > > If you really want to do modular LSMs, then you need to submit a patch > which fixes all the race conditions in LSM removal *without* adding > much extra overhead. I'm sure if your solutions works then everyone > will be much more open to modular LSMs. I said this before: Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module. Consider the use case of joe admin who is running enterprise-supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Without James's patch, he can do that, and at worst has a tainted kernel. RH or Novell or his favorite distro vendor can fix that with a wave of the hand and bless FooSecure as a module. With James's patch, he has to patch his kernels, and then enterprise support is hopeless, to say nothing of the barrier to entry that "patch and rebuild kernel" is more than many admins are willing to do. So to solve the problem James & Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Jun 26, 2007, at 09:47:12, Serge E. Hallyn wrote: Quoting Kyle Moffett ([EMAIL PROTECTED]): On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Here are a few questions for you: 1) What do you expect to happen to all the megs of security data when you "rmmod selinux"? Read the sentence right above yours again. Noone is saying we should be able to rmmod selinux. Ok, so say we extend LSM to do what AppArmor or TOMOYO need, what do you expect to happen when you "rmmod tomoyo", "rmmod apparmor", or whatever? Each of those is also going to stick lots of context on various objects during the course of running, the same way that the VM subsystem sticks lots of context on filesystem pages while running. Besides, even the standard "capabilities" module wants to attach a list of capabilities to every process and defines inheritance rules for them. Ergo you have the problems described below: Do you maintain a massive linked list of security data (with all the locking and performance problems) so that you can iterate over it calling kfree()? What synchronization primitive do we have right now which could safely stop all CPUs outside of security calls while we NULL out and free security data and disable security operations? Don't say "software suspend" and "process freezer", since those have whole order-of-magnitude-complexity problems of their own (and don't always work right either). 2) When you "modprobe my_custom_security_module", how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? Those don't all need labels for capabilities, for instance. This question is as wrong as the last one. Ok, so let's just restrict ourselves to the simple dumb-as-dirt capabilities module. Every process is "labeled" with capabilities while running under that LSM, right? What happens when you "rmmod capabilities"? Do you iterate over all the processes to remove their security data even while they may be using it? Or do you just let it leak? Some daemons test if capabilities are supported, and if so they modify their capability set instead of forking a high-priv and a low-priv process and doing IPC. When you remove the capabilities module, suddenly all those programs will lose that critical "low- privilege" data and become full root. What happens later when you "modprobe capabilities"? Do you suddenly have to stop the system while you iterate over EVERY process to set capabilities based on whether it's root or not? It's also impossible to determine from a given state in time what processes should have capabilities, as the model includes inheritance, which includes processes that don't even exist anymore. 3) This sounds suspiciously like "The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole". No, your argument sounds like "my fs can't be a module so neither should any." Let's go over the differences between "my fs" and "my LSM", and the similarities between "my VM" and "my LSM": Filesystems don't get hooked from virtually every userspace-initiated operation, whereas both VMs and LSMs do. VMs and LSMs attach anonymous state data to a large percentage of the allocated objects in the system, whereas filesystems allocate their own independent datastructure and use that. Would you want to "rmmod ext3" and then "modprobe ext2" while you have an ext2-as-ext3 filesystem *mounted*??? If you want a good analogy, that's a better one than the "my fs can't be a module" crap. This whole discussion boils down to 2 points: 1) As currently implemented, no LSM may be safely rmmod-ed 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. I said this before: So... Do you have a proposal for solving those rather fundamental design gotchas? If so, I'm sure everybody here would love to see your patch Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Tue, Jun 26, 2007 at 10:53:29AM -0500, Serge E. Hallyn wrote:
> Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote:
> > > Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > > > On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> > > > > Quoting James Morris ([EMAIL PROTECTED]):
> > > > > > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> > > > > >
> > > > > > > It's useful for some LSMs to be modular, and LSMs which are y/n
> > > > > > > options won't
> > > > > > > have any security architecture issues with unloading at all.
> > > > > >
> > > > > > Which LSMs? Upstream, there are SELinux and capabilty, and they're
> > > > > > not
> > > > > > safe as loadable modules.
> > > > > >
> > > > > > > The mere fact
> > > > > > > that SELinux cannot be built as a module is a rather weak
> > > > > > > argument for
> > > > > > > disabling LSM modules as a whole, so please don't.
> > > > > >
> > > > > > That's not the argument. Please review the thread.
> > > > >
> > > > > The argument is 'abuse', right?
> > > > >
> > > > > Abuse is defined as using the LSM hooks for non-security applications,
> > > > > right?
> > > > >
> > > > > It seems to me that the community is doing a good job of discouraging
> > > > > such abuse - by redirecting the "wrong-doers" to implement proper
> > > > > upstream solutions, i.e. taskstats, the audit subsystem, etc.
> > > > >
> > > > > Such encouragement seems a far better response than taking away
> > > > > freedoms
> > > > > and flexibility from everyone.
> > > >
> > > > We are not living in a world where everyone had good intentions...
> > >
> > > Oh no, i took a wrong turn somewhere :)
> > >
> > > > For _some_ "wrong-doers" your approach works.
> > > >
> > > > But how do you convince the "wrong-doers" who do things like putting
> > > > MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
> > > > and get away because noone sues them?
> > >
> > > Do these really exist? Maybe noone sues them because noone knows who
> > > they are...
> >
> >http://lwn.net/Articles/82306/
>
> LinuxAnt? Are they using LSM?
>
> It looks to me like this patch will do nothing about them.
It was an example how creative "wrong-doers" sometimes are.
> > > But - note that you've changed completely the meaning of 'abuse'.
> > > So mine was wrong?
> >
> > Technical and legal abuse are related.
>
> True but going by your logic we could remove support for modules period
> to prevent legal abuse by non-gpl modules.
The problem is that this would result in distributions having to ship
50 MB kernel images.
> > For GPL'ed modules you might assume good faith and get the authors to do
> > things in a proper way. Authors of legally questionable modules that
> > cheat in many ways are quite a different issue.
> >
> > > > The spirit of the GPLv2 is to defend the freedom of the software
> > > > (different from the spirit of the BSD licence), and considering that
> > > > there aren't many people defending the GPLv2 copyright of the Linux
> > > > kernel at court against abusers, making it harder for people to do the
> > > > abuse might not be the worst choice...
> > >
> > > Well, but you seem to be saying that the license means squat, and
> > > resorting to making things inconvenient rather than illegal.
> >
> > No, the point is that there's no reason for making illegal things
> > convenient.
>
> But no, the point is that that you are making legal things very
> inconvenient.
>
> > I'm not talking about removing things that are used inside the kernel,
>
> Since capabilities can currently be compiled as a module, you are.
> (Though that sounds weird, so maybe I'm misreading what you are saying)
If the LSM maintainer says non-modular capabilities is the way to go
then there's no user left.
> > but what you call "freedom" can also be called "hooks for possible abuse".
>
> Yup, that is true.
>
> > Additionally, it both makes the kernel bigger for everyone and requires
> > proper handling of loading/unloading in the security architecture.
> >
> > > Now I guess if it really is accepted that that's the way it should be,
> > > then this patch will go in.
>
> thanks,
> -serge
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Greg KH ([EMAIL PROTECTED]):
> On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote:
> > Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > > On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> > > > Quoting James Morris ([EMAIL PROTECTED]):
> > > > > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> > > > >
> > > > > > It's useful for some LSMs to be modular, and LSMs which are y/n
> > > > > > options won't
> > > > > > have any security architecture issues with unloading at all.
> > > > >
> > > > > Which LSMs? Upstream, there are SELinux and capabilty, and they're
> > > > > not
> > > > > safe as loadable modules.
> > > > >
> > > > > > The mere fact
> > > > > > that SELinux cannot be built as a module is a rather weak argument
> > > > > > for
> > > > > > disabling LSM modules as a whole, so please don't.
> > > > >
> > > > > That's not the argument. Please review the thread.
> > > >
> > > > The argument is 'abuse', right?
> > > >
> > > > Abuse is defined as using the LSM hooks for non-security applications,
> > > > right?
> > > >
> > > > It seems to me that the community is doing a good job of discouraging
> > > > such abuse - by redirecting the "wrong-doers" to implement proper
> > > > upstream solutions, i.e. taskstats, the audit subsystem, etc.
> > > >
> > > > Such encouragement seems a far better response than taking away freedoms
> > > > and flexibility from everyone.
> > >
> > > We are not living in a world where everyone had good intentions...
> >
> > Oh no, i took a wrong turn somewhere :)
> >
> > > For _some_ "wrong-doers" your approach works.
> > >
> > > But how do you convince the "wrong-doers" who do things like putting
> > > MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
> > > and get away because noone sues them?
> >
> > Do these really exist?
>
> Yes they do.
>
> > Maybe noone sues them because noone knows who they are...
>
> Maybe no one knows because the people doing the legal action against
> them are trying to be nice and do it quietly.
So they're being nice to the violaters, and then clamping down on
everyone...
> And legal action takes time, it is quite slow going unfortunatly.
>
> Heck, I've seen code that is even properly licensed under the GPL abuse
> this security layer for things it was not ment to do at all, and that
> stuff comes from _very_ big companies that really should know better...
But that's back to the other type of 'abuse' which i was originally
talking about, and which IMO is being well addressed through education.
As for the others, I have no better suggestions. I wish I did.
> So I agree that we should unexport it. It will make people who want to
> abuse the interface at least think twice about it.
And those who don't abuse it too.
> thanks,
>
> greg "I want to mark structures read-only" k-h
And I know I'm not the one who's going to stop you...
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote:
> Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> > > Quoting James Morris ([EMAIL PROTECTED]):
> > > > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> > > >
> > > > > It's useful for some LSMs to be modular, and LSMs which are y/n
> > > > > options won't
> > > > > have any security architecture issues with unloading at all.
> > > >
> > > > Which LSMs? Upstream, there are SELinux and capabilty, and they're not
> > > > safe as loadable modules.
> > > >
> > > > > The mere fact
> > > > > that SELinux cannot be built as a module is a rather weak argument
> > > > > for
> > > > > disabling LSM modules as a whole, so please don't.
> > > >
> > > > That's not the argument. Please review the thread.
> > >
> > > The argument is 'abuse', right?
> > >
> > > Abuse is defined as using the LSM hooks for non-security applications,
> > > right?
> > >
> > > It seems to me that the community is doing a good job of discouraging
> > > such abuse - by redirecting the "wrong-doers" to implement proper
> > > upstream solutions, i.e. taskstats, the audit subsystem, etc.
> > >
> > > Such encouragement seems a far better response than taking away freedoms
> > > and flexibility from everyone.
> >
> > We are not living in a world where everyone had good intentions...
>
> Oh no, i took a wrong turn somewhere :)
>
> > For _some_ "wrong-doers" your approach works.
> >
> > But how do you convince the "wrong-doers" who do things like putting
> > MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
> > and get away because noone sues them?
>
> Do these really exist?
Yes they do.
> Maybe noone sues them because noone knows who they are...
Maybe no one knows because the people doing the legal action against
them are trying to be nice and do it quietly.
And legal action takes time, it is quite slow going unfortunatly.
Heck, I've seen code that is even properly licensed under the GPL abuse
this security layer for things it was not ment to do at all, and that
stuff comes from _very_ big companies that really should know better...
So I agree that we should unexport it. It will make people who want to
abuse the interface at least think twice about it.
thanks,
greg "I want to mark structures read-only" k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Adrian Bunk ([EMAIL PROTECTED]):
> On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote:
> > Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > > On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> > > > Quoting James Morris ([EMAIL PROTECTED]):
> > > > > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> > > > >
> > > > > > It's useful for some LSMs to be modular, and LSMs which are y/n
> > > > > > options won't
> > > > > > have any security architecture issues with unloading at all.
> > > > >
> > > > > Which LSMs? Upstream, there are SELinux and capabilty, and they're
> > > > > not
> > > > > safe as loadable modules.
> > > > >
> > > > > > The mere fact
> > > > > > that SELinux cannot be built as a module is a rather weak argument
> > > > > > for
> > > > > > disabling LSM modules as a whole, so please don't.
> > > > >
> > > > > That's not the argument. Please review the thread.
> > > >
> > > > The argument is 'abuse', right?
> > > >
> > > > Abuse is defined as using the LSM hooks for non-security applications,
> > > > right?
> > > >
> > > > It seems to me that the community is doing a good job of discouraging
> > > > such abuse - by redirecting the "wrong-doers" to implement proper
> > > > upstream solutions, i.e. taskstats, the audit subsystem, etc.
> > > >
> > > > Such encouragement seems a far better response than taking away freedoms
> > > > and flexibility from everyone.
> > >
> > > We are not living in a world where everyone had good intentions...
> >
> > Oh no, i took a wrong turn somewhere :)
> >
> > > For _some_ "wrong-doers" your approach works.
> > >
> > > But how do you convince the "wrong-doers" who do things like putting
> > > MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
> > > and get away because noone sues them?
> >
> > Do these really exist? Maybe noone sues them because noone knows who
> > they are...
>
>http://lwn.net/Articles/82306/
LinuxAnt? Are they using LSM?
It looks to me like this patch will do nothing about them.
> > But - note that you've changed completely the meaning of 'abuse'.
> > So mine was wrong?
>
> Technical and legal abuse are related.
True but going by your logic we could remove support for modules period
to prevent legal abuse by non-gpl modules.
> For GPL'ed modules you might assume good faith and get the authors to do
> things in a proper way. Authors of legally questionable modules that
> cheat in many ways are quite a different issue.
>
> > > The spirit of the GPLv2 is to defend the freedom of the software
> > > (different from the spirit of the BSD licence), and considering that
> > > there aren't many people defending the GPLv2 copyright of the Linux
> > > kernel at court against abusers, making it harder for people to do the
> > > abuse might not be the worst choice...
> >
> > Well, but you seem to be saying that the license means squat, and
> > resorting to making things inconvenient rather than illegal.
>
> No, the point is that there's no reason for making illegal things
> convenient.
But no, the point is that that you are making legal things very
inconvenient.
> I'm not talking about removing things that are used inside the kernel,
Since capabilities can currently be compiled as a module, you are.
(Though that sounds weird, so maybe I'm misreading what you are saying)
> but what you call "freedom" can also be called "hooks for possible abuse".
Yup, that is true.
> Additionally, it both makes the kernel bigger for everyone and requires
> proper handling of loading/unloading in the security architecture.
>
> > Now I guess if it really is accepted that that's the way it should be,
> > then this patch will go in.
> >
> > -serge
>
> cu
> Adrian
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote:
> Quoting Adrian Bunk ([EMAIL PROTECTED]):
> > On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> > > Quoting James Morris ([EMAIL PROTECTED]):
> > > > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> > > >
> > > > > It's useful for some LSMs to be modular, and LSMs which are y/n
> > > > > options won't
> > > > > have any security architecture issues with unloading at all.
> > > >
> > > > Which LSMs? Upstream, there are SELinux and capabilty, and they're not
> > > > safe as loadable modules.
> > > >
> > > > > The mere fact
> > > > > that SELinux cannot be built as a module is a rather weak argument
> > > > > for
> > > > > disabling LSM modules as a whole, so please don't.
> > > >
> > > > That's not the argument. Please review the thread.
> > >
> > > The argument is 'abuse', right?
> > >
> > > Abuse is defined as using the LSM hooks for non-security applications,
> > > right?
> > >
> > > It seems to me that the community is doing a good job of discouraging
> > > such abuse - by redirecting the "wrong-doers" to implement proper
> > > upstream solutions, i.e. taskstats, the audit subsystem, etc.
> > >
> > > Such encouragement seems a far better response than taking away freedoms
> > > and flexibility from everyone.
> >
> > We are not living in a world where everyone had good intentions...
>
> Oh no, i took a wrong turn somewhere :)
>
> > For _some_ "wrong-doers" your approach works.
> >
> > But how do you convince the "wrong-doers" who do things like putting
> > MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
> > and get away because noone sues them?
>
> Do these really exist? Maybe noone sues them because noone knows who
> they are...
http://lwn.net/Articles/82306/
> But - note that you've changed completely the meaning of 'abuse'.
> So mine was wrong?
Technical and legal abuse are related.
For GPL'ed modules you might assume good faith and get the authors to do
things in a proper way. Authors of legally questionable modules that
cheat in many ways are quite a different issue.
> > The spirit of the GPLv2 is to defend the freedom of the software
> > (different from the spirit of the BSD licence), and considering that
> > there aren't many people defending the GPLv2 copyright of the Linux
> > kernel at court against abusers, making it harder for people to do the
> > abuse might not be the worst choice...
>
> Well, but you seem to be saying that the license means squat, and
> resorting to making things inconvenient rather than illegal.
No, the point is that there's no reason for making illegal things
convenient.
I'm not talking about removing things that are used inside the kernel,
but what you call "freedom" can also be called "hooks for possible abuse".
Additionally, it both makes the kernel bigger for everyone and requires
proper handling of loading/unloading in the security architecture.
> Now I guess if it really is accepted that that's the way it should be,
> then this patch will go in.
>
> -serge
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Adrian Bunk ([EMAIL PROTECTED]):
> On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> > Quoting James Morris ([EMAIL PROTECTED]):
> > > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> > >
> > > > It's useful for some LSMs to be modular, and LSMs which are y/n options
> > > > won't
> > > > have any security architecture issues with unloading at all.
> > >
> > > Which LSMs? Upstream, there are SELinux and capabilty, and they're not
> > > safe as loadable modules.
> > >
> > > > The mere fact
> > > > that SELinux cannot be built as a module is a rather weak argument for
> > > > disabling LSM modules as a whole, so please don't.
> > >
> > > That's not the argument. Please review the thread.
> >
> > The argument is 'abuse', right?
> >
> > Abuse is defined as using the LSM hooks for non-security applications,
> > right?
> >
> > It seems to me that the community is doing a good job of discouraging
> > such abuse - by redirecting the "wrong-doers" to implement proper
> > upstream solutions, i.e. taskstats, the audit subsystem, etc.
> >
> > Such encouragement seems a far better response than taking away freedoms
> > and flexibility from everyone.
>
> We are not living in a world where everyone had good intentions...
Oh no, i took a wrong turn somewhere :)
> For _some_ "wrong-doers" your approach works.
>
> But how do you convince the "wrong-doers" who do things like putting
> MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
> and get away because noone sues them?
Do these really exist? Maybe noone sues them because noone knows who
they are...
But - note that you've changed completely the meaning of 'abuse'.
So mine was wrong?
> The spirit of the GPLv2 is to defend the freedom of the software
> (different from the spirit of the BSD licence), and considering that
> there aren't many people defending the GPLv2 copyright of the Linux
> kernel at court against abusers, making it harder for people to do the
> abuse might not be the worst choice...
Well, but you seem to be saying that the license means squat, and
resorting to making things inconvenient rather than illegal.
Now I guess if it really is accepted that that's the way it should be,
then this patch will go in.
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Kyle Moffett ([EMAIL PROTECTED]): > On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote: > >On Monday 25 June 2007 06:33, James Morris wrote: > >>Convert LSM into a static interface, as the ability to unload a > >>security module is not required by in-tree users and potentially > >>complicates the overall security architecture. > > > >It's useful for some LSMs to be modular, and LSMs which are y/n > >options won't have any security architecture issues with unloading > >at all. The mere fact that SELinux cannot be built as a module is a > >rather weak argument for disabling LSM modules as a whole, so > >please don't. > > Here are a few questions for you: > > 1) What do you expect to happen to all the megs of security data > when you "rmmod selinux"? Read the sentence right above yours again. Noone is saying we should be able to rmmod selinux. > Do you maintain a massive linked list of > security data (with all the locking and performance problems) so that > you can iterate over it calling kfree()? What synchronization > primitive do we have right now which could safely stop all CPUs > outside of security calls while we NULL out and free security data > and disable security operations? Don't say "software suspend" and > "process freezer", since those have whole order-of-magnitude- > complexity problems of their own (and don't always work right either). > > 2) When you "modprobe my_custom_security_module", how exactly do > you expect that all the processes, files, shared memory segments, > file descriptors, sockets, SYSV mutexes, packets, etc will get > appropriate security pointers?> Those don't all need labels for capabilities, for instance. This question is as wrong as the last one. > This isn't even solvable the same way > the "rmmod" problem is, since most of that isn't even accessible > without iterating over the ENTIRE dcache, icache, every process, > every process' file-descriptors, every socket, every unix socket, > every anonymous socket, every SYSV shm object, every currently-in- > process packet. > > 3) This sounds suspiciously like "The mere fact that the > Linux-2.6-VM cannot be built as a module is a rather weak argument > for disabling VFS modules as a whole". We don't do "pluggable No, your argument sounds like "my fs can't be a module so neither should any." > fundamental infrastructure" in Linux. If it's fundamental > infrastructure then you eliminate as many differences as possible and > leave the rest to CONFIG options (or delete it entirely). > > > So... Do you have a proposal for solving those rather fundamental > design gotchas? If so, I'm sure everybody here would love to see > your patch; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM > beware, the merge-conflict-from-hell is on its way). On the other > hand, if you accept that these problems basically can't be solved and > we make things static and rip out a bunch of code, we can probably > improve our performance under larger security models (like SELinux/ > AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two. > > Cheers, > Kyle Moffett > > - > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote:
> Quoting James Morris ([EMAIL PROTECTED]):
> > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:
> >
> > > It's useful for some LSMs to be modular, and LSMs which are y/n options
> > > won't
> > > have any security architecture issues with unloading at all.
> >
> > Which LSMs? Upstream, there are SELinux and capabilty, and they're not
> > safe as loadable modules.
> >
> > > The mere fact
> > > that SELinux cannot be built as a module is a rather weak argument for
> > > disabling LSM modules as a whole, so please don't.
> >
> > That's not the argument. Please review the thread.
>
> The argument is 'abuse', right?
>
> Abuse is defined as using the LSM hooks for non-security applications,
> right?
>
> It seems to me that the community is doing a good job of discouraging
> such abuse - by redirecting the "wrong-doers" to implement proper
> upstream solutions, i.e. taskstats, the audit subsystem, etc.
>
> Such encouragement seems a far better response than taking away freedoms
> and flexibility from everyone.
We are not living in a world where everyone had good intentions...
For _some_ "wrong-doers" your approach works.
But how do you convince the "wrong-doers" who do things like putting
MODULE_LICENSE("GPL") into their binary-only modules and who ignore you
and get away because noone sues them?
The spirit of the GPLv2 is to defend the freedom of the software
(different from the spirit of the BSD licence), and considering that
there aren't many people defending the GPLv2 copyright of the Linux
kernel at court against abusers, making it harder for people to do the
abuse might not be the worst choice...
> -serge
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? The spirit of the GPLv2 is to defend the freedom of the software (different from the spirit of the BSD licence), and considering that there aren't many people defending the GPLv2 copyright of the Linux kernel at court against abusers, making it harder for people to do the abuse might not be the worst choice... -serge 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Kyle Moffett ([EMAIL PROTECTED]): On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote: On Monday 25 June 2007 06:33, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Here are a few questions for you: 1) What do you expect to happen to all the megs of security data when you rmmod selinux? Read the sentence right above yours again. Noone is saying we should be able to rmmod selinux. Do you maintain a massive linked list of security data (with all the locking and performance problems) so that you can iterate over it calling kfree()? What synchronization primitive do we have right now which could safely stop all CPUs outside of security calls while we NULL out and free security data and disable security operations? Don't say software suspend and process freezer, since those have whole order-of-magnitude- complexity problems of their own (and don't always work right either). 2) When you modprobe my_custom_security_module, how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? Those don't all need labels for capabilities, for instance. This question is as wrong as the last one. This isn't even solvable the same way the rmmod problem is, since most of that isn't even accessible without iterating over the ENTIRE dcache, icache, every process, every process' file-descriptors, every socket, every unix socket, every anonymous socket, every SYSV shm object, every currently-in- process packet. 3) This sounds suspiciously like The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole. We don't do pluggable No, your argument sounds like my fs can't be a module so neither should any. fundamental infrastructure in Linux. If it's fundamental infrastructure then you eliminate as many differences as possible and leave the rest to CONFIG options (or delete it entirely). So... Do you have a proposal for solving those rather fundamental design gotchas? If so, I'm sure everybody here would love to see your patch; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM beware, the merge-conflict-from-hell is on its way). On the other hand, if you accept that these problems basically can't be solved and we make things static and rip out a bunch of code, we can probably improve our performance under larger security models (like SELinux/ AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... Oh no, i took a wrong turn somewhere :) For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? Do these really exist? Maybe noone sues them because noone knows who they are... But - note that you've changed completely the meaning of 'abuse'. So mine was wrong? The spirit of the GPLv2 is to defend the freedom of the software (different from the spirit of the BSD licence), and considering that there aren't many people defending the GPLv2 copyright of the Linux kernel at court against abusers, making it harder for people to do the abuse might not be the worst choice... Well, but you seem to be saying that the license means squat, and resorting to making things inconvenient rather than illegal. Now I guess if it really is accepted that that's the way it should be, then this patch will go in. -serge - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... Oh no, i took a wrong turn somewhere :) For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? Do these really exist? Maybe noone sues them because noone knows who they are... http://lwn.net/Articles/82306/ But - note that you've changed completely the meaning of 'abuse'. So mine was wrong? Technical and legal abuse are related. For GPL'ed modules you might assume good faith and get the authors to do things in a proper way. Authors of legally questionable modules that cheat in many ways are quite a different issue. The spirit of the GPLv2 is to defend the freedom of the software (different from the spirit of the BSD licence), and considering that there aren't many people defending the GPLv2 copyright of the Linux kernel at court against abusers, making it harder for people to do the abuse might not be the worst choice... Well, but you seem to be saying that the license means squat, and resorting to making things inconvenient rather than illegal. No, the point is that there's no reason for making illegal things convenient. I'm not talking about removing things that are used inside the kernel, but what you call freedom can also be called hooks for possible abuse. Additionally, it both makes the kernel bigger for everyone and requires proper handling of loading/unloading in the security architecture. Now I guess if it really is accepted that that's the way it should be, then this patch will go in. -serge 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Adrian Bunk ([EMAIL PROTECTED]): On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... Oh no, i took a wrong turn somewhere :) For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? Do these really exist? Maybe noone sues them because noone knows who they are... http://lwn.net/Articles/82306/ LinuxAnt? Are they using LSM? It looks to me like this patch will do nothing about them. But - note that you've changed completely the meaning of 'abuse'. So mine was wrong? Technical and legal abuse are related. True but going by your logic we could remove support for modules period to prevent legal abuse by non-gpl modules. For GPL'ed modules you might assume good faith and get the authors to do things in a proper way. Authors of legally questionable modules that cheat in many ways are quite a different issue. The spirit of the GPLv2 is to defend the freedom of the software (different from the spirit of the BSD licence), and considering that there aren't many people defending the GPLv2 copyright of the Linux kernel at court against abusers, making it harder for people to do the abuse might not be the worst choice... Well, but you seem to be saying that the license means squat, and resorting to making things inconvenient rather than illegal. No, the point is that there's no reason for making illegal things convenient. But no, the point is that that you are making legal things very inconvenient. I'm not talking about removing things that are used inside the kernel, Since capabilities can currently be compiled as a module, you are. (Though that sounds weird, so maybe I'm misreading what you are saying) but what you call freedom can also be called hooks for possible abuse. Yup, that is true. Additionally, it both makes the kernel bigger for everyone and requires proper handling of loading/unloading in the security architecture. Now I guess if it really is accepted that that's the way it should be, then this patch will go in. -serge cu Adrian thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... Oh no, i took a wrong turn somewhere :) For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? Do these really exist? Yes they do. Maybe noone sues them because noone knows who they are... Maybe no one knows because the people doing the legal action against them are trying to be nice and do it quietly. And legal action takes time, it is quite slow going unfortunatly. Heck, I've seen code that is even properly licensed under the GPL abuse this security layer for things it was not ment to do at all, and that stuff comes from _very_ big companies that really should know better... So I agree that we should unexport it. It will make people who want to abuse the interface at least think twice about it. thanks, greg I want to mark structures read-only k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting Greg KH ([EMAIL PROTECTED]): On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... Oh no, i took a wrong turn somewhere :) For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? Do these really exist? Yes they do. Maybe noone sues them because noone knows who they are... Maybe no one knows because the people doing the legal action against them are trying to be nice and do it quietly. So they're being nice to the violaters, and then clamping down on everyone... And legal action takes time, it is quite slow going unfortunatly. Heck, I've seen code that is even properly licensed under the GPL abuse this security layer for things it was not ment to do at all, and that stuff comes from _very_ big companies that really should know better... But that's back to the other type of 'abuse' which i was originally talking about, and which IMO is being well addressed through education. As for the others, I have no better suggestions. I wish I did. So I agree that we should unexport it. It will make people who want to abuse the interface at least think twice about it. And those who don't abuse it too. thanks, greg I want to mark structures read-only k-h And I know I'm not the one who's going to stop you... -serge - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Tue, Jun 26, 2007 at 10:53:29AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. We are not living in a world where everyone had good intentions... Oh no, i took a wrong turn somewhere :) For _some_ wrong-doers your approach works. But how do you convince the wrong-doers who do things like putting MODULE_LICENSE(GPL) into their binary-only modules and who ignore you and get away because noone sues them? Do these really exist? Maybe noone sues them because noone knows who they are... http://lwn.net/Articles/82306/ LinuxAnt? Are they using LSM? It looks to me like this patch will do nothing about them. It was an example how creative wrong-doers sometimes are. But - note that you've changed completely the meaning of 'abuse'. So mine was wrong? Technical and legal abuse are related. True but going by your logic we could remove support for modules period to prevent legal abuse by non-gpl modules. The problem is that this would result in distributions having to ship 50 MB kernel images. For GPL'ed modules you might assume good faith and get the authors to do things in a proper way. Authors of legally questionable modules that cheat in many ways are quite a different issue. The spirit of the GPLv2 is to defend the freedom of the software (different from the spirit of the BSD licence), and considering that there aren't many people defending the GPLv2 copyright of the Linux kernel at court against abusers, making it harder for people to do the abuse might not be the worst choice... Well, but you seem to be saying that the license means squat, and resorting to making things inconvenient rather than illegal. No, the point is that there's no reason for making illegal things convenient. But no, the point is that that you are making legal things very inconvenient. I'm not talking about removing things that are used inside the kernel, Since capabilities can currently be compiled as a module, you are. (Though that sounds weird, so maybe I'm misreading what you are saying) If the LSM maintainer says non-modular capabilities is the way to go then there's no user left. but what you call freedom can also be called hooks for possible abuse. Yup, that is true. Additionally, it both makes the kernel bigger for everyone and requires proper handling of loading/unloading in the security architecture. Now I guess if it really is accepted that that's the way it should be, then this patch will go in. thanks, -serge 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Jun 26, 2007, at 09:47:12, Serge E. Hallyn wrote: Quoting Kyle Moffett ([EMAIL PROTECTED]): On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Here are a few questions for you: 1) What do you expect to happen to all the megs of security data when you rmmod selinux? Read the sentence right above yours again. Noone is saying we should be able to rmmod selinux. Ok, so say we extend LSM to do what AppArmor or TOMOYO need, what do you expect to happen when you rmmod tomoyo, rmmod apparmor, or whatever? Each of those is also going to stick lots of context on various objects during the course of running, the same way that the VM subsystem sticks lots of context on filesystem pages while running. Besides, even the standard capabilities module wants to attach a list of capabilities to every process and defines inheritance rules for them. Ergo you have the problems described below: Do you maintain a massive linked list of security data (with all the locking and performance problems) so that you can iterate over it calling kfree()? What synchronization primitive do we have right now which could safely stop all CPUs outside of security calls while we NULL out and free security data and disable security operations? Don't say software suspend and process freezer, since those have whole order-of-magnitude-complexity problems of their own (and don't always work right either). 2) When you modprobe my_custom_security_module, how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? Those don't all need labels for capabilities, for instance. This question is as wrong as the last one. Ok, so let's just restrict ourselves to the simple dumb-as-dirt capabilities module. Every process is labeled with capabilities while running under that LSM, right? What happens when you rmmod capabilities? Do you iterate over all the processes to remove their security data even while they may be using it? Or do you just let it leak? Some daemons test if capabilities are supported, and if so they modify their capability set instead of forking a high-priv and a low-priv process and doing IPC. When you remove the capabilities module, suddenly all those programs will lose that critical low- privilege data and become full root. What happens later when you modprobe capabilities? Do you suddenly have to stop the system while you iterate over EVERY process to set capabilities based on whether it's root or not? It's also impossible to determine from a given state in time what processes should have capabilities, as the model includes inheritance, which includes processes that don't even exist anymore. 3) This sounds suspiciously like The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole. No, your argument sounds like my fs can't be a module so neither should any. Let's go over the differences between my fs and my LSM, and the similarities between my VM and my LSM: Filesystems don't get hooked from virtually every userspace-initiated operation, whereas both VMs and LSMs do. VMs and LSMs attach anonymous state data to a large percentage of the allocated objects in the system, whereas filesystems allocate their own independent datastructure and use that. Would you want to rmmod ext3 and then modprobe ext2 while you have an ext2-as-ext3 filesystem *mounted*??? If you want a good analogy, that's a better one than the my fs can't be a module crap. This whole discussion boils down to 2 points: 1) As currently implemented, no LSM may be safely rmmod-ed 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. I said this before: So... Do you have a proposal for solving those rather fundamental design gotchas? If so, I'm sure everybody here would love to see your patch Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Kyle Moffett wrote: Let's go over the differences between my fs and my LSM, and the similarities between my VM and my LSM: Filesystems don't get hooked from virtually every userspace-initiated operation, whereas both VMs and LSMs do. VMs and LSMs attach anonymous state data to a large percentage of the allocated objects in the system, whereas filesystems allocate their own independent datastructure and use that. Would you want to rmmod ext3 and then modprobe ext2 while you have an ext2-as-ext3 filesystem *mounted*??? If you want a good analogy, that's a better one than the my fs can't be a module crap. This whole discussion boils down to 2 points: 1) As currently implemented, no LSM may be safely rmmod-ed 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. I said this before: Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module. Consider the use case of joe admin who is running enterprise-supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Without James's patch, he can do that, and at worst has a tainted kernel. RH or Novell or his favorite distro vendor can fix that with a wave of the hand and bless FooSecure as a module. With James's patch, he has to patch his kernels, and then enterprise support is hopeless, to say nothing of the barrier to entry that patch and rebuild kernel is more than many admins are willing to do. So to solve the problem James Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Jun 26, 2007, at 20:57:53, Crispin Cowan wrote: Kyle Moffett wrote: Let's go over the differences between my fs and my LSM, and the similarities between my VM and my LSM: Filesystems don't get hooked from virtually every userspace-initiated operation, whereas both VMs and LSMs do. VMs and LSMs attach anonymous state data to a large percentage of the allocated objects in the system, whereas filesystems allocate their own independent datastructure and use that. Would you want to rmmod ext3 and then modprobe ext2 while you have an ext2-as-ext3 filesystem *mounted*??? If you want a good analogy, that's a better one than the my fs can't be a module crap. This whole discussion boils down to 2 points: 1) As currently implemented, no LSM may be safely rmmod-ed 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module. You must have missed this in my emails: 2) When you modprobe my_custom_security_module, how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? This isn't even solvable the same way the rmmod problem is, since most of that isn't even accessible without iterating over the ENTIRE dcache, icache, every process, every process' file-descriptors, every socket, every unix socket, every anonymous socket, every SYSV shm object, every currently-in-process packet. I'd argue that security-module-insertion is actually MORE complicated than removal. Here's one example: TOMOYO cares about the process execution tree, but you can't penalize the no-LSM case by a percent or two to add that kind of data. When TOMOYO is loaded, it wants to do access control based on process execution trees for which data DOES NOT EXIST!!! Not only that, but the processes which originally ran the one you care about (and which you'd need to recreate that data) may have exited anywhere from seconds to years before. It is fundamentally IMPOSSIBLE to recreate that data, even if you could solve the problems of how to do it while the system is running without racing with existing process operations. Imagine a process which hasn't had security data tagged to it yet which opens thousands of FIFOs per second, waits for your tagging code to assign security data to them in the filesystem, and then removes them; if you did it right you could prevent the code from EVER completely tagging every object (even assuming you could recreate enough information). Such a need to add extra security data to multiple classes of objects is *fundamental* to any security module (isn't that the whole point?) As such, you can't just modprobe one and expect it to work. That's like mounting an ext2 filesystem, and then later trying to modprobe ext3 and dynamically switch to the ext3 code and enable journalling all at once ON THE MOUNTED FILESYSTEM!!! Sure, theoretically it *could* be done, but the code complexity is hardly worth it (plus nobody has yet even tried posting patches to make it happen). Consider the use case of joe admin who is running enterprise- supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Flatly impossible. You simply cannot load a security module and hope to provide any useful information about the system's present state. If you want comprehensive security it has to be there before a single byte of userspace code is executed. SELinux sort-of handles unlabelled objects by treating them with a small set of initial types, but that's only enough to get the system up enough to actually relabel objects with type-transitions (after init loads the selinux policy it reexecs itself, before doing anything else). So to solve the problem James Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. An LSM simple enough to unload would be too simple for anybody to want to load in the first place (even capabilities can have this problem). What kind of
Re: [PATCH try #2] security: Convert LSM into a static interface
* Crispin Cowan ([EMAIL PROTECTED]) wrote: and simple LSMs that can be unloaded safely can permit it. there are none, and making the above possible is prohibitively expensive. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Oops, typo: On Jun 26, 2007, at 00:09:24, Kyle Moffett wrote: This sounds suspiciously like "The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole" Meant to say: "...disabling VM modules as a whole." Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote: On Monday 25 June 2007 06:33, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Here are a few questions for you: 1) What do you expect to happen to all the megs of security data when you "rmmod selinux"? Do you maintain a massive linked list of security data (with all the locking and performance problems) so that you can iterate over it calling kfree()? What synchronization primitive do we have right now which could safely stop all CPUs outside of security calls while we NULL out and free security data and disable security operations? Don't say "software suspend" and "process freezer", since those have whole order-of-magnitude- complexity problems of their own (and don't always work right either). 2) When you "modprobe my_custom_security_module", how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? This isn't even solvable the same way the "rmmod" problem is, since most of that isn't even accessible without iterating over the ENTIRE dcache, icache, every process, every process' file-descriptors, every socket, every unix socket, every anonymous socket, every SYSV shm object, every currently-in- process packet. 3) This sounds suspiciously like "The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole". We don't do "pluggable fundamental infrastructure" in Linux. If it's fundamental infrastructure then you eliminate as many differences as possible and leave the rest to CONFIG options (or delete it entirely). So... Do you have a proposal for solving those rather fundamental design gotchas? If so, I'm sure everybody here would love to see your patch; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM beware, the merge-conflict-from-hell is on its way). On the other hand, if you accept that these problems basically can't be solved and we make things static and rip out a bunch of code, we can probably improve our performance under larger security models (like SELinux/ AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): > On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: > > > It's useful for some LSMs to be modular, and LSMs which are y/n options > > won't > > have any security architecture issues with unloading at all. > > Which LSMs? Upstream, there are SELinux and capabilty, and they're not > safe as loadable modules. > > > The mere fact > > that SELinux cannot be built as a module is a rather weak argument for > > disabling LSM modules as a whole, so please don't. > > That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the "wrong-doers" to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: > It's useful for some LSMs to be modular, and LSMs which are y/n options won't > have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. > The mere fact > that SELinux cannot be built as a module is a rather weak argument for > disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Monday 25 June 2007 06:33, James Morris wrote: > Convert LSM into a static interface, as the ability to unload a security > module is not required by in-tree users and potentially complicates the > overall security architecture. It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, 2007-06-25 at 00:33 -0400, James Morris wrote: > Convert LSM into a static interface, as the ability to unload a security > module is not required by in-tree users and potentially complicates the > overall security architecture. > > Needlessly exported LSM symbols have been unexported, to help reduce API > abuse. > > Parameters for the capability and root_plug modules are now specified at > boot. > > The SECURITY_FRAMEWORK_VERSION macro has also been removed. > > Signed-off-by: James Morris <[EMAIL PROTECTED]> > --- > diff --git a/security/security.c b/security/security.c > index fc8601b..e49dae2 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -172,8 +170,5 @@ int mod_unreg_security(const char *name, struct > security_operations *ops) > return security_ops->unregister_security(name, ops); > } > > -EXPORT_SYMBOL_GPL(register_security); > -EXPORT_SYMBOL_GPL(unregister_security); > -EXPORT_SYMBOL_GPL(mod_reg_security); > -EXPORT_SYMBOL_GPL(mod_unreg_security); > +/* Export required for modular use of security.h inlines */ > EXPORT_SYMBOL(security_ops); I think you want to eliminate that last export too, by taking the security hooks that are called by modules into out-of-line wrapper functions in security.c rather than directly referencing security_ops. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, 2007-06-25 at 00:33 -0400, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. Needlessly exported LSM symbols have been unexported, to help reduce API abuse. Parameters for the capability and root_plug modules are now specified at boot. The SECURITY_FRAMEWORK_VERSION macro has also been removed. Signed-off-by: James Morris [EMAIL PROTECTED] --- diff --git a/security/security.c b/security/security.c index fc8601b..e49dae2 100644 --- a/security/security.c +++ b/security/security.c @@ -172,8 +170,5 @@ int mod_unreg_security(const char *name, struct security_operations *ops) return security_ops-unregister_security(name, ops); } -EXPORT_SYMBOL_GPL(register_security); -EXPORT_SYMBOL_GPL(unregister_security); -EXPORT_SYMBOL_GPL(mod_reg_security); -EXPORT_SYMBOL_GPL(mod_unreg_security); +/* Export required for modular use of security.h inlines */ EXPORT_SYMBOL(security_ops); I think you want to eliminate that last export too, by taking the security hooks that are called by modules into out-of-line wrapper functions in security.c rather than directly referencing security_ops. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Monday 25 June 2007 06:33, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Thanks, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. Which LSMs? Upstream, there are SELinux and capabilty, and they're not safe as loadable modules. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. That's not the argument. Please review the thread. The argument is 'abuse', right? Abuse is defined as using the LSM hooks for non-security applications, right? It seems to me that the community is doing a good job of discouraging such abuse - by redirecting the wrong-doers to implement proper upstream solutions, i.e. taskstats, the audit subsystem, etc. Such encouragement seems a far better response than taking away freedoms and flexibility from everyone. -serge - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Jun 25, 2007, at 16:37:58, Andreas Gruenbacher wrote: On Monday 25 June 2007 06:33, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. It's useful for some LSMs to be modular, and LSMs which are y/n options won't have any security architecture issues with unloading at all. The mere fact that SELinux cannot be built as a module is a rather weak argument for disabling LSM modules as a whole, so please don't. Here are a few questions for you: 1) What do you expect to happen to all the megs of security data when you rmmod selinux? Do you maintain a massive linked list of security data (with all the locking and performance problems) so that you can iterate over it calling kfree()? What synchronization primitive do we have right now which could safely stop all CPUs outside of security calls while we NULL out and free security data and disable security operations? Don't say software suspend and process freezer, since those have whole order-of-magnitude- complexity problems of their own (and don't always work right either). 2) When you modprobe my_custom_security_module, how exactly do you expect that all the processes, files, shared memory segments, file descriptors, sockets, SYSV mutexes, packets, etc will get appropriate security pointers? This isn't even solvable the same way the rmmod problem is, since most of that isn't even accessible without iterating over the ENTIRE dcache, icache, every process, every process' file-descriptors, every socket, every unix socket, every anonymous socket, every SYSV shm object, every currently-in- process packet. 3) This sounds suspiciously like The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole. We don't do pluggable fundamental infrastructure in Linux. If it's fundamental infrastructure then you eliminate as many differences as possible and leave the rest to CONFIG options (or delete it entirely). So... Do you have a proposal for solving those rather fundamental design gotchas? If so, I'm sure everybody here would love to see your patch; though maybe not if it's a 32MB patch-zilla-of-doom (AKPM beware, the merge-conflict-from-hell is on its way). On the other hand, if you accept that these problems basically can't be solved and we make things static and rip out a bunch of code, we can probably improve our performance under larger security models (like SELinux/ AppArmor/TOMOYO/MagicSecurityFlavorOfTheWeek(TM)) by a percent or two. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Oops, typo: On Jun 26, 2007, at 00:09:24, Kyle Moffett wrote: This sounds suspiciously like The mere fact that the Linux-2.6-VM cannot be built as a module is a rather weak argument for disabling VFS modules as a whole Meant to say: ...disabling VM modules as a whole. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Sun, 24 Jun 2007, Petr Vandrovec wrote:
> > -module_param(debug, bool, 0600);
> > -MODULE_PARM_DESC(debug, "Debug enabled or not");
> > +static int __init root_plug_debug(char *str)
> > +{
> > + debug = simple_strtol(str, NULL, 0);
> > + return 1;
> > +}
> > +__setup("root_plug_debug=", root_plug_debug);
>
> is this necessary? What about just documenting
> root_plug.{vendor_id,product_id,debug}, so it won't break existing root_plug
> users (if there are any) ? I thought that typed module_param() is prefered
> over untyped __setup()...
I didn't know module_param was preferred.
The idea was that root_plug is example code, and should do the typical
thing, which I thought would be __setup.
I can easily change it if needed.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, "Debug enabled or not");
+static int __init root_plug_debug(char *str)
+{
+ debug = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup("root_plug_debug=", root_plug_debug);
is this necessary? What about just documenting
root_plug.{vendor_id,product_id,debug}, so it won't break existing
root_plug users (if there are any) ? I thought that typed
module_param() is prefered over untyped __setup()...
Thanks,
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH try #2] security: Convert LSM into a static interface
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Needlessly exported LSM symbols have been unexported, to help reduce API
abuse.
Parameters for the capability and root_plug modules are now specified at
boot.
The SECURITY_FRAMEWORK_VERSION macro has also been removed.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
Changes:
- retain capability.disable kernel param name
Documentation/kernel-parameters.txt | 17 +++
security/Kconfig|4 +-
security/capability.c | 24
security/commoncap.c|3 --
security/dummy.c|1 -
security/root_plug.c| 53 +-
security/security.c |9 +
security/selinux/hooks.c|1 -
security/selinux/xfrm.c |1 -
9 files changed, 41 insertions(+), 72 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5d0283c..35e1202 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -74,10 +74,12 @@ parameter is applicable:
PPT Parallel port support is enabled.
PS2 Appropriate PS/2 support is enabled.
RAM RAM disk support is enabled.
+ ROOTPLUG The example Root Plug LSM is enabled.
S390S390 architecture is enabled.
SCSIAppropriate SCSI support is enabled.
A lot of drivers has their options described inside of
Documentation/scsi/.
+ SECURITY Different security models are enabled.
SELINUX SELinux support is enabled.
SERIAL Serial support is enabled.
SH SuperH architecture is enabled.
@@ -376,6 +378,12 @@ and is between 256 and 4096 characters. It is defined in
the file
possible to determine what the correct size should be.
This option provides an override for these situations.
+ capability.disable=
+ [SECURITY] Disable capabilities. This would normally
+ be used only if an alternative security model is to be
+ configured. Potentially dangerous and should only be
+ used if you are entirely sure of the consequences.
+
cdu31a= [HW,CD]
Format: ,[,PAS]
See header of drivers/cdrom/cdu31a.c.
@@ -1541,6 +1549,15 @@ and is between 256 and 4096 characters. It is defined in
the file
rootfstype= [KNL] Set root filesystem type
+ root_plug_vendor_id=
+ [ROOTPLUG] Override the default vendor ID
+
+ root_plug_product_id=
+ [ROOTPLUG] Override the default product ID
+
+ root_plug_debug=
+ [ROOTPLUG] Enable debugging output
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..8ae5490 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -74,14 +74,14 @@ config SECURITY_NETWORK_XFRM
If you are unsure how to answer this question, answer N.
config SECURITY_CAPABILITIES
- tristate "Default Linux Capabilities"
+ bool "Default Linux Capabilities"
depends on SECURITY
help
This enables the "default" Linux capabilities functionality.
If you are unsure how to answer this question, answer Y.
config SECURITY_ROOTPLUG
- tristate "Root Plug Support"
+ bool "Root Plug Support"
depends on USB && SECURITY
help
This is a sample LSM module that should only be used as such.
diff --git a/security/capability.c b/security/capability.c
index 38296a0..fda6a14 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -8,7 +8,6 @@
*
*/
-#include
#include
#include
#include
@@ -52,7 +51,6 @@ static int secondary;
static int capability_disable;
module_param_named(disable, capability_disable, int, 0);
-MODULE_PARM_DESC(disable, "To disable capabilities module set disable = 1");
static int __init capability_init (void)
{
@@ -75,26 +73,4 @@ static int __init capability_init (void)
return 0;
}
-static void __exit capability_exit (void)
-{
- if (capability_disable)
- return;
- /* remove ourselves from the security framework */
- if (secondary) {
- if (mod_unreg_security (KBUILD_MODNAME, _ops))
- printk (KERN_INFO "Failure unregistering capabilities "
- "with primary module.\n");
- return;
- }
-
- if (unregister_security (_ops)) {
- printk
Re: [PATCH try #2] security: Convert LSM into a static interface
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, Debug enabled or not);
+static int __init root_plug_debug(char *str)
+{
+ debug = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup(root_plug_debug=, root_plug_debug);
is this necessary? What about just documenting
root_plug.{vendor_id,product_id,debug}, so it won't break existing
root_plug users (if there are any) ? I thought that typed
module_param() is prefered over untyped __setup()...
Thanks,
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH try #2] security: Convert LSM into a static interface
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Needlessly exported LSM symbols have been unexported, to help reduce API
abuse.
Parameters for the capability and root_plug modules are now specified at
boot.
The SECURITY_FRAMEWORK_VERSION macro has also been removed.
Signed-off-by: James Morris [EMAIL PROTECTED]
---
Changes:
- retain capability.disable kernel param name
Documentation/kernel-parameters.txt | 17 +++
security/Kconfig|4 +-
security/capability.c | 24
security/commoncap.c|3 --
security/dummy.c|1 -
security/root_plug.c| 53 +-
security/security.c |9 +
security/selinux/hooks.c|1 -
security/selinux/xfrm.c |1 -
9 files changed, 41 insertions(+), 72 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5d0283c..35e1202 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -74,10 +74,12 @@ parameter is applicable:
PPT Parallel port support is enabled.
PS2 Appropriate PS/2 support is enabled.
RAM RAM disk support is enabled.
+ ROOTPLUG The example Root Plug LSM is enabled.
S390S390 architecture is enabled.
SCSIAppropriate SCSI support is enabled.
A lot of drivers has their options described inside of
Documentation/scsi/.
+ SECURITY Different security models are enabled.
SELINUX SELinux support is enabled.
SERIAL Serial support is enabled.
SH SuperH architecture is enabled.
@@ -376,6 +378,12 @@ and is between 256 and 4096 characters. It is defined in
the file
possible to determine what the correct size should be.
This option provides an override for these situations.
+ capability.disable=
+ [SECURITY] Disable capabilities. This would normally
+ be used only if an alternative security model is to be
+ configured. Potentially dangerous and should only be
+ used if you are entirely sure of the consequences.
+
cdu31a= [HW,CD]
Format: io,irq[,PAS]
See header of drivers/cdrom/cdu31a.c.
@@ -1541,6 +1549,15 @@ and is between 256 and 4096 characters. It is defined in
the file
rootfstype= [KNL] Set root filesystem type
+ root_plug_vendor_id=
+ [ROOTPLUG] Override the default vendor ID
+
+ root_plug_product_id=
+ [ROOTPLUG] Override the default product ID
+
+ root_plug_debug=
+ [ROOTPLUG] Enable debugging output
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..8ae5490 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -74,14 +74,14 @@ config SECURITY_NETWORK_XFRM
If you are unsure how to answer this question, answer N.
config SECURITY_CAPABILITIES
- tristate Default Linux Capabilities
+ bool Default Linux Capabilities
depends on SECURITY
help
This enables the default Linux capabilities functionality.
If you are unsure how to answer this question, answer Y.
config SECURITY_ROOTPLUG
- tristate Root Plug Support
+ bool Root Plug Support
depends on USB SECURITY
help
This is a sample LSM module that should only be used as such.
diff --git a/security/capability.c b/security/capability.c
index 38296a0..fda6a14 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -8,7 +8,6 @@
*
*/
-#include linux/module.h
#include linux/init.h
#include linux/kernel.h
#include linux/security.h
@@ -52,7 +51,6 @@ static int secondary;
static int capability_disable;
module_param_named(disable, capability_disable, int, 0);
-MODULE_PARM_DESC(disable, To disable capabilities module set disable = 1);
static int __init capability_init (void)
{
@@ -75,26 +73,4 @@ static int __init capability_init (void)
return 0;
}
-static void __exit capability_exit (void)
-{
- if (capability_disable)
- return;
- /* remove ourselves from the security framework */
- if (secondary) {
- if (mod_unreg_security (KBUILD_MODNAME, capability_ops))
- printk (KERN_INFO Failure unregistering capabilities
- with primary module.\n);
- return;
- }
-
- if
Re: [PATCH try #2] security: Convert LSM into a static interface
On Sun, 24 Jun 2007, Petr Vandrovec wrote:
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, Debug enabled or not);
+static int __init root_plug_debug(char *str)
+{
+ debug = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup(root_plug_debug=, root_plug_debug);
is this necessary? What about just documenting
root_plug.{vendor_id,product_id,debug}, so it won't break existing root_plug
users (if there are any) ? I thought that typed module_param() is prefered
over untyped __setup()...
I didn't know module_param was preferred.
The idea was that root_plug is example code, and should do the typical
thing, which I thought would be __setup.
I can easily change it if needed.
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
