Re: [PATCH try #3] security: Convert LSM into a static interface
On Tue, Jul 24, 2007 at 01:58:46AM -0700, Andrew Morton wrote: > On Tue, 24 Jul 2007 01:53:58 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: > > > On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Convert LSM into a static interface > > > > > > allmodconfig broke > > > > > > security/built-in.o: In function `rootplug_bprm_check_security': > > > security/root_plug.c:64: undefined reference to `usb_find_device' > > > security/root_plug.c:70: undefined reference to `usb_put_dev' > > > > That's wierd, who would have disabled the exports of those functions or > > removed the "#include " from this file? > > > > root_plug is linked into vmlinux and usb is modular. I did this: > > --- a/security/Kconfig~security-convert-lsm-into-a-static-interface-fix-2 > +++ a/security/Kconfig > @@ -82,7 +82,7 @@ config SECURITY_CAPABILITIES > > config SECURITY_ROOTPLUG > bool "Root Plug Support" > - depends on USB && SECURITY > + depends on USB=y && SECURITY > help > This is a sample LSM module that should only be used as such. > It prevents any programs running with egid == 0 if a specific That looks correct to me. thanks, greg 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 #3] security: Convert LSM into a static interface
On Tue, 24 Jul 2007 01:53:58 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: > > On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris <[EMAIL PROTECTED]> > > wrote: > > > > > Convert LSM into a static interface > > > > allmodconfig broke > > > > security/built-in.o: In function `rootplug_bprm_check_security': > > security/root_plug.c:64: undefined reference to `usb_find_device' > > security/root_plug.c:70: undefined reference to `usb_put_dev' > > That's wierd, who would have disabled the exports of those functions or > removed the "#include " from this file? > root_plug is linked into vmlinux and usb is modular. I did this: --- a/security/Kconfig~security-convert-lsm-into-a-static-interface-fix-2 +++ a/security/Kconfig @@ -82,7 +82,7 @@ config SECURITY_CAPABILITIES config SECURITY_ROOTPLUG bool "Root Plug Support" - depends on USB && SECURITY + depends on USB=y && SECURITY help This is a sample LSM module that should only be used as such. It prevents any programs running with egid == 0 if a specific _ I suppose we could do SECURITY_ROOTPLUG=m if USB=m, but I thought the whole point was to disallow modular LSM clients? - 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 #3] security: Convert LSM into a static interface
On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: > On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris <[EMAIL PROTECTED]> > wrote: > > > Convert LSM into a static interface > > allmodconfig broke > > security/built-in.o: In function `rootplug_bprm_check_security': > security/root_plug.c:64: undefined reference to `usb_find_device' > security/root_plug.c:70: undefined reference to `usb_put_dev' That's wierd, who would have disabled the exports of those functions or removed the "#include " from this file? thanks, greg 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 #3] security: Convert LSM into a static interface
On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris <[EMAIL PROTECTED]> wrote: > Convert LSM into a static interface allmodconfig broke security/built-in.o: In function `rootplug_bprm_check_security': security/root_plug.c:64: undefined reference to `usb_find_device' security/root_plug.c:70: undefined reference to `usb_put_dev' - 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 #3] security: Convert LSM into a static interface
On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] wrote: Convert LSM into a static interface allmodconfig broke security/built-in.o: In function `rootplug_bprm_check_security': security/root_plug.c:64: undefined reference to `usb_find_device' security/root_plug.c:70: undefined reference to `usb_put_dev' - 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 #3] security: Convert LSM into a static interface
On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] wrote: Convert LSM into a static interface allmodconfig broke security/built-in.o: In function `rootplug_bprm_check_security': security/root_plug.c:64: undefined reference to `usb_find_device' security/root_plug.c:70: undefined reference to `usb_put_dev' That's wierd, who would have disabled the exports of those functions or removed the #include linux/usb.h from this file? thanks, greg 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 #3] security: Convert LSM into a static interface
On Tue, 24 Jul 2007 01:53:58 -0700 Greg KH [EMAIL PROTECTED] wrote: On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] wrote: Convert LSM into a static interface allmodconfig broke security/built-in.o: In function `rootplug_bprm_check_security': security/root_plug.c:64: undefined reference to `usb_find_device' security/root_plug.c:70: undefined reference to `usb_put_dev' That's wierd, who would have disabled the exports of those functions or removed the #include linux/usb.h from this file? root_plug is linked into vmlinux and usb is modular. I did this: --- a/security/Kconfig~security-convert-lsm-into-a-static-interface-fix-2 +++ a/security/Kconfig @@ -82,7 +82,7 @@ config SECURITY_CAPABILITIES config SECURITY_ROOTPLUG bool Root Plug Support - depends on USB SECURITY + depends on USB=y SECURITY help This is a sample LSM module that should only be used as such. It prevents any programs running with egid == 0 if a specific _ I suppose we could do SECURITY_ROOTPLUG=m if USB=m, but I thought the whole point was to disallow modular LSM clients? - 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 #3] security: Convert LSM into a static interface
On Tue, Jul 24, 2007 at 01:58:46AM -0700, Andrew Morton wrote: On Tue, 24 Jul 2007 01:53:58 -0700 Greg KH [EMAIL PROTECTED] wrote: On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] wrote: Convert LSM into a static interface allmodconfig broke security/built-in.o: In function `rootplug_bprm_check_security': security/root_plug.c:64: undefined reference to `usb_find_device' security/root_plug.c:70: undefined reference to `usb_put_dev' That's wierd, who would have disabled the exports of those functions or removed the #include linux/usb.h from this file? root_plug is linked into vmlinux and usb is modular. I did this: --- a/security/Kconfig~security-convert-lsm-into-a-static-interface-fix-2 +++ a/security/Kconfig @@ -82,7 +82,7 @@ config SECURITY_CAPABILITIES config SECURITY_ROOTPLUG bool Root Plug Support - depends on USB SECURITY + depends on USB=y SECURITY help This is a sample LSM module that should only be used as such. It prevents any programs running with egid == 0 if a specific That looks correct to me. thanks, greg 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 #3] security: Convert LSM into a static interface
Quoting Arjan van de Ven ([EMAIL PROTECTED]): > > > > > :) > > > > Actually, given that when lsm was being introduced, lsm seemed to > > improve performance overall, have you taken any measurements to show > > that this is actually the case? Of course it makes sense that it would, > > but witjout measurements we do not know. > > SuSE did a bunch of measurement I think a year ago and they showed a > several percent performance increase with a hack similar to the proposed > next step.. Very good. -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 #3] security: Convert LSM into a static interface
> > :) > > Actually, given that when lsm was being introduced, lsm seemed to > improve performance overall, have you taken any measurements to show > that this is actually the case? Of course it makes sense that it would, > but witjout measurements we do not know. SuSE did a bunch of measurement I think a year ago and they showed a several percent performance increase with a hack similar to the proposed next step.. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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 #3] security: Convert LSM into a static interface
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > Actually, given that when lsm was being introduced, lsm seemed to > improve performance overall, have you taken any measurements to show > that this is actually the case? Of course it makes sense that it would, > but witjout measurements we do not know. Yes, it does. I have measured it as have others (esp. after Kurt Garloff pointed out issues on ia64). thanks, -chris - 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 09:54:30AM -0700, Arjan van de Ven wrote: > the next step after this patch is to have an option to get rid of all > the function pointer chasing (which is expensive) for the case where you > know you only want one security module (which you then can turn on or > off)... that advantage is a performance gain for a lot of people I'm pretty sure that at least the security_ops function pointers could be resolved statically with some proprocessor trickery right now. E.g. define macros for the security_* hooks in the single security module that is configured statically and include those defines in security.h instead of the prototypes for the inline functions. Am I missing something? If a distribution enables such an option there is no way to load a security module, true. This is what we have right now if the distro disables loadable module support or disables security modules. regards Christian signature.asc Description: Digital signature
Re: [PATCH try #3] security: Convert LSM into a static interface
Quoting Arjan van de Ven ([EMAIL PROTECTED]): > > > Right, the ability to boot with security.capability=disabpled (or > > whatever) and then load a custom module without having to use a whole > > new kernel is something I'm sure end-users want. > > > > Especially since compiling a kernel which works with, say, a default > > fedora install, with lvm etc, is not imo for a novice (where novice > > != security novice). > > the next step after this patch is to have an option to get rid of all > the function pointer chasing (which is expensive) for the case where you > know you only want one security module (which you then can turn on or > off)... that advantage is a performance gain for a lot of people but > if the person configuring the kernel selects this, it does mean there's > no way to load modules. I don't know what Fedora will do, but they might > select such an option. That's CHOICE... War is peace Freedom is slavery Ignorance is strength -1984 :) Actually, given that when lsm was being introduced, lsm seemed to improve performance overall, have you taken any measurements to show that this is actually the case? Of course it makes sense that it would, but witjout measurements we do not know. > they chose a performance > improvement over enabling external kernel modules that they don't ship > anyway... > > but is it really worth blocking such clear improvements in performance? I'm blocking nothing. In fact I concede that this patch might force any out of tree module authors to come to the table, which is a good thing. -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 #3] security: Convert LSM into a static interface
> Right, the ability to boot with security.capability=disabpled (or > whatever) and then load a custom module without having to use a whole > new kernel is something I'm sure end-users want. > > Especially since compiling a kernel which works with, say, a default > fedora install, with lvm etc, is not imo for a novice (where novice > != security novice). the next step after this patch is to have an option to get rid of all the function pointer chasing (which is expensive) for the case where you know you only want one security module (which you then can turn on or off)... that advantage is a performance gain for a lot of people but if the person configuring the kernel selects this, it does mean there's no way to load modules. I don't know what Fedora will do, but they might select such an option. That's CHOICE... they chose a performance improvement over enabling external kernel modules that they don't ship anyway... but is it really worth blocking such clear improvements in performance? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 08:37:27AM -0500, Serge E. Hallyn wrote: > Quoting James Morris ([EMAIL PROTECTED]): > > On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > > > > > > It's already pretty clear. > > > > > > I doubt anyone not on lkml or linux-security-module has heard of this. > > > > > > So we'll see. > > > > > > (I was, obviously, talking about end-users) > > > > If distributions are shipping binary modules and other out of tree code to > > their users, then they should bear responsibility for supporting and > > maintaining the infrastructure required for it, and not expect upstream > > maintainers to do it for them. > > > > Additionally, if they want to expose their users to risks arising from > > broken and unecessary infrastructure, then they should bear the cost and > > responsibility of doing that and not expect others to do so as well. > > > > I don't see how this is even slightly difficult to understand. > > I'm not talking about distros - I don't see how this is even slightly > difficult to understand :) > > The situation I have in mind is someone who decideds to use, say, SLIM, > but wants to otherwise use the distro kernel. >... AFAIR this does anyway not work because at least the version of SLIM that once was in -mm required some patching of the kernel. > -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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 09:19:56AM -0400, James Morris wrote: > On Thu, 19 Jul 2007, James Morris wrote: > > > On Thu, 19 Jul 2007, Jim Kovaric wrote: > > > > > IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a > > > loadable module, > > > which is an "out of tree module", and registers "itself" as a security > > > module during the TAMOS startup > > > process. It also requires that SElinux be "disabled" > > > > Please provide a link to the source code, so we can understand how you're > > using the API. > > I think I've found it: > > ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6.0.0/6.0.0-TIV-PDO-FP0007/6.0.0-TIV-PDO-Linux.i386-FP0007.tar > > Is that correct? If so, that code seems to have been run through a "code obfuscator" and as such, is not abiding by the GPL. Can IBM please post the real code as the GPL requires? Jim, if you are not the person to make this request too, can you point me at the correct person? thanks, greg 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 09:19:56AM -0400, James Morris wrote: > Is my understanding correct? > > You're shipping this to customers as a security feature? It's the usual Tivoli crap, what would you expect? - 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 #3] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): > On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > > > > It's already pretty clear. > > > > I doubt anyone not on lkml or linux-security-module has heard of this. > > > > So we'll see. > > > > (I was, obviously, talking about end-users) > > If distributions are shipping binary modules and other out of tree code to > their users, then they should bear responsibility for supporting and > maintaining the infrastructure required for it, and not expect upstream > maintainers to do it for them. > > Additionally, if they want to expose their users to risks arising from > broken and unecessary infrastructure, then they should bear the cost and > responsibility of doing that and not expect others to do so as well. > > I don't see how this is even slightly difficult to understand. I'm not talking about distros - I don't see how this is even slightly difficult to understand :) The situation I have in mind is someone who decideds to use, say, SLIM, but wants to otherwise use the distro kernel. James, relax, I'm done arguing against your patch, I just think end-users/customers might complain. -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 #3] security: Convert LSM into a static interface
On 7/19/07, Alan Cox <[EMAIL PROTECTED]> wrote: > Please distinguish between "cater to" and "support". If the kernel > didn't worry about supporting out-of-tree code, then why would there > be loadable module at all? Memory usage, flexibility, debugging. Module support was not added for external modules. Code that is being debugged is, often [usually, I hope], out-of-tree code, though it may be aimed at future inclusion. However, I do agree that there is value to having loadable modules for in-tree functionality, too. scott -- scott preece - 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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, James Morris wrote: > On Thu, 19 Jul 2007, Jim Kovaric wrote: > > > IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a > > loadable module, > > which is an "out of tree module", and registers "itself" as a security > > module during the TAMOS startup > > process. It also requires that SElinux be "disabled" > > Please provide a link to the source code, so we can understand how you're > using the API. I think I've found it: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6.0.0/6.0.0-TIV-PDO-FP0007/6.0.0-TIV-PDO-Linux.i386-FP0007.tar Is that correct? kail_trap_syscalls() seems to be revectoring the syscall table and siliently disabling any active LSM. kail_restore_syscalls() attempts to restore them on module unload. Is my understanding correct? You're shipping this to customers as a security feature? - 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 07:56:53AM -0500, Scott Preece wrote: > On 7/19/07, James Morris <[EMAIL PROTECTED]> wrote: >> On Thu, 19 Jul 2007, Serge E. Hallyn wrote: >> >> > If we could get a few (non-afilliated :) people who work with >> > customers in the security field to tell us whether this is being >> > used, that would be very helpful. Not sure how to get that. >> >> The mainline kernel does not cater to out of tree code. > > Please distinguish between "cater to" and "support". If the kernel > didn't worry about supporting out-of-tree code, then why would there > be loadable module at all? >... Distribution kernels need modules or the kernel images would be extremely large. > Another twist is to use a tool to generate the module from a > policy-definition file; this could be done at boot-time or could be > done to replace the current policy on a running system (perhaps to add > a new domain corresponding to a newly added service). Yes, this would > need to be done with a lot of care, but part of providing mechanism > (rather than policy) is enabling people to use the mechanism in the > ways they prefer. Why do you need to generate a module for changing a policy? Software like SELinux contains the mechanisms to change the policy without having to change the kernel. > scott 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 #3] security: Convert LSM into a static interface
> Please distinguish between "cater to" and "support". If the kernel > didn't worry about supporting out-of-tree code, then why would there > be loadable module at all? Memory usage, flexibility, debugging. Module support was not added for external modules. - 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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, Jim Kovaric wrote: > IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a > loadable module, > which is an "out of tree module", and registers "itself" as a security > module during the TAMOS startup > process. It also requires that SElinux be "disabled" Please provide a link to the source code, so we can understand how you're using the API. - 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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > > It's already pretty clear. > > I doubt anyone not on lkml or linux-security-module has heard of this. > > So we'll see. > > (I was, obviously, talking about end-users) If distributions are shipping binary modules and other out of tree code to their users, then they should bear responsibility for supporting and maintaining the infrastructure required for it, and not expect upstream maintainers to do it for them. Additionally, if they want to expose their users to risks arising from broken and unecessary infrastructure, then they should bear the cost and responsibility of doing that and not expect others to do so as well. I don't see how this is even slightly difficult to understand. - 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 #3] security: Convert LSM into a static interface
On 7/19/07, James Morris <[EMAIL PROTECTED]> wrote: On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > If we could get a few (non-afilliated :) people who work with > customers in the security field to tell us whether this is being > used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. Please distinguish between "cater to" and "support". If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Christian Ehrhardt already pointed to two reasons for loadable LSMs that are sufficient to justify keeping them - so you can replace them iteratively while you're developing them or choose between alternatives. Another twist is to use a tool to generate the module from a policy-definition file; this could be done at boot-time or could be done to replace the current policy on a running system (perhaps to add a new domain corresponding to a newly added service). Yes, this would need to be done with a lot of care, but part of providing mechanism (rather than policy) is enabling people to use the mechanism in the ways they prefer. scott -- scott preece - 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 #3] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): > On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > > > If we could get a few (non-afilliated :) people who work with > > customers in the security field to tell us whether this is being > > used, that would be very helpful. Not sure how to get that. > > The mainline kernel does not cater to out of tree code. (Must... resist...) > > Or we just apply the patch and see who yells :) > > > It's already pretty clear. I doubt anyone not on lkml or linux-security-module has heard of this. So we'll see. (I was, obviously, talking about end-users) -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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, Serge E. Hallyn wrote: > If we could get a few (non-afilliated :) people who work with > customers in the security field to tell us whether this is being > used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. > Or we just apply the patch and see who yells :) It's already pretty clear. - 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 #3] security: Convert LSM into a static interface
Quoting Christian Ehrhardt ([EMAIL PROTECTED]): > On Wed, Jul 18, 2007 at 06:35:03PM -0700, Andrew Morton wrote: > > On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) > > James Morris <[EMAIL PROTECTED]> 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. > > > > I'd like to understand who is (or claims to be) adversely affected by this > > change, and what their complaints (if any) will be. > > I am currently loading and unloading a prototype like security module > on a regular basis. The fact that such a module can be loaded and > unloaded (albeit in an unsecure way) greatly simplifies development. > Thus this change will adversely affect me and probably also others that > develop LSMs. > > Additionally deployment of and choice among legitimate security modules > that may or may not (yet) be part of the main kernel tree is simplified by > an option to load these security modules (e.g. at boot time) into a running Right, the ability to boot with security.capability=disabpled (or whatever) and then load a custom module without having to use a whole new kernel is something I'm sure end-users want. Especially since compiling a kernel which works with, say, a default fedora install, with lvm etc, is not imo for a novice (where novice != security novice). Maybe there are no out of tree modules being used this way, or maybe there are but I just don't know about them, or maybe like James says they are all illegal modules and kill a puppy every time they are loaded. > kernel. This way a distribution can provide AppArmor, SELinux, SecLevl and > whatever as options very much in the same way that this works for a driver. > > > Because I prefer my flamewars pre- rather than post-merge. > > You asked for oppinion. I do not plan to engage in any flamewars. Ditto. There is very loud support for this - which may mean there is *broad* support for it. If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. Or we just apply the patch and see who yells :) -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 #3] security: Convert LSM into a static interface
On Wed, Jul 18, 2007 at 06:35:03PM -0700, Andrew Morton wrote: > On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) > James Morris <[EMAIL PROTECTED]> 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. > > I'd like to understand who is (or claims to be) adversely affected by this > change, and what their complaints (if any) will be. I am currently loading and unloading a prototype like security module on a regular basis. The fact that such a module can be loaded and unloaded (albeit in an unsecure way) greatly simplifies development. Thus this change will adversely affect me and probably also others that develop LSMs. Additionally deployment of and choice among legitimate security modules that may or may not (yet) be part of the main kernel tree is simplified by an option to load these security modules (e.g. at boot time) into a running kernel. This way a distribution can provide AppArmor, SELinux, SecLevl and whatever as options very much in the same way that this works for a driver. > Because I prefer my flamewars pre- rather than post-merge. You asked for oppinion. I do not plan to engage in any flamewars. regards Christian signature.asc Description: Digital signature
Re: [PATCH try #3] security: Convert LSM into a static interface
On Wed, Jul 18, 2007 at 10:42:09PM -0400, James Morris wrote: > On Wed, 18 Jul 2007, Andrew Morton wrote: > > aww man, you passed over an opportunity to fix vast amounts of coding style > > cruftiness. > > GregKH-esque :-) Yeah, sorry, that was when I was young and foolish and liked to bang on the spacebar more than I should have :) greg 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 #3] security: Convert LSM into a static interface
On Wed, Jul 18, 2007 at 10:42:09PM -0400, James Morris wrote: On Wed, 18 Jul 2007, Andrew Morton wrote: aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. GregKH-esque :-) Yeah, sorry, that was when I was young and foolish and liked to bang on the spacebar more than I should have :) greg 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 #3] security: Convert LSM into a static interface
On Wed, Jul 18, 2007 at 06:35:03PM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] 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. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. I am currently loading and unloading a prototype like security module on a regular basis. The fact that such a module can be loaded and unloaded (albeit in an unsecure way) greatly simplifies development. Thus this change will adversely affect me and probably also others that develop LSMs. Additionally deployment of and choice among legitimate security modules that may or may not (yet) be part of the main kernel tree is simplified by an option to load these security modules (e.g. at boot time) into a running kernel. This way a distribution can provide AppArmor, SELinux, SecLevl and whatever as options very much in the same way that this works for a driver. Because I prefer my flamewars pre- rather than post-merge. You asked for oppinion. I do not plan to engage in any flamewars. regards Christian signature.asc Description: Digital signature
Re: [PATCH try #3] security: Convert LSM into a static interface
Quoting Christian Ehrhardt ([EMAIL PROTECTED]): On Wed, Jul 18, 2007 at 06:35:03PM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] 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. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. I am currently loading and unloading a prototype like security module on a regular basis. The fact that such a module can be loaded and unloaded (albeit in an unsecure way) greatly simplifies development. Thus this change will adversely affect me and probably also others that develop LSMs. Additionally deployment of and choice among legitimate security modules that may or may not (yet) be part of the main kernel tree is simplified by an option to load these security modules (e.g. at boot time) into a running Right, the ability to boot with security.capability=disabpled (or whatever) and then load a custom module without having to use a whole new kernel is something I'm sure end-users want. Especially since compiling a kernel which works with, say, a default fedora install, with lvm etc, is not imo for a novice (where novice != security novice). Maybe there are no out of tree modules being used this way, or maybe there are but I just don't know about them, or maybe like James says they are all illegal modules and kill a puppy every time they are loaded. kernel. This way a distribution can provide AppArmor, SELinux, SecLevl and whatever as options very much in the same way that this works for a driver. Because I prefer my flamewars pre- rather than post-merge. You asked for oppinion. I do not plan to engage in any flamewars. Ditto. There is very loud support for this - which may mean there is *broad* support for it. If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. Or we just apply the patch and see who yells :) -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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, Serge E. Hallyn wrote: If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. Or we just apply the patch and see who yells :) It's already pretty clear. - 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 #3] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): On Thu, 19 Jul 2007, Serge E. Hallyn wrote: If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. (Must... resist...) Or we just apply the patch and see who yells :) It's already pretty clear. I doubt anyone not on lkml or linux-security-module has heard of this. So we'll see. (I was, obviously, talking about end-users) -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 #3] security: Convert LSM into a static interface
On 7/19/07, James Morris [EMAIL PROTECTED] wrote: On Thu, 19 Jul 2007, Serge E. Hallyn wrote: If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. Please distinguish between cater to and support. If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Christian Ehrhardt already pointed to two reasons for loadable LSMs that are sufficient to justify keeping them - so you can replace them iteratively while you're developing them or choose between alternatives. Another twist is to use a tool to generate the module from a policy-definition file; this could be done at boot-time or could be done to replace the current policy on a running system (perhaps to add a new domain corresponding to a newly added service). Yes, this would need to be done with a lot of care, but part of providing mechanism (rather than policy) is enabling people to use the mechanism in the ways they prefer. scott -- scott preece - 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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, Serge E. Hallyn wrote: It's already pretty clear. I doubt anyone not on lkml or linux-security-module has heard of this. So we'll see. (I was, obviously, talking about end-users) If distributions are shipping binary modules and other out of tree code to their users, then they should bear responsibility for supporting and maintaining the infrastructure required for it, and not expect upstream maintainers to do it for them. Additionally, if they want to expose their users to risks arising from broken and unecessary infrastructure, then they should bear the cost and responsibility of doing that and not expect others to do so as well. I don't see how this is even slightly difficult to understand. - 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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, Jim Kovaric wrote: IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a loadable module, which is an out of tree module, and registers itself as a security module during the TAMOS startup process. It also requires that SElinux be disabled Please provide a link to the source code, so we can understand how you're using the API. - 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 #3] security: Convert LSM into a static interface
Please distinguish between cater to and support. If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Memory usage, flexibility, debugging. Module support was not added for external modules. - 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 07:56:53AM -0500, Scott Preece wrote: On 7/19/07, James Morris [EMAIL PROTECTED] wrote: On Thu, 19 Jul 2007, Serge E. Hallyn wrote: If we could get a few (non-afilliated :) people who work with customers in the security field to tell us whether this is being used, that would be very helpful. Not sure how to get that. The mainline kernel does not cater to out of tree code. Please distinguish between cater to and support. If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? ... Distribution kernels need modules or the kernel images would be extremely large. Another twist is to use a tool to generate the module from a policy-definition file; this could be done at boot-time or could be done to replace the current policy on a running system (perhaps to add a new domain corresponding to a newly added service). Yes, this would need to be done with a lot of care, but part of providing mechanism (rather than policy) is enabling people to use the mechanism in the ways they prefer. Why do you need to generate a module for changing a policy? Software like SELinux contains the mechanisms to change the policy without having to change the kernel. scott 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 #3] security: Convert LSM into a static interface
On Thu, 19 Jul 2007, James Morris wrote: On Thu, 19 Jul 2007, Jim Kovaric wrote: IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a loadable module, which is an out of tree module, and registers itself as a security module during the TAMOS startup process. It also requires that SElinux be disabled Please provide a link to the source code, so we can understand how you're using the API. I think I've found it: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6.0.0/6.0.0-TIV-PDO-FP0007/6.0.0-TIV-PDO-Linux.i386-FP0007.tar Is that correct? kail_trap_syscalls() seems to be revectoring the syscall table and siliently disabling any active LSM. kail_restore_syscalls() attempts to restore them on module unload. Is my understanding correct? You're shipping this to customers as a security feature? - 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 #3] security: Convert LSM into a static interface
On 7/19/07, Alan Cox [EMAIL PROTECTED] wrote: Please distinguish between cater to and support. If the kernel didn't worry about supporting out-of-tree code, then why would there be loadable module at all? Memory usage, flexibility, debugging. Module support was not added for external modules. Code that is being debugged is, often [usually, I hope], out-of-tree code, though it may be aimed at future inclusion. However, I do agree that there is value to having loadable modules for in-tree functionality, too. scott -- scott preece - 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 #3] security: Convert LSM into a static interface
Quoting James Morris ([EMAIL PROTECTED]): On Thu, 19 Jul 2007, Serge E. Hallyn wrote: It's already pretty clear. I doubt anyone not on lkml or linux-security-module has heard of this. So we'll see. (I was, obviously, talking about end-users) If distributions are shipping binary modules and other out of tree code to their users, then they should bear responsibility for supporting and maintaining the infrastructure required for it, and not expect upstream maintainers to do it for them. Additionally, if they want to expose their users to risks arising from broken and unecessary infrastructure, then they should bear the cost and responsibility of doing that and not expect others to do so as well. I don't see how this is even slightly difficult to understand. I'm not talking about distros - I don't see how this is even slightly difficult to understand :) The situation I have in mind is someone who decideds to use, say, SLIM, but wants to otherwise use the distro kernel. James, relax, I'm done arguing against your patch, I just think end-users/customers might complain. -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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 09:19:56AM -0400, James Morris wrote: Is my understanding correct? You're shipping this to customers as a security feature? It's the usual Tivoli crap, what would you expect? - 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 09:19:56AM -0400, James Morris wrote: On Thu, 19 Jul 2007, James Morris wrote: On Thu, 19 Jul 2007, Jim Kovaric wrote: IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a loadable module, which is an out of tree module, and registers itself as a security module during the TAMOS startup process. It also requires that SElinux be disabled Please provide a link to the source code, so we can understand how you're using the API. I think I've found it: ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6.0.0/6.0.0-TIV-PDO-FP0007/6.0.0-TIV-PDO-Linux.i386-FP0007.tar Is that correct? If so, that code seems to have been run through a code obfuscator and as such, is not abiding by the GPL. Can IBM please post the real code as the GPL requires? Jim, if you are not the person to make this request too, can you point me at the correct person? thanks, greg 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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 08:37:27AM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Thu, 19 Jul 2007, Serge E. Hallyn wrote: It's already pretty clear. I doubt anyone not on lkml or linux-security-module has heard of this. So we'll see. (I was, obviously, talking about end-users) If distributions are shipping binary modules and other out of tree code to their users, then they should bear responsibility for supporting and maintaining the infrastructure required for it, and not expect upstream maintainers to do it for them. Additionally, if they want to expose their users to risks arising from broken and unecessary infrastructure, then they should bear the cost and responsibility of doing that and not expect others to do so as well. I don't see how this is even slightly difficult to understand. I'm not talking about distros - I don't see how this is even slightly difficult to understand :) The situation I have in mind is someone who decideds to use, say, SLIM, but wants to otherwise use the distro kernel. ... AFAIR this does anyway not work because at least the version of SLIM that once was in -mm required some patching of the kernel. -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 #3] security: Convert LSM into a static interface
Right, the ability to boot with security.capability=disabpled (or whatever) and then load a custom module without having to use a whole new kernel is something I'm sure end-users want. Especially since compiling a kernel which works with, say, a default fedora install, with lvm etc, is not imo for a novice (where novice != security novice). the next step after this patch is to have an option to get rid of all the function pointer chasing (which is expensive) for the case where you know you only want one security module (which you then can turn on or off)... that advantage is a performance gain for a lot of people but if the person configuring the kernel selects this, it does mean there's no way to load modules. I don't know what Fedora will do, but they might select such an option. That's CHOICE... they chose a performance improvement over enabling external kernel modules that they don't ship anyway... but is it really worth blocking such clear improvements in performance? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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 #3] security: Convert LSM into a static interface
Quoting Arjan van de Ven ([EMAIL PROTECTED]): Right, the ability to boot with security.capability=disabpled (or whatever) and then load a custom module without having to use a whole new kernel is something I'm sure end-users want. Especially since compiling a kernel which works with, say, a default fedora install, with lvm etc, is not imo for a novice (where novice != security novice). the next step after this patch is to have an option to get rid of all the function pointer chasing (which is expensive) for the case where you know you only want one security module (which you then can turn on or off)... that advantage is a performance gain for a lot of people but if the person configuring the kernel selects this, it does mean there's no way to load modules. I don't know what Fedora will do, but they might select such an option. That's CHOICE... War is peace Freedom is slavery Ignorance is strength -1984 :) Actually, given that when lsm was being introduced, lsm seemed to improve performance overall, have you taken any measurements to show that this is actually the case? Of course it makes sense that it would, but witjout measurements we do not know. they chose a performance improvement over enabling external kernel modules that they don't ship anyway... but is it really worth blocking such clear improvements in performance? I'm blocking nothing. In fact I concede that this patch might force any out of tree module authors to come to the table, which is a good thing. -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 #3] security: Convert LSM into a static interface
On Thu, Jul 19, 2007 at 09:54:30AM -0700, Arjan van de Ven wrote: the next step after this patch is to have an option to get rid of all the function pointer chasing (which is expensive) for the case where you know you only want one security module (which you then can turn on or off)... that advantage is a performance gain for a lot of people I'm pretty sure that at least the security_ops function pointers could be resolved statically with some proprocessor trickery right now. E.g. define macros for the security_* hooks in the single security module that is configured statically and include those defines in security.h instead of the prototypes for the inline functions. Am I missing something? If a distribution enables such an option there is no way to load a security module, true. This is what we have right now if the distro disables loadable module support or disables security modules. regards Christian signature.asc Description: Digital signature
Re: [PATCH try #3] security: Convert LSM into a static interface
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: Actually, given that when lsm was being introduced, lsm seemed to improve performance overall, have you taken any measurements to show that this is actually the case? Of course it makes sense that it would, but witjout measurements we do not know. Yes, it does. I have measured it as have others (esp. after Kurt Garloff pointed out issues on ia64). thanks, -chris - 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 #3] security: Convert LSM into a static interface
:) Actually, given that when lsm was being introduced, lsm seemed to improve performance overall, have you taken any measurements to show that this is actually the case? Of course it makes sense that it would, but witjout measurements we do not know. SuSE did a bunch of measurement I think a year ago and they showed a several percent performance increase with a hack similar to the proposed next step.. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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 #3] security: Convert LSM into a static interface
Quoting Arjan van de Ven ([EMAIL PROTECTED]): :) Actually, given that when lsm was being introduced, lsm seemed to improve performance overall, have you taken any measurements to show that this is actually the case? Of course it makes sense that it would, but witjout measurements we do not know. SuSE did a bunch of measurement I think a year ago and they showed a several percent performance increase with a hack similar to the proposed next step.. Very good. -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 #3] security: Convert LSM into a static interface
On Wed, 18 Jul 2007, James Morris wrote: On Wed, 18 Jul 2007, Andrew Morton wrote: The SECURITY_FRAMEWORK_VERSION macro has also been removed. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. Because I prefer my flamewars pre- rather than post-merge. This was already discussed and resolved during previous postings of the patch. In a nutshell, there is no safe way to unload an LSM. The modular interface is thus unecessary and broken infrastructure. It is used only by out-of-tree modules, which are often binary-only, illegal, abusive of the API and dangerous, e.g. silently re-vectoring SELinux. there's a difference between 'often' and 'always'. I really don't think you want to start that sort of argument (after all, would you like it if the MPAA argued "dvd burners are often used to make pirate copies, let's make it so that they won't burn anything without being given a special key"?) and arguing that the LSM is only used by out-of-tree modules and then strenuously opposing mergeing of such modules means that one of your arguments is bogus David Lang Chris has already agreed to take the patch: http://lkml.org/lkml/2007/6/24/152 aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. GregKH-esque :-) Here you go.. Thanks. - 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 #3] security: Convert LSM into a static interface
On Wed, 18 Jul 2007, Andrew Morton wrote: > > The SECURITY_FRAMEWORK_VERSION macro has also been removed. > > I'd like to understand who is (or claims to be) adversely affected by this > change, and what their complaints (if any) will be. > > Because I prefer my flamewars pre- rather than post-merge. This was already discussed and resolved during previous postings of the patch. In a nutshell, there is no safe way to unload an LSM. The modular interface is thus unecessary and broken infrastructure. It is used only by out-of-tree modules, which are often binary-only, illegal, abusive of the API and dangerous, e.g. silently re-vectoring SELinux. Chris has already agreed to take the patch: http://lkml.org/lkml/2007/6/24/152 > aww man, you passed over an opportunity to fix vast amounts of coding style > cruftiness. GregKH-esque :-) > > > Here you go.. Thanks. -- 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 #3] security: Convert LSM into a static interface
On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris <[EMAIL PROTECTED]> 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. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. Because I prefer my flamewars pre- rather than post-merge. > +int security_ptrace (struct task_struct * parent, struct task_struct * > child); > +int security_capget (struct task_struct *target, > + kernel_cap_t *effective, > + kernel_cap_t *inheritable, > + kernel_cap_t *permitted); > +int security_capset_check (struct task_struct *target, > +kernel_cap_t *effective, > +kernel_cap_t *inheritable, > +kernel_cap_t *permitted); > +void security_capset_set (struct task_struct *target, > + kernel_cap_t *effective, > + kernel_cap_t *inheritable, > + kernel_cap_t *permitted); > +int security_capable(struct task_struct *tsk, int cap); > +int security_acct (struct file *file); > aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. Here you go.. include/linux/security.h | 252 +- security/security.c | 504 ++--- 2 files changed, 378 insertions(+), 378 deletions(-) diff -puN include/linux/security.h~security-convert-lsm-into-a-static-interface-fix include/linux/security.h --- a/include/linux/security.h~security-convert-lsm-into-a-static-interface-fix +++ a/include/linux/security.h @@ -1414,151 +1414,151 @@ extern void securityfs_remove(struct den /* Security operations */ -int security_ptrace (struct task_struct * parent, struct task_struct * child); -int security_capget (struct task_struct *target, +int security_ptrace(struct task_struct *parent, struct task_struct *child); +int security_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); -int security_capset_check (struct task_struct *target, +int security_capset_check(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); -void security_capset_set (struct task_struct *target, +void security_capset_set(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); int security_capable(struct task_struct *tsk, int cap); -int security_acct (struct file *file); +int security_acct(struct file *file); int security_sysctl(struct ctl_table *table, int op); -int security_quotactl (int cmds, int type, int id, struct super_block *sb); -int security_quota_on (struct dentry * dentry); +int security_quotactl(int cmds, int type, int id, struct super_block *sb); +int security_quota_on(struct dentry *dentry); int security_syslog(int type); int security_settime(struct timespec *ts, struct timezone *tz); int security_vm_enough_memory(long pages); -int security_bprm_alloc (struct linux_binprm *bprm); -void security_bprm_free (struct linux_binprm *bprm); -void security_bprm_apply_creds (struct linux_binprm *bprm, int unsafe); -void security_bprm_post_apply_creds (struct linux_binprm *bprm); -int security_bprm_set (struct linux_binprm *bprm); -int security_bprm_check (struct linux_binprm *bprm); -int security_bprm_secureexec (struct linux_binprm *bprm); -int security_sb_alloc (struct super_block *sb); -void security_sb_free (struct super_block *sb); -int security_sb_copy_data (struct file_system_type *type, void *orig, void *copy); -int security_sb_kern_mount (struct super_block *sb, void *data); -int security_sb_statfs (struct dentry *dentry); -int security_sb_mount (char *dev_name, struct nameidata *nd, +int security_bprm_alloc(struct linux_binprm *bprm); +void security_bprm_free(struct linux_binprm *bprm); +void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe); +void security_bprm_post_apply_creds(struct linux_binprm *bprm); +int security_bprm_set(struct linux_binprm *bprm); +int security_bprm_check(struct linux_binprm *bprm); +int security_bprm_secureexec(struct linux_binprm *bprm); +int security_sb_alloc(struct super_block *sb); +void security_sb_free(struct super_block *sb); +int security_sb_copy_data(struct file_system_type *type, void *orig, void *copy); +int
Re: [PATCH try #3] security: Convert LSM into a static interface
On Sat, 2007-07-14 at 12:37 -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]> This is a good cleanup since modular LSM modules just aren't working, and prepares for the option of removing the runtime overhead of LSM altogether for selected configs... that is going to be a big step forward to make SELinux and any other model be more acceptable for people who care about performance. Acked-by: Arjan van de Ven <[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 #3] security: Convert LSM into a static interface
On Sat, 2007-07-14 at 12:37 -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] This is a good cleanup since modular LSM modules just aren't working, and prepares for the option of removing the runtime overhead of LSM altogether for selected configs... that is going to be a big step forward to make SELinux and any other model be more acceptable for people who care about performance. Acked-by: Arjan van de Ven [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 #3] security: Convert LSM into a static interface
On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] 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. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. Because I prefer my flamewars pre- rather than post-merge. +int security_ptrace (struct task_struct * parent, struct task_struct * child); +int security_capget (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted); +int security_capset_check (struct task_struct *target, +kernel_cap_t *effective, +kernel_cap_t *inheritable, +kernel_cap_t *permitted); +void security_capset_set (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted); +int security_capable(struct task_struct *tsk, int cap); +int security_acct (struct file *file); aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. does whizzy things Here you go.. include/linux/security.h | 252 +- security/security.c | 504 ++--- 2 files changed, 378 insertions(+), 378 deletions(-) diff -puN include/linux/security.h~security-convert-lsm-into-a-static-interface-fix include/linux/security.h --- a/include/linux/security.h~security-convert-lsm-into-a-static-interface-fix +++ a/include/linux/security.h @@ -1414,151 +1414,151 @@ extern void securityfs_remove(struct den /* Security operations */ -int security_ptrace (struct task_struct * parent, struct task_struct * child); -int security_capget (struct task_struct *target, +int security_ptrace(struct task_struct *parent, struct task_struct *child); +int security_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); -int security_capset_check (struct task_struct *target, +int security_capset_check(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); -void security_capset_set (struct task_struct *target, +void security_capset_set(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); int security_capable(struct task_struct *tsk, int cap); -int security_acct (struct file *file); +int security_acct(struct file *file); int security_sysctl(struct ctl_table *table, int op); -int security_quotactl (int cmds, int type, int id, struct super_block *sb); -int security_quota_on (struct dentry * dentry); +int security_quotactl(int cmds, int type, int id, struct super_block *sb); +int security_quota_on(struct dentry *dentry); int security_syslog(int type); int security_settime(struct timespec *ts, struct timezone *tz); int security_vm_enough_memory(long pages); -int security_bprm_alloc (struct linux_binprm *bprm); -void security_bprm_free (struct linux_binprm *bprm); -void security_bprm_apply_creds (struct linux_binprm *bprm, int unsafe); -void security_bprm_post_apply_creds (struct linux_binprm *bprm); -int security_bprm_set (struct linux_binprm *bprm); -int security_bprm_check (struct linux_binprm *bprm); -int security_bprm_secureexec (struct linux_binprm *bprm); -int security_sb_alloc (struct super_block *sb); -void security_sb_free (struct super_block *sb); -int security_sb_copy_data (struct file_system_type *type, void *orig, void *copy); -int security_sb_kern_mount (struct super_block *sb, void *data); -int security_sb_statfs (struct dentry *dentry); -int security_sb_mount (char *dev_name, struct nameidata *nd, +int security_bprm_alloc(struct linux_binprm *bprm); +void security_bprm_free(struct linux_binprm *bprm); +void security_bprm_apply_creds(struct linux_binprm *bprm, int unsafe); +void security_bprm_post_apply_creds(struct linux_binprm *bprm); +int security_bprm_set(struct linux_binprm *bprm); +int security_bprm_check(struct linux_binprm *bprm); +int security_bprm_secureexec(struct linux_binprm *bprm); +int security_sb_alloc(struct super_block *sb); +void security_sb_free(struct super_block *sb); +int security_sb_copy_data(struct file_system_type *type, void *orig, void *copy); +int
Re: [PATCH try #3] security: Convert LSM into a static interface
On Wed, 18 Jul 2007, Andrew Morton wrote: The SECURITY_FRAMEWORK_VERSION macro has also been removed. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. Because I prefer my flamewars pre- rather than post-merge. This was already discussed and resolved during previous postings of the patch. In a nutshell, there is no safe way to unload an LSM. The modular interface is thus unecessary and broken infrastructure. It is used only by out-of-tree modules, which are often binary-only, illegal, abusive of the API and dangerous, e.g. silently re-vectoring SELinux. Chris has already agreed to take the patch: http://lkml.org/lkml/2007/6/24/152 aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. GregKH-esque :-) does whizzy things Here you go.. Thanks. -- 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 #3] security: Convert LSM into a static interface
On Wed, 18 Jul 2007, James Morris wrote: On Wed, 18 Jul 2007, Andrew Morton wrote: The SECURITY_FRAMEWORK_VERSION macro has also been removed. I'd like to understand who is (or claims to be) adversely affected by this change, and what their complaints (if any) will be. Because I prefer my flamewars pre- rather than post-merge. This was already discussed and resolved during previous postings of the patch. In a nutshell, there is no safe way to unload an LSM. The modular interface is thus unecessary and broken infrastructure. It is used only by out-of-tree modules, which are often binary-only, illegal, abusive of the API and dangerous, e.g. silently re-vectoring SELinux. there's a difference between 'often' and 'always'. I really don't think you want to start that sort of argument (after all, would you like it if the MPAA argued dvd burners are often used to make pirate copies, let's make it so that they won't burn anything without being given a special key?) and arguing that the LSM is only used by out-of-tree modules and then strenuously opposing mergeing of such modules means that one of your arguments is bogus David Lang Chris has already agreed to take the patch: http://lkml.org/lkml/2007/6/24/152 aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. GregKH-esque :-) does whizzy things Here you go.. Thanks. - 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 #3] security: Convert LSM into a static interface
In article <[EMAIL PROTECTED]> you 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]> NAK. First, such an interface should be obsoleted by first making an entry to Documentation/feature-removal-schedule.txt and waiting for some months. Second, security modules that cannot be loaded/unloaded can just marked so and the LSM interface kept as-is. You are aware of the out of tree users, like AppArmor and other security modules and there are also several antivirus modules like dazuko, mcafee (got riddance for the latter, but in general) using LSM. Ciao, Marcus - 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 #3] security: Convert LSM into a static interface
In article [EMAIL PROTECTED] you 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] NAK. First, such an interface should be obsoleted by first making an entry to Documentation/feature-removal-schedule.txt and waiting for some months. Second, security modules that cannot be loaded/unloaded can just marked so and the LSM interface kept as-is. You are aware of the out of tree users, like AppArmor and other security modules and there are also several antivirus modules like dazuko, mcafee (got riddance for the latter, but in general) using LSM. Ciao, Marcus - 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/
