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: [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: [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
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/
