Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
Hi Amon, On Thu, Feb 24, 2005 at 09:28:38AM +0100, Amon Ott wrote: > On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote: > > If you apply them (and I hope Linus will), capabilities is default > > and you can replace that by loading an LSM. You can stack capability > > on top of the primary LSM again, if the latter supports this. > > Well, not quite, although it is an improvement. > > As long as the capabilities module does not support stacking, anybody > needing capabilities and e.g. on-access scanning with Dazuko will > have to unload this module, load another module, and reload it. Nope. With the patchset applied you get capabilities as default behaviour, so with_out_ any LSM loaded. > This creates a nasty race condition. You can load any module to replace capabilities. No race condition (except that the point in time when the security_ops is actually updated is not well defined as there's no locking nor wmb()). You can also load the capabilities module on top of the default, but it won't change any behaviour then (other than eating a few percent performance in some paths). > BTW, what happens if capabilities > have been compiled static, not as a module? Why would you want to do this? > AFAIK, not all LSM modules provide correct stacking. True. Regards, -- Kurt Garloff, Director SUSE Labs, Novell Inc. pgp0fIaB5al7x.pgp Description: PGP signature
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
Hi Amon, On Thu, Feb 24, 2005 at 09:28:38AM +0100, Amon Ott wrote: On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote: If you apply them (and I hope Linus will), capabilities is default and you can replace that by loading an LSM. You can stack capability on top of the primary LSM again, if the latter supports this. Well, not quite, although it is an improvement. As long as the capabilities module does not support stacking, anybody needing capabilities and e.g. on-access scanning with Dazuko will have to unload this module, load another module, and reload it. Nope. With the patchset applied you get capabilities as default behaviour, so with_out_ any LSM loaded. This creates a nasty race condition. You can load any module to replace capabilities. No race condition (except that the point in time when the security_ops is actually updated is not well defined as there's no locking nor wmb()). You can also load the capabilities module on top of the default, but it won't change any behaviour then (other than eating a few percent performance in some paths). BTW, what happens if capabilities have been compiled static, not as a module? Why would you want to do this? AFAIK, not all LSM modules provide correct stacking. True. Regards, -- Kurt Garloff, Director SUSE Labs, Novell Inc. pgp0fIaB5al7x.pgp Description: PGP signature
Re: Thoughts on the "No Linux Security Modules framework" old claims
On Wed, 2005-02-23 at 13:37 -0800, Crispin Cowan wrote: > You are confused. It is Secure Computing Corporation that holds patents > that threaten SELinux > http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf The NSA made a statement in response to that statement a long time ago, and in any event, the patents in question have expired AFAICS. -- Stephen Smalley <[EMAIL PROTECTED]> National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote: > On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote: > > Without rechecking the current state: At least the last time I > > checked, the hardwired kernel capabilities were explicitely disabled > > when LSM got switched on. You had to use the capabilities LSM module > > instead, which was not able to stack. It always had to be the last in > > the chain, thus effectively sealing against any other LSM module to > > be loaded later. > > My patches posted Feb 13 fix this. > > If you apply them (and I hope Linus will), capabilities is default > and you can replace that by loading an LSM. You can stack capability > on top of the primary LSM again, if the latter supports this. Well, not quite, although it is an improvement. As long as the capabilities module does not support stacking, anybody needing capabilities and e.g. on-access scanning with Dazuko will have to unload this module, load another module, and reload it. This creates a nasty race condition. BTW, what happens if capabilities have been compiled static, not as a module? AFAIK, not all LSM modules provide correct stacking. At least all modules in the main line kernel should really support the official way. But this is just a few cents from someone not using LSM... Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 pgphp6iwnva6v.pgp Description: PGP signature
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
On Donnerstag 24 Februar 2005 01:55, Kurt Garloff wrote: On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote: Without rechecking the current state: At least the last time I checked, the hardwired kernel capabilities were explicitely disabled when LSM got switched on. You had to use the capabilities LSM module instead, which was not able to stack. It always had to be the last in the chain, thus effectively sealing against any other LSM module to be loaded later. My patches posted Feb 13 fix this. If you apply them (and I hope Linus will), capabilities is default and you can replace that by loading an LSM. You can stack capability on top of the primary LSM again, if the latter supports this. Well, not quite, although it is an improvement. As long as the capabilities module does not support stacking, anybody needing capabilities and e.g. on-access scanning with Dazuko will have to unload this module, load another module, and reload it. This creates a nasty race condition. BTW, what happens if capabilities have been compiled static, not as a module? AFAIK, not all LSM modules provide correct stacking. At least all modules in the main line kernel should really support the official way. But this is just a few cents from someone not using LSM... Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 pgphp6iwnva6v.pgp Description: PGP signature
Re: Thoughts on the No Linux Security Modules framework old claims
On Wed, 2005-02-23 at 13:37 -0800, Crispin Cowan wrote: You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf The NSA made a statement in response to that statement a long time ago, and in any event, the patents in question have expired AFAICS. -- Stephen Smalley [EMAIL PROTECTED] National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
Hi Amon, On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote: > > -> 5. Posix Capabilities Without Stacking Support > > > > I don't get the point of these claims. > > The LSM framework currently has full support for dynamic and > > logic-changeable POSIX.1e capabilities, using the capable() hook and > > calling capable(from whatever location inside any other hook to apply > > further logic checks (ie. in capable() check for jailed @current process > > and deny use of CAP_SYS_CHROOT and CAP_SYS_ADMIN or what-ever-else > > capabilities) or in syslog() to deny access to kernel messages stack to > > unprivileged users. > > Without rechecking the current state: At least the last time I > checked, the hardwired kernel capabilities were explicitely disabled > when LSM got switched on. You had to use the capabilities LSM module > instead, which was not able to stack. It always had to be the last in > the chain, thus effectively sealing against any other LSM module to > be loaded later. My patches posted Feb 13 fix this. If you apply them (and I hope Linus will), capabilities is default and you can replace that by loading an LSM. You can stack capability on top of the primary LSM again, if the latter supports this. Best regards, -- Kurt Garloff, Director SUSE Labs, Novell Inc. pgpoRQjzM1H0i.pgp Description: PGP signature
Re: Thoughts on the "No Linux Security Modules framework" old claims
El mié, 23-02-2005 a las 14:07 -0800, Crispin Cowan escribió: > If that is what you meant, then we had no issue. > > It looked like you were referring to Immunix because, in the quoted > text, one paragraph only discussed Immunix (by name) and then the > subsequent paragraph just said "them" and then talked about patents. > There was no mention of SCC. > > So even if you meant SCC, the casual reader only saw "Immunix" followed > by "patents", and would infer the obvious. Yes, my fault. I hope this will let readers out of any possible confusion, again, sorry for any inconveniences, wasn't my intention to create confusion around Immunix. At least from my side, I don't have fights nor bad relationships with anybody from Immunix, but also I just know a very few people from there. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
Lorenzo Hernández García-Hierro wrote: El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió: Lorenzo Hernández García-Hierro wrote: You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf Immunix has never threatened any open source project with patent infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of "the enterprise" which could lead to confusion.I apologize for that. If that is what you meant, then we had no issue. It looked like you were referring to Immunix because, in the quoted text, one paragraph only discussed Immunix (by name) and then the subsequent paragraph just said "them" and then talked about patents. There was no mention of SCC. So even if you meant SCC, the casual reader only saw "Immunix" followed by "patents", and would infer the obvious. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com - 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: Thoughts on the "No Linux Security Modules framework" old claims
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió: > Lorenzo Hernández García-Hierro wrote: > You are confused. It is Secure Computing Corporation that holds patents > that threaten SELinux > http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf > > Immunix has never threatened any open source project with patent > infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of "the enterprise" which could lead to confusion.I apologize for that. > Please get your facts straight before accusing someone of a serious act > like that. I'm sure I do, haven't accused someone, AFAIK. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the "No Linux Security Modules framework" old claims
Lorenzo Hernández García-Hierro wrote: Also, it was a pretty good thing from them this piece of work. Think that they investors may dislike the model they followed when the merge happened, anyways, and as an example, I pretty ignore those patents claims,for example, think that Type Enforcement (TE) is patented and before SELinux got in mainline the enterprise with rights on the patent made a public announcement about their "opening" and "for-free" use of their patented model. You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf Immunix has never threatened any open source project with patent infringement. Please get your facts straight before accusing someone of a serious act like that. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com - 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: Thoughts on the No Linux Security Modules framework old claims
Lorenzo Hernández García-Hierro wrote: Also, it was a pretty good thing from them this piece of work. Think that they investors may dislike the model they followed when the merge happened, anyways, and as an example, I pretty ignore those patents claims,for example, think that Type Enforcement (TE) is patented and before SELinux got in mainline the enterprise with rights on the patent made a public announcement about their opening and for-free use of their patented model. You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf Immunix has never threatened any open source project with patent infringement. Please get your facts straight before accusing someone of a serious act like that. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com - 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: Thoughts on the No Linux Security Modules framework old claims
El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió: Lorenzo Hernández García-Hierro wrote: You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf Immunix has never threatened any open source project with patent infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of the enterprise which could lead to confusion.I apologize for that. Please get your facts straight before accusing someone of a serious act like that. I'm sure I do, haven't accused someone, AFAIK. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the No Linux Security Modules framework old claims
Lorenzo Hernández García-Hierro wrote: El mié, 23-02-2005 a las 13:37 -0800, Crispin Cowan escribió: Lorenzo Hernández García-Hierro wrote: You are confused. It is Secure Computing Corporation that holds patents that threaten SELinux http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf Immunix has never threatened any open source project with patent infringement. You got it wrong, I was talking about SCC, not Immunix, relating the TE patent, anyways, it's my fault to don't refer to SCC instead of the enterprise which could lead to confusion.I apologize for that. If that is what you meant, then we had no issue. It looked like you were referring to Immunix because, in the quoted text, one paragraph only discussed Immunix (by name) and then the subsequent paragraph just said them and then talked about patents. There was no mention of SCC. So even if you meant SCC, the casual reader only saw Immunix followed by patents, and would infer the obvious. Crispin -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com - 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: Thoughts on the No Linux Security Modules framework old claims
El mié, 23-02-2005 a las 14:07 -0800, Crispin Cowan escribió: If that is what you meant, then we had no issue. It looked like you were referring to Immunix because, in the quoted text, one paragraph only discussed Immunix (by name) and then the subsequent paragraph just said them and then talked about patents. There was no mention of SCC. So even if you meant SCC, the casual reader only saw Immunix followed by patents, and would infer the obvious. Yes, my fault. I hope this will let readers out of any possible confusion, again, sorry for any inconveniences, wasn't my intention to create confusion around Immunix. At least from my side, I don't have fights nor bad relationships with anybody from Immunix, but also I just know a very few people from there. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
Hi Amon, On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote: - 5. Posix Capabilities Without Stacking Support I don't get the point of these claims. The LSM framework currently has full support for dynamic and logic-changeable POSIX.1e capabilities, using the capable() hook and calling capable(from whatever location inside any other hook to apply further logic checks (ie. in capable() check for jailed @current process and deny use of CAP_SYS_CHROOT and CAP_SYS_ADMIN or what-ever-else capabilities) or in syslog() to deny access to kernel messages stack to unprivileged users. Without rechecking the current state: At least the last time I checked, the hardwired kernel capabilities were explicitely disabled when LSM got switched on. You had to use the capabilities LSM module instead, which was not able to stack. It always had to be the last in the chain, thus effectively sealing against any other LSM module to be loaded later. My patches posted Feb 13 fix this. If you apply them (and I hope Linus will), capabilities is default and you can replace that by loading an LSM. You can stack capability on top of the primary LSM again, if the latter supports this. Best regards, -- Kurt Garloff, Director SUSE Labs, Novell Inc. pgpoRQjzM1H0i.pgp Description: PGP signature
Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
--- Amon Ott <[EMAIL PROTECTED]> wrote: > On Montag 21 Februar 2005 18:50, Casey Schaufler > wrote: > > > > --- Lorenzo Hernández García-Hierro > <[EMAIL PROTECTED]> > > wrote: > > > > > > > > There are cases where Linux DAC and MAC cannot > > > live happily together, > > > > because Linux DAC is too limited. > > > > > > Agreed. > > > > OKay, I'll bite. MAC and DAC are seperate. > > How is it that (the limited nature of) the DAC > > behavior makes a system with both unhappy? > > Back in 2001/2002 (versions 1.1.2 and 1.2.0), I > added DAC disabling > support first for the full filesystem ... There's way to much context missing for me to make heads or tails of what the issue was! = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
On Montag 21 Februar 2005 18:50, Casey Schaufler wrote: > > --- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> > wrote: > > > > > There are cases where Linux DAC and MAC cannot > > live happily together, > > > because Linux DAC is too limited. > > > > Agreed. > > OKay, I'll bite. MAC and DAC are seperate. > How is it that (the limited nature of) the DAC > behavior makes a system with both unhappy? Back in 2001/2002 (versions 1.1.2 and 1.2.0), I added DAC disabling support first for the full filesystem, then for selected dir trees and the converter tool linux2acl to RSBAC. I remember the actual problem coming from a provider of virtual web servers, but I cannot find the old mails. Too long ago. We were not able to solve the given problem without changing the Linux mode to 0777 (what means disabling DAC effectively). The reason to add this feature was that the dir mode should not be changed to 0777, because this would leave it completely unprotected with a non-RSBAC kernel. Some programs even check Linux modes and refuse to run with too many rights on their config files (what is usually a good idea, but sometimes problematic), this is also a convenient workaround for those. Personally, I do not use the object based override myself, but rather subject based override with additional Linux capabilities for selected accounts and/or programs (which can be set with the RSBAC CAP module, and which are dangerous because of LD_PRELOAD etc., if the environment is not controlled). This means that I have to use MAC configuration to restrict these users/programs afterwards, but that is not the problem. The moment you want to implement separation of duty for administration, you will again and again run against Linux DAC limits, because it only knows of one single admin. E.g. think of a separate account doing user management and adding user dirs. Amon. -- http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22 pgpHehBYqyGMw.pgp Description: PGP signature
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
--- Amon Ott [EMAIL PROTECTED] wrote: On Montag 21 Februar 2005 18:50, Casey Schaufler wrote: --- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote: There are cases where Linux DAC and MAC cannot live happily together, because Linux DAC is too limited. Agreed. OKay, I'll bite. MAC and DAC are seperate. How is it that (the limited nature of) the DAC behavior makes a system with both unhappy? Back in 2001/2002 (versions 1.1.2 and 1.2.0), I added DAC disabling support first for the full filesystem ... There's way to much context missing for me to make heads or tails of what the issue was! = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
--- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote: > > There are cases where Linux DAC and MAC cannot > live happily together, > > because Linux DAC is too limited. > > Agreed. OKay, I'll bite. MAC and DAC are seperate. How is it that (the limited nature of) the DAC behavior makes a system with both unhappy? = Casey Schaufler [EMAIL PROTECTED] __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo - 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: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
El lun, 21-02-2005 a las 11:19 +0100, Amon Ott escribió: > Hi folks, > > this is a late reply, because I was away for a week Hey ao, I was looking for you last week, nice to know you're back again ;) > > Documentation is a general problem in all projects, not only the > kernel. For me, this has never been an issue against LSM, although > some things, especially the weird stacking, should be documented to > avoid errors in implementation. Yes, I definitely agree with this, it's just that there's a need of people being able to contribute to it and have something done. > I strongly object against the "no overhead" argument, as I did many > times before. Overhead should be low, and it can be. Security comes > with some costs - you can either say "minimize overhead at all > costs", "maximize security at all costs", or try to make a good > balance. IMHO, the first has been selected as a guide for LSM to get > it accepted for mainline, which I still regard as a bad decision. Anyways, LSM does *not* provide the solution itself, so, commenting that the framework achieved such following the point 1 it's not completely accurate. It's just the *way* to deploy such security, unless you *deply and implement* something following such *way*. The costs come when you stop using the framework itself and making use of a solution that relies in it, then the overhead it's a thing in charge of the people who use and design the solution. > As pointed out in another reply, the actual real world overhead is > pretty small - even with more extensive and data gathering hooks like > those of RSBAC. Even making MAC decisions with logging checks before > the Linux DAC decisions should be acceptable, because in almost all > cases access will be granted anyway, so the order of calls does not > matter. I agree, but it depends on what do you want to achieve with such use of checks and logics. > This is a portability issue, these interfaces are very Linux specific, > some are even kernel version specific. The good old syscall is very > portable, and you can use a dispatcher to march dozens of calls > through this. Of course many interfaces are Linux specific, that's how they wanted to do them :) But, for example, this wasn't a reason to stop the effort to port SELinux functionalities to FreeBSD by the TrustedBSD project. Maybe it's not all the big the problem seems to be, or at least I hope. > There is a separate auditing subsystem now, but this was not my point. > Access decisions can be logged where they happen, or in some central > dispatcher. If it achieves the goal that you remark, why you should care on how exactly auditing happens within the framework if you are going to externally make use of such features? > Some people even want to override DAC, because it is quite limited. I > agree that this is dangerous - overriding should be off by default, > and there must be a big warning. Yes, but adding such checks add further overhead and if they are implmented in a dirty-#if-#etc manner, then it's not up for mainline, AFAIK, but this should be commented by an "official" kernel folk. > Actually, in RSBAC you have separate decisions for every active > decision module - up to 13 decisions for each request, plus the > runtime loaded modules registered through the REG facility. This is > not a problem, if it gives you a real benefit. My usual configuration > has 7 modules active, and the overhead is still low. Yes, but again, it depends if we are talking about high scalability systems or whatever uncommon-for-us (at least me, :P) environment. Then the lowest overhead can't be acceptable. > No, they do not override LSM checks - they cannot grant access, if LSM > wants to deny it. I mean that it depends on when the LSM hook is called, if before or after the DAC checks. > There are cases where Linux DAC and MAC cannot live happily together, > because Linux DAC is too limited. Agreed. > Again, I disagree. If you look at the age old discussion RSBAC vs. > SELinux between Stephen Smalley and me, he criticized that even the > few structures available in RSBAC hooks were dangerous. > > Now LSM exposes many, many more of them, and expects modules to use > them directly. Most RSBAC modules work without ever touching the few > structures. It depends on which scope you're talking about. From rom the side of the developer, it's a thing in charge of such developer to bother with them with care. > It is easy to freeze the kernel, but it is much easier, if you must > access lots of structures under locking conditions you do not know > about (and which might change between kernel versions). I agree with you with that point, anyways, that's a point I can't talk further. > The stacking problem is a direct consequence of the design with > distributed single user hooks. It has been criticized from the very > beginning and since then people have been trying to solve it. > > Another big problem is
Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
Hi folks, this is a late reply, because I was away for a week. On Dienstag 15 Februar 2005 23:38, Lorenzo Hernández García-Hierro wrote: > The purpose of this email is not re-opening the old flame on the > anti-LSM "pleas" that were subject of many discussion and > disappointments in certain developers and user groups. > > I will try to answer some of those in as much as possible organized > manner, without any personal opinion being show in front of the > objective analysis, and talking from the side of the developer who is > looking at the advantages and shortcomings of different solutions to > achieve almost the same thing (or at least, help when achieving it): > > [ http://www.rsbac.org/documentation/lsm.php ] This is my text, written some time ago. Some of the arguments are still valid, some others have been discussed in the mean time. > -> 1. Incompleteness > > AFAIK, the LSM framework has evolved much more since it got accepted in > the kernel mainline, many independent hackers contributed to it because > they thought that it needed further improvement, but even if people > could think in the beginning that it was going to be more a weakness > than a real security enhancement, nowadays there are many available > hooks, demonstrating how complete it can be, also, hooks can be added I have no doubt that many small improvements have been done, and LSM is more complete by now. My main objectives are still valid, though. > easily even if there's no (AFAIK, visible) documentation on it (a thing > I'm planning to solve in the forthcoming months, maybe updating the > current documentation at immunix.org), depending on how well the > developer knows about how LSM framework works and how the kernel DAC and > standard checks work themselves. Documentation is a general problem in all projects, not only the kernel. For me, this has never been an issue against LSM, although some things, especially the weird stacking, should be documented to avoid errors in implementation. > The point is that people must have in mind that hooks need to work as > they are supposed to do: no ABI/API breaking, no unexpected effects on > "normal operation flow" of the kernel (if it's not explicitly wanted), > no extra overhead or logics messing...etc. Agreed to "not breaking APIs", unless unavoidable to get some important functionality. And certainly, all extensions must be optional. I strongly object against the "no overhead" argument, as I did many times before. Overhead should be low, and it can be. Security comes with some costs - you can either say "minimize overhead at all costs", "maximize security at all costs", or try to make a good balance. IMHO, the first has been selected as a guide for LSM to get it accepted for mainline, which I still regard as a bad decision. As pointed out in another reply, the actual real world overhead is pretty small - even with more extensive and data gathering hooks like those of RSBAC. Even making MAC decisions with logging checks before the Linux DAC decisions should be acceptable, because in almost all cases access will be granted anyway, so the order of calls does not matter. > In addition, LKMs using the LSM framework *don't need* to use *only* a > procfs sysctl interface or something alike for providing > user-land<->kernel space communication capabilities. > We have more options: registering a sysfs-based subsystem for example. This is a portability issue, these interfaces are very Linux specific, some are even kernel version specific. The good old syscall is very portable, and you can use a dispatcher to march dozens of calls through this. > -> 2. Access Control Only > > Yes, and that's noticed from the "official" documentation. > But, who says that we can't place auditing facilities inside the > existing hooks? or even file system linking related tweaks? There is a separate auditing subsystem now, but this was not my point. Access decisions can be logged where they happen, or in some central dispatcher. > Also, why disabling DAC? It's not a good idea if you have to handle > *ALL* at *your OWN*. > And it represents, BTW, a real performance hit because you do *double > checking* or logics overhead. Some people even want to override DAC, because it is quite limited. I agree that this is dangerous - overriding should be off by default, and there must be a big warning. Actually, in RSBAC you have separate decisions for every active decision module - up to 13 decisions for each request, plus the runtime loaded modules registered through the REG facility. This is not a problem, if it gives you a real benefit. My usual configuration has 7 modules active, and the overhead is still low. > DAC checks normally *override* LSM checks, except in certain situations > when both pre- and post-processing LSM hooks are used. No, they do not override LSM checks - they cannot grant access, if LSM wants to deny it. > An operation must at
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
Hi folks, this is a late reply, because I was away for a week. On Dienstag 15 Februar 2005 23:38, Lorenzo Hernández García-Hierro wrote: The purpose of this email is not re-opening the old flame on the anti-LSM pleas that were subject of many discussion and disappointments in certain developers and user groups. I will try to answer some of those in as much as possible organized manner, without any personal opinion being show in front of the objective analysis, and talking from the side of the developer who is looking at the advantages and shortcomings of different solutions to achieve almost the same thing (or at least, help when achieving it): [ http://www.rsbac.org/documentation/lsm.php ] This is my text, written some time ago. Some of the arguments are still valid, some others have been discussed in the mean time. - 1. Incompleteness AFAIK, the LSM framework has evolved much more since it got accepted in the kernel mainline, many independent hackers contributed to it because they thought that it needed further improvement, but even if people could think in the beginning that it was going to be more a weakness than a real security enhancement, nowadays there are many available hooks, demonstrating how complete it can be, also, hooks can be added I have no doubt that many small improvements have been done, and LSM is more complete by now. My main objectives are still valid, though. easily even if there's no (AFAIK, visible) documentation on it (a thing I'm planning to solve in the forthcoming months, maybe updating the current documentation at immunix.org), depending on how well the developer knows about how LSM framework works and how the kernel DAC and standard checks work themselves. Documentation is a general problem in all projects, not only the kernel. For me, this has never been an issue against LSM, although some things, especially the weird stacking, should be documented to avoid errors in implementation. The point is that people must have in mind that hooks need to work as they are supposed to do: no ABI/API breaking, no unexpected effects on normal operation flow of the kernel (if it's not explicitly wanted), no extra overhead or logics messing...etc. Agreed to not breaking APIs, unless unavoidable to get some important functionality. And certainly, all extensions must be optional. I strongly object against the no overhead argument, as I did many times before. Overhead should be low, and it can be. Security comes with some costs - you can either say minimize overhead at all costs, maximize security at all costs, or try to make a good balance. IMHO, the first has been selected as a guide for LSM to get it accepted for mainline, which I still regard as a bad decision. As pointed out in another reply, the actual real world overhead is pretty small - even with more extensive and data gathering hooks like those of RSBAC. Even making MAC decisions with logging checks before the Linux DAC decisions should be acceptable, because in almost all cases access will be granted anyway, so the order of calls does not matter. In addition, LKMs using the LSM framework *don't need* to use *only* a procfs sysctl interface or something alike for providing user-land-kernel space communication capabilities. We have more options: registering a sysfs-based subsystem for example. This is a portability issue, these interfaces are very Linux specific, some are even kernel version specific. The good old syscall is very portable, and you can use a dispatcher to march dozens of calls through this. - 2. Access Control Only Yes, and that's noticed from the official documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? There is a separate auditing subsystem now, but this was not my point. Access decisions can be logged where they happen, or in some central dispatcher. Also, why disabling DAC? It's not a good idea if you have to handle *ALL* at *your OWN*. And it represents, BTW, a real performance hit because you do *double checking* or logics overhead. Some people even want to override DAC, because it is quite limited. I agree that this is dangerous - overriding should be off by default, and there must be a big warning. Actually, in RSBAC you have separate decisions for every active decision module - up to 13 decisions for each request, plus the runtime loaded modules registered through the REG facility. This is not a problem, if it gives you a real benefit. My usual configuration has 7 modules active, and the overhead is still low. DAC checks normally *override* LSM checks, except in certain situations when both pre- and post-processing LSM hooks are used. No, they do not override LSM checks - they cannot grant access, if LSM wants to deny it. An operation must at least be (if no override present): 1) DAC compliant, 2)
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
El lun, 21-02-2005 a las 11:19 +0100, Amon Ott escribió: Hi folks, this is a late reply, because I was away for a week Hey ao, I was looking for you last week, nice to know you're back again ;) Documentation is a general problem in all projects, not only the kernel. For me, this has never been an issue against LSM, although some things, especially the weird stacking, should be documented to avoid errors in implementation. Yes, I definitely agree with this, it's just that there's a need of people being able to contribute to it and have something done. I strongly object against the no overhead argument, as I did many times before. Overhead should be low, and it can be. Security comes with some costs - you can either say minimize overhead at all costs, maximize security at all costs, or try to make a good balance. IMHO, the first has been selected as a guide for LSM to get it accepted for mainline, which I still regard as a bad decision. Anyways, LSM does *not* provide the solution itself, so, commenting that the framework achieved such following the point 1 it's not completely accurate. It's just the *way* to deploy such security, unless you *deply and implement* something following such *way*. The costs come when you stop using the framework itself and making use of a solution that relies in it, then the overhead it's a thing in charge of the people who use and design the solution. As pointed out in another reply, the actual real world overhead is pretty small - even with more extensive and data gathering hooks like those of RSBAC. Even making MAC decisions with logging checks before the Linux DAC decisions should be acceptable, because in almost all cases access will be granted anyway, so the order of calls does not matter. I agree, but it depends on what do you want to achieve with such use of checks and logics. This is a portability issue, these interfaces are very Linux specific, some are even kernel version specific. The good old syscall is very portable, and you can use a dispatcher to march dozens of calls through this. Of course many interfaces are Linux specific, that's how they wanted to do them :) But, for example, this wasn't a reason to stop the effort to port SELinux functionalities to FreeBSD by the TrustedBSD project. Maybe it's not all the big the problem seems to be, or at least I hope. There is a separate auditing subsystem now, but this was not my point. Access decisions can be logged where they happen, or in some central dispatcher. If it achieves the goal that you remark, why you should care on how exactly auditing happens within the framework if you are going to externally make use of such features? Some people even want to override DAC, because it is quite limited. I agree that this is dangerous - overriding should be off by default, and there must be a big warning. Yes, but adding such checks add further overhead and if they are implmented in a dirty-#if-#etc manner, then it's not up for mainline, AFAIK, but this should be commented by an official kernel folk. Actually, in RSBAC you have separate decisions for every active decision module - up to 13 decisions for each request, plus the runtime loaded modules registered through the REG facility. This is not a problem, if it gives you a real benefit. My usual configuration has 7 modules active, and the overhead is still low. Yes, but again, it depends if we are talking about high scalability systems or whatever uncommon-for-us (at least me, :P) environment. Then the lowest overhead can't be acceptable. No, they do not override LSM checks - they cannot grant access, if LSM wants to deny it. I mean that it depends on when the LSM hook is called, if before or after the DAC checks. There are cases where Linux DAC and MAC cannot live happily together, because Linux DAC is too limited. Agreed. Again, I disagree. If you look at the age old discussion RSBAC vs. SELinux between Stephen Smalley and me, he criticized that even the few structures available in RSBAC hooks were dangerous. Now LSM exposes many, many more of them, and expects modules to use them directly. Most RSBAC modules work without ever touching the few structures. It depends on which scope you're talking about. From rom the side of the developer, it's a thing in charge of such developer to bother with them with care. It is easy to freeze the kernel, but it is much easier, if you must access lots of structures under locking conditions you do not know about (and which might change between kernel versions). I agree with you with that point, anyways, that's a point I can't talk further. The stacking problem is a direct consequence of the design with distributed single user hooks. It has been criticized from the very beginning and since then people have been trying to solve it. Another big problem is that there is only one pointer at some kernel structures for
Re: [rsbac] Thoughts on the No Linux Security Modules framework old claims
--- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote: There are cases where Linux DAC and MAC cannot live happily together, because Linux DAC is too limited. Agreed. OKay, I'll bite. MAC and DAC are seperate. How is it that (the limited nature of) the DAC behavior makes a system with both unhappy? = Casey Schaufler [EMAIL PROTECTED] __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo - 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: Thoughts on the "No Linux Security Modules framework" old claims
On Wed, 16 Feb 2005 07:52:51 PST, Casey Schaufler said: > The advice given by the NSA during our B1 > evaluation was that is was that in the case > above was that the MAC check should be done > first (because it's more important) and > because you want the audit record to report > the MAC failure whenever possible. The > team advised us that if we didn't do the MAC > check first we would have a tough row to hoe > explaining the design decision and an even > tougher time explaining that the audit of > MAC criteria had been met. Fine advice, if the LSM exits had in fact been structured that way. But the LSM hooks are where they are, and as a result not useful for auditing. As others noted, the current 2.6 kernel *does* have a separate audit framework (although it will still report DAC failures in preference to MAC failures). I admit having no good idea how to solve that issue, other than having the audit framework do a dummy LSM call to see if a MAC failure would have been reported as well if it's an audited syscall. But that's still quite high on the bletcherous scale pgpAQFB8jRcqp.pgp Description: PGP signature
Re: Thoughts on the "No Linux Security Modules framework" old claims
--- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote: > ... but think it's main > shortcoming is that it cuts > performance Ya'know, I keep hearing this assertion, but the evidence of actual system implementations that have been measured to determine this "performance impact" is that there is no difference except in contrived cases. In contrived cases the performance is better if you do the "special" checks first. > and adds further overlapping to the DAC > checks, that should > be the first ones being called (as most times they > do) and then apply > the LSM basis, so, post-processing will be only > required if the DAC > checks get in override or passed, without adding > too-much overhead to > the current behavior. No. There are a number of reasons, including audit and nearline storage issues that make it important to do the special checks first. Some access control schemes may not work if the Classic DAC check is done first. > So, I just agree partially, but yes, maybe modifying > the DAC checks > themselves and add what-ever-else helper function to > handle by-default > auditing in certain operations could be interesting. I remain a advocate of authoritative hooks. > I think it could be worthy to have a roadmap in a > wiki or even talk > about a one, trying to write it, so, we all could > know what needs to be > improved and done, getting a higher percentage of > mainline-accepted > approaches. Sigh. = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: Thoughts on the "No Linux Security Modules framework" old claims
--- [EMAIL PROTECTED] wrote: > Many auditing policies require an audit event to be > generated if the operation > is rejected by *either* the DAC (as implemented by > the file permissions > and possibly ACLs) *or* the MAC (as implemented by > the LSM exit). However, > in most (all?) cases, the DAC check is made *first*, > and the LSM exit isn't > even called if the DAC check fails. As a result, if > you try to open() a file > and get -EPERM due to the file permissions, the LSM > exit isn't called and > you can't cut an audit record there. The advice given by the NSA during our B1 evaluation was that is was that in the case above was that the MAC check should be done first (because it's more important) and because you want the audit record to report the MAC failure whenever possible. The team advised us that if we didn't do the MAC check first we would have a tough row to hoe explaining the design decision and an even tougher time explaining that the audit of MAC criteria had been met. = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: Thoughts on the "No Linux Security Modules framework" old claims
On Wed, 2005-02-16 at 08:29, Lorenzo HernÃndez GarcÃa-Hierro wrote: > Yes, there are many cases that apply to such scenario and context, this > may be worth to work on, but think it's main shortcoming is that it cuts > performance and adds further overlapping to the DAC checks, that should > be the first ones being called (as most times they do) and then apply > the LSM basis, so, post-processing will be only required if the DAC > checks get in override or passed, without adding too-much overhead to > the current behavior. > > So, I just agree partially, but yes, maybe modifying the DAC checks > themselves and add what-ever-else helper function to handle by-default > auditing in certain operations could be interesting. Audit is being handled by a separate audit framework, not by LSM. There is already support in the Linux 2.6 kernel for auditing at syscall exit (thereby guaranteeing that you capture the final return value in all cases), with the ability of an LSM to enable such auditing for a particular event from its hook functions. Further, there is ongoing work (see the linux-audit mailing list) for a set of audit-related hooks that will allow auditing based on object identity and the requested mode separate from any particular LSM. -- Stephen Smalley <[EMAIL PROTECTED]> National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
El mar, 15-02-2005 a las 23:21 -0500, [EMAIL PROTECTED] escribió: > On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= > =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > > > Yes, and that's noticed from the "official" documentation. > > But, who says that we can't place auditing facilities inside the > > existing hooks? or even file system linking related tweaks? > > Many auditing policies require an audit event to be generated if the operation > is rejected by *either* the DAC (as implemented by the file permissions > and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, > in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't > even called if the DAC check fails. As a result, if you try to open() a file > and get -EPERM due to the file permissions, the LSM exit isn't called and > you can't cut an audit record there. Yes, there are many cases that apply to such scenario and context, this may be worth to work on, but think it's main shortcoming is that it cuts performance and adds further overlapping to the DAC checks, that should be the first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. I think it could be worthy to have a roadmap in a wiki or even talk about a one, trying to write it, so, we all could know what needs to be improved and done, getting a higher percentage of mainline-accepted approaches. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the No Linux Security Modules framework old claims
El mar, 15-02-2005 a las 23:21 -0500, [EMAIL PROTECTED] escribió: On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: Yes, and that's noticed from the official documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? Many auditing policies require an audit event to be generated if the operation is rejected by *either* the DAC (as implemented by the file permissions and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. Yes, there are many cases that apply to such scenario and context, this may be worth to work on, but think it's main shortcoming is that it cuts performance and adds further overlapping to the DAC checks, that should be the first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. I think it could be worthy to have a roadmap in a wiki or even talk about a one, trying to write it, so, we all could know what needs to be improved and done, getting a higher percentage of mainline-accepted approaches. Cheers, -- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] [1024D/6F2B2DEC] [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Thoughts on the No Linux Security Modules framework old claims
On Wed, 2005-02-16 at 08:29, Lorenzo Hernndez Garca-Hierro wrote: Yes, there are many cases that apply to such scenario and context, this may be worth to work on, but think it's main shortcoming is that it cuts performance and adds further overlapping to the DAC checks, that should be the first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. Audit is being handled by a separate audit framework, not by LSM. There is already support in the Linux 2.6 kernel for auditing at syscall exit (thereby guaranteeing that you capture the final return value in all cases), with the ability of an LSM to enable such auditing for a particular event from its hook functions. Further, there is ongoing work (see the linux-audit mailing list) for a set of audit-related hooks that will allow auditing based on object identity and the requested mode separate from any particular LSM. -- Stephen Smalley [EMAIL PROTECTED] National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the No Linux Security Modules framework old claims
--- [EMAIL PROTECTED] wrote: Many auditing policies require an audit event to be generated if the operation is rejected by *either* the DAC (as implemented by the file permissions and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. The advice given by the NSA during our B1 evaluation was that is was that in the case above was that the MAC check should be done first (because it's more important) and because you want the audit record to report the MAC failure whenever possible. The team advised us that if we didn't do the MAC check first we would have a tough row to hoe explaining the design decision and an even tougher time explaining that the audit of MAC criteria had been met. = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: Thoughts on the No Linux Security Modules framework old claims
--- Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote: ... but think it's main shortcoming is that it cuts performance Ya'know, I keep hearing this assertion, but the evidence of actual system implementations that have been measured to determine this performance impact is that there is no difference except in contrived cases. In contrived cases the performance is better if you do the special checks first. and adds further overlapping to the DAC checks, that should be the first ones being called (as most times they do) and then apply the LSM basis, so, post-processing will be only required if the DAC checks get in override or passed, without adding too-much overhead to the current behavior. No. There are a number of reasons, including audit and nearline storage issues that make it important to do the special checks first. Some access control schemes may not work if the Classic DAC check is done first. So, I just agree partially, but yes, maybe modifying the DAC checks themselves and add what-ever-else helper function to handle by-default auditing in certain operations could be interesting. I remain a advocate of authoritative hooks. I think it could be worthy to have a roadmap in a wiki or even talk about a one, trying to write it, so, we all could know what needs to be improved and done, getting a higher percentage of mainline-accepted approaches. Sigh. = Casey Schaufler [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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: Thoughts on the No Linux Security Modules framework old claims
On Wed, 16 Feb 2005 07:52:51 PST, Casey Schaufler said: The advice given by the NSA during our B1 evaluation was that is was that in the case above was that the MAC check should be done first (because it's more important) and because you want the audit record to report the MAC failure whenever possible. The team advised us that if we didn't do the MAC check first we would have a tough row to hoe explaining the design decision and an even tougher time explaining that the audit of MAC criteria had been met. Fine advice, if the LSM exits had in fact been structured that way. But the LSM hooks are where they are, and as a result not useful for auditing. As others noted, the current 2.6 kernel *does* have a separate audit framework (although it will still report DAC failures in preference to MAC failures). I admit having no good idea how to solve that issue, other than having the audit framework do a dummy LSM call to see if a MAC failure would have been reported as well if it's an audited syscall. But that's still quite high on the bletcherous scale pgpAQFB8jRcqp.pgp Description: PGP signature
Re: Thoughts on the "No Linux Security Modules framework" old claims
On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > Yes, and that's noticed from the "official" documentation. > But, who says that we can't place auditing facilities inside the > existing hooks? or even file system linking related tweaks? Many auditing policies require an audit event to be generated if the operation is rejected by *either* the DAC (as implemented by the file permissions and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. pgpIg1VbKxmpP.pgp Description: PGP signature
Thoughts on the "No Linux Security Modules framework" old claims
Hi, The purpose of this email is not re-opening the old flame on the anti-LSM "pleas" that were subject of many discussion and disappointments in certain developers and user groups. I will try to answer some of those in as much as possible organized manner, without any personal opinion being show in front of the objective analysis, and talking from the side of the developer who is looking at the advantages and shortcomings of different solutions to achieve almost the same thing (or at least, help when achieving it): [ http://www.rsbac.org/documentation/lsm.php ] -> 1. Incompleteness AFAIK, the LSM framework has evolved much more since it got accepted in the kernel mainline, many independent hackers contributed to it because they thought that it needed further improvement, but even if people could think in the beginning that it was going to be more a weakness than a real security enhancement, nowadays there are many available hooks, demonstrating how complete it can be, also, hooks can be added easily even if there's no (AFAIK, visible) documentation on it (a thing I'm planning to solve in the forthcoming months, maybe updating the current documentation at immunix.org), depending on how well the developer knows about how LSM framework works and how the kernel DAC and standard checks work themselves. The point is that people must have in mind that hooks need to work as they are supposed to do: no ABI/API breaking, no unexpected effects on "normal operation flow" of the kernel (if it's not explicitly wanted), no extra overhead or logics messing...etc. In addition, LKMs using the LSM framework *don't need* to use *only* a procfs sysctl interface or something alike for providing user-land<->kernel space communication capabilities. We have more options: registering a sysfs-based subsystem for example. During the research I was doing recently on the current hook'ing architecture, I wrote an useless patch to add a hook for sys_chmod(), just because I forgot that notify_change() calls an existing LSM hook, that can handle most file modes changing operation. I just mean that I'm working daily with them and I forgot *ALL* about it, so, it's not strange that many people could simply forget that LSM makes developers and the kernel itself being able of hooks re-using within similar or related syscalls that have in common some kernel objects or standard checks. In short, it's a complicated architecture that needs further research in order to make solid critics on it, same for RSBAC (which it's not known for me in terms of internal design and implementation, just having the idea from the available documentation). Both are good, but we must admit it, and we must admit that finally LSM got in mainline and now seems getting more solid and stable. -> 2. Access Control Only Yes, and that's noticed from the "official" documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? Also, why disabling DAC? It's not a good idea if you have to handle *ALL* at *your OWN*. And it represents, BTW, a real performance hit because you do *double checking* or logics overhead. DAC checks normally *override* LSM checks, except in certain situations when both pre- and post-processing LSM hooks are used. An operation must at least be (if no override present): 1) DAC compliant, 2) LSM->user compliant. Going into personal thoughts, what's the point of having a *real pain* and maintenance overhead due to modifying the by-default permissions and access control basis with your own, even if they can live and have sex together? You can split up yours and maintain DAC alone and working with RSBAC when the user chooses explicitly to use the RSBAC-basis checking, as LSM does. -> 3. Low Level Internal Data Structures I agree that incorrect handling of the structures on-flow can lead to kernel stack or runtime corruption, but this is nonsense to be claimed as an LSM fault. I had freezes many times when I started doing some development with the LSM framework, but it was more because of my incompetency than the framework itself. When new kernel releases hit the streets, LSM framework is stable and compatible with it, as many people contributes and also the folks maintaining it are good and responsible ones. Common mistakes that lead to system take down are more pointer and structures wrong initialization, but again, those are related with the developer side. (It's the cost of doing "low level" sexy-thing development ;) ) -> 4. Stacking I agree with this, but AFAIK there has been work done in this area, as far it comes to mind, Serge Hallyn is someone to be asked about it. Stacking seems not fully support in a out-of-the-box working manner, nope, you need further work from your side to let other modules using the framework being subjects of redirection from your hooks. Anyways, we can even work together on the complete nifty-smooth-good smelling solution
Thoughts on the No Linux Security Modules framework old claims
Hi, The purpose of this email is not re-opening the old flame on the anti-LSM pleas that were subject of many discussion and disappointments in certain developers and user groups. I will try to answer some of those in as much as possible organized manner, without any personal opinion being show in front of the objective analysis, and talking from the side of the developer who is looking at the advantages and shortcomings of different solutions to achieve almost the same thing (or at least, help when achieving it): [ http://www.rsbac.org/documentation/lsm.php ] - 1. Incompleteness AFAIK, the LSM framework has evolved much more since it got accepted in the kernel mainline, many independent hackers contributed to it because they thought that it needed further improvement, but even if people could think in the beginning that it was going to be more a weakness than a real security enhancement, nowadays there are many available hooks, demonstrating how complete it can be, also, hooks can be added easily even if there's no (AFAIK, visible) documentation on it (a thing I'm planning to solve in the forthcoming months, maybe updating the current documentation at immunix.org), depending on how well the developer knows about how LSM framework works and how the kernel DAC and standard checks work themselves. The point is that people must have in mind that hooks need to work as they are supposed to do: no ABI/API breaking, no unexpected effects on normal operation flow of the kernel (if it's not explicitly wanted), no extra overhead or logics messing...etc. In addition, LKMs using the LSM framework *don't need* to use *only* a procfs sysctl interface or something alike for providing user-land-kernel space communication capabilities. We have more options: registering a sysfs-based subsystem for example. During the research I was doing recently on the current hook'ing architecture, I wrote an useless patch to add a hook for sys_chmod(), just because I forgot that notify_change() calls an existing LSM hook, that can handle most file modes changing operation. I just mean that I'm working daily with them and I forgot *ALL* about it, so, it's not strange that many people could simply forget that LSM makes developers and the kernel itself being able of hooks re-using within similar or related syscalls that have in common some kernel objects or standard checks. In short, it's a complicated architecture that needs further research in order to make solid critics on it, same for RSBAC (which it's not known for me in terms of internal design and implementation, just having the idea from the available documentation). Both are good, but we must admit it, and we must admit that finally LSM got in mainline and now seems getting more solid and stable. - 2. Access Control Only Yes, and that's noticed from the official documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? Also, why disabling DAC? It's not a good idea if you have to handle *ALL* at *your OWN*. And it represents, BTW, a real performance hit because you do *double checking* or logics overhead. DAC checks normally *override* LSM checks, except in certain situations when both pre- and post-processing LSM hooks are used. An operation must at least be (if no override present): 1) DAC compliant, 2) LSM-user compliant. Going into personal thoughts, what's the point of having a *real pain* and maintenance overhead due to modifying the by-default permissions and access control basis with your own, even if they can live and have sex together? You can split up yours and maintain DAC alone and working with RSBAC when the user chooses explicitly to use the RSBAC-basis checking, as LSM does. - 3. Low Level Internal Data Structures I agree that incorrect handling of the structures on-flow can lead to kernel stack or runtime corruption, but this is nonsense to be claimed as an LSM fault. I had freezes many times when I started doing some development with the LSM framework, but it was more because of my incompetency than the framework itself. When new kernel releases hit the streets, LSM framework is stable and compatible with it, as many people contributes and also the folks maintaining it are good and responsible ones. Common mistakes that lead to system take down are more pointer and structures wrong initialization, but again, those are related with the developer side. (It's the cost of doing low level sexy-thing development ;) ) - 4. Stacking I agree with this, but AFAIK there has been work done in this area, as far it comes to mind, Serge Hallyn is someone to be asked about it. Stacking seems not fully support in a out-of-the-box working manner, nope, you need further work from your side to let other modules using the framework being subjects of redirection from your hooks. Anyways, we can even work together on the complete nifty-smooth-good smelling solution and avoid the
Re: Thoughts on the No Linux Security Modules framework old claims
On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: Yes, and that's noticed from the official documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? Many auditing policies require an audit event to be generated if the operation is rejected by *either* the DAC (as implemented by the file permissions and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. pgpIg1VbKxmpP.pgp Description: PGP signature
