Re: LSM conversion to static interface
Jan Engelhardt <[EMAIL PROTECTED]> writes: > Which reminded me of the TuxGuardian LSM[1] - another of the real-world > uses to meet Linus's criteria? ("had examples of their real-world use to > step forward and explain their use") > > In this specific project, LSM is used to collect up calls to bind() and > connect() and pass them to userspace, e.g. do it ZoneAlarm-style and > display a dialog window. Its codebase is probably not too up-to-date > (website says last change last April - but I guess that's a no-brainer > to update it). > > [1] http://tuxguardian.sf.net/ It's not exactly true, tuxguardian is only dealing with .socket_create and .socket_listen from the struct security_operations, and not socket_bind I have done some work in this area since last year, and mailed the netdev list about it. [1] the project is 'network events connector' [2]. It's using the LSM hooks to get interesting informations from syscalls, to push them to userpace. So differences between projects will be on features and the code itself. Before getting a more infos on the project, as a 'LSM user', my main concern is not that we can unload/load dynamically the security modules, or have to reboot to do that. I don't have any point on this. My point is more that the 'user' have to be able to choose which system is better for him, and by 'user' we can hear linux distros. If security's modules don't do the same thing, we have to accept to have multiple modules, ie for example 'the 'network event connector' as a personnal firewall, and why not another security module for checking filesystem. Whitout this approach, tools like mine are pointless for linux distros, because there are already working on SELinux, Appamor, etc.. Not thinking this, is to think that on day, we will have the perfect and standard security module, but this won't happen, because users don't want the same thing: "I only want a personnal firewall at first place, and not a entire role based model". Now here is more infos on the project, so if not interested so you can escape now :) A/ for features: 1/ more hooks static struct security_operations snet_security_ops = { .socket_create = snet_socket_create, .socket_bind= snet_socket_bind, .socket_connect = snet_socket_connect, .socket_listen = snet_socket_listen, .socket_accept = snet_socket_accept, .socket_post_accept = snet_socket_post_accept, .socket_sendmsg = snet_socket_sendmsg, .socket_recvmsg = snet_socket_recvmsg, .socket_sock_rcv_skb= snet_socket_sock_rcv_skb, }; 2/ global control the main idea behind tuxguardian is preventing rootkit applications to execute listen(), so it's warning userspace. This is really interesting, but I think we can do more than just that. We can allow in a simple/dynamical way such iptables rules : iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 --syn -m state --state NEW -j ACCEPT just by detecting the sys_listen() call which has been execute by sshd, and for example only by /usr/bin/sshd (path name based) or 'sshd' role group (ie SELinux approach), and let packets coming from the network for this socket to bypass the firewall (of course the user/admin is controlling it from the userspace). But we also can control the sys_connect() dynamically from userspace for example, and prevent application using connect(), regarding the destination IP address/port, protocol, uid, application (and why not time, etc). The main problem and interesting part is the sys_accept(), because only the LSM hook socket_accept can make the syscall failling. But what could be interesting is to block/accept the syscall regarding the remote socket informations (ie which IP address is connecting ?). And this approch is not possible with the socket_accept hook (it comes too early) Tomoyo tried to solve this by moving the security_socket_post_accept() before the fd_install() [3]. This is bad for at least two reasons: - this hook was historically not added for this kind of filtering [4] - we already have a netfilter tool to help us: libnetfilter_queue [5] The idea is to send informations about the sys_listen() syscall, so inform the userspace that a application is maybe waiting for packets, then using libnetfilter_queue, check packets that match the socket involved on the sys_listen(). If we have such packet, we can ask the user to accept or deny this packets. This approach don't require a modification in the LSM architecture, and it's better to use netfilter to deal with packets. B/ for the code itself: 1/ I'm moving the code from the netlink connector to use generic netlink/libnl. Tuxguardian is using sock_sendmsg/sock_recvmsg directly 2/ for receiving answers from userspace (I call that "verdict"), tuxguardian is using sock_recvmsg(), so there is no timeout. I'm using waitqueue and timers for each "events" sent and "verdict".
Re: LSM conversion to static interface
Jan Engelhardt [EMAIL PROTECTED] writes: Which reminded me of the TuxGuardian LSM[1] - another of the real-world uses to meet Linus's criteria? (had examples of their real-world use to step forward and explain their use) In this specific project, LSM is used to collect up calls to bind() and connect() and pass them to userspace, e.g. do it ZoneAlarm-style and display a dialog window. Its codebase is probably not too up-to-date (website says last change last April - but I guess that's a no-brainer to update it). [1] http://tuxguardian.sf.net/ It's not exactly true, tuxguardian is only dealing with .socket_create and .socket_listen from the struct security_operations, and not socket_bind I have done some work in this area since last year, and mailed the netdev list about it. [1] the project is 'network events connector' [2]. It's using the LSM hooks to get interesting informations from syscalls, to push them to userpace. So differences between projects will be on features and the code itself. Before getting a more infos on the project, as a 'LSM user', my main concern is not that we can unload/load dynamically the security modules, or have to reboot to do that. I don't have any point on this. My point is more that the 'user' have to be able to choose which system is better for him, and by 'user' we can hear linux distros. If security's modules don't do the same thing, we have to accept to have multiple modules, ie for example 'the 'network event connector' as a personnal firewall, and why not another security module for checking filesystem. Whitout this approach, tools like mine are pointless for linux distros, because there are already working on SELinux, Appamor, etc.. Not thinking this, is to think that on day, we will have the perfect and standard security module, but this won't happen, because users don't want the same thing: I only want a personnal firewall at first place, and not a entire role based model. Now here is more infos on the project, so if not interested so you can escape now :) A/ for features: 1/ more hooks static struct security_operations snet_security_ops = { .socket_create = snet_socket_create, .socket_bind= snet_socket_bind, .socket_connect = snet_socket_connect, .socket_listen = snet_socket_listen, .socket_accept = snet_socket_accept, .socket_post_accept = snet_socket_post_accept, .socket_sendmsg = snet_socket_sendmsg, .socket_recvmsg = snet_socket_recvmsg, .socket_sock_rcv_skb= snet_socket_sock_rcv_skb, }; 2/ global control the main idea behind tuxguardian is preventing rootkit applications to execute listen(), so it's warning userspace. This is really interesting, but I think we can do more than just that. We can allow in a simple/dynamical way such iptables rules : iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 --syn -m state --state NEW -j ACCEPT just by detecting the sys_listen() call which has been execute by sshd, and for example only by /usr/bin/sshd (path name based) or 'sshd' role group (ie SELinux approach), and let packets coming from the network for this socket to bypass the firewall (of course the user/admin is controlling it from the userspace). But we also can control the sys_connect() dynamically from userspace for example, and prevent application using connect(), regarding the destination IP address/port, protocol, uid, application (and why not time, etc). The main problem and interesting part is the sys_accept(), because only the LSM hook socket_accept can make the syscall failling. But what could be interesting is to block/accept the syscall regarding the remote socket informations (ie which IP address is connecting ?). And this approch is not possible with the socket_accept hook (it comes too early) Tomoyo tried to solve this by moving the security_socket_post_accept() before the fd_install() [3]. This is bad for at least two reasons: - this hook was historically not added for this kind of filtering [4] - we already have a netfilter tool to help us: libnetfilter_queue [5] The idea is to send informations about the sys_listen() syscall, so inform the userspace that a application is maybe waiting for packets, then using libnetfilter_queue, check packets that match the socket involved on the sys_listen(). If we have such packet, we can ask the user to accept or deny this packets. This approach don't require a modification in the LSM architecture, and it's better to use netfilter to deal with packets. B/ for the code itself: 1/ I'm moving the code from the netlink connector to use generic netlink/libnl. Tuxguardian is using sock_sendmsg/sock_recvmsg directly 2/ for receiving answers from userspace (I call that verdict), tuxguardian is using sock_recvmsg(), so there is no timeout. I'm using waitqueue and timers for each events sent and verdict. I'm calling a event the
Re: LSM conversion to static interface
As I read through LWN today, I noted the following comment, http://lwn.net/Articles/255832/ : Personally, I think it's absolutely essential to be able to build a kernel with dynamic LSM. Whether we like it or not, people do want to add in runtime loadable security modules for things like virus scanners, and until upstream offers these folks a viable alternative to LSM...well, they'll use it. Which reminded me of the TuxGuardian LSM[1] - another of the real-world uses to meet Linus's criteria? ("had examples of their real-world use to step forward and explain their use") In this specific project, LSM is used to collect up calls to bind() and connect() and pass them to userspace, e.g. do it ZoneAlarm-style and display a dialog window. Its codebase is probably not too up-to-date (website says last change last April - but I guess that's a no-brainer to update it). [1] http://tuxguardian.sf.net/ - 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: LSM conversion to static interface
On Tue, 23 Oct 2007 10:34:09 CDT, "Serge E. Hallyn" said: > And he will still be able to *run* the suid binary, but if cap_bound is > reduced he won't be able to use capabilities taken out of the bounding > set, multiadm loaded or not. I am willing to bet that there's still a *lot* of unaudited set[ug]id code out there that's vulnerable to the same sorts of attacks as the one that hit Sendmail a few back. As such, I have to agree with your original post of the patch that CAP_SYS_ADMIN should be required to lower the set, as there's just too much danger of an exploit if users can create their own reduced-set processes. I'm debating whether we should have a printk if we detect that a removed capability caused an -EPERM. Yes, it can be used to spam the logs. On the other hand, I as the sysadmin would like to know if it's happening. Looks like time for a sysctl or something pgpqCdr9MDnmX.pgp Description: PGP signature
Re: LSM conversion to static interface
On Tue, 23 Oct 2007 10:34:09 CDT, Serge E. Hallyn said: And he will still be able to *run* the suid binary, but if cap_bound is reduced he won't be able to use capabilities taken out of the bounding set, multiadm loaded or not. I am willing to bet that there's still a *lot* of unaudited set[ug]id code out there that's vulnerable to the same sorts of attacks as the one that hit Sendmail a few back. As such, I have to agree with your original post of the patch that CAP_SYS_ADMIN should be required to lower the set, as there's just too much danger of an exploit if users can create their own reduced-set processes. I'm debating whether we should have a printk if we detect that a removed capability caused an -EPERM. Yes, it can be used to spam the logs. On the other hand, I as the sysadmin would like to know if it's happening. Looks like time for a sysctl or something pgpqCdr9MDnmX.pgp Description: PGP signature
Re: LSM conversion to static interface
As I read through LWN today, I noted the following comment, http://lwn.net/Articles/255832/ : Personally, I think it's absolutely essential to be able to build a kernel with dynamic LSM. Whether we like it or not, people do want to add in runtime loadable security modules for things like virus scanners, and until upstream offers these folks a viable alternative to LSM...well, they'll use it. Which reminded me of the TuxGuardian LSM[1] - another of the real-world uses to meet Linus's criteria? (had examples of their real-world use to step forward and explain their use) In this specific project, LSM is used to collect up calls to bind() and connect() and pass them to userspace, e.g. do it ZoneAlarm-style and display a dialog window. Its codebase is probably not too up-to-date (website says last change last April - but I guess that's a no-brainer to update it). [1] http://tuxguardian.sf.net/ - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 17:31:28 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Chris Wright wrote: > > Yes, and I think we can still improve performance although I can't > > see anyway to help out the modular case, so I guess it will have to > > incur the hit that's always been there. > > Broaden the paravirt patching machinery? > so far I've something much simpler in mind, I have a first prototype and it shows code that is pretty much optimal on modern cpus. I hope to have something postable in a week or so - 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: LSM conversion to static interface
On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote: > * Some people are not comfortable building kernels from source. It > doesn't matter how easy *you* think it is, it is a significant > barrier to entry for a lot of people. Especially if their day job > is systems or security administration, and not kernel hacking. That's why I wrote a whole book about how to do just that. And it's free, print it out and give it to all your friends! www.kroah.com/lkn/ 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: LSM conversion to static interface [revert patch]
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: > Chris Wright wrote: > > Yes, and I think we can still improve performance although I can't see > > anyway to help out the modular case, so I guess it will have to incur > > the hit that's always been there. > > Broaden the paravirt patching machinery? Yup, that's essentially what we've been talking about. 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: LSM conversion to static interface [revert patch]
Chris Wright wrote: > Yes, and I think we can still improve performance although I can't see > anyway to help out the modular case, so I guess it will have to incur > the hit that's always been there. Broaden the paravirt patching machinery? J - 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: LSM conversion to static interface
On Sun, 21 Oct 2007, Greg KH wrote: > On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: > > As Sarbanes-Oxley and > > other regulatory laws require these customers to use "standard > > kernels", the result is a rather dreary form of vendor lock-in, where the > > security framework is coupled to the distribution. > > Wait, what? > > Since when does Sarbanes-Oxley decree that a company must use a > "standard kernel"? And just exactly what defines such "standard > kernel"? Can you point out where in that bill it requires such a thing? Simple, these days Sarbanes-Oxley is the default argument behind anything being pushed down your throat in a company. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds - 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: LSM conversion to static interface
On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote: > Greg KH wrote: >> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: >> >>> Yes, I think Crispin has succinctly summed it up: irrevocably closing >>> the LSM prevents commercial customers from using security modules other >>> than that provided by their Linux distributor. >>> >> >> Any "customer" using a security model other than provided by their Linux >> distributor instantly voided all support from that distro by doing that. >> >> So, since the support is gone, they can easily build their own kernels, >> with their own LSM interfaces, and get the exact same lack of support :) > > Running a vendor kernel has the advantage of reusing all the QA work that > has gone into that kernel. It is very different from running 2.6.24-rc1 > (or 2.6.22.x). Hence projects like centos: you don't get any support, but > the likelihood of actually requiring support is lower than running some > random kernel. You can also get the QA work by building your own kernel from vendor kernel sources. E.g. the Debian distribution ships a package linux-source-2.6.18 that contains a linux-source-2.6.18.tar.bz2 with the patched 2.6.18 kernel sources Debian uses for building its kernels. > [but I agree that someone who has somehow determined that they need a > specific LSM will probably have determined that they need vendor support as > well] 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: LSM conversion to static interface
Quoting Jan Engelhardt ([EMAIL PROTECTED]): > > On Oct 23 2007 10:20, Serge E. Hallyn wrote: > > > >Once the per-process capability bounding set is accepted > >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something > >like: > > > > 1. Create user 'jdoe' with uid 0 > > UID 0 is _not_ acceptable for me. I'm aware. > > 2. write a pam module which, when jdoe logs in, takes > >CAP_NET_ADMIN out of his capability bounding set > > 3. Now jdoe can log in with the kind of capabilities subset > >you describe. > > It is not that easy. > CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security > checks in kernel code, and then the detailed implementation of > limitation is done inside multiadm. You mean the read/write split? > This is not just raising or lowering capabilities. Nope, but it's related, and as I pointed out below it fits in pretty nicely. > >It's not a perfect solution, since it doesn't allow jdoe any way at all > >to directly execute a file with more caps (setuid and file capabilities > >are subject to the capbound). So there is certainly still a place for > >multiadm. > > A normal user can execute suid binaries today, and so can s/he with mtadm. > I do not see where that will change - it does not need any caps atm. And he will still be able to *run* the suid binary, but if cap_bound is reduced he won't be able to use capabilities taken out of the bounding set, multiadm loaded or not. -serge - 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: LSM conversion to static interface
On Oct 23 2007 10:20, Serge E. Hallyn wrote: > >Once the per-process capability bounding set is accepted >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something >like: > > 1. Create user 'jdoe' with uid 0 UID 0 is _not_ acceptable for me. > 2. write a pam module which, when jdoe logs in, takes > CAP_NET_ADMIN out of his capability bounding set > 3. Now jdoe can log in with the kind of capabilities subset > you describe. It is not that easy. CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security checks in kernel code, and then the detailed implementation of limitation is done inside multiadm. This is not just raising or lowering capabilities. >It's not a perfect solution, since it doesn't allow jdoe any way at all >to directly execute a file with more caps (setuid and file capabilities >are subject to the capbound). So there is certainly still a place for >multiadm. A normal user can execute suid binaries today, and so can s/he with mtadm. I do not see where that will change - it does not need any caps atm. - 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: LSM conversion to static interface
Quoting Jan Engelhardt ([EMAIL PROTECTED]): > > On Oct 23 2007 07:44, Giacomo Catenazzi wrote: > > > >> I do have a pseudo LSM called "multiadm" at > >> http://freshmeat.net/p/multiadm/ , quoting: > > > >> Policy is dead simple since it is based on UIDs. The UID ranges can be > >> set on module load time or during runtime (sysfs params). This LSM is > >> basically grants extra rights unlike most other LSMs[1], which is why > >> modprobe makes much more sense here. (It also does not have to do any > >> security labelling that would require it to be loaded at boot time > >> already.) > > > >But his is against LSM design (and first agreements about LSM): > >LSM can deny rights, but it should not give extra permissions > >or bypass standard unix permissions. > > It is just not feasible to add ACLs to all million files in /home, > also because ACLs are limited to around 25 entries. > And it is obvious I do not want to have UID 0, because > then you cannot distinguish who created what file. > So the requirement to the task is to have unique UIDs. > The next logical step would be to give capabilities to those UIDs. > > *Is that wrong*? Who says that only UID 0 is allowed to have > all 31 capability bits turned on, and that all non-UID 0 users > need to have all 31 capability bits turned off? > > So, we give caps to the subadmins (which is IMHO a natural task), > and then, as per LSM design (wonder where that is written) deny > some of the rights that the capabilities raised for subadmins grant, > because that is obviously too much. Once the per-process capability bounding set is accepted (http://lkml.org/lkml/2007/10/3/315) you will be able to do something like: 1. Create user 'jdoe' with uid 0 2. write a pam module which, when jdoe logs in, takes CAP_NET_ADMIN out of his capability bounding set 3. Now jdoe can log in with the kind of capabilities subset you describe. It's not a perfect solution, since it doesn't allow jdoe any way at all to directly execute a file with more caps (setuid and file capabilities are subject to the capbound). So there is certainly still a place for multiadm. -serge - 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: LSM conversion to static interface
On Mon, October 22, 2007 18:13, Greg KH wrote: > I agree, that is why customers do not load other random security modules > in their kernel today, and why they will not do so tomorrow. So, > because of that, this whole point about compliance with regulatory law > seems kind of moot :) > > Again, LSM isn't going away at all, this is just one config option for > allowing LSM to work as a module that is changing. If a customer > demands that this feature come back, I'm sure that the big distros will > be the first to push for it. But currently, given that there are no > known external LSMs being used by customers demanding support, I don't > see what the big issue here really is. I have an out of tree module to do per-port (tcp/udp) bind permissions, it works fine with the "capability" module as secondary and I can load or unload both of them at any time... this recent change completely breaks that. (I had to #include dummy.c though). Why should I now need to: 1. reboot every time I change the code when I could just reload modules before? 2. put it into my kernel source tree to use it? -- Simon Arlott - 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: LSM conversion to static interface
On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote: >> So, we give caps to the subadmins (which is IMHO a natural task), >> and then, as per LSM design (wonder where that is written) deny >> some of the rights that the capabilities raised for subadmins grant, >> because that is obviously too much. > > Nothing wrong. I only said that it was against (IIRC) the > principle of LSM in kernel (we should only remove capacities). Leave my capacitance alone! :) [i hope you get the joke] Anyway - I see your point. But what would give the user the capabilities in the first place, if not a security module that implements this-and-that capability-raising scheme? - 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: LSM conversion to static interface [revert patch]
On Oct 23 2007 02:13, Chris Wright wrote: >* Jan Engelhardt ([EMAIL PROTECTED]) wrote: >> On Oct 22 2007 22:16, Chris Wright wrote: >> >Yes, and I think we can still improve performance although I can't see >> >anyway to help out the modular case, so I guess it will have to incur >> >the hit that's always been there. I think your Kconfig option is a >> >decent compromise. >> >> (Un)registering security modules is a one-time hit. You do not load >> and unload modules on a per-minute basis outside debugging. > >I'm referring to the hit for indirect calls Indeed, I just seen that. Not too nice :( - 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: LSM conversion to static interface
Jan Engelhardt wrote: On Oct 23 2007 07:44, Giacomo Catenazzi wrote: I do have a pseudo LSM called "multiadm" at http://freshmeat.net/p/multiadm/ , quoting: Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. It is just not feasible to add ACLs to all million files in /home, also because ACLs are limited to around 25 entries. And it is obvious I do not want to have UID 0, because then you cannot distinguish who created what file. So the requirement to the task is to have unique UIDs. The next logical step would be to give capabilities to those UIDs. *Is that wrong*? Who says that only UID 0 is allowed to have all 31 capability bits turned on, and that all non-UID 0 users need to have all 31 capability bits turned off? So, we give caps to the subadmins (which is IMHO a natural task), and then, as per LSM design (wonder where that is written) deny some of the rights that the capabilities raised for subadmins grant, because that is obviously too much. Nothing wrong. I only said that it was against (IIRC) the principle of LSM in kernel (we should only remove capacities). I've nothing against the changing the design or rules. It was only a commentary, to be sure that we know what we do ;-) ciao cate - 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: LSM conversion to static interface [revert patch]
* Jan Engelhardt ([EMAIL PROTECTED]) wrote: > On Oct 22 2007 22:16, Chris Wright wrote: > >Yes, and I think we can still improve performance although I can't see > >anyway to help out the modular case, so I guess it will have to incur > >the hit that's always been there. I think your Kconfig option is a > >decent compromise. > > (Un)registering security modules is a one-time hit. You do not load > and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls - 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: LSM conversion to static interface
On Oct 21 2007 08:57, James Morris wrote: >> >I'd like to note that I asked people who were actually affected, and had >> >examples of their real-world use to step forward and explain their use, >> >and that I explicitly mentioned that this is something we can easily >> >re-visit. [...] I looked at commit 20510f2f4e2dabb0ff6c13901807627ec9452f98 [havenot done much kernel activity recently] where you transform the security interface, and what I see is that all the static inline functions are replaced by an extern one, with the same content. That actually seems to include more performance hit than the (un)registering fluff. Why is that, actually? - 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: LSM conversion to static interface [revert patch]
On Oct 22 2007 22:16, Chris Wright wrote: >> >> If it turns out that the above module becomes unmaintained and no >> longer usable, and no other useful cases show up, we can always >> garbage collect this code in the future; it's now low-overhead >> anyway for those who care, due to the KConfig option. > >Yes, and I think we can still improve performance although I can't see >anyway to help out the modular case, so I guess it will have to incur >the hit that's always been there. I think your Kconfig option is a >decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. - 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: LSM conversion to static interface
On Oct 23 2007 07:44, Giacomo Catenazzi wrote: > >> I do have a pseudo LSM called "multiadm" at >> http://freshmeat.net/p/multiadm/ , quoting: > >> Policy is dead simple since it is based on UIDs. The UID ranges can be >> set on module load time or during runtime (sysfs params). This LSM is >> basically grants extra rights unlike most other LSMs[1], which is why >> modprobe makes much more sense here. (It also does not have to do any >> security labelling that would require it to be loaded at boot time >> already.) > >But his is against LSM design (and first agreements about LSM): >LSM can deny rights, but it should not give extra permissions >or bypass standard unix permissions. It is just not feasible to add ACLs to all million files in /home, also because ACLs are limited to around 25 entries. And it is obvious I do not want to have UID 0, because then you cannot distinguish who created what file. So the requirement to the task is to have unique UIDs. The next logical step would be to give capabilities to those UIDs. *Is that wrong*? Who says that only UID 0 is allowed to have all 31 capability bits turned on, and that all non-UID 0 users need to have all 31 capability bits turned off? So, we give caps to the subadmins (which is IMHO a natural task), and then, as per LSM design (wonder where that is written) deny some of the rights that the capabilities raised for subadmins grant, because that is obviously too much. - 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: LSM conversion to static interface
Crispin Cowan wrote: Giacomo Catenazzi wrote: What do technical and regulatory differences have "driver/LSM module" that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. *I* understand that, from a security and logic integrity point of view, there is not much difference between a rebuilt-from-source kernel, and a standard kernel from the distro with a new module loaded. However, there is a big difference for other people, depending on their circumstances. * Some people live in organizations where the stock kernel is required, even if you are allowed to load modules. That may not make sense to you, but that doesn't change the rule. [read also the very last commentary: don't take to seriously my arguments] ok, but why simplifying life of company with such silly rule? Are not the same people that required commercial UNIX kernel? So don't worry about internal company rules. In one year a lot of things changes. Anyway it is a good motivation to delay the conversion, if there are really so many external LSM modules used in production environment. (but see next point) * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. Configuring a new kernel is not "kernel hacking" and IIRC is considered in the very first level of LPI. Anyway where you will find the new module? It should be very specific on the actual kernel installed. I find few differences to distribute a module or a kernel. Distributions have/had a lot of kernels (versions, SMP, processor specific, vserver, xen, readhat, clusteres, ...), so why not distribute a new kernel? > Think of it like device drivers: Linux would be an enterprise > failure if you had to re-compile the kernel from source every > time you added a new kind of device and device driver. This is a frequent argument, but I don't believe it ;-) I see more time this argument that new devices on an enterprise. The real argument is: : Think of it like device drivers: Linux would be an enterprise : failure if you had to *compile* the kernel from source for : *every machine*. Which is a good point to have modules. Is it still a good point to have LSM modules? And to obey the "Sarbanes-Oxley" Don't take me wrong, the above commentaries are not so serious, and my point was not about modules, but why "Sarbanes-Oxley" tell us that new modules are simpler then new kernel. I like kernel without modules, so I want to understand all motivations why people need modules (and this thread showed me other (non-classical) reasons). I know that the modules are necessary in most situation, but I like to see if some reasons can be solved in other ways, so to simplify also the life of "build-in" peoples. ciao cate - 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: LSM conversion to static interface
Giacomo Catenazzi wrote: > What do technical and regulatory differences have "driver/LSM module" that > is build-in and one that is modular? > It seems to me silly to find difference. A kernel with a new kernel module > is a new kernel. > *I* understand that, from a security and logic integrity point of view, there is not much difference between a rebuilt-from-source kernel, and a standard kernel from the distro with a new module loaded. However, there is a big difference for other people, depending on their circumstances. * Some people live in organizations where the stock kernel is required, even if you are allowed to load modules. That may not make sense to you, but that doesn't change the rule. * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. Think of it like device drivers: Linux would be an enterprise failure if you had to re-compile the kernel from source every time you added a new kind of device and device driver. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
Giacomo Catenazzi wrote: What do technical and regulatory differences have driver/LSM module that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. *I* understand that, from a security and logic integrity point of view, there is not much difference between a rebuilt-from-source kernel, and a standard kernel from the distro with a new module loaded. However, there is a big difference for other people, depending on their circumstances. * Some people live in organizations where the stock kernel is required, even if you are allowed to load modules. That may not make sense to you, but that doesn't change the rule. * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. Think of it like device drivers: Linux would be an enterprise failure if you had to re-compile the kernel from source every time you added a new kind of device and device driver. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
Crispin Cowan wrote: Giacomo Catenazzi wrote: What do technical and regulatory differences have driver/LSM module that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. *I* understand that, from a security and logic integrity point of view, there is not much difference between a rebuilt-from-source kernel, and a standard kernel from the distro with a new module loaded. However, there is a big difference for other people, depending on their circumstances. * Some people live in organizations where the stock kernel is required, even if you are allowed to load modules. That may not make sense to you, but that doesn't change the rule. [read also the very last commentary: don't take to seriously my arguments] ok, but why simplifying life of company with such silly rule? Are not the same people that required commercial UNIX kernel? So don't worry about internal company rules. In one year a lot of things changes. Anyway it is a good motivation to delay the conversion, if there are really so many external LSM modules used in production environment. (but see next point) * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. Configuring a new kernel is not kernel hacking and IIRC is considered in the very first level of LPI. Anyway where you will find the new module? It should be very specific on the actual kernel installed. I find few differences to distribute a module or a kernel. Distributions have/had a lot of kernels (versions, SMP, processor specific, vserver, xen, readhat, clusteres, ...), so why not distribute a new kernel? Think of it like device drivers: Linux would be an enterprise failure if you had to re-compile the kernel from source every time you added a new kind of device and device driver. This is a frequent argument, but I don't believe it ;-) I see more time this argument that new devices on an enterprise. The real argument is: : Think of it like device drivers: Linux would be an enterprise : failure if you had to *compile* the kernel from source for : *every machine*. Which is a good point to have modules. Is it still a good point to have LSM modules? And to obey the Sarbanes-Oxley Don't take me wrong, the above commentaries are not so serious, and my point was not about modules, but why Sarbanes-Oxley tell us that new modules are simpler then new kernel. I like kernel without modules, so I want to understand all motivations why people need modules (and this thread showed me other (non-classical) reasons). I know that the modules are necessary in most situation, but I like to see if some reasons can be solved in other ways, so to simplify also the life of build-in peoples. ciao cate - 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: LSM conversion to static interface
On Oct 23 2007 07:44, Giacomo Catenazzi wrote: I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. It is just not feasible to add ACLs to all million files in /home, also because ACLs are limited to around 25 entries. And it is obvious I do not want prof to have UID 0, because then you cannot distinguish who created what file. So the requirement to the task is to have unique UIDs. The next logical step would be to give capabilities to those UIDs. *Is that wrong*? Who says that only UID 0 is allowed to have all 31 capability bits turned on, and that all non-UID 0 users need to have all 31 capability bits turned off? So, we give caps to the subadmins (which is IMHO a natural task), and then, as per LSM design (wonder where that is written) deny some of the rights that the capabilities raised for subadmins grant, because that is obviously too much. - 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: LSM conversion to static interface [revert patch]
On Oct 22 2007 22:16, Chris Wright wrote: If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. - 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: LSM conversion to static interface [revert patch]
* Jan Engelhardt ([EMAIL PROTECTED]) wrote: On Oct 22 2007 22:16, Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls - 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: LSM conversion to static interface
On Oct 21 2007 08:57, James Morris wrote: I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. [...] I looked at commit 20510f2f4e2dabb0ff6c13901807627ec9452f98 [havenot done much kernel activity recently] where you transform the security interface, and what I see is that all the static inline functions are replaced by an extern one, with the same content. That actually seems to include more performance hit than the (un)registering fluff. Why is that, actually? - 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: LSM conversion to static interface [revert patch]
On Oct 23 2007 02:13, Chris Wright wrote: * Jan Engelhardt ([EMAIL PROTECTED]) wrote: On Oct 22 2007 22:16, Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. (Un)registering security modules is a one-time hit. You do not load and unload modules on a per-minute basis outside debugging. I'm referring to the hit for indirect calls Indeed, I just seen that. Not too nice :( - 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: LSM conversion to static interface
Jan Engelhardt wrote: On Oct 23 2007 07:44, Giacomo Catenazzi wrote: I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. It is just not feasible to add ACLs to all million files in /home, also because ACLs are limited to around 25 entries. And it is obvious I do not want prof to have UID 0, because then you cannot distinguish who created what file. So the requirement to the task is to have unique UIDs. The next logical step would be to give capabilities to those UIDs. *Is that wrong*? Who says that only UID 0 is allowed to have all 31 capability bits turned on, and that all non-UID 0 users need to have all 31 capability bits turned off? So, we give caps to the subadmins (which is IMHO a natural task), and then, as per LSM design (wonder where that is written) deny some of the rights that the capabilities raised for subadmins grant, because that is obviously too much. Nothing wrong. I only said that it was against (IIRC) the principle of LSM in kernel (we should only remove capacities). I've nothing against the changing the design or rules. It was only a commentary, to be sure that we know what we do ;-) ciao cate - 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: LSM conversion to static interface
On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote: So, we give caps to the subadmins (which is IMHO a natural task), and then, as per LSM design (wonder where that is written) deny some of the rights that the capabilities raised for subadmins grant, because that is obviously too much. Nothing wrong. I only said that it was against (IIRC) the principle of LSM in kernel (we should only remove capacities). Leave my capacitance alone! :) [i hope you get the joke] Anyway - I see your point. But what would give the user the capabilities in the first place, if not a security module that implements this-and-that capability-raising scheme? - 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: LSM conversion to static interface
On Mon, October 22, 2007 18:13, Greg KH wrote: I agree, that is why customers do not load other random security modules in their kernel today, and why they will not do so tomorrow. So, because of that, this whole point about compliance with regulatory law seems kind of moot :) Again, LSM isn't going away at all, this is just one config option for allowing LSM to work as a module that is changing. If a customer demands that this feature come back, I'm sure that the big distros will be the first to push for it. But currently, given that there are no known external LSMs being used by customers demanding support, I don't see what the big issue here really is. I have an out of tree module to do per-port (tcp/udp) bind permissions, it works fine with the capability module as secondary and I can load or unload both of them at any time... this recent change completely breaks that. (I had to #include dummy.c though). Why should I now need to: 1. reboot every time I change the code when I could just reload modules before? 2. put it into my kernel source tree to use it? -- Simon Arlott - 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: LSM conversion to static interface
Quoting Jan Engelhardt ([EMAIL PROTECTED]): On Oct 23 2007 07:44, Giacomo Catenazzi wrote: I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. It is just not feasible to add ACLs to all million files in /home, also because ACLs are limited to around 25 entries. And it is obvious I do not want prof to have UID 0, because then you cannot distinguish who created what file. So the requirement to the task is to have unique UIDs. The next logical step would be to give capabilities to those UIDs. *Is that wrong*? Who says that only UID 0 is allowed to have all 31 capability bits turned on, and that all non-UID 0 users need to have all 31 capability bits turned off? So, we give caps to the subadmins (which is IMHO a natural task), and then, as per LSM design (wonder where that is written) deny some of the rights that the capabilities raised for subadmins grant, because that is obviously too much. Once the per-process capability bounding set is accepted (http://lkml.org/lkml/2007/10/3/315) you will be able to do something like: 1. Create user 'jdoe' with uid 0 2. write a pam module which, when jdoe logs in, takes CAP_NET_ADMIN out of his capability bounding set 3. Now jdoe can log in with the kind of capabilities subset you describe. It's not a perfect solution, since it doesn't allow jdoe any way at all to directly execute a file with more caps (setuid and file capabilities are subject to the capbound). So there is certainly still a place for multiadm. -serge - 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: LSM conversion to static interface
On Oct 23 2007 10:20, Serge E. Hallyn wrote: Once the per-process capability bounding set is accepted (http://lkml.org/lkml/2007/10/3/315) you will be able to do something like: 1. Create user 'jdoe' with uid 0 UID 0 is _not_ acceptable for me. 2. write a pam module which, when jdoe logs in, takes CAP_NET_ADMIN out of his capability bounding set 3. Now jdoe can log in with the kind of capabilities subset you describe. It is not that easy. CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security checks in kernel code, and then the detailed implementation of limitation is done inside multiadm. This is not just raising or lowering capabilities. It's not a perfect solution, since it doesn't allow jdoe any way at all to directly execute a file with more caps (setuid and file capabilities are subject to the capbound). So there is certainly still a place for multiadm. A normal user can execute suid binaries today, and so can s/he with mtadm. I do not see where that will change - it does not need any caps atm. - 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: LSM conversion to static interface
Quoting Jan Engelhardt ([EMAIL PROTECTED]): On Oct 23 2007 10:20, Serge E. Hallyn wrote: Once the per-process capability bounding set is accepted (http://lkml.org/lkml/2007/10/3/315) you will be able to do something like: 1. Create user 'jdoe' with uid 0 UID 0 is _not_ acceptable for me. I'm aware. 2. write a pam module which, when jdoe logs in, takes CAP_NET_ADMIN out of his capability bounding set 3. Now jdoe can log in with the kind of capabilities subset you describe. It is not that easy. CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security checks in kernel code, and then the detailed implementation of limitation is done inside multiadm. You mean the read/write split? This is not just raising or lowering capabilities. Nope, but it's related, and as I pointed out below it fits in pretty nicely. It's not a perfect solution, since it doesn't allow jdoe any way at all to directly execute a file with more caps (setuid and file capabilities are subject to the capbound). So there is certainly still a place for multiadm. A normal user can execute suid binaries today, and so can s/he with mtadm. I do not see where that will change - it does not need any caps atm. And he will still be able to *run* the suid binary, but if cap_bound is reduced he won't be able to use capabilities taken out of the bounding set, multiadm loaded or not. -serge - 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: LSM conversion to static interface
On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote: Greg KH wrote: On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. Any customer using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. So, since the support is gone, they can easily build their own kernels, with their own LSM interfaces, and get the exact same lack of support :) Running a vendor kernel has the advantage of reusing all the QA work that has gone into that kernel. It is very different from running 2.6.24-rc1 (or 2.6.22.x). Hence projects like centos: you don't get any support, but the likelihood of actually requiring support is lower than running some random kernel. You can also get the QA work by building your own kernel from vendor kernel sources. E.g. the Debian distribution ships a package linux-source-2.6.18 that contains a linux-source-2.6.18.tar.bz2 with the patched 2.6.18 kernel sources Debian uses for building its kernels. [but I agree that someone who has somehow determined that they need a specific LSM will probably have determined that they need vendor support as well] 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: LSM conversion to static interface
On Sun, 21 Oct 2007, Greg KH wrote: On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels, the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Wait, what? Since when does Sarbanes-Oxley decree that a company must use a standard kernel? And just exactly what defines such standard kernel? Can you point out where in that bill it requires such a thing? Simple, these days Sarbanes-Oxley is the default argument behind anything being pushed down your throat in a company. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds - 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: LSM conversion to static interface [revert patch]
Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. Broaden the paravirt patching machinery? J - 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: LSM conversion to static interface [revert patch]
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. Broaden the paravirt patching machinery? Yup, that's essentially what we've been talking about. 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: LSM conversion to static interface
On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote: * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. That's why I wrote a whole book about how to do just that. And it's free, print it out and give it to all your friends! www.kroah.com/lkn/ 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 17:31:28 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Chris Wright wrote: Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. Broaden the paravirt patching machinery? so far I've something much simpler in mind, I have a first prototype and it shows code that is pretty much optimal on modern cpus. I hope to have something postable in a week or so - 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: LSM conversion to static interface
Thomas Fricaccia wrote: > Some well-respected contributors have taken exception my amplification > of Crispin Cowan's point about the patch that closes LSM. > > Crispin Cowan <[EMAIL PROTECTED]> wrote: >> * It prevents enterprise users, and in fact anyone who isn't >> comfortable compiling their own kernel, from ever trying out any >> security module that their distro vendor of choice did not ship. > > I extended this point by observing that regulatory laws make it difficult > for enterprise customers to compile their own kernels, mentioning one > of the more invasive statutes, Sarbanes-Oxley. > > In reply, "Alan Cox" <[EMAIL PROTECTED]> writes: >> Crispin at least is providing genuine discussion points. Sarbox has >> nothing to say on "using vendor linux kernels". > > And just previously, "Greg KH" <[EMAIL PROTECTED]> had written: >> Since when does Sarbanes-Oxley decree that a company must use a >> "standard kernel"? And just exactly what defines such "standard >> kernel"? Can you point out where in that bill it requires such a >> thing? > > I was actually talking about the *effects* of regulatory law, rather > than the wording in the text of the statutes. The misunderstanding > could be partially my fault, as my exact words were > >As Sarbanes-Oxley and other regulatory laws require these >customers to use "standard kernels" > > which may not have been as unambiguously clear as I intended. > > But as long as we're here, let me elaborate on the point I tried to make. > > SOX and other laws require enterprise customers to keep specified > controls on their internal processing procedures, and keep documentation > that can be audited to prove compliance. The auditing requirements > are extensive and detailed, and certainly include the kernel of an > operating system used to process business and/or financial transactions. > > It is within this framework that enterprise customers conclude something > like (and this is vernacular, not the language within the statutes) "if > we use any kernel other than that supplied by our distributor, the > SOX auditing paperwork will be a nightmare." (I've actually heard > statements similar to this, and so believe that it is an accurate > portrayal of the perception of the effects of regulatory law. I'm not > a lawyer.) > > As I said at the beginning, I meant to amplify Crispin's observation > that enterprise customers are reluctant to compile their own kernels > with the additional observation that the complexities of regulatory > law create obstacles that are significant contributors to that reluctance. > > I'll not belabor the unfortunate non sequitur further. You can find > plenty of documentation of auditing requirements with by Googling > combinations of "Sarbanes-Oxley," "operating system integrity", etc. > This is a big-business topic of wide concern. What do technical and regulatory differences have "driver/LSM module" that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. ciao cate - 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: LSM conversion to static interface
Jan Engelhardt wrote: > I do have a pseudo LSM called "multiadm" at > http://freshmeat.net/p/multiadm/ , quoting: > Policy is dead simple since it is based on UIDs. The UID ranges can be > set on module load time or during runtime (sysfs params). This LSM is > basically grants extra rights unlike most other LSMs[1], which is why > modprobe makes much more sense here. (It also does not have to do any > security labelling that would require it to be loaded at boot time > already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. ciao cate - 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: LSM conversion to static interface
On Mon, 22 Oct 2007, Crispin Cowan wrote: Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. one reason to not be willing to rebuild the kernel is that they may rely on a module from a different third party that is shipped/tested for the specific pre-compiled kernels from the distro. David Lang - 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: LSM conversion to static interface [revert patch]
* Arjan van de Ven ([EMAIL PROTECTED]) wrote: > On Sun, 21 Oct 2007 08:57:06 +1000 (EST) > James Morris <[EMAIL PROTECTED]> wrote: > > > On Sat, 20 Oct 2007, Jan Engelhardt wrote: > > > > > >I'd like to note that I asked people who were actually affected, > > > >and had examples of their real-world use to step forward and > > > >explain their use, and that I explicitly mentioned that this is > > > >something we can easily re-visit. > > > > > > > > > > I do have a pseudo LSM called "multiadm" at > > > http://freshmeat.net/p/multiadm/ , quoting: > > > > > > > Based on Linus' criteria, this appears to be a case for reverting the > > static LSM patch. > > I don't want to argue for or against the actual revert; however if > Linus/James/Chris > decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. > (doing a full git revert is tricky since it gets mixed up with various other > cleanup > patches; even inside the original patch. I've done the relevant pieces by > hand via a > selective patch -R and compile-tested it). In addition I've made the > modularity a > Kconfig option, since it's clearly something that is contested and thus is > justified > as a user compile time choice; people who don't want this (out of paranoia or > otherwise) > can now decide to disable, while others who want to experiment or use out of > tree > LSM modules, can select the KConfig option. > > If it turns out that the above module becomes unmaintained and no longer > usable, and no > other useful cases show up, we can always garbage collect this code in the > future; it's > now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. thanks, -chris - 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: LSM conversion to static interface
Greg KH wrote: > On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: > >> Security is big business, as is compliance with regulatory law. Large >> enterprise customers are NOT going to either void their system support >> contracts, or place themselves in jeopardy of failing a SOX audit. >> > I agree, that is why customers do not load other random security modules > in their kernel today, That "random" module could be a module supplied by a vendor other than the distro supplier, such as a security vendor. It could be a research prototype that the user wants to try out on their enterprise-supported kernel. It could even be an in-house developed module that a local site wants to run on his larger organization's blessed kernel. So far from "random", these modules are motivated by circumstances radically different than yours. In particular, rebuilding a kernel for you (GregKH, many LKML developers) is a casual thing to be done before breakfast, but is a scary obstacle to many others. It is an obstacle to people who are skilled at computers but deliberately *not* kernel developers (the whole world does not need to be a Linux kernel developer) and it is an obstacle to large enterprise admins who have organizational pressure to use specific, pre-built kernels. > and why they will not do so tomorrow. So, > because of that, this whole point about compliance with regulatory law > seems kind of moot :) > I think the specific stuff about regulatory compliance is tangential. SarBox and friends don't specify Linux kernel versions, they are incredibly vague and subject to interpretation. But they are part of what drive organizations to have self-imposed rules about only running blessed kernel versions. Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. > Again, LSM isn't going away at all, this is just one config option for > allowing LSM to work as a module that is changing. If a customer > demands that this feature come back, I'm sure that the big distros will > be the first to push for it. But currently, given that there are no > known external LSMs being used by customers demanding support, I don't > see what the big issue here really is. > As I said, it is a medium issue, not a big one, which is why I didn't speak out before. I am opposed to this change because I see zero benefit to it, and a lot of down-side in loss of user choice. Because that is what this does: it does not help the kernel get better. It *definitely* does not help the kernel become more secure. It mostly just removes user's choice, by making it difficult to do things that some people don't approve of. As I've said, it doesn't hurt AppArmor, because 3 major distros ship it. But it will hurt user choice and innovation, by making anything not shipped by a distro more difficult to access. There is some performance gains to be had by doing something to the LSM interface. Certainly a configuration option that statically inlines all the hooks and points them at a compiled in module would yield some performance gain, but I don't know how much. But that raises 2 questions: 1. Was *performance* really the reason this patch was proposed? Or was it because James really did want the restrictive effect of preventing people from choosing after-market modules and dynamically unloading them if they want? I believe that James was well-intentioned in trying to block these actions because he believes them to be insecure, and he's right, they are insecure. However, these actions are also very practically useful in many circumstances. I disagree with the change because an individual LSM can block both such actions if you wish, so imposing it on all LSM modules is restricting choice unnecessarily. 2. Is the performance issue that this might address really big enough to bother fixing at all? Maybe, but I don't know. Again, I'm strictly opposed to the loss of flexibility until the performance issue is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 14:56:52 +1000 (EST) James Morris <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2007, Arjan van de Ven wrote: > > > @@ -4895,6 +4908,7 @@ static struct security_operations selinu > > .sem_semop =selinux_sem_semop, > > > > .register_security = > > selinux_register_security, > > + .unregister_security = > > selinux_unregister_security, > > .d_instantiate =selinux_d_instantiate, > > You also need to consider whether to allow capabilities to be built > as an unloadable module. If not, then we don't need this hook added > back into SELinux. Otherwise, if it is desired, you also need to > reinstate capability_exit and general modular bits for > security/capability.c. > this just allows 3d party replacements of capability like functions; there is no need/point to have the existing capability back as modular to be honest. - 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: LSM conversion to static interface [revert patch]
On Mon, 22 Oct 2007, Arjan van de Ven wrote: > @@ -4895,6 +4908,7 @@ static struct security_operations selinu > .sem_semop =selinux_sem_semop, > > .register_security =selinux_register_security, > + .unregister_security = selinux_unregister_security, > > .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. - James -- James Morris <[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: LSM conversion to static interface [revert patch]
On Sun, 21 Oct 2007 08:57:06 +1000 (EST) James Morris <[EMAIL PROTECTED]> wrote: > On Sat, 20 Oct 2007, Jan Engelhardt wrote: > > > >I'd like to note that I asked people who were actually affected, > > >and had examples of their real-world use to step forward and > > >explain their use, and that I explicitly mentioned that this is > > >something we can easily re-visit. > > > > > > > I do have a pseudo LSM called "multiadm" at > > http://freshmeat.net/p/multiadm/ , quoting: > > > > Based on Linus' criteria, this appears to be a case for reverting the > static LSM patch. I don't want to argue for or against the actual revert; however if Linus/James/Chris decide to do a revert, I've made a patch to do that below (doing a full git revert is tricky since it gets mixed up with various other cleanup patches; even inside the original patch. I've done the relevant pieces by hand via a selective patch -R and compile-tested it). In addition I've made the modularity a Kconfig option, since it's clearly something that is contested and thus is justified as a user compile time choice; people who don't want this (out of paranoia or otherwise) can now decide to disable, while others who want to experiment or use out of tree LSM modules, can select the KConfig option. If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. --- From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: revert the modular LSM patch Since there is a real out of tree, non-racey modular LSM module, add back the capability to have modular LSM modules as a config option. (note that this patch fails checkpatch.pl in a few places, however since this is just a reverse-patch of the original code, I don't want to fix this in order to keep exact revert behavior) Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> diff -purN linux-2.6.23-git17/include/linux.org/security.h linux-2.6.23-git17/include/linux/security.h --- linux-2.6.23-git17/include/linux.org/security.h 2007-10-21 10:35:49.0 +0200 +++ linux-2.6.23-git17/include/linux/security.h 2007-10-21 10:36:00.0 +0200 @@ -1178,6 +1178,10 @@ struct request_sock; * allow module stacking. * @name contains the name of the security module being stacked. * @ops contains a pointer to the struct security_operations of the module to stack. + * @unregister_security: + * remove a stacked module. + * @name contains the name of the security module being unstacked. + * @ops contains a pointer to the struct security_operations of the module to unstack. * * @secid_to_secctx: * Convert secid to security context. @@ -1365,6 +1369,8 @@ struct security_operations { /* allow module stacking */ int (*register_security) (const char *name, struct security_operations *ops); + int (*unregister_security) (const char *name, + struct security_operations *ops); void (*d_instantiate) (struct dentry *dentry, struct inode *inode); @@ -1445,7 +1451,9 @@ struct security_operations { /* prototypes */ extern int security_init (void); extern int register_security (struct security_operations *ops); +extern int unregister_security (struct security_operations *ops); extern int mod_reg_security(const char *name, struct security_operations *ops); +extern int mod_unreg_security (const char *name, struct security_operations *ops); extern struct dentry *securityfs_create_file(const char *name, mode_t mode, struct dentry *parent, void *data, const struct file_operations *fops); diff -purN linux-2.6.23-git17/security.org/dummy.c linux-2.6.23-git17/security/dummy.c --- linux-2.6.23-git17/security.org/dummy.c 2007-10-21 02:04:21.0 +0200 +++ linux-2.6.23-git17/security/dummy.c 2007-10-21 10:36:00.0 +0200 @@ -908,6 +908,11 @@ static int dummy_register_security (cons return -EINVAL; } +static int dummy_unregister_security (const char *name, struct security_operations *ops) +{ + return -EINVAL; +} + static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode) { return; @@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security set_to_dummy_if_null(ops, netlink_send); set_to_dummy_if_null(ops, netlink_recv); set_to_dummy_if_null(ops, register_security); + set_to_dummy_if_null(ops, unregister_security); set_to_dummy_if_null(ops, d_instantiate); set_to_dummy_if_null(ops, getprocattr); set_to_dummy_if_null(ops, setprocattr); diff -purN linux-2.6.23-git17/security.org/Kconfig linux-2.6.23-git17/security/Kconfig ---
Re: LSM conversion to static interface
Greg KH wrote: On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. Any "customer" using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. So, since the support is gone, they can easily build their own kernels, with their own LSM interfaces, and get the exact same lack of support :) Running a vendor kernel has the advantage of reusing all the QA work that has gone into that kernel. It is very different from running 2.6.24-rc1 (or 2.6.22.x). Hence projects like centos: you don't get any support, but the likelihood of actually requiring support is lower than running some random kernel. [but I agree that someone who has somehow determined that they need a specific LSM will probably have determined that they need vendor support as well] -- error compiling committee.c: too many arguments to function - 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: LSM conversion to static interface
On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: > To possibly save bandwidth, I'll also respond to another of Greg's points: > > "Greg KH" <[EMAIL PROTECTED]> wrote: > > Any "customer" using a security model other than provided by their Linux > > distributor instantly voided all support from that distro by doing that. > > This isn't necessarily true. In fact, I don't think it's even _remotely_ > likely to be typical. But that is completly true _today_ and is the way that the "enterprise" distros work. Do you have any evidence of it not being the case? > Security is big business, as is compliance with regulatory law. Large > enterprise customers are NOT going to either void their system support > contracts, or place themselves in jeopardy of failing a SOX audit. I agree, that is why customers do not load other random security modules in their kernel today, and why they will not do so tomorrow. So, because of that, this whole point about compliance with regulatory law seems kind of moot :) Again, LSM isn't going away at all, this is just one config option for allowing LSM to work as a module that is changing. If a customer demands that this feature come back, I'm sure that the big distros will be the first to push for it. But currently, given that there are no known external LSMs being used by customers demanding support, I don't see what the big issue here really is. 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: LSM conversion to static interface
> The point of contention: closing LSM significantly reduces the freedom > of an important class of Linux users, the commercial enterprises, to > use whatever security framework they desire. Greg and Alan didn't No it doesn't. Strange interpretations of peculiar US laws may be doing that. Thats [with Linux community hat on] _not_our_problem_. > Why can't a CONFIG_ system be developed that can give everyone pretty > much what he wants? It should be possible to develop a system > permitting much flexibility wrt security frameworks: > 1. a kernel configured with statically-linked hooks into exactly > one framework. > --- OR --- > 2. a kernel configured with an in-tree framework, but which uses > an LSM "security_operations" table. (This is what we pretty much > have in 2.6.23). In addition, a new boot parameter could let the > end user name the framework to use, which would completely > replace the in-tree default framework at boot time. Send patches. > In the same note, he agreed with Alan that "SarBox is not really the issue > here." Well, I'm pretty certain that regulatory law strongly shapes > market forces and enterprise needs. In particular, I've heard several > times that enterprises users really want to just BUY all their security > products, and that these products must be accompanied by documentation for > any audits. So, I'm pretty sure that if it is "not ... the issue", it > strongly influences the issue. Corporations practice "liability dumping" so that would be expected. They want to dumb liability onto their suppliers, their customers and anyone else they can find. Its the logical commercial practice faced by any rational body evolving in the US marketplace. But thats still their issue, no the community's issue. Alan - 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: LSM conversion to static interface
Some well-respected contributors have taken exception my amplification of Crispin Cowan's point about the patch that closes LSM. Crispin Cowan <[EMAIL PROTECTED]> wrote: > * It prevents enterprise users, and in fact anyone who isn't > comfortable compiling their own kernel, from ever trying out any > security module that their distro vendor of choice did not ship. I extended this point by observing that regulatory laws make it difficult for enterprise customers to compile their own kernels, mentioning one of the more invasive statutes, Sarbanes-Oxley. In reply, "Alan Cox" <[EMAIL PROTECTED]> writes: > Crispin at least is providing genuine discussion points. Sarbox has > nothing to say on "using vendor linux kernels". And just previously, "Greg KH" <[EMAIL PROTECTED]> had written: > Since when does Sarbanes-Oxley decree that a company must use a > "standard kernel"? And just exactly what defines such "standard > kernel"? Can you point out where in that bill it requires such a > thing? I was actually talking about the *effects* of regulatory law, rather than the wording in the text of the statutes. The misunderstanding could be partially my fault, as my exact words were As Sarbanes-Oxley and other regulatory laws require these customers to use "standard kernels" which may not have been as unambiguously clear as I intended. But as long as we're here, let me elaborate on the point I tried to make. SOX and other laws require enterprise customers to keep specified controls on their internal processing procedures, and keep documentation that can be audited to prove compliance. The auditing requirements are extensive and detailed, and certainly include the kernel of an operating system used to process business and/or financial transactions. It is within this framework that enterprise customers conclude something like (and this is vernacular, not the language within the statutes) "if we use any kernel other than that supplied by our distributor, the SOX auditing paperwork will be a nightmare." (I've actually heard statements similar to this, and so believe that it is an accurate portrayal of the perception of the effects of regulatory law. I'm not a lawyer.) As I said at the beginning, I meant to amplify Crispin's observation that enterprise customers are reluctant to compile their own kernels with the additional observation that the complexities of regulatory law create obstacles that are significant contributors to that reluctance. I'll not belabor the unfortunate non sequitur further. You can find plenty of documentation of auditing requirements with by Googling combinations of "Sarbanes-Oxley," "operating system integrity", etc. This is a big-business topic of wide concern. = So where were we before that detour? Oh yes, The point of contention: closing LSM significantly reduces the freedom of an important class of Linux users, the commercial enterprises, to use whatever security framework they desire. Greg and Alan didn't address this, and neither has anyone else. Crispin's concluding remark on the patch closing LSM to modules has also not been addressed: > So I don't think I am being self-serving in arguing against this > patch. I just think it is bad for Linux. Yes. Why indeed should Linux, justly famous for being configurable to many disparate purposes, close down an important subsystem so that only a few types of security frameworks are possible? Why can't a CONFIG_ system be developed that can give everyone pretty much what he wants? It should be possible to develop a system permitting much flexibility wrt security frameworks: 1. a kernel configured with statically-linked hooks into exactly one framework. --- OR --- 2. a kernel configured with an in-tree framework, but which uses an LSM "security_operations" table. (This is what we pretty much have in 2.6.23). In addition, a new boot parameter could let the end user name the framework to use, which would completely replace the in-tree default framework at boot time. To possibly save bandwidth, I'll also respond to another of Greg's points: "Greg KH" <[EMAIL PROTECTED]> wrote: > Any "customer" using a security model other than provided by their Linux > distributor instantly voided all support from that distro by doing that. This isn't necessarily true. In fact, I don't think it's even _remotely_ likely to be typical. Security is big business, as is compliance with regulatory law. Large enterprise customers are NOT going to either void their system support contracts, or place themselves in jeopardy of failing a SOX audit. Much more likely would be negotiated collaboration between some Linux distributors and security software firms that will permit enterprise customers to purchase, in a bundle, the security software products they require, along with the documentation needed to prove compliance with regulatory law. At least,
Re: LSM conversion to static interface
On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote: > > For that reason I think keeping LSM is the right thing to do. Wait, we aren't talking about dropping LSM at all, just the "LSM is a module" option. That's it. And by making LSM not a module, we can then go on to fix some of the reported speed issues that are present with the LSM option enabled right now. 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: LSM conversion to static interface
> > Crispin at least is providing genuine discussion points. Sarbox has > > nothing to say on "using vendor linux kernels". > > > I agree that SarBox is not really the issue here. Partially related is > enterprise rules about what kernels one is allowed to load. More > generally, this change forces users who want to use a different LSM than > their vendor provides to recompile their kernel, where they did not have > to recompile before. It forces LSM module developers who want to modify > their LSM to reboot, where they didn't necessarily have to reboot before. The moment they load a module from a third party they usually hit support issues, unless there is some kind of arrangement between the parties. > > That is not a catastrophe, it is just tedious. It does not kill baby > seals, and it does not make Linux utterly useless. OTOH, I think it is > strictly negative: it takes away user choice in 2 dimensions, and adds > zero value. So apply it if you must to bake the kernel developer's lives > easier, but it really is a net loss in Linux kernel capability. Frankly I don't care about apparmor, I don't see it as a serious project. Smack is kind of neat but looks like a nicer way to specify selinux rules. What I do care about is that at some point something is going to appear which is based on all the same good practice and experience and forty years of research that leads towards SELinux, and which is much better. At that point there will be a changeover phase and the LSM is exactly what is needed for this. The fact it allows people to play with toy security systems, propose new ones like SMACK, and do research and PhD work on Linux into security is a convenient and very good side effect. For that reason I think keeping LSM is the right thing to do. Alan - 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: LSM conversion to static interface
Alan Cox wrote: > On Sun, 21 Oct 2007 19:24:42 -0700 > "Thomas Fricaccia" <[EMAIL PROTECTED]> wrote >> Yes, I think Crispin has succinctly summed it up: irrevocably closing >> the LSM prevents commercial customers from using security modules other >> than that provided by their Linux distributor. As Sarbanes-Oxley and >> other regulatory laws require these customers to use "standard >> kernels", the result is a rather dreary form of vendor lock-in, where the >> security framework is coupled to the distribution. >> > Crispin at least is providing genuine discussion points. Sarbox has > nothing to say on "using vendor linux kernels". > I agree that SarBox is not really the issue here. Partially related is enterprise rules about what kernels one is allowed to load. More generally, this change forces users who want to use a different LSM than their vendor provides to recompile their kernel, where they did not have to recompile before. It forces LSM module developers who want to modify their LSM to reboot, where they didn't necessarily have to reboot before. That is not a catastrophe, it is just tedious. It does not kill baby seals, and it does not make Linux utterly useless. OTOH, I think it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is a net loss in Linux kernel capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
On Sun, 21 Oct 2007 19:24:42 -0700 "Thomas Fricaccia" <[EMAIL PROTECTED]> wrote: > Yes, I think Crispin has succinctly summed it up: irrevocably closing > the LSM prevents commercial customers from using security modules other > than that provided by their Linux distributor. As Sarbanes-Oxley and > other regulatory laws require these customers to use "standard > kernels", the result is a rather dreary form of vendor lock-in, where the > security framework is coupled to the distribution. Crispin at least is providing genuine discussion points. Sarbox has nothing to say on "using vendor linux kernels". - 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: LSM conversion to static interface
On Sun, 21 Oct 2007 19:24:42 -0700 Thomas Fricaccia [EMAIL PROTECTED] wrote: Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels, the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Crispin at least is providing genuine discussion points. Sarbox has nothing to say on using vendor linux kernels. - 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: LSM conversion to static interface
Alan Cox wrote: On Sun, 21 Oct 2007 19:24:42 -0700 Thomas Fricaccia [EMAIL PROTECTED] wrote Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels, the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Crispin at least is providing genuine discussion points. Sarbox has nothing to say on using vendor linux kernels. I agree that SarBox is not really the issue here. Partially related is enterprise rules about what kernels one is allowed to load. More generally, this change forces users who want to use a different LSM than their vendor provides to recompile their kernel, where they did not have to recompile before. It forces LSM module developers who want to modify their LSM to reboot, where they didn't necessarily have to reboot before. That is not a catastrophe, it is just tedious. It does not kill baby seals, and it does not make Linux utterly useless. OTOH, I think it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is a net loss in Linux kernel capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
Crispin at least is providing genuine discussion points. Sarbox has nothing to say on using vendor linux kernels. I agree that SarBox is not really the issue here. Partially related is enterprise rules about what kernels one is allowed to load. More generally, this change forces users who want to use a different LSM than their vendor provides to recompile their kernel, where they did not have to recompile before. It forces LSM module developers who want to modify their LSM to reboot, where they didn't necessarily have to reboot before. The moment they load a module from a third party they usually hit support issues, unless there is some kind of arrangement between the parties. That is not a catastrophe, it is just tedious. It does not kill baby seals, and it does not make Linux utterly useless. OTOH, I think it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is a net loss in Linux kernel capability. Frankly I don't care about apparmor, I don't see it as a serious project. Smack is kind of neat but looks like a nicer way to specify selinux rules. What I do care about is that at some point something is going to appear which is based on all the same good practice and experience and forty years of research that leads towards SELinux, and which is much better. At that point there will be a changeover phase and the LSM is exactly what is needed for this. The fact it allows people to play with toy security systems, propose new ones like SMACK, and do research and PhD work on Linux into security is a convenient and very good side effect. For that reason I think keeping LSM is the right thing to do. Alan - 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: LSM conversion to static interface
On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote: For that reason I think keeping LSM is the right thing to do. Wait, we aren't talking about dropping LSM at all, just the LSM is a module option. That's it. And by making LSM not a module, we can then go on to fix some of the reported speed issues that are present with the LSM option enabled right now. 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: LSM conversion to static interface
Some well-respected contributors have taken exception my amplification of Crispin Cowan's point about the patch that closes LSM. Crispin Cowan [EMAIL PROTECTED] wrote: * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. I extended this point by observing that regulatory laws make it difficult for enterprise customers to compile their own kernels, mentioning one of the more invasive statutes, Sarbanes-Oxley. In reply, Alan Cox [EMAIL PROTECTED] writes: Crispin at least is providing genuine discussion points. Sarbox has nothing to say on using vendor linux kernels. And just previously, Greg KH [EMAIL PROTECTED] had written: Since when does Sarbanes-Oxley decree that a company must use a standard kernel? And just exactly what defines such standard kernel? Can you point out where in that bill it requires such a thing? I was actually talking about the *effects* of regulatory law, rather than the wording in the text of the statutes. The misunderstanding could be partially my fault, as my exact words were As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels which may not have been as unambiguously clear as I intended. But as long as we're here, let me elaborate on the point I tried to make. SOX and other laws require enterprise customers to keep specified controls on their internal processing procedures, and keep documentation that can be audited to prove compliance. The auditing requirements are extensive and detailed, and certainly include the kernel of an operating system used to process business and/or financial transactions. It is within this framework that enterprise customers conclude something like (and this is vernacular, not the language within the statutes) if we use any kernel other than that supplied by our distributor, the SOX auditing paperwork will be a nightmare. (I've actually heard statements similar to this, and so believe that it is an accurate portrayal of the perception of the effects of regulatory law. I'm not a lawyer.) As I said at the beginning, I meant to amplify Crispin's observation that enterprise customers are reluctant to compile their own kernels with the additional observation that the complexities of regulatory law create obstacles that are significant contributors to that reluctance. I'll not belabor the unfortunate non sequitur further. You can find plenty of documentation of auditing requirements with by Googling combinations of Sarbanes-Oxley, operating system integrity, etc. This is a big-business topic of wide concern. = So where were we before that detour? Oh yes, The point of contention: closing LSM significantly reduces the freedom of an important class of Linux users, the commercial enterprises, to use whatever security framework they desire. Greg and Alan didn't address this, and neither has anyone else. Crispin's concluding remark on the patch closing LSM to modules has also not been addressed: So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Yes. Why indeed should Linux, justly famous for being configurable to many disparate purposes, close down an important subsystem so that only a few types of security frameworks are possible? Why can't a CONFIG_ system be developed that can give everyone pretty much what he wants? It should be possible to develop a system permitting much flexibility wrt security frameworks: 1. a kernel configured with statically-linked hooks into exactly one framework. --- OR --- 2. a kernel configured with an in-tree framework, but which uses an LSM security_operations table. (This is what we pretty much have in 2.6.23). In addition, a new boot parameter could let the end user name the framework to use, which would completely replace the in-tree default framework at boot time. To possibly save bandwidth, I'll also respond to another of Greg's points: Greg KH [EMAIL PROTECTED] wrote: Any customer using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. This isn't necessarily true. In fact, I don't think it's even _remotely_ likely to be typical. Security is big business, as is compliance with regulatory law. Large enterprise customers are NOT going to either void their system support contracts, or place themselves in jeopardy of failing a SOX audit. Much more likely would be negotiated collaboration between some Linux distributors and security software firms that will permit enterprise customers to purchase, in a bundle, the security software products they require, along with the documentation needed to prove compliance with regulatory law. At least, this seems to be what the market demands, or is
Re: LSM conversion to static interface
The point of contention: closing LSM significantly reduces the freedom of an important class of Linux users, the commercial enterprises, to use whatever security framework they desire. Greg and Alan didn't No it doesn't. Strange interpretations of peculiar US laws may be doing that. Thats [with Linux community hat on] _not_our_problem_. Why can't a CONFIG_ system be developed that can give everyone pretty much what he wants? It should be possible to develop a system permitting much flexibility wrt security frameworks: 1. a kernel configured with statically-linked hooks into exactly one framework. --- OR --- 2. a kernel configured with an in-tree framework, but which uses an LSM security_operations table. (This is what we pretty much have in 2.6.23). In addition, a new boot parameter could let the end user name the framework to use, which would completely replace the in-tree default framework at boot time. Send patches. In the same note, he agreed with Alan that SarBox is not really the issue here. Well, I'm pretty certain that regulatory law strongly shapes market forces and enterprise needs. In particular, I've heard several times that enterprises users really want to just BUY all their security products, and that these products must be accompanied by documentation for any audits. So, I'm pretty sure that if it is not ... the issue, it strongly influences the issue. Corporations practice liability dumping so that would be expected. They want to dumb liability onto their suppliers, their customers and anyone else they can find. Its the logical commercial practice faced by any rational body evolving in the US marketplace. But thats still their issue, no the community's issue. Alan - 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: LSM conversion to static interface
On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: To possibly save bandwidth, I'll also respond to another of Greg's points: Greg KH [EMAIL PROTECTED] wrote: Any customer using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. This isn't necessarily true. In fact, I don't think it's even _remotely_ likely to be typical. But that is completly true _today_ and is the way that the enterprise distros work. Do you have any evidence of it not being the case? Security is big business, as is compliance with regulatory law. Large enterprise customers are NOT going to either void their system support contracts, or place themselves in jeopardy of failing a SOX audit. I agree, that is why customers do not load other random security modules in their kernel today, and why they will not do so tomorrow. So, because of that, this whole point about compliance with regulatory law seems kind of moot :) Again, LSM isn't going away at all, this is just one config option for allowing LSM to work as a module that is changing. If a customer demands that this feature come back, I'm sure that the big distros will be the first to push for it. But currently, given that there are no known external LSMs being used by customers demanding support, I don't see what the big issue here really is. 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: LSM conversion to static interface
Greg KH wrote: On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. Any customer using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. So, since the support is gone, they can easily build their own kernels, with their own LSM interfaces, and get the exact same lack of support :) Running a vendor kernel has the advantage of reusing all the QA work that has gone into that kernel. It is very different from running 2.6.24-rc1 (or 2.6.22.x). Hence projects like centos: you don't get any support, but the likelihood of actually requiring support is lower than running some random kernel. [but I agree that someone who has somehow determined that they need a specific LSM will probably have determined that they need vendor support as well] -- error compiling committee.c: too many arguments to function - 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: LSM conversion to static interface [revert patch]
On Sun, 21 Oct 2007 08:57:06 +1000 (EST) James Morris [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Jan Engelhardt wrote: I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. I don't want to argue for or against the actual revert; however if Linus/James/Chris decide to do a revert, I've made a patch to do that below (doing a full git revert is tricky since it gets mixed up with various other cleanup patches; even inside the original patch. I've done the relevant pieces by hand via a selective patch -R and compile-tested it). In addition I've made the modularity a Kconfig option, since it's clearly something that is contested and thus is justified as a user compile time choice; people who don't want this (out of paranoia or otherwise) can now decide to disable, while others who want to experiment or use out of tree LSM modules, can select the KConfig option. If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. --- From: Arjan van de Ven [EMAIL PROTECTED] Subject: revert the modular LSM patch Since there is a real out of tree, non-racey modular LSM module, add back the capability to have modular LSM modules as a config option. (note that this patch fails checkpatch.pl in a few places, however since this is just a reverse-patch of the original code, I don't want to fix this in order to keep exact revert behavior) Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] diff -purN linux-2.6.23-git17/include/linux.org/security.h linux-2.6.23-git17/include/linux/security.h --- linux-2.6.23-git17/include/linux.org/security.h 2007-10-21 10:35:49.0 +0200 +++ linux-2.6.23-git17/include/linux/security.h 2007-10-21 10:36:00.0 +0200 @@ -1178,6 +1178,10 @@ struct request_sock; * allow module stacking. * @name contains the name of the security module being stacked. * @ops contains a pointer to the struct security_operations of the module to stack. + * @unregister_security: + * remove a stacked module. + * @name contains the name of the security module being unstacked. + * @ops contains a pointer to the struct security_operations of the module to unstack. * * @secid_to_secctx: * Convert secid to security context. @@ -1365,6 +1369,8 @@ struct security_operations { /* allow module stacking */ int (*register_security) (const char *name, struct security_operations *ops); + int (*unregister_security) (const char *name, + struct security_operations *ops); void (*d_instantiate) (struct dentry *dentry, struct inode *inode); @@ -1445,7 +1451,9 @@ struct security_operations { /* prototypes */ extern int security_init (void); extern int register_security (struct security_operations *ops); +extern int unregister_security (struct security_operations *ops); extern int mod_reg_security(const char *name, struct security_operations *ops); +extern int mod_unreg_security (const char *name, struct security_operations *ops); extern struct dentry *securityfs_create_file(const char *name, mode_t mode, struct dentry *parent, void *data, const struct file_operations *fops); diff -purN linux-2.6.23-git17/security.org/dummy.c linux-2.6.23-git17/security/dummy.c --- linux-2.6.23-git17/security.org/dummy.c 2007-10-21 02:04:21.0 +0200 +++ linux-2.6.23-git17/security/dummy.c 2007-10-21 10:36:00.0 +0200 @@ -908,6 +908,11 @@ static int dummy_register_security (cons return -EINVAL; } +static int dummy_unregister_security (const char *name, struct security_operations *ops) +{ + return -EINVAL; +} + static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode) { return; @@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security set_to_dummy_if_null(ops, netlink_send); set_to_dummy_if_null(ops, netlink_recv); set_to_dummy_if_null(ops, register_security); + set_to_dummy_if_null(ops, unregister_security); set_to_dummy_if_null(ops, d_instantiate); set_to_dummy_if_null(ops, getprocattr); set_to_dummy_if_null(ops, setprocattr); diff -purN linux-2.6.23-git17/security.org/Kconfig linux-2.6.23-git17/security/Kconfig --- linux-2.6.23-git17/security.org/Kconfig 2007-10-21 02:04:21.0
Re: LSM conversion to static interface [revert patch]
On Mon, 22 Oct 2007, Arjan van de Ven wrote: @@ -4895,6 +4908,7 @@ static struct security_operations selinu .sem_semop =selinux_sem_semop, .register_security =selinux_register_security, + .unregister_security = selinux_unregister_security, .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. - James -- James Morris [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: LSM conversion to static interface [revert patch]
On Tue, 23 Oct 2007 14:56:52 +1000 (EST) James Morris [EMAIL PROTECTED] wrote: On Mon, 22 Oct 2007, Arjan van de Ven wrote: @@ -4895,6 +4908,7 @@ static struct security_operations selinu .sem_semop =selinux_sem_semop, .register_security = selinux_register_security, + .unregister_security = selinux_unregister_security, .d_instantiate =selinux_d_instantiate, You also need to consider whether to allow capabilities to be built as an unloadable module. If not, then we don't need this hook added back into SELinux. Otherwise, if it is desired, you also need to reinstate capability_exit and general modular bits for security/capability.c. this just allows 3d party replacements of capability like functions; there is no need/point to have the existing capability back as modular to be honest. - 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: LSM conversion to static interface
Greg KH wrote: On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: Security is big business, as is compliance with regulatory law. Large enterprise customers are NOT going to either void their system support contracts, or place themselves in jeopardy of failing a SOX audit. I agree, that is why customers do not load other random security modules in their kernel today, That random module could be a module supplied by a vendor other than the distro supplier, such as a security vendor. It could be a research prototype that the user wants to try out on their enterprise-supported kernel. It could even be an in-house developed module that a local site wants to run on his larger organization's blessed kernel. So far from random, these modules are motivated by circumstances radically different than yours. In particular, rebuilding a kernel for you (GregKH, many LKML developers) is a casual thing to be done before breakfast, but is a scary obstacle to many others. It is an obstacle to people who are skilled at computers but deliberately *not* kernel developers (the whole world does not need to be a Linux kernel developer) and it is an obstacle to large enterprise admins who have organizational pressure to use specific, pre-built kernels. and why they will not do so tomorrow. So, because of that, this whole point about compliance with regulatory law seems kind of moot :) I think the specific stuff about regulatory compliance is tangential. SarBox and friends don't specify Linux kernel versions, they are incredibly vague and subject to interpretation. But they are part of what drive organizations to have self-imposed rules about only running blessed kernel versions. Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. Again, LSM isn't going away at all, this is just one config option for allowing LSM to work as a module that is changing. If a customer demands that this feature come back, I'm sure that the big distros will be the first to push for it. But currently, given that there are no known external LSMs being used by customers demanding support, I don't see what the big issue here really is. As I said, it is a medium issue, not a big one, which is why I didn't speak out before. I am opposed to this change because I see zero benefit to it, and a lot of down-side in loss of user choice. Because that is what this does: it does not help the kernel get better. It *definitely* does not help the kernel become more secure. It mostly just removes user's choice, by making it difficult to do things that some people don't approve of. As I've said, it doesn't hurt AppArmor, because 3 major distros ship it. But it will hurt user choice and innovation, by making anything not shipped by a distro more difficult to access. There is some performance gains to be had by doing something to the LSM interface. Certainly a configuration option that statically inlines all the hooks and points them at a compiled in module would yield some performance gain, but I don't know how much. But that raises 2 questions: 1. Was *performance* really the reason this patch was proposed? Or was it because James really did want the restrictive effect of preventing people from choosing after-market modules and dynamically unloading them if they want? I believe that James was well-intentioned in trying to block these actions because he believes them to be insecure, and he's right, they are insecure. However, these actions are also very practically useful in many circumstances. I disagree with the change because an individual LSM can block both such actions if you wish, so imposing it on all LSM modules is restricting choice unnecessarily. 2. Is the performance issue that this might address really big enough to bother fixing at all? Maybe, but I don't know. Again, I'm strictly opposed to the loss of flexibility until the performance issue is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface [revert patch]
* Arjan van de Ven ([EMAIL PROTECTED]) wrote: On Sun, 21 Oct 2007 08:57:06 +1000 (EST) James Morris [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Jan Engelhardt wrote: I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. I don't want to argue for or against the actual revert; however if Linus/James/Chris decide to do a revert, I've made a patch to do that below Thanks Arjan. I did not actually oppose making it non-modular, and thought there was sufficient time for people to complain meaningfully on that change. I also think there's not a lot of value in the modular interface, but it's very difficult to have rational discussions in this area. (doing a full git revert is tricky since it gets mixed up with various other cleanup patches; even inside the original patch. I've done the relevant pieces by hand via a selective patch -R and compile-tested it). In addition I've made the modularity a Kconfig option, since it's clearly something that is contested and thus is justified as a user compile time choice; people who don't want this (out of paranoia or otherwise) can now decide to disable, while others who want to experiment or use out of tree LSM modules, can select the KConfig option. If it turns out that the above module becomes unmaintained and no longer usable, and no other useful cases show up, we can always garbage collect this code in the future; it's now low-overhead anyway for those who care, due to the KConfig option. Yes, and I think we can still improve performance although I can't see anyway to help out the modular case, so I guess it will have to incur the hit that's always been there. I think your Kconfig option is a decent compromise. thanks, -chris - 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: LSM conversion to static interface
On Mon, 22 Oct 2007, Crispin Cowan wrote: Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. one reason to not be willing to rebuild the kernel is that they may rely on a module from a different third party that is shipped/tested for the specific pre-compiled kernels from the distro. David Lang - 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: LSM conversion to static interface
Jan Engelhardt wrote: I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) But his is against LSM design (and first agreements about LSM): LSM can deny rights, but it should not give extra permissions or bypass standard unix permissions. ciao cate - 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: LSM conversion to static interface
Thomas Fricaccia wrote: Some well-respected contributors have taken exception my amplification of Crispin Cowan's point about the patch that closes LSM. Crispin Cowan [EMAIL PROTECTED] wrote: * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. I extended this point by observing that regulatory laws make it difficult for enterprise customers to compile their own kernels, mentioning one of the more invasive statutes, Sarbanes-Oxley. In reply, Alan Cox [EMAIL PROTECTED] writes: Crispin at least is providing genuine discussion points. Sarbox has nothing to say on using vendor linux kernels. And just previously, Greg KH [EMAIL PROTECTED] had written: Since when does Sarbanes-Oxley decree that a company must use a standard kernel? And just exactly what defines such standard kernel? Can you point out where in that bill it requires such a thing? I was actually talking about the *effects* of regulatory law, rather than the wording in the text of the statutes. The misunderstanding could be partially my fault, as my exact words were As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels which may not have been as unambiguously clear as I intended. But as long as we're here, let me elaborate on the point I tried to make. SOX and other laws require enterprise customers to keep specified controls on their internal processing procedures, and keep documentation that can be audited to prove compliance. The auditing requirements are extensive and detailed, and certainly include the kernel of an operating system used to process business and/or financial transactions. It is within this framework that enterprise customers conclude something like (and this is vernacular, not the language within the statutes) if we use any kernel other than that supplied by our distributor, the SOX auditing paperwork will be a nightmare. (I've actually heard statements similar to this, and so believe that it is an accurate portrayal of the perception of the effects of regulatory law. I'm not a lawyer.) As I said at the beginning, I meant to amplify Crispin's observation that enterprise customers are reluctant to compile their own kernels with the additional observation that the complexities of regulatory law create obstacles that are significant contributors to that reluctance. I'll not belabor the unfortunate non sequitur further. You can find plenty of documentation of auditing requirements with by Googling combinations of Sarbanes-Oxley, operating system integrity, etc. This is a big-business topic of wide concern. What do technical and regulatory differences have driver/LSM module that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. ciao cate - 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: LSM conversion to static interface
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: > Yes, I think Crispin has succinctly summed it up: irrevocably closing > the LSM prevents commercial customers from using security modules other > than that provided by their Linux distributor. Any "customer" using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. So, since the support is gone, they can easily build their own kernels, with their own LSM interfaces, and get the exact same lack of support :) And, what are these "other LSM modules" you speak of that people rely on to run their businesses? > As Sarbanes-Oxley and > other regulatory laws require these customers to use "standard > kernels", the result is a rather dreary form of vendor lock-in, where the > security framework is coupled to the distribution. Wait, what? Since when does Sarbanes-Oxley decree that a company must use a "standard kernel"? And just exactly what defines such "standard kernel"? Can you point out where in that bill it requires such a thing? Totally confused, 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: LSM conversion to static interface
Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use "standard kernels", the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Though it would require a somewhat undesirable complexity of CONFIG_ flags, it should be possible to construct flexibility enough for everyone to get what he wants. For example, it should be possible to configure kernels with a single security framework hard-linked, AND it should also be possible to configure kernels such that the default security framework could be completely replaced at boot time by another, be it out-of-tree module, or other. I agree entirely that preserving this form of freedom for the end user makes Linux a much stronger technology than not. For one thing, the consequences of closing LSM are fairly certain to irritate enterprise commercial customers, which is probably a sign that the technology has taken a wrong turn. Tommy F. Crispin Cowan <[EMAIL PROTECTED]> wrote: > So the net impact of this patch is: > >* It takes a deployment practice (static compiled-in security) that > is arguably good in many circumstances and makes it mandatory at > all times. >* It takes a development practice that is very convenient and > slightly risky, and forces you into the pessimal inconvenient > development practice at all times. >* It prevents enterprise users, and in fact anyone who isn't > comfortable compiling their own kernel, from ever trying out any > security module that their distro vendor of choice did not ship. > > This strikes me as a rather anti-choice position to take. It says that > because candy is bad for you, you only ever get to eat vegetables. I > don't understand why Linux would want to do this to its users. > > It doesn't hurt me or AppArmor. Since AppArmor is now shipping with > SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer > modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise > users. So I don't think I am being self-serving in arguing against this > patch. I just think it is bad for Linux. > > Crispin > > -- > Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ > Itanium. Vista. GPLv3. Complexity at work - 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: Re: LSM conversion to static interface
To discuss how LSM should work, it would have been really helpful if the OP had cc'd the LSM mailing list. I've cc'd the LSM list here ... Linus Torvalds wrote: > On Wed, 17 Oct 2007, Thomas Fricaccia wrote: > >> But then I noticed that, while the LSM would remain in existence, it was >> being closed to out-of-tree security frameworks. Yikes! Since then, >> I've been following the rush to put SMACK, TOMOYO and AppArmor >> "in-tree". >> > Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE > people were ok with it (AppArmor), but I'm with you - I applied it, but > I'm also perfectly willing to unapply it if there actually are valid > out-of-tree users that people push for not merging. > I did not speak up against this patch because it does not hurt AppArmor, and I was trying to reduce the amount of LKML flaming that I engage in :) but since you asked, IMHO this patch is extremely bad for Linux and bad for Linux users. The patch does have benefits, I just think those benefits are weak and unimportant. It prohibits dynamic loading of security modules (you must be compiled in) and prohibits unloading of security modules (because it is unsafe, and potentially insecure). What makes these benefits weak and unimportant is that you can have those benefits now without the patch by just writing your module that way: if you think that a security module should be compiled in and present when the kernel boots, and should never be unloaded. > For example, I do kind of see the point that a "real" security model might > want to be compiled-in, and not something you override from a module. Of > course, I'm personally trying to not use any modules at all, so I'm just > odd and contrary, so whatever.. > Why would you want to dynamically unload a module: because it is convenient for debugging. Ok, so it is unsafe, and sometimes wedges your kernel, which sometimes forces you to reboot. With this patch in place, it forces you to *always* reboot when you want to try a hack to the module. Why you would want to dynamically load a security module: because you are an enterprise user, required to use a specific build of a kernel, rather than compile your own kernel, but you also want to use (or even try out) a security module that your enterprise's vendor of choice has not chosen to bundle. In the current state, such a user can just go get a module and use it. With this patch, such a user is just screwed, they can't load and try the module without having to get into kernel building. So the net impact of this patch is: * It takes a deployment practice (static compiled-in security) that is arguably good in many circumstances and makes it mandatory at all times. * It takes a development practice that is very convenient and slightly risky, and forces you into the pessimal inconvenient development practice at all times. * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. This strikes me as a rather anti-choice position to take. It says that because candy is bad for you, you only ever get to eat vegetables. I don't understand why Linux would want to do this to its users. It doesn't hurt me or AppArmor. Since AppArmor is now shipping with SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote: > On Sat, 20 Oct 2007, Jan Engelhardt wrote: > > > >I'd like to note that I asked people who were actually affected, and had > > >examples of their real-world use to step forward and explain their use, > > >and that I explicitly mentioned that this is something we can easily > > >re-visit. > > > > I do have a pseudo LSM called "multiadm" at > > http://freshmeat.net/p/multiadm/ , quoting: > > Based on Linus' criteria, this appears to be a case for reverting the > static LSM patch. >... If you take it that strictly, the in-kernel root_plug LSM could have been considered enough reason for reverting... The interesting question is IMHO still: Were Greg and Jan the only people to write such LSMs, or how many non-abusive users that make sense as modules do really exist after 5 years? Either you can count such real-world users with your fingers or there's a reason why these modules didn't get included. IOW: Either the API has proven to not attract enough modular users or we are having a to-be-fixed problem with getting the LSMs submitted and included. > - James 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: LSM conversion to static interface
On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote: On Sat, 20 Oct 2007, Jan Engelhardt wrote: I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. ... If you take it that strictly, the in-kernel root_plug LSM could have been considered enough reason for reverting... The interesting question is IMHO still: Were Greg and Jan the only people to write such LSMs, or how many non-abusive users that make sense as modules do really exist after 5 years? Either you can count such real-world users with your fingers or there's a reason why these modules didn't get included. IOW: Either the API has proven to not attract enough modular users or we are having a to-be-fixed problem with getting the LSMs submitted and included. - James 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: Re: LSM conversion to static interface
To discuss how LSM should work, it would have been really helpful if the OP had cc'd the LSM mailing list. I've cc'd the LSM list here ... Linus Torvalds wrote: On Wed, 17 Oct 2007, Thomas Fricaccia wrote: But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor in-tree. Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. I did not speak up against this patch because it does not hurt AppArmor, and I was trying to reduce the amount of LKML flaming that I engage in :) but since you asked, IMHO this patch is extremely bad for Linux and bad for Linux users. The patch does have benefits, I just think those benefits are weak and unimportant. It prohibits dynamic loading of security modules (you must be compiled in) and prohibits unloading of security modules (because it is unsafe, and potentially insecure). What makes these benefits weak and unimportant is that you can have those benefits now without the patch by just writing your module that way: if you think that a security module should be compiled in and present when the kernel boots, and should never be unloaded. For example, I do kind of see the point that a real security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Why would you want to dynamically unload a module: because it is convenient for debugging. Ok, so it is unsafe, and sometimes wedges your kernel, which sometimes forces you to reboot. With this patch in place, it forces you to *always* reboot when you want to try a hack to the module. Why you would want to dynamically load a security module: because you are an enterprise user, required to use a specific build of a kernel, rather than compile your own kernel, but you also want to use (or even try out) a security module that your enterprise's vendor of choice has not chosen to bundle. In the current state, such a user can just go get a module and use it. With this patch, such a user is just screwed, they can't load and try the module without having to get into kernel building. So the net impact of this patch is: * It takes a deployment practice (static compiled-in security) that is arguably good in many circumstances and makes it mandatory at all times. * It takes a development practice that is very convenient and slightly risky, and forces you into the pessimal inconvenient development practice at all times. * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. This strikes me as a rather anti-choice position to take. It says that because candy is bad for you, you only ever get to eat vegetables. I don't understand why Linux would want to do this to its users. It doesn't hurt me or AppArmor. Since AppArmor is now shipping with SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels, the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Though it would require a somewhat undesirable complexity of CONFIG_ flags, it should be possible to construct flexibility enough for everyone to get what he wants. For example, it should be possible to configure kernels with a single security framework hard-linked, AND it should also be possible to configure kernels such that the default security framework could be completely replaced at boot time by another, be it out-of-tree module, or other. I agree entirely that preserving this form of freedom for the end user makes Linux a much stronger technology than not. For one thing, the consequences of closing LSM are fairly certain to irritate enterprise commercial customers, which is probably a sign that the technology has taken a wrong turn. Tommy F. Crispin Cowan [EMAIL PROTECTED] wrote: So the net impact of this patch is: * It takes a deployment practice (static compiled-in security) that is arguably good in many circumstances and makes it mandatory at all times. * It takes a development practice that is very convenient and slightly risky, and forces you into the pessimal inconvenient development practice at all times. * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. This strikes me as a rather anti-choice position to take. It says that because candy is bad for you, you only ever get to eat vegetables. I don't understand why Linux would want to do this to its users. It doesn't hurt me or AppArmor. Since AppArmor is now shipping with SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - 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: LSM conversion to static interface
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. Any customer using a security model other than provided by their Linux distributor instantly voided all support from that distro by doing that. So, since the support is gone, they can easily build their own kernels, with their own LSM interfaces, and get the exact same lack of support :) And, what are these other LSM modules you speak of that people rely on to run their businesses? As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels, the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Wait, what? Since when does Sarbanes-Oxley decree that a company must use a standard kernel? And just exactly what defines such standard kernel? Can you point out where in that bill it requires such a thing? Totally confused, 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: LSM conversion to static interface
On Sat, 20 Oct 2007, Jan Engelhardt wrote: > >I'd like to note that I asked people who were actually affected, and had > >examples of their real-world use to step forward and explain their use, > >and that I explicitly mentioned that this is something we can easily > >re-visit. > > > > I do have a pseudo LSM called "multiadm" at > http://freshmeat.net/p/multiadm/ , quoting: > Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. Jan, I remember you posting this last year and IIRC, there were really only coding style issues to be addressed. There were some review queries and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers -- certainly not now that security architecture and security model objections are out of bounds. So, I would suggest reposting the code for upstream inclusion, which would be better at least in terms of upstream maintenance, as your code will be visible in the tree. - James -- James Morris <[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: LSM conversion to static interface
On Oct 19 2007 13:40, Linus Torvalds wrote: >On Fri, 19 Oct 2007, Andreas Gruenbacher wrote: >> >> Non-trivial modules (i.e., practically everything beyond capabilities) >> become >> effective only after loading policy, anyway. If you can load policy, you can >> as well first load a security module without making the system insecure. > >I'd like to note that I asked people who were actually affected, and had >examples of their real-world use to step forward and explain their use, >and that I explicitly mentioned that this is something we can easily >re-visit. > I do have a pseudo LSM called "multiadm" at http://freshmeat.net/p/multiadm/ , quoting: The MultiAdmin security framework kernel module provides a means to have multiple "root" users with unique UIDs. This bypasses collation order problems with NSCD, allows you to have files with unique owners, and allows you to track the quota usage for every "real" user. It also implements a "sub-admin", a partially restricted root user who has full read-only access to most subsystems, but write rights only to a limited subset, for example writing to files or killing processes only of certain users. The use case is so that profs (taking the role of sub-admins), can operate on student's data/processes/etc. (quite often needed), but without having the full root privileges. Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) Does that sound productive? >The fact is, security people *are* insane. You just argue all the time, >instead fo doing anything productive. So please don't include me in the Cc >on your insane arguments - instead do something productive and I'm >interested. [1] SELinux: What I remember from coker.com.au's selinux test machine, everyone had UID 0 and instead had powers revoked. - 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: LSM conversion to static interface
On Oct 19 2007 13:40, Linus Torvalds wrote: On Fri, 19 Oct 2007, Andreas Gruenbacher wrote: Non-trivial modules (i.e., practically everything beyond capabilities) become effective only after loading policy, anyway. If you can load policy, you can as well first load a security module without making the system insecure. I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: The MultiAdmin security framework kernel module provides a means to have multiple root users with unique UIDs. This bypasses collation order problems with NSCD, allows you to have files with unique owners, and allows you to track the quota usage for every real user. It also implements a sub-admin, a partially restricted root user who has full read-only access to most subsystems, but write rights only to a limited subset, for example writing to files or killing processes only of certain users. The use case is so that profs (taking the role of sub-admins), can operate on student's data/processes/etc. (quite often needed), but without having the full root privileges. Policy is dead simple since it is based on UIDs. The UID ranges can be set on module load time or during runtime (sysfs params). This LSM is basically grants extra rights unlike most other LSMs[1], which is why modprobe makes much more sense here. (It also does not have to do any security labelling that would require it to be loaded at boot time already.) Does that sound productive? The fact is, security people *are* insane. You just argue all the time, instead fo doing anything productive. So please don't include me in the Cc on your insane arguments - instead do something productive and I'm interested. [1] SELinux: What I remember from coker.com.au's selinux test machine, everyone had UID 0 and instead had powers revoked. - 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: LSM conversion to static interface
On Sat, 20 Oct 2007, Jan Engelhardt wrote: I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. I do have a pseudo LSM called multiadm at http://freshmeat.net/p/multiadm/ , quoting: Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. Jan, I remember you posting this last year and IIRC, there were really only coding style issues to be addressed. There were some review queries and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers -- certainly not now that security architecture and security model objections are out of bounds. So, I would suggest reposting the code for upstream inclusion, which would be better at least in terms of upstream maintenance, as your code will be visible in the tree. - James -- James Morris [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: LSM conversion to static interface
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote: > Quoting from commit 20510f2f (Convert LSM into a static interface): > > 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. > > This is idiotic. Just because there is no safe way to unload SELinux > > - doesn't mean there is no safe way to unload other LSMs: if nothing >but that, unloading is handy during development. Can you provide an example of a real LSM which can be safely unloaded and also needs to be unloaded? Why should we maintain infrastructure and extra complexity in the kernel for theoretical or unknown modules ? Linus has asked for any valid out of tree users who need a dynamic interface to step forward. Where are they? As one of the people who actually maintains LSM (rather than simply speculates about it), I object to maintaining infrastructure which, to the best of my knowledge, is only used by out of tree, binary, broken junk. If you recall, the original motivation for this patch was when the idea of adding a new capability to control security model unload was raised. That is, new security infrastructure was being proposed merely to cater to some other existing unnecessary security infrastructure. So, rather than doing that, I proposed removing the unnecessary infrastructure. I agree with Linus: if you can demonstrate a valid, concrete use for dynamic LSMs, then the infrastructure to support them can easily be reinstated. But until then, it seems both reasonable and in keeping with good kernel development practices, to not maintain unused infrastructure. - James -- James Morris <[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: LSM conversion to static interface
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote: > > Non-trivial modules (i.e., practically everything beyond capabilities) become > effective only after loading policy, anyway. If you can load policy, you can > as well first load a security module without making the system insecure. I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. But I also note that you did no such thing, neither has anybody else. The fact is, security people *are* insane. You just argue all the time, instead fo doing anything productive. So please don't include me in the Cc on your insane arguments - instead do something productive and I'm interested. Ok? That was the whole point of LSM in the first place. I'm *not* interested in getting roped into your insane arguments. I'm interested in moving forward and having real examples of real use and code. Until then, this issue is closed. I thought I had made that clear already, but apparently not clear enough. So I repeat: we can undo that commit, but I will damn well not care one whit about yet another pointless security model flamewar. Linus - 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: LSM conversion to static interface
On Thursday 18 October 2007 04:18, Linus Torvalds wrote: > On Wed, 17 Oct 2007, Thomas Fricaccia wrote: > > > > But then I noticed that, while the LSM would remain in existence, it was > > being closed to out-of-tree security frameworks. Yikes! Since then, > > I've been following the rush to put SMACK, TOMOYO and AppArmor > > "in-tree". > > Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE > people were ok with it (AppArmor), but I'm with you - I applied it, but > I'm also perfectly willing to unapply it if there actually are valid > out-of-tree users that people push for not merging. The patch doesn't hurt AppArmor, but it's still a step in the wrong direction. Quoting from commit 20510f2f (Convert LSM into a static interface): > 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. This is idiotic. Just because there is no safe way to unload SELinux - doesn't mean there is no safe way to unload other LSMs: if nothing but that, unloading is handy during development. - doesn't mean that module *loading* is unsafe. The patch removes module loading as well, which hurts more than removing module unloading. LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM loadable modules have been known to do lots of bad things, and yet nobody made them non-loadable either (yet). > [...] > For example, I do kind of see the point that a "real" security model might > want to be compiled-in, and not something you override from a module. Non-trivial modules (i.e., practically everything beyond capabilities) become effective only after loading policy, anyway. If you can load policy, you can as well first load a security module without making the system insecure. Thanks, Andreas - 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: LSM conversion to static interface
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote: Quoting from commit 20510f2f (Convert LSM into a static interface): 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. This is idiotic. Just because there is no safe way to unload SELinux - doesn't mean there is no safe way to unload other LSMs: if nothing but that, unloading is handy during development. Can you provide an example of a real LSM which can be safely unloaded and also needs to be unloaded? Why should we maintain infrastructure and extra complexity in the kernel for theoretical or unknown modules ? Linus has asked for any valid out of tree users who need a dynamic interface to step forward. Where are they? As one of the people who actually maintains LSM (rather than simply speculates about it), I object to maintaining infrastructure which, to the best of my knowledge, is only used by out of tree, binary, broken junk. If you recall, the original motivation for this patch was when the idea of adding a new capability to control security model unload was raised. That is, new security infrastructure was being proposed merely to cater to some other existing unnecessary security infrastructure. So, rather than doing that, I proposed removing the unnecessary infrastructure. I agree with Linus: if you can demonstrate a valid, concrete use for dynamic LSMs, then the infrastructure to support them can easily be reinstated. But until then, it seems both reasonable and in keeping with good kernel development practices, to not maintain unused infrastructure. - James -- James Morris [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: LSM conversion to static interface
On Thursday 18 October 2007 04:18, Linus Torvalds wrote: On Wed, 17 Oct 2007, Thomas Fricaccia wrote: But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor in-tree. Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. The patch doesn't hurt AppArmor, but it's still a step in the wrong direction. Quoting from commit 20510f2f (Convert LSM into a static interface): 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. This is idiotic. Just because there is no safe way to unload SELinux - doesn't mean there is no safe way to unload other LSMs: if nothing but that, unloading is handy during development. - doesn't mean that module *loading* is unsafe. The patch removes module loading as well, which hurts more than removing module unloading. LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM loadable modules have been known to do lots of bad things, and yet nobody made them non-loadable either (yet). [...] For example, I do kind of see the point that a real security model might want to be compiled-in, and not something you override from a module. Non-trivial modules (i.e., practically everything beyond capabilities) become effective only after loading policy, anyway. If you can load policy, you can as well first load a security module without making the system insecure. Thanks, Andreas - 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: LSM conversion to static interface
On Fri, 19 Oct 2007, Andreas Gruenbacher wrote: Non-trivial modules (i.e., practically everything beyond capabilities) become effective only after loading policy, anyway. If you can load policy, you can as well first load a security module without making the system insecure. I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit. But I also note that you did no such thing, neither has anybody else. The fact is, security people *are* insane. You just argue all the time, instead fo doing anything productive. So please don't include me in the Cc on your insane arguments - instead do something productive and I'm interested. Ok? That was the whole point of LSM in the first place. I'm *not* interested in getting roped into your insane arguments. I'm interested in moving forward and having real examples of real use and code. Until then, this issue is closed. I thought I had made that clear already, but apparently not clear enough. So I repeat: we can undo that commit, but I will damn well not care one whit about yet another pointless security model flamewar. Linus - 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: LSM conversion to static interface
On Wed, 17 Oct 2007 18:34:16 -0700 "Thomas Fricaccia" <[EMAIL PROTECTED]> wrote: > > But then I noticed that, while the LSM would remain in existence, it > was being closed to out-of-tree security frameworks. Yikes! Since > then, I've been following the rush to put SMACK, TOMOYO and AppArmor > "in-tree". I think your statement isn't quite correct: it's not closed to out of tree security frameworks; it's no longer possible to do MODULES. You can easily patch any of the ones you mention in (and in fact, this is how distros that use apparmor will use it anyway). You are totally free to compile whatever security module you want into your kernel and use it... I would actually highly encourage that; the freedom to do that is what Linux is about. The problem with "loadable security modules" is actually fundamental, and afaik even the AppArmor people mostly agree with this: The security any such system provides is generally based on being in a "Safe" state from the start, so knowing all objects that go through the system, being able to label them (or at least do something with them, I realize the term "label" is maybe seen as SELinux specific, but I mean it in a generic way; the SELinux people will tell you I'm not a fan of their approach *at all*), check them etc etc. A loadable-module approach can't do that, it would, at load time, have to inspect the system, make sure no operations are in "half process" when the LSM hooks go into effect (just think of it: if you have an operation that gets 3 LSM checks done to it, and you load and activate your module after the first one is done as NOP, and your code only sees the 2nd and 3rd... showing that that gives you sane behavior unpleasant no matter what you do) and on unload, undo all it's work in a semi atomic way (just try doing it race free is already impossible). This is the prime motivation behind the change as I understand it: It wasn't really an option to get this correct, the distros who deploy these frameworks tend to compile them in anyway as a result, and there are real downsides as well (see below). > technical arguments seem to be (1) some people use the LSM interface > for "non-security" purposes, which is frowned upon, (2) it's > difficult to properly secure a system with an open-ended interface > like LSM, and (3) my security framework should be all any fair-minded > person would ever want, so we won't let you use something else. you missed another one: the curent (now merged) patch allows a new option (which is under development and will be proposed for 2.6.25): A config option to compile the kernel such that the security framework of your choice gets compiled as "exclusive" for your binary kernel, and such that the code doesn't go via the LSM function pointers anymore, but just via preprocessor rules, does direct calls instead. (And gets patched out if you issue kernel commandline options to disable security entirely). This takes away one of the main performance overheads of LSM (many many function pointer calls) for those who know which LSM module they'll be using. That option obviously doesn't mean that you can't have multiple LSM drivers anymore in the kernel, again it is an option that IF you know you'll only use one, you can get rid of all the overhead of needing to be ready to do multiple. While this strict technically isn't in conflict with the non-modular LSM (modular-LSM can obviously be a config option in itself as well), it does make it a lot easier and cleaner to do things this way. - 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: LSM conversion to static interface
On Wed, 17 Oct 2007, Casey Schaufler wrote: > > The in-tree vs out-of-tree discussion is independent of LSM. Indeed. I think there is certainly likely to be some small overlap, but I *think* they are largely independent issues - "do we want choice in securitu models" (a very emphatic YES as far as I'm concerned) vs "do we necessarily want to do them as out-of-tree modules" (I'd like people who actually *do* things like that to educate us on why and what they are doing). Hmm? Linus - 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: LSM conversion to static interface
On Wed, 17 Oct 2007, Thomas Fricaccia wrote: > > But then I noticed that, while the LSM would remain in existence, it was > being closed to out-of-tree security frameworks. Yikes! Since then, > I've been following the rush to put SMACK, TOMOYO and AppArmor > "in-tree". Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. So Í don't think this is settled in any way - please keep discussing, and bringing it up. I'm definitely not in the camp that thinks that LSM needs to be "controlled", but on the other hand, I'm also not going to undo that commit unless there are good real arguments for undoing it (not just theoretical ones). For example, I do kind of see the point that a "real" security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Real usage scenarios with LSM modules, please speak up! Linus - To 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: LSM conversion to static interface
--- Thomas Fricaccia <[EMAIL PROTECTED]> wrote: > ... > > But then I noticed that, while the LSM would remain in existence, it was > being closed to out-of-tree security frameworks. Yikes! Since then, I've > been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". > > Since I know that the people behind these security frameworks are serious and > worthy folk of general good repute, I make no claims to worthyness, strongly deny being serious, and challenge you to demonstrate my good repute. > I've reluctantly come to the tentative > conclusion that the fix is in. Nope. I remain carefully neutral regarding the static/dynamic LSM issue. I was involved with the LSM when SELinux was still known as the Flask port and my development group proposed the first implementation, featuring authoritative hooks. Believe me, this is nothing compared to what we went through as a community then. > There seem to be powers at work that want LSM > closed, and they don't want much public discussion about it. The thing that killed authoritative hooks and that could kill LSM is the notion (which I refuse to take a side on) that out of tree facilities can use it to avoid the stated intent of the GPL. > I think this is bad technology. I've done due diligence by reviewing the > LKML discussion behind closing LSM (and there isn't much). I think the primary parties have gotten to the point where they just call out the arguments by number we've been over them so many times. > The technical > arguments seem to be (1) some people use the LSM interface for "non-security" > purposes, which is frowned upon, It goes way beyond frowned upon. The first use proposed for LSM was an audit implementation and that was throughly shredded. Additional restrictions on accesses only. > (2) it's difficult to properly secure a > system with an open-ended interface like LSM, and Which is pure feldercarb. > (3) my security framework > should be all any fair-minded person would ever want, so we won't let you use > something else. That argument makes Linus mad. > Exactly. > > Well, any system that permits loading code into "ring 0" can't be made > completely secure, so argument 2 reduces to argument 3, which is > transparently self-serving (and invalid). > > I submit for discussion the idea that a free and open operating system should > preserve as much freedom for the end user as possible. To this end, the > kernel should cleanly permit and support the deployment of ANY security > framework the end user desires, whether "in-tree" or "out-of-tree". I agree > that any out-of-tree LSM module should be licensed under the GPL (if for no > other reason than many current commercial support contracts require > non-tainted kernels). > > But restricting security frameworks to "in-tree" only is bad technology. > > "Freedom" includes the power to do bad things to yourself by, for example, > making poor choices in security frameworks. This possible and permitted end > result shouldn't be the concern of kernel developers. Making configuration > and installation of user-chosen frameworks as clean and safe as possible > should be. > > In my opinion. > > Though not sure why, I expect to be scorched by this. Try not to patronize > or condescend. Give me technical arguments backed by real data. Show me why > a home user or 10,000 node commercial enterprise shouldn't be able to choose > what he wants for security without having to jump through your hoops. Show > me why you shouldn't make his use of technology up to him, and as safely and > conveniently as you can contrive. The in-tree vs out-of-tree discussion is independent of LSM. Casey Schaufler [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: LSM conversion to static interface
--- Thomas Fricaccia [EMAIL PROTECTED] wrote: ... But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor in-tree. Since I know that the people behind these security frameworks are serious and worthy folk of general good repute, I make no claims to worthyness, strongly deny being serious, and challenge you to demonstrate my good repute. I've reluctantly come to the tentative conclusion that the fix is in. Nope. I remain carefully neutral regarding the static/dynamic LSM issue. I was involved with the LSM when SELinux was still known as the Flask port and my development group proposed the first implementation, featuring authoritative hooks. Believe me, this is nothing compared to what we went through as a community then. There seem to be powers at work that want LSM closed, and they don't want much public discussion about it. The thing that killed authoritative hooks and that could kill LSM is the notion (which I refuse to take a side on) that out of tree facilities can use it to avoid the stated intent of the GPL. I think this is bad technology. I've done due diligence by reviewing the LKML discussion behind closing LSM (and there isn't much). I think the primary parties have gotten to the point where they just call out the arguments by number we've been over them so many times. The technical arguments seem to be (1) some people use the LSM interface for non-security purposes, which is frowned upon, It goes way beyond frowned upon. The first use proposed for LSM was an audit implementation and that was throughly shredded. Additional restrictions on accesses only. (2) it's difficult to properly secure a system with an open-ended interface like LSM, and Which is pure feldercarb. (3) my security framework should be all any fair-minded person would ever want, so we won't let you use something else. That argument makes Linus mad. Exactly. Well, any system that permits loading code into ring 0 can't be made completely secure, so argument 2 reduces to argument 3, which is transparently self-serving (and invalid). I submit for discussion the idea that a free and open operating system should preserve as much freedom for the end user as possible. To this end, the kernel should cleanly permit and support the deployment of ANY security framework the end user desires, whether in-tree or out-of-tree. I agree that any out-of-tree LSM module should be licensed under the GPL (if for no other reason than many current commercial support contracts require non-tainted kernels). But restricting security frameworks to in-tree only is bad technology. Freedom includes the power to do bad things to yourself by, for example, making poor choices in security frameworks. This possible and permitted end result shouldn't be the concern of kernel developers. Making configuration and installation of user-chosen frameworks as clean and safe as possible should be. In my opinion. Though not sure why, I expect to be scorched by this. Try not to patronize or condescend. Give me technical arguments backed by real data. Show me why a home user or 10,000 node commercial enterprise shouldn't be able to choose what he wants for security without having to jump through your hoops. Show me why you shouldn't make his use of technology up to him, and as safely and conveniently as you can contrive. The in-tree vs out-of-tree discussion is independent of LSM. Casey Schaufler [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: LSM conversion to static interface
On Wed, 17 Oct 2007, Thomas Fricaccia wrote: But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor in-tree. Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. So Í don't think this is settled in any way - please keep discussing, and bringing it up. I'm definitely not in the camp that thinks that LSM needs to be controlled, but on the other hand, I'm also not going to undo that commit unless there are good real arguments for undoing it (not just theoretical ones). For example, I do kind of see the point that a real security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Real usage scenarios with LSM modules, please speak up! Linus - To 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/