Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
Stephen Smalley wrote: >> It is if I have to maintain a special pieces of code for each possible LSM. >> One piece for SELinux, one piece for AppArmour, one piece for Smack, one >> piece >> for Casey's security system. That sounds like a pain. >> > All your code has to do is invoke a function provided by libselinux. If > at some later time a liblsm is introduced that provides a common > front-end to a libselinux, libsmack, ..., then you can use that. But it > doesn't exist today. But it all just becomes a simple function call > regardless. > libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
override, given the daemon's own security context? That seems entirely > reasonable to me. > That semantically maps well to the AppArmor change_profile() API, so conceptually it should work. It would be easier if you did that in user space instead of in the kernel, I don't know if it causes a problem to attempt to kind-of call change_profile() from within the kernel. Notably, change_profile can fail, so what does your kernel module do when the attempt to change security context fails? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
a problem to attempt to kind-of call change_profile() from within the kernel. Notably, change_profile can fail, so what does your kernel module do when the attempt to change security context fails? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
Stephen Smalley wrote: It is if I have to maintain a special pieces of code for each possible LSM. One piece for SELinux, one piece for AppArmour, one piece for Smack, one piece for Casey's security system. That sounds like a pain. All your code has to do is invoke a function provided by libselinux. If at some later time a liblsm is introduced that provides a common front-end to a libselinux, libsmack, ..., then you can use that. But it doesn't exist today. But it all just becomes a simple function call regardless. libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Out of tree module using LSM
James Morris wrote: > On Fri, 30 Nov 2007, Crispin Cowan wrote: >> restored faces a lot of challenges, but I hope that some kind of >> solution can be found, because the alternative is to effectively force >> vendors like Sophos to do it the "dirty" way by fishing in memory for >> the syscall table. >> > I don't think this is quite correct. > > The alternative is to engage with the kernel community to become part of > the development process, to ensure that appropriate APIs are implemented, > and to get code upstream before shipping it. > That would be part of the "some kind of solution can be found" so I think we are in agreement here. > In any case, a patch to revert the dynamic aspect of LSM has been posted > by Arjan (and acked by myself) for the case of valid out of tree users. > The only case of this so far has been Multiadm, although there seems to be > no reason for it to stay out of tree. > Dazuko. It has the same yucky code issues as Talpa, but AFAIK is pure GPL2 and thus is clean on the license issues. That these modules are valid modules that users want to use, are GPL clean, and are *not* something LKML wants to upstream because of code issues, is precisely why the LSM interface makes sense. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Out of tree module using LSM
Tvrtko A. Ursulin wrote: > During one recent LKML discussion > (http://marc.info/?l=linux-kernelm=119267398722085w=2) about > LSM going > static you called for LSM users to speak up. Great big clue: If "LSM" is in the subject line, then cc: the LSM list [EMAIL PROTECTED] For LSM readers seeing this for the first time, the thread starts here and goes for a while http://lkml.org/lkml/2007/11/28/106 I'm sympathetic to the desire to be able to provide a 3rd party LSM that end users can install on their systems. That is why I advocated for keeping the dynamic LSM interface. Getting the dynamic interface restored faces a lot of challenges, but I hope that some kind of solution can be found, because the alternative is to effectively force vendors like Sophos to do it the "dirty" way by fishing in memory for the syscall table. I would much rather that Linux offers you a way to do what you need to do than force you to do nasty things. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Out of tree module using LSM
James Morris wrote: On Fri, 30 Nov 2007, Crispin Cowan wrote: restored faces a lot of challenges, but I hope that some kind of solution can be found, because the alternative is to effectively force vendors like Sophos to do it the dirty way by fishing in memory for the syscall table. I don't think this is quite correct. The alternative is to engage with the kernel community to become part of the development process, to ensure that appropriate APIs are implemented, and to get code upstream before shipping it. That would be part of the some kind of solution can be found so I think we are in agreement here. In any case, a patch to revert the dynamic aspect of LSM has been posted by Arjan (and acked by myself) for the case of valid out of tree users. The only case of this so far has been Multiadm, although there seems to be no reason for it to stay out of tree. Dazuko. It has the same yucky code issues as Talpa, but AFAIK is pure GPL2 and thus is clean on the license issues. That these modules are valid modules that users want to use, are GPL clean, and are *not* something LKML wants to upstream because of code issues, is precisely why the LSM interface makes sense. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Out of tree module using LSM
Tvrtko A. Ursulin wrote: During one recent LKML discussion (http://marc.info/?l=linux-kernelamp;m=119267398722085amp;w=2) about LSM going static you called for LSM users to speak up. Great big clue: If LSM is in the subject line, then cc: the LSM list [EMAIL PROTECTED] For LSM readers seeing this for the first time, the thread starts here and goes for a while http://lkml.org/lkml/2007/11/28/106 I'm sympathetic to the desire to be able to provide a 3rd party LSM that end users can install on their systems. That is why I advocated for keeping the dynamic LSM interface. Getting the dynamic interface restored faces a lot of challenges, but I hope that some kind of solution can be found, because the alternative is to effectively force vendors like Sophos to do it the dirty way by fishing in memory for the syscall table. I would much rather that Linux offers you a way to do what you need to do than force you to do nasty things. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Kyle Moffett wrote: > On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: >> Andrew Morgan wrote: >>> It feels to me as if a MAC "override capability" is, if true to its >>> name, extra to the MAC model; any MAC model that needs an 'override' >>> to function seems under-specified... SELinux clearly feels no need >>> for one, >> That's not quite right. More specifically, it already has one in the >> form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" >> permission. Its not that they don't need one, it is that they already >> have one. They get to have one because they allow you to actually >> write a policy that is more nuanced than "process label must dominate >> object label". > Actually, a fully-secured strict-mode SELinux system will have no > unconfined_t processes; none of my test systems have any. Generally > "unconfined_t" is used for situations similar to what AppArmor was > designed for, where the only "interesting" security is that of the > daemon (which is properly labelled) and one or more of the users are > unconfined. Interesting. In a Targeted Policy, you do your policy administration from unconfined_t. But how do you administer a Strict Policy machine? I can think of 2 ways: * reboot to single user and hack away o hurts usability because you need physical presence to change policy, but is highly secure * there is some type that is tighter than unconfined_t but none the less has sufficient privilege to change policy o to me, this would be semantically equivalent to unconfined_t, because any rogue code or user with this type could then fabricate unconfined_t and do what they want > Even then "unconfined_t" is not an implicit part of the policy, it is > explicitly given the ability to take any action on any object by rules > in the policy, and it typically still falls under a few MLS labeling > restrictions even in the targeted policy. Which is more or less the distinction I was trying to draw between hierarchical systems (MLS) and policy systems (SELinux TE, AppArmor, etc.) that policy systems let you write yourself an escape hatch in policy, and MLS systems don't. Or at least they need to kludge something :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Andrew Morgan wrote: > Its not so much why you are wrong, as being clear that we're not using a > generic name and inadvertently limiting ourselves to a SMACK-like model... > It seems we all agree that it is a bad idea to tie a POSIX Capability to one specific LSM model. > It feels to me as if a MAC "override capability" is, if true to its > name, extra to the MAC model; any MAC model that needs an 'override' to > function seems under-specified... An interesting observation. This is a core part of why I have always found the hierarchical models BLP and Biba to be unsatisfying. These systems essentially have one simple fixed policy "process label must dominate object label to get access", and then you express all the rest of your "policy" by labeling your stuff. It is impossible to manage such systems without a MAC_OVERRIDE escape hatch of some kind, because the "policy" is too simple and inflexible, e.g. it does not allow you to reclassify anything. > SELinux clearly feels no need for one, > That's not quite right. More specifically, it already has one in the form of unconfined_t. AppArmor has a similar escape hatch in the "Ux" permission. Its not that they don't need one, it is that they already have one. They get to have one because they allow you to actually write a policy that is more nuanced than "process label must dominate object label". > and browsing through your SMACK patch, there are many instances where > this capability is used as an convenience privileged override. However, > in other situations, it appears as if the capability is required for > basic SMACK operations to succeed. > > My sense is that there is a case to be made for: CAP_MAC_ADMIN and > CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or > whatever MAC supports it) requires privilege to perform a privileged MAC > operation, and the latter for saying "OK, I'm without a paddle but need > one" (or words to that effect). > I don't get the difference. Both seem to permit the process to violate the MAC policy. I could make up a meaning for MAC_ADMIN that is different from MAC_OVERRIDE in the AppArmor sense, but I don't want to :-) and worse, I suspect the distinction would be different for each LSM. So let not, and just have one MAC_OVERRIDE capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Casey Schaufler wrote: > --- Andrew Morgan <[EMAIL PROTECTED]> wrote: >> I do have a question about whether one capability is sufficient in >> general for MAC. Looking at the: >> >> http://wt.xpilot.org/publications/posix.1e/download.html >> >> last draft, there are no less than 5 capabilities (p173) allocated for >> MAC. Presumably there was a good reason for 5 and not 1 back then - >> could you summarize what is different now? >> > There are to my mind two important differences. The first is that > my experiance with Trusted Irix (Trix from here on), which used (uses?) > capabilities and MAC together, is that the granularity is lost on > 99 44/100% of programs, programmers, evaluators, admins, and problems. > You just don't get that many cases where it actually gets you anything > to have less than all the MAC capabilities. Applications that care > about MAC to the extent that they use the capabilities tend to use the > lot, if not all the time, in certain circumstances. I'm afraid that > I am not a major fan of fine grained privilege based on my experiance > with it. > > The second and perhaps more important reason is that the POSIX > draft assumed a Bell & LaPadula sensitivity model, or at least > a model very much like it. What would CAP_MAC_DOWNGRADE mean on > a Smack system configured: > > OneHand OtherHandr--- > OtherHandGrippingHand r--- > GrippingHand OneHand r--- > Shout out to Niven & Pournelle :-) > What would CAP_MAC_UPGRADE mean, for that matter? It's even worse > to consider that the relationships can change. > > CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does > CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can > do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ, > and the other way around, and if you're not going to use one > of the other capabilities after you find out interesting things > using CAP_MAC_READ it's hard to figure why you'd bother. > All of that assumes a hierarchical security model (BLP, Biba). This depends on whether you think "MAC" means: * specifically the hierarchical models BLP and Biba, or * any policy system where the rules are mandatory with respect to the users The former would include SMACK, the venerable Argus Pitbull system (if it ever gets ported to LSM), and the recent MLS work implemented on top of FLASK. It would notably *not* include SELinux's Type Enforcement, AppArmor, or TOMOYO. If you take the latter view (a I do) then the meaning of MAC_READ vs. MAC_WRITE, and especially MAC_RELABEL_SUBJECT, becomes murky, e.g. I have no clue WtF "relabel subject" means to AppArmor. But I can very easily understand what "CAP_MAC_OVERRIDE" means to AppArmor. So I'm with Casey; I support a simple 1-bit capability for MAC override. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Casey Schaufler wrote: --- Andrew Morgan [EMAIL PROTECTED] wrote: I do have a question about whether one capability is sufficient in general for MAC. Looking at the: http://wt.xpilot.org/publications/posix.1e/download.html last draft, there are no less than 5 capabilities (p173) allocated for MAC. Presumably there was a good reason for 5 and not 1 back then - could you summarize what is different now? There are to my mind two important differences. The first is that my experiance with Trusted Irix (Trix from here on), which used (uses?) capabilities and MAC together, is that the granularity is lost on 99 44/100% of programs, programmers, evaluators, admins, and problems. You just don't get that many cases where it actually gets you anything to have less than all the MAC capabilities. Applications that care about MAC to the extent that they use the capabilities tend to use the lot, if not all the time, in certain circumstances. I'm afraid that I am not a major fan of fine grained privilege based on my experiance with it. The second and perhaps more important reason is that the POSIX draft assumed a Bell LaPadula sensitivity model, or at least a model very much like it. What would CAP_MAC_DOWNGRADE mean on a Smack system configured: OneHand OtherHandr--- OtherHandGrippingHand r--- GrippingHand OneHand r--- Shout out to Niven Pournelle :-) What would CAP_MAC_UPGRADE mean, for that matter? It's even worse to consider that the relationships can change. CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ, and the other way around, and if you're not going to use one of the other capabilities after you find out interesting things using CAP_MAC_READ it's hard to figure why you'd bother. All of that assumes a hierarchical security model (BLP, Biba). This depends on whether you think MAC means: * specifically the hierarchical models BLP and Biba, or * any policy system where the rules are mandatory with respect to the users The former would include SMACK, the venerable Argus Pitbull system (if it ever gets ported to LSM), and the recent MLS work implemented on top of FLASK. It would notably *not* include SELinux's Type Enforcement, AppArmor, or TOMOYO. If you take the latter view (a I do) then the meaning of MAC_READ vs. MAC_WRITE, and especially MAC_RELABEL_SUBJECT, becomes murky, e.g. I have no clue WtF relabel subject means to AppArmor. But I can very easily understand what CAP_MAC_OVERRIDE means to AppArmor. So I'm with Casey; I support a simple 1-bit capability for MAC override. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Andrew Morgan wrote: Its not so much why you are wrong, as being clear that we're not using a generic name and inadvertently limiting ourselves to a SMACK-like model... It seems we all agree that it is a bad idea to tie a POSIX Capability to one specific LSM model. It feels to me as if a MAC override capability is, if true to its name, extra to the MAC model; any MAC model that needs an 'override' to function seems under-specified... An interesting observation. This is a core part of why I have always found the hierarchical models BLP and Biba to be unsatisfying. These systems essentially have one simple fixed policy process label must dominate object label to get access, and then you express all the rest of your policy by labeling your stuff. It is impossible to manage such systems without a MAC_OVERRIDE escape hatch of some kind, because the policy is too simple and inflexible, e.g. it does not allow you to reclassify anything. SELinux clearly feels no need for one, That's not quite right. More specifically, it already has one in the form of unconfined_t. AppArmor has a similar escape hatch in the Ux permission. Its not that they don't need one, it is that they already have one. They get to have one because they allow you to actually write a policy that is more nuanced than process label must dominate object label. and browsing through your SMACK patch, there are many instances where this capability is used as an convenience privileged override. However, in other situations, it appears as if the capability is required for basic SMACK operations to succeed. My sense is that there is a case to be made for: CAP_MAC_ADMIN and CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or whatever MAC supports it) requires privilege to perform a privileged MAC operation, and the latter for saying OK, I'm without a paddle but need one (or words to that effect). I don't get the difference. Both seem to permit the process to violate the MAC policy. I could make up a meaning for MAC_ADMIN that is different from MAC_OVERRIDE in the AppArmor sense, but I don't want to :-) and worse, I suspect the distinction would be different for each LSM. So let not, and just have one MAC_OVERRIDE capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree
Kyle Moffett wrote: On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: Andrew Morgan wrote: It feels to me as if a MAC override capability is, if true to its name, extra to the MAC model; any MAC model that needs an 'override' to function seems under-specified... SELinux clearly feels no need for one, That's not quite right. More specifically, it already has one in the form of unconfined_t. AppArmor has a similar escape hatch in the Ux permission. Its not that they don't need one, it is that they already have one. They get to have one because they allow you to actually write a policy that is more nuanced than process label must dominate object label. Actually, a fully-secured strict-mode SELinux system will have no unconfined_t processes; none of my test systems have any. Generally unconfined_t is used for situations similar to what AppArmor was designed for, where the only interesting security is that of the daemon (which is properly labelled) and one or more of the users are unconfined. Interesting. In a Targeted Policy, you do your policy administration from unconfined_t. But how do you administer a Strict Policy machine? I can think of 2 ways: * reboot to single user and hack away o hurts usability because you need physical presence to change policy, but is highly secure * there is some type that is tighter than unconfined_t but none the less has sufficient privilege to change policy o to me, this would be semantically equivalent to unconfined_t, because any rogue code or user with this type could then fabricate unconfined_t and do what they want Even then unconfined_t is not an implicit part of the policy, it is explicitly given the ability to take any action on any object by rules in the policy, and it typically still falls under a few MLS labeling restrictions even in the targeted policy. Which is more or less the distinction I was trying to draw between hierarchical systems (MLS) and policy systems (SELinux TE, AppArmor, etc.) that policy systems let you write yourself an escape hatch in policy, and MLS systems don't. Or at least they need to kludge something :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
Peter Dolding wrote: > On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > >> --- Peter Dolding <[EMAIL PROTECTED]> wrote: >>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: >>> >>>> Peter Dolding wrote: >>>> >>>>> Assign application to >>>>> a cgroup that contains there filesystem access permissions. Done >>>>> right this could even be stacked. Only give less access to >>>>> application unless LSM particularly overrides >>>> This comes no where close to AppArmor's functionality: >>>> >>>> * Can't do learning mode >>>> * Can't do wildcards >>>> * Sucks up huge loads of memory to do that much FS mounting (imagine >>>> thousands of bind mounts) >>>> * I'm not sure, but I don't think you can do file granularity, only >>>> directorie >>> Ok sorry to say so far almost percent wrong. Please note netlabels >>> falls into a control group. All function of Apparmor is doable bar >>> exactly learning mode. For learning mode that would have to be a >>> hook back to a LSM I would expect. >>> >>> Done right should suck up no more memory than current apparmor. But >>> it will required all LSM's doing file access to come to common >>> agreement how to do it. Not just hooks into the kernel system any >>> more. >>> >> The ability to provide alternative access control schemes is the >> purpose of LSM. The fact that we insane security people can't come >> to the agreement you require is why we have LSM. You can not have >> what you are asking for. Please suggest an alternative design. >> > Part of the building the alternative design requires aggreeing to > build sections common. > Ok. I vehemently disagree with your design ideas. So do lots of other people, and I have not seen one single person ever speak up in favor of your ideas. So far, you have no agreement at all. >>>> Containers and access controls provide related but different functions. >>>> Stop trying to force containers to be an access control system, it does >>>> not fit well at all. >>>> >>>> Rather, we need to ensure that LSM and containers play well together. >>>> What you proposed in the past was to have an LSM module per container, >>>> but I find that absurdly complex: if you want that, then use a real VMM >>>> like Xen or something. Containers are mostly used for massive virtual >>>> domain hosting, and what you want there is as much sharing as possible >>>> while maintaining isolation. so why would you corrupt that with separate >>>> LSM modules per container? >>>> >>> Please stop being foolish. Xen and the like don't share memory. You >>> are basically saying blow out memory usage just because someone wants >>> to use a different LSM. >>> >> Yup. No one ever said security was cheap. Most real, serious security >> solutions implemented today rely on separate physical machines for >> isolation. Some progressive installations are using virtualization, >> and the lunatic fringe uses the sort of systems well served by LSM. >> Let's face it, people who really care are willing to pay a premium. >> > > Bigger problem Containers are processor neutral Xen and lot of the > other solutions are not. There are advantages for people who don't > need full blown. There needs to be two levels. Ie VM for the heavy. > Containers for where the security is needed but no to the point of > needing two different kernels. Remarkable. I agree completely with this paragraph, but draw the opposite conclusion that you do. Having private LSMs per container means having a separate kernel per container. That would seem to put that idea in the "heavy" category. Which is why I suggested that people who want to do what you desire should use full VMM instead of containers. > Now restricting what can be in a > Container due to some poor reason that has not been attempted to be > worked around is not a valid reason. It is rejected for perfectly sound engineering reasons like complexity bloat and memory bloat. Come back with a workable design or STFU. >In theory using Containers you > should be able to run every Linux distro on earth under one kernel as > long as it supports that series kernel. Ie 2.6 2.4... In "theory" as long as this theory ignores the fact that all distros patch their kernel. So yeah, you can run different &q
Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
Peter Dolding wrote: On Nov 18, 2007 5:22 AM, Casey Schaufler [EMAIL PROTECTED] wrote: --- Peter Dolding [EMAIL PROTECTED] wrote: On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote: Peter Dolding wrote: Assign application to a cgroup that contains there filesystem access permissions. Done right this could even be stacked. Only give less access to application unless LSM particularly overrides This comes no where close to AppArmor's functionality: * Can't do learning mode * Can't do wildcards * Sucks up huge loads of memory to do that much FS mounting (imagine thousands of bind mounts) * I'm not sure, but I don't think you can do file granularity, only directorie Ok sorry to say so far almost percent wrong. Please note netlabels falls into a control group. All function of Apparmor is doable bar exactly learning mode. For learning mode that would have to be a hook back to a LSM I would expect. Done right should suck up no more memory than current apparmor. But it will required all LSM's doing file access to come to common agreement how to do it. Not just hooks into the kernel system any more. The ability to provide alternative access control schemes is the purpose of LSM. The fact that we insane security people can't come to the agreement you require is why we have LSM. You can not have what you are asking for. Please suggest an alternative design. Part of the building the alternative design requires aggreeing to build sections common. Ok. I vehemently disagree with your design ideas. So do lots of other people, and I have not seen one single person ever speak up in favor of your ideas. So far, you have no agreement at all. Containers and access controls provide related but different functions. Stop trying to force containers to be an access control system, it does not fit well at all. Rather, we need to ensure that LSM and containers play well together. What you proposed in the past was to have an LSM module per container, but I find that absurdly complex: if you want that, then use a real VMM like Xen or something. Containers are mostly used for massive virtual domain hosting, and what you want there is as much sharing as possible while maintaining isolation. so why would you corrupt that with separate LSM modules per container? Please stop being foolish. Xen and the like don't share memory. You are basically saying blow out memory usage just because someone wants to use a different LSM. Yup. No one ever said security was cheap. Most real, serious security solutions implemented today rely on separate physical machines for isolation. Some progressive installations are using virtualization, and the lunatic fringe uses the sort of systems well served by LSM. Let's face it, people who really care are willing to pay a premium. Bigger problem Containers are processor neutral Xen and lot of the other solutions are not. There are advantages for people who don't need full blown. There needs to be two levels. Ie VM for the heavy. Containers for where the security is needed but no to the point of needing two different kernels. Remarkable. I agree completely with this paragraph, but draw the opposite conclusion that you do. Having private LSMs per container means having a separate kernel per container. That would seem to put that idea in the heavy category. Which is why I suggested that people who want to do what you desire should use full VMM instead of containers. Now restricting what can be in a Container due to some poor reason that has not been attempted to be worked around is not a valid reason. It is rejected for perfectly sound engineering reasons like complexity bloat and memory bloat. Come back with a workable design or STFU. In theory using Containers you should be able to run every Linux distro on earth under one kernel as long as it supports that series kernel. Ie 2.6 2.4... In theory as long as this theory ignores the fact that all distros patch their kernel. So yeah, you can run different distros as long as you don't care about device support, and you ignore which LSM you want to use. Containers fundamentally share the kernel, and the LSM module(s) loaded are part of the kernel, and therefore are fundamentally shared among the Containers. Besides file access control is part of running containers isolated in the first place and need to be LSM neutral. File access control is within the scope of the LSM. If your feature can't deal with that you need to fix your feature. This is the problem for containers File access controls need to be like netlabels common between LSM's. This is one of your impossible dreams. For file access controls to be common between LSM's there would have to be one file access model that everyone can agree on. It is quite clear that this is not the case, and Linus
More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
Peter Dolding wrote: >>> What is left unspecified here is 'how' a child 'with its own profile' is >>> confined here. Are it is confined to just its own profile, it may that >>> the "complicit process" communication may need to be wider specified to >>> include this. >>> > Sorry have to bring this up. cgroups why not? Because I can't find any documentation for cgroups? :) > Assign application to > a cgroup that contains there filesystem access permissions. Done > right this could even be stacked. Only give less access to > application unless LSM particularly overrides. > This comes no where close to AppArmor's functionality: * Can't do learning mode * Can't do wildcards * Sucks up huge loads of memory to do that much FS mounting (imagine thousands of bind mounts) * I'm not sure, but I don't think you can do file granularity, only directories > There are reasons why I keep on bring containers up it changes the > model. Yes I know coming to a common agreement in these sections will > not be simple. But at some point it has to be done. > Containers and access controls provide related but different functions. Stop trying to force containers to be an access control system, it does not fit well at all. Rather, we need to ensure that LSM and containers play well together. What you proposed in the past was to have an LSM module per container, but I find that absurdly complex: if you want that, then use a real VMM like Xen or something. Containers are mostly used for massive virtual domain hosting, and what you want there is as much sharing as possible while maintaining isolation. so why would you corrupt that with separate LSM modules per container? What makes sense to me is to ensure that it is easy for an LSM module to have a policy per container. This is relatively easy to do, and maps very well to the primary use of containers for hosting virtual domains. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
Peter Dolding wrote: What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. Sorry have to bring this up. cgroups why not? Because I can't find any documentation for cgroups? :) Assign application to a cgroup that contains there filesystem access permissions. Done right this could even be stacked. Only give less access to application unless LSM particularly overrides. This comes no where close to AppArmor's functionality: * Can't do learning mode * Can't do wildcards * Sucks up huge loads of memory to do that much FS mounting (imagine thousands of bind mounts) * I'm not sure, but I don't think you can do file granularity, only directories There are reasons why I keep on bring containers up it changes the model. Yes I know coming to a common agreement in these sections will not be simple. But at some point it has to be done. Containers and access controls provide related but different functions. Stop trying to force containers to be an access control system, it does not fit well at all. Rather, we need to ensure that LSM and containers play well together. What you proposed in the past was to have an LSM module per container, but I find that absurdly complex: if you want that, then use a real VMM like Xen or something. Containers are mostly used for massive virtual domain hosting, and what you want there is as much sharing as possible while maintaining isolation. so why would you corrupt that with separate LSM modules per container? What makes sense to me is to ensure that it is easy for an LSM module to have a policy per container. This is relatively easy to do, and maps very well to the primary use of containers for hosting virtual domains. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Apparmor-dev] Re: AppArmor Security Goal
Re-sent with proper addressing ... Rob Meijer wrote: >> The >> system is "defended" in that the worst the attacker can do to corrupt >> the system is limited to the transitive closure of what the confined >> processes are allowed to access. >> > The damage the atacker can do would be defined by the authority not the > permissions the process has. > As far as I can tall, the transitive closure of permissions is precisely authority. >> * AppArmor confines processes if they are children of a confined >> process, or if the name of the exec'd child matches the name of an >> AppArmor profile. >> > What is left unspecified here is 'how' a child 'with its own profile' is > confined here. Are it is confined to just its own profile, it may that > the "complicit process" communication may need to be wider specified to > include this. > It is deliberately unspecified in this document, because it is a matter of policy. And this item that you've excerpted is just one of a list of specific disclaimers that were put here in response to criticisms and misunderstandings of AppArmor in the past. Remember, the purpose of *this* document is to define the security goals that AppArmor has to live up to. It is fine to use it as a jumping off point for design ideas that some system might employ some day, or even proposed enhancements to AppArmor itself, but don't over-burden the "security goal" document, it needs to be short & comprehensible. >> * A confined process can operate on a file descriptor passed to it >> by an unconfined process, even if it manipulates a file not in the >> confined process's profile. To block this attack, confine the >> process that passed the file descriptor. >> > This should not count as an 'attack' given that the unconfined process > would either be trusted, or be mallicious and fall inside the "influence" > of the confined process anyway. > It counts as a surprising result, and so is specifically disclaimed. I can tell it is surprising, because it surprised Andi Kleen :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Apparmor-dev] Re: AppArmor Security Goal
Re-sent with proper addressing ... Rob Meijer wrote: The system is defended in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access. The damage the atacker can do would be defined by the authority not the permissions the process has. As far as I can tall, the transitive closure of permissions is precisely authority. * AppArmor confines processes if they are children of a confined process, or if the name of the exec'd child matches the name of an AppArmor profile. What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. It is deliberately unspecified in this document, because it is a matter of policy. And this item that you've excerpted is just one of a list of specific disclaimers that were put here in response to criticisms and misunderstandings of AppArmor in the past. Remember, the purpose of *this* document is to define the security goals that AppArmor has to live up to. It is fine to use it as a jumping off point for design ideas that some system might employ some day, or even proposed enhancements to AppArmor itself, but don't over-burden the security goal document, it needs to be short comprehensible. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile. To block this attack, confine the process that passed the file descriptor. This should not count as an 'attack' given that the unconfined process would either be trusted, or be mallicious and fall inside the influence of the confined process anyway. It counts as a surprising result, and so is specifically disclaimed. I can tell it is surprising, because it surprised Andi Kleen :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
[EMAIL PROTECTED] wrote: > a question for Crispin, > is there a wildcard replacement for username? so that you could > grant permission to /home/$user/.mozilla.. and grant each user > access to only their own stuff? I realize that in this particular > example the underlying DAC will handle it, but I can see other cases > where people may want to have users more intermixed (say webserver > files or directories for example) This is possible, but tricky. There is no internal kernel data structure for a UID's home dir. That is parsable at policy load time, so we could enhance the language so that a rule of "~/.plan" expanded into a special token that corresponded to some table of user home directories at the time the policy was loaded. But that is racy, as it becomes invalid if anyone's home dir moves, or any users are added or removed. Another way to do it is what JJ posted: enhance the rule language so you can have one rule for files that you own, and a different rule for files owned by others. The AppArmor community (well, JJ and I :) are debating the cost/benefit of this: is the added flexibility worth the added complexity? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Alan Cox wrote: >> but how can the system know if the directory the user wants to add is >> reasonable or not? what if the user says they want to store their >> documents in /etc? >> > A more clear example is wanting to wrap a specific tool with temporary > rules. Those rules would depend on the exact file being edited at this > moment - something root cannot know in advance > (although with apparmor I guess mv $my_file apparmour_magic.name ; foo; > mv it back might work 8)) > If you have unconfined root privilege on an AppArmor box, then setting up a temporary profile is trivial. As Alan suggests, you could just have a standard profile for /home/crispin/bin/foo and fun with mv would switch programs in and out of it. Or for more control, just draft a new policy and load it; it just takes a few seconds to cp the profile for something else and edit it a bit, and then load it. The big difference between the former and latter is that the former is inflexible (it either works or it doesn't) and the latter requires privilege. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: > * Crispin Cowan ([EMAIL PROTECTED]) wrote: > >> I mostly don't see this as a serious limitation, because almost everyone >> has their own workstation, and thus has root on that workstation. There >> are 2 major exceptions: >> >> * Schools, where the "workstations" are thin client X terminals and >> everyone is logged into a giant shared machine. Sorry, AppArmor is >> not a good choice for that environment, but it is a pretty scarce >> environment. >> * Enterprises, where workers get their own workstation, but they >> don't get root. Well, the reason the worker doesn't get root is >> the enterprise doesn't trust them with it, and so not letting them >> edit security policy is probably a good idea. >> > I don't actually see your distinction here between those two environments; > why does it matter if there is one non-priveliged user or many? > Because it is easier to solve if there is only one non-privileged user: you just give them privilege (fun with chmod and sudo) to edit the system policies, and you're done (assuming you are happy allowing the non-privileged user to edit policy at all). If there are lots of non-privileged users sharing a computer, then I submit that solutions are either insecure, intractable, or purely restrictive. >> Can you explain why you want a non-privileged user to be able to edit >> policy? I would like to better understand the problem here. >> > I think it might depend on how strict the users starting point is; > you could say: >1 This document editor can read and write any part of the users home > directory other than the . files. > > or you could say: >2 This document editor can read any files but only write to the > 'Documents directory'. > > If the adminisrator set something up with (2) as the starting point it > would seem reasonable for the user to be able to add the ability to edit > documents in extra directories for their style of organising documents > they work on; but they would be restricted in what they could add > so that they couldn't add the ability to write to their settings > files. > Ok, I can see where that would be useful in theory. But solving it is VERY hard in practice, and AppArmor is not attempting to address this problem of user extensibility of mandatory access controls. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: I mostly don't see this as a serious limitation, because almost everyone has their own workstation, and thus has root on that workstation. There are 2 major exceptions: * Schools, where the workstations are thin client X terminals and everyone is logged into a giant shared machine. Sorry, AppArmor is not a good choice for that environment, but it is a pretty scarce environment. * Enterprises, where workers get their own workstation, but they don't get root. Well, the reason the worker doesn't get root is the enterprise doesn't trust them with it, and so not letting them edit security policy is probably a good idea. I don't actually see your distinction here between those two environments; why does it matter if there is one non-priveliged user or many? Because it is easier to solve if there is only one non-privileged user: you just give them privilege (fun with chmod and sudo) to edit the system policies, and you're done (assuming you are happy allowing the non-privileged user to edit policy at all). If there are lots of non-privileged users sharing a computer, then I submit that solutions are either insecure, intractable, or purely restrictive. Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. I think it might depend on how strict the users starting point is; you could say: 1 This document editor can read and write any part of the users home directory other than the . files. or you could say: 2 This document editor can read any files but only write to the 'Documents directory'. If the adminisrator set something up with (2) as the starting point it would seem reasonable for the user to be able to add the ability to edit documents in extra directories for their style of organising documents they work on; but they would be restricted in what they could add so that they couldn't add the ability to write to their settings files. Ok, I can see where that would be useful in theory. But solving it is VERY hard in practice, and AppArmor is not attempting to address this problem of user extensibility of mandatory access controls. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Alan Cox wrote: but how can the system know if the directory the user wants to add is reasonable or not? what if the user says they want to store their documents in /etc? A more clear example is wanting to wrap a specific tool with temporary rules. Those rules would depend on the exact file being edited at this moment - something root cannot know in advance (although with apparmor I guess mv $my_file apparmour_magic.name ; foo; mv it back might work 8)) If you have unconfined root privilege on an AppArmor box, then setting up a temporary profile is trivial. As Alan suggests, you could just have a standard profile for /home/crispin/bin/foo and fun with mv would switch programs in and out of it. Or for more control, just draft a new policy and load it; it just takes a few seconds to cp the profile for something else and edit it a bit, and then load it. The big difference between the former and latter is that the former is inflexible (it either works or it doesn't) and the latter requires privilege. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
[EMAIL PROTECTED] wrote: a question for Crispin, is there a wildcard replacement for username? so that you could grant permission to /home/$user/.mozilla.. and grant each user access to only their own stuff? I realize that in this particular example the underlying DAC will handle it, but I can see other cases where people may want to have users more intermixed (say webserver files or directories for example) This is possible, but tricky. There is no internal kernel data structure for a UID's home dir. That is parsable at policy load time, so we could enhance the language so that a rule of ~/.plan expanded into a special token that corresponded to some table of user home directories at the time the policy was loaded. But that is racy, as it becomes invalid if anyone's home dir moves, or any users are added or removed. Another way to do it is what JJ posted: enhance the rule language so you can have one rule for files that you own, and a different rule for files owned by others. The AppArmor community (well, JJ and I :) are debating the cost/benefit of this: is the added flexibility worth the added complexity? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Alan Cox wrote: >> Can you explain why you want a non-privileged user to be able to edit >> policy? I would like to better understand the problem here. >> > Because root doesn't trust users who in turn may not trust apps they run > or wish to control things. I don't see a problem with that viewpoint in > terms of forbidding things providing the user (or process tree) does not > get to undo rules merely add more restrictions. > Do you mean that the OS privilege of "uid 0" does not trust non-privileged users? Or you mean that the human in charge of root on the box does not trust the human who owns the account "alice" on the box? In the case of the former, this is exactly why AppArmor does not let non-privileged users edit security policy. SELinux, SMACK, LIDS, etc. also all treat manipulating policy as privileged. In the case of the latter, my main claim is that such circumstances are rare, because most users have their own personal workstation. Of course there are exceptions where people are using a multi-user host, and I'm not saying that there is anything wrong with that, just that AppArmor is not particularly good at supporting that environment. I know that multi-user machines is the classic UNIX environment, but that model has slowly faded away and is little used any more, so AppArmor made a trade-off for simplicity at the expense of supporting this use case. User-extensible security policy is a hard problem, and AppArmor does not attempt to solve it. >> non-privileged user to further tighten the profile on a program. To me, >> that adds complexity with not much value, but if lots of users want it, >> then I'm wrong :) >> > Assuming you have any value in the first place, which is another topic, I > can see value for this in all the security models. > There is value in most features, and the question is whether the feature pays its freight, does the value exceed the cost? AppArmor is particularly sensitive to cost/benefit ratios, because much of AppArmor's value is its simplicity, so there is a naturally high barrier to adding complicating features to AppArmor. All of this is valid discussion for how AppArmor might be improved, but is far, far removed from the dual question that Arjan posed: * Is the model valid? Not "is it exactly what I want?" but merely "is it non-silly, such that clearly it provides value to some users?" * Does the code live up to the model? I submit that the AppArmor model is valid, even if it totally failed all of David Gilbert's questions (I think AppArmor can actually provide about half of what he asked for). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: > * Crispin Cowan ([EMAIL PROTECTED]) wrote: > >> I don't get the problem: if you want your web browser to be able to >> access where you commonly store your documents, then give it that >> permission. The above rule says that your web browser doesn't get to go >> change AppArmor policy on its own. >> > But can I as a non-privileged user say which directories I want it to > be able to access? > No, you have to be privileged (root) to edit security policy and to reload policy. I mostly don't see this as a serious limitation, because almost everyone has their own workstation, and thus has root on that workstation. There are 2 major exceptions: * Schools, where the "workstations" are thin client X terminals and everyone is logged into a giant shared machine. Sorry, AppArmor is not a good choice for that environment, but it is a pretty scarce environment. * Enterprises, where workers get their own workstation, but they don't get root. Well, the reason the worker doesn't get root is the enterprise doesn't trust them with it, and so not letting them edit security policy is probably a good idea. Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. Note that John Johansen is also interested in allowing non-privileged users to manipulate AppArmor policy, but his view was to only allow a non-privileged user to further tighten the profile on a program. To me, that adds complexity with not much value, but if lots of users want it, then I'm wrong :) >> I have serious doubts about the utility of restricting a text editor. >> You nominally want to be able to edit any file on the system, so >> confining it would be fairly meaningless. >> > Text editor probably true; but I'm thinking here more of OpenOffice > and the like; there have been plenty of document carried malware in the > past. > How to usefully confine an office suite like OpenOffice is current work at Mercenary Linux. We think we have a solution that is just AppArmor policy, without having to do any feature enhancements. >>> Similarly I'd like to be able to split applications so that >>> the 'preferences' editing facilities are done by separate >>> envrionments so that there is no way that a fault in parsing >>> external data could edit the config (e.g. change home page or >>> proxy in a browser or default document in an editor). >>> >> AppArmor will let you do that; most of the work is in splitting the >> application. If you can get e.g. Firefox to use a separate process that >> it exec's for editing your preferences, then AppArmor can confine that >> helper app with a different policy than Firefox itself, including >> granting the helper write permission to the config directory. >> > Yes, and designing the app so that it's filenames are predictable; > firefox has a fun habit of using randomly named profile directories. > You just glob that directory, so the rule would look like: /home/*/.mozilla/default/*/prefs.js rw, if you wanted it to be a generic policy for all users. If you want a tighter policy for your workstation, then it might look like /home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw, hard-coding both your username and the random directory name that Mozilla chose. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: > * Crispin Cowan ([EMAIL PROTECTED]) wrote: > > * Manipulating AppArmor policy requires being both root privileged >> and not being confined by AppArmor, thus there is explicitly no >> capability for non-privileged users to change AppArmor policy. >> > It's a pity that there is no way to do this; it would be nice to restrict > web browsers, document editors etc but allow them > to access the places you commonly store documents etc. > I don't get the problem: if you want your web browser to be able to access where you commonly store your documents, then give it that permission. The above rule says that your web browser doesn't get to go change AppArmor policy on its own. I have serious doubts about the utility of restricting a text editor. You nominally want to be able to edit any file on the system, so confining it would be fairly meaningless. > Similarly I'd like to be able to split applications so that > the 'preferences' editing facilities are done by separate > envrionments so that there is no way that a fault in parsing > external data could edit the config (e.g. change home page or > proxy in a browser or default document in an editor). > AppArmor will let you do that; most of the work is in splitting the application. If you can get e.g. Firefox to use a separate process that it exec's for editing your preferences, then AppArmor can confine that helper app with a different policy than Firefox itself, including granting the helper write permission to the config directory. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Andi Kleen wrote: > Crispin Cowan <[EMAIL PROTECTED]> writes: > > The document should be a good base for a merge. > > >> * A confined process can operate on a file descriptor passed to it >> by an unconfined process, even if it manipulates a file not in the >> confined process's profile. To block this attack, confine the >> process that passed the file descriptor. >> > > That is the only thing that tripped me up a bit while reading the document. > Can you expand a bit on the reasons why the fd is not rechecked in > the context of the target process? Best do it in a new version of the > document. > The reason is a disgusting implementation problem, so instead of going into lots of detail, I just disclaimed it. The excuse :) is that UNIX/Linux already has an object-capability orientation with respect to passing file descriptors around; you can pass an FD to a process that doesn't have access to the file, and DAC (user ownership & such) won't check it either. This aspect of the semantics is not my favorite, but it is at least consistent with the AppArmor view that unconfined processes can do absolutely anything and AppArmor won't try to stop them. The actual reason: FDs that are passed from some other *confined* process actually are checked, because the FD has data structures on it that we can use to hook for checking. The problem is that an FD from a completely unconfined process has no such data structures. To fix this, we would have to check access on every single read and write, and that would make performance suck. If there is a clean way to close this issue, I would be interested. On the other hand, there is a fairly passionate community of Object Capability fans who really want access rights to be delegable, and the other way to go is to remove all checking on passed FDs. There are advantages to going both ways, and I don't believe that AppArmor is locked in stone, so either one could be chosen in the future. See this interesting thread on LSM http://marc.info/?t=11946492933=1=2 Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Andi Kleen wrote: Crispin Cowan [EMAIL PROTECTED] writes: The document should be a good base for a merge. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile. To block this attack, confine the process that passed the file descriptor. That is the only thing that tripped me up a bit while reading the document. Can you expand a bit on the reasons why the fd is not rechecked in the context of the target process? Best do it in a new version of the document. The reason is a disgusting implementation problem, so instead of going into lots of detail, I just disclaimed it. The excuse :) is that UNIX/Linux already has an object-capability orientation with respect to passing file descriptors around; you can pass an FD to a process that doesn't have access to the file, and DAC (user ownership such) won't check it either. This aspect of the semantics is not my favorite, but it is at least consistent with the AppArmor view that unconfined processes can do absolutely anything and AppArmor won't try to stop them. The actual reason: FDs that are passed from some other *confined* process actually are checked, because the FD has data structures on it that we can use to hook for checking. The problem is that an FD from a completely unconfined process has no such data structures. To fix this, we would have to check access on every single read and write, and that would make performance suck. If there is a clean way to close this issue, I would be interested. On the other hand, there is a fairly passionate community of Object Capability fans who really want access rights to be delegable, and the other way to go is to remove all checking on passed FDs. There are advantages to going both ways, and I don't believe that AppArmor is locked in stone, so either one could be chosen in the future. See this interesting thread on LSM http://marc.info/?t=11946492933r=1w=2 Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: snip * Manipulating AppArmor policy requires being both root privileged and not being confined by AppArmor, thus there is explicitly no capability for non-privileged users to change AppArmor policy. It's a pity that there is no way to do this; it would be nice to restrict web browsers, document editors etc but allow them to access the places you commonly store documents etc. I don't get the problem: if you want your web browser to be able to access where you commonly store your documents, then give it that permission. The above rule says that your web browser doesn't get to go change AppArmor policy on its own. I have serious doubts about the utility of restricting a text editor. You nominally want to be able to edit any file on the system, so confining it would be fairly meaningless. Similarly I'd like to be able to split applications so that the 'preferences' editing facilities are done by separate envrionments so that there is no way that a fault in parsing external data could edit the config (e.g. change home page or proxy in a browser or default document in an editor). AppArmor will let you do that; most of the work is in splitting the application. If you can get e.g. Firefox to use a separate process that it exec's for editing your preferences, then AppArmor can confine that helper app with a different policy than Firefox itself, including granting the helper write permission to the config directory. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: I don't get the problem: if you want your web browser to be able to access where you commonly store your documents, then give it that permission. The above rule says that your web browser doesn't get to go change AppArmor policy on its own. But can I as a non-privileged user say which directories I want it to be able to access? No, you have to be privileged (root) to edit security policy and to reload policy. I mostly don't see this as a serious limitation, because almost everyone has their own workstation, and thus has root on that workstation. There are 2 major exceptions: * Schools, where the workstations are thin client X terminals and everyone is logged into a giant shared machine. Sorry, AppArmor is not a good choice for that environment, but it is a pretty scarce environment. * Enterprises, where workers get their own workstation, but they don't get root. Well, the reason the worker doesn't get root is the enterprise doesn't trust them with it, and so not letting them edit security policy is probably a good idea. Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. Note that John Johansen is also interested in allowing non-privileged users to manipulate AppArmor policy, but his view was to only allow a non-privileged user to further tighten the profile on a program. To me, that adds complexity with not much value, but if lots of users want it, then I'm wrong :) I have serious doubts about the utility of restricting a text editor. You nominally want to be able to edit any file on the system, so confining it would be fairly meaningless. Text editor probably true; but I'm thinking here more of OpenOffice and the like; there have been plenty of document carried malware in the past. How to usefully confine an office suite like OpenOffice is current work at Mercenary Linux. We think we have a solution that is just AppArmor policy, without having to do any feature enhancements. Similarly I'd like to be able to split applications so that the 'preferences' editing facilities are done by separate envrionments so that there is no way that a fault in parsing external data could edit the config (e.g. change home page or proxy in a browser or default document in an editor). AppArmor will let you do that; most of the work is in splitting the application. If you can get e.g. Firefox to use a separate process that it exec's for editing your preferences, then AppArmor can confine that helper app with a different policy than Firefox itself, including granting the helper write permission to the config directory. Yes, and designing the app so that it's filenames are predictable; firefox has a fun habit of using randomly named profile directories. You just glob that directory, so the rule would look like: /home/*/.mozilla/default/*/prefs.js rw, if you wanted it to be a generic policy for all users. If you want a tighter policy for your workstation, then it might look like /home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw, hard-coding both your username and the random directory name that Mozilla chose. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor Security Goal
Alan Cox wrote: Can you explain why you want a non-privileged user to be able to edit policy? I would like to better understand the problem here. Because root doesn't trust users who in turn may not trust apps they run or wish to control things. I don't see a problem with that viewpoint in terms of forbidding things providing the user (or process tree) does not get to undo rules merely add more restrictions. Do you mean that the OS privilege of uid 0 does not trust non-privileged users? Or you mean that the human in charge of root on the box does not trust the human who owns the account alice on the box? In the case of the former, this is exactly why AppArmor does not let non-privileged users edit security policy. SELinux, SMACK, LIDS, etc. also all treat manipulating policy as privileged. In the case of the latter, my main claim is that such circumstances are rare, because most users have their own personal workstation. Of course there are exceptions where people are using a multi-user host, and I'm not saying that there is anything wrong with that, just that AppArmor is not particularly good at supporting that environment. I know that multi-user machines is the classic UNIX environment, but that model has slowly faded away and is little used any more, so AppArmor made a trade-off for simplicity at the expense of supporting this use case. User-extensible security policy is a hard problem, and AppArmor does not attempt to solve it. non-privileged user to further tighten the profile on a program. To me, that adds complexity with not much value, but if lots of users want it, then I'm wrong :) Assuming you have any value in the first place, which is another topic, I can see value for this in all the security models. There is value in most features, and the question is whether the feature pays its freight, does the value exceed the cost? AppArmor is particularly sensitive to cost/benefit ratios, because much of AppArmor's value is its simplicity, so there is a naturally high barrier to adding complicating features to AppArmor. All of this is valid discussion for how AppArmor might be improved, but is far, far removed from the dual question that Arjan posed: * Is the model valid? Not is it exactly what I want? but merely is it non-silly, such that clearly it provides value to some users? * Does the code live up to the model? I submit that the AppArmor model is valid, even if it totally failed all of David Gilbert's questions (I think AppArmor can actually provide about half of what he asked for). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AppArmor Security Goal
re-sent due to a typo in addressing. AppArmor Security Goal Crispin Cowan, PhD MercenaryLinux.com This document is intended to specify the security goal that AppArmor is intended to achieve, so that users can evaluate whether AppArmor will meet their needs, and kernel developers can evaluate whether AppArmor is living up to its claims. This document is *not* a general purpose explanation of how AppArmor works, nor is it an explanation for why one might want to use AppArmor rather than some other system. AppArmor is intended to protect systems from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. AppArmor addresses this threat by confining the application to access only the resources it needs to access to execute properly, effectively imposing "least privilege" execution on the application. Applications have access to a number of resources including files, interprocess communication, networking, capabilities, and execution of other applications. The purpose of least privilege is to bound the damage that a malicious user or code can do by removing access to all resources that the application does not need for its intended function. For instance, a policy for a web server might grant read only access to most web documents, preventing an attacker who can corrupt the web server from defacing the web pages. An "application" is one or more related processes performing a function, e.g. the gang of processes that constitute an Apache web server, or a Postfix mail server. AppArmor *only* confines processes that the AppArmor policy says it should confine, and other processes are permitted to do anything that DAC permits. This is sometimes known as a targeted security policy. AppArmor does not provide a "default" policy that applies to all processes. So to defend an entire host, you have to piece-wise confine each process that is exposed to potential attack. For instance, to defend a system against network attack, place AppArmor profiles around every application that accesses the network. This limits the damage a network attacker can do to the file system to only those files granted by the profiles for the network-available applications. Similarly, to defend a system against attack from the console, place AppArmor profiles around every application that accessed the keyboard and mouse. The system is "defended" in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access. AppArmor currently mediates access to files, ability to use POSIX.1e Capabilities, and coarse-grained control on network access. This is sufficient to prevent a confined process from *directly* corrupting the file system. It is not sufficient to prevent a confined process from *indirectly* corrupting the system by influencing some other process to do the dirty deed. But to do so requires a complicit process that can be manipulated through another channel such as IPC. A "complicit" process is either a malicious process the attacker somehow got control of, or is a process that is actively listening to IPC of some kind and can be corrupted via IPC. The only IPC that AppArmor mediates is access to named sockets, FIFOs, etc. that appear in the file system name space, a side effect of AppArmor's file access mediation. Future versions of AppArmor will mediate more resources, including finer grained network access controls, and controls on various forms of IPC. AppArmor specifies the programs to be confined and the resources they can access in a syntax similar to how users are accustomed to accessing those resources. So file access controls are specified using absolute paths with respect to the name space the process is in. POSIX.1e capabilities are specified by name. Network access controls currently are specified by simply naming the protocol that can be used e.g. tcp, udp, and in the future will be more general, resembling firewall rules. Thus the AppArmor security goal should be considered piecewise from the point of view of a single confined process: that process should only be able to access the resources specified in its profile: * can only access files that are reachable in its name space by path names matching its profile, and only with the permitted modes: read, append, write, memory map, execute, and link * can only use the POSIX.1e capabilities listed in the profile * can only perform the network operations listed in the profile Security issues that AppArmor explicitly does *not* address: * Processes that are not confined by AppArmor are not restricted in any way by AppArmor. If an unconfined process is considered an unacceptable threat, then confine additional applications until adequate security is achieved. *
Re: Problem with accessing namespace_sem from LSM.
Christoph Hellwig wrote: > On Thu, Nov 08, 2007 at 07:04:23AM +0900, Tetsuo Handa wrote: >> The reason why I want to access namespace_sem inside security_inode_create() >> is that >> it doesn't receive "struct vfsmount" parameter. >> If "struct vfsmount" *were* passed to security_inode_create(), >> I have no need to access namespace_sem. >> > Same argument as with the AA folks: it does not have any business looking > at the vfsmount. If you create a file it can and in many setups will > show up in multiple vfsmounts, so making decisions based on the particular > one this creat happens through is wrong and actually dangerous. > This has been said many times, and I have never been able to translate it into anything other than "pathname access control is bad". Pathname-based access control systems, among other things, let you write a policy that says "you may create files under /foo/bar/baz". So when you attempt to create a file "/foo/bar/baz/biff" the LSM needs to know which VFS mount you are creating it in. Multiple mount points, bind mounts, and other fun with mounting, do in fact allow you to create aliases. Because of that, an LSM that set a policy of "you can create files anywhere *except* /foo/bar/baz" would be trivially bypassable. But a policy that says "You may *only* create files under /foo/bar/baz" (plus whatever other explicit permissions it grants) does not seem to create any problems, so long as the confined processes are not permitted to create arbitrary aliases by using fun with mount. So just exactly what is dangerous about this? Caveat: complaints that you can create a policy that is bypassable are not interesting, you can do that with any policy system. To show "dangerous" you would have to show how a reasonable policy that should be secure is in fact bypassable. This threat from mount point aliases, this has often been conjectured but has never been shown. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with accessing namespace_sem from LSM.
Christoph Hellwig wrote: On Thu, Nov 08, 2007 at 07:04:23AM +0900, Tetsuo Handa wrote: The reason why I want to access namespace_sem inside security_inode_create() is that it doesn't receive struct vfsmount parameter. If struct vfsmount *were* passed to security_inode_create(), I have no need to access namespace_sem. Same argument as with the AA folks: it does not have any business looking at the vfsmount. If you create a file it can and in many setups will show up in multiple vfsmounts, so making decisions based on the particular one this creat happens through is wrong and actually dangerous. This has been said many times, and I have never been able to translate it into anything other than pathname access control is bad. Pathname-based access control systems, among other things, let you write a policy that says you may create files under /foo/bar/baz. So when you attempt to create a file /foo/bar/baz/biff the LSM needs to know which VFS mount you are creating it in. Multiple mount points, bind mounts, and other fun with mounting, do in fact allow you to create aliases. Because of that, an LSM that set a policy of you can create files anywhere *except* /foo/bar/baz would be trivially bypassable. But a policy that says You may *only* create files under /foo/bar/baz (plus whatever other explicit permissions it grants) does not seem to create any problems, so long as the confined processes are not permitted to create arbitrary aliases by using fun with mount. So just exactly what is dangerous about this? Caveat: complaints that you can create a policy that is bypassable are not interesting, you can do that with any policy system. To show dangerous you would have to show how a reasonable policy that should be secure is in fact bypassable. This threat from mount point aliases, this has often been conjectured but has never been shown. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AppArmor Security Goal
re-sent due to a typo in addressing. AppArmor Security Goal Crispin Cowan, PhD MercenaryLinux.com This document is intended to specify the security goal that AppArmor is intended to achieve, so that users can evaluate whether AppArmor will meet their needs, and kernel developers can evaluate whether AppArmor is living up to its claims. This document is *not* a general purpose explanation of how AppArmor works, nor is it an explanation for why one might want to use AppArmor rather than some other system. AppArmor is intended to protect systems from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. AppArmor addresses this threat by confining the application to access only the resources it needs to access to execute properly, effectively imposing least privilege execution on the application. Applications have access to a number of resources including files, interprocess communication, networking, capabilities, and execution of other applications. The purpose of least privilege is to bound the damage that a malicious user or code can do by removing access to all resources that the application does not need for its intended function. For instance, a policy for a web server might grant read only access to most web documents, preventing an attacker who can corrupt the web server from defacing the web pages. An application is one or more related processes performing a function, e.g. the gang of processes that constitute an Apache web server, or a Postfix mail server. AppArmor *only* confines processes that the AppArmor policy says it should confine, and other processes are permitted to do anything that DAC permits. This is sometimes known as a targeted security policy. AppArmor does not provide a default policy that applies to all processes. So to defend an entire host, you have to piece-wise confine each process that is exposed to potential attack. For instance, to defend a system against network attack, place AppArmor profiles around every application that accesses the network. This limits the damage a network attacker can do to the file system to only those files granted by the profiles for the network-available applications. Similarly, to defend a system against attack from the console, place AppArmor profiles around every application that accessed the keyboard and mouse. The system is defended in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access. AppArmor currently mediates access to files, ability to use POSIX.1e Capabilities, and coarse-grained control on network access. This is sufficient to prevent a confined process from *directly* corrupting the file system. It is not sufficient to prevent a confined process from *indirectly* corrupting the system by influencing some other process to do the dirty deed. But to do so requires a complicit process that can be manipulated through another channel such as IPC. A complicit process is either a malicious process the attacker somehow got control of, or is a process that is actively listening to IPC of some kind and can be corrupted via IPC. The only IPC that AppArmor mediates is access to named sockets, FIFOs, etc. that appear in the file system name space, a side effect of AppArmor's file access mediation. Future versions of AppArmor will mediate more resources, including finer grained network access controls, and controls on various forms of IPC. AppArmor specifies the programs to be confined and the resources they can access in a syntax similar to how users are accustomed to accessing those resources. So file access controls are specified using absolute paths with respect to the name space the process is in. POSIX.1e capabilities are specified by name. Network access controls currently are specified by simply naming the protocol that can be used e.g. tcp, udp, and in the future will be more general, resembling firewall rules. Thus the AppArmor security goal should be considered piecewise from the point of view of a single confined process: that process should only be able to access the resources specified in its profile: * can only access files that are reachable in its name space by path names matching its profile, and only with the permitted modes: read, append, write, memory map, execute, and link * can only use the POSIX.1e capabilities listed in the profile * can only perform the network operations listed in the profile Security issues that AppArmor explicitly does *not* address: * Processes that are not confined by AppArmor are not restricted in any way by AppArmor. If an unconfined process is considered an unacceptable threat, then confine additional applications until adequate security is achieved. * A process that is not permitted to directly access a resource
Re: Defense in depth: LSM *modules*, not a static interface
Simon Arlott wrote: > On Tue, October 30, 2007 07:14, Cliffe wrote: > >> And while I acknowledge that many of these layers are currently buried >> within the kernel (netfilter...) they are security layers which in many >> cases would probably make sense as stackable security modules. >> >> Making the interface static forces mammoth solutions which then must >> attempt to solve all of the above in one ls*m*. What happened to >> dividing tasks into easy to manage chunks? >> > Would it be possible to have Kconfig select which LSM should handle each > area of security? Selecting LSM A would automatically disable LSM B and > C since they both implement the same security functions, while LSM D > would still be selectable since it implements something else. The default > capabilities code would then turn off parts of itself that another LSM > is handling. > I get what you mean, but the problem is that there is little consensus on what "area" means. Rather the opposite, it could easily be the case that different modules have such a different view of the world that you cannot easily mechanically determine whether they can stack. Some categories that occur to me: * Restrictive vs. Permissive: o LSM is mostly restrictive, but the POSIX.1e Capabilities hooks are permissive. o Some modules like MultiADM and File Capabilities are deliberately permissive, while others like AppArmor and SMACK are purely restrictive. o In any kind of stacking scheme, it would be important to load the permissive modules first, followed by the restrictive modules. o This becomes problematic as soon as you have a module that is both permissive and restrictive. o Note: AppArmor is both permissive and restrictive because it incorporates the Capabilities code rather than trying to stack with it. With a good clean stacker, AA might be able to become purely restrictive. * Access control vs. Intrusion prevention: o An Access control policy is one that specifies what a confined subject can access. o An Intrusion prevention engine specifies classes of things that may never happen, e.g. the Openwall hard and symbolic link restrictions. o An intrusion prevention mechanism might be a blanket effect that prevents the Bad Thing from happening for all processes, or it might be policy driven, and only prevent the Bad Thing for explicitly confined processes, or explicitly allow the Bad Thing for permitted processes. o Access control and Intrusion Prevention modules are naturally complementary, making stacking very attractive. o Note: SELinux already incorporates some intrusion prevention features, and AppArmor plans to incorporate such features. With a good clean stacker, AA might be able to instead use stacking. > Alternatively the M in LSM can be restored and modules can be stacked. > It should be possible for the primary LSM to check the security_ops of the > secondary LSM(s) and complain if it considers there to be an incompatiblity. > That is what I advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FUD threats). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Defense in depth: LSM *modules*, not a static interface
Simon Arlott wrote: On Tue, October 30, 2007 07:14, Cliffe wrote: And while I acknowledge that many of these layers are currently buried within the kernel (netfilter...) they are security layers which in many cases would probably make sense as stackable security modules. Making the interface static forces mammoth solutions which then must attempt to solve all of the above in one ls*m*. What happened to dividing tasks into easy to manage chunks? Would it be possible to have Kconfig select which LSM should handle each area of security? Selecting LSM A would automatically disable LSM B and C since they both implement the same security functions, while LSM D would still be selectable since it implements something else. The default capabilities code would then turn off parts of itself that another LSM is handling. I get what you mean, but the problem is that there is little consensus on what area means. Rather the opposite, it could easily be the case that different modules have such a different view of the world that you cannot easily mechanically determine whether they can stack. Some categories that occur to me: * Restrictive vs. Permissive: o LSM is mostly restrictive, but the POSIX.1e Capabilities hooks are permissive. o Some modules like MultiADM and File Capabilities are deliberately permissive, while others like AppArmor and SMACK are purely restrictive. o In any kind of stacking scheme, it would be important to load the permissive modules first, followed by the restrictive modules. o This becomes problematic as soon as you have a module that is both permissive and restrictive. o Note: AppArmor is both permissive and restrictive because it incorporates the Capabilities code rather than trying to stack with it. With a good clean stacker, AA might be able to become purely restrictive. * Access control vs. Intrusion prevention: o An Access control policy is one that specifies what a confined subject can access. o An Intrusion prevention engine specifies classes of things that may never happen, e.g. the Openwall hard and symbolic link restrictions. o An intrusion prevention mechanism might be a blanket effect that prevents the Bad Thing from happening for all processes, or it might be policy driven, and only prevent the Bad Thing for explicitly confined processes, or explicitly allow the Bad Thing for permitted processes. o Access control and Intrusion Prevention modules are naturally complementary, making stacking very attractive. o Note: SELinux already incorporates some intrusion prevention features, and AppArmor plans to incorporate such features. With a good clean stacker, AA might be able to instead use stacking. Alternatively the M in LSM can be restored and modules can be stacked. It should be possible for the primary LSM to check the security_ops of the secondary LSM(s) and complain if it considers there to be an incompatiblity. That is what I advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FUD threats). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface
Tetsuo Handa wrote: > I think there are two other problems regarding LSM. > > (1) There is only one "struct security_ops" structure in the system. > > (2) There is only one "void *security" field in "struct task_struct". > > > Years ago, there was only one MAC implementation (i.e. SELinux) > in the mainline kernel. > But now, there are many MAC (or access control/tracking) implementations > waiting for inclusion into the mainline kernel. > The competition for occupying "struct security_ops" has started. > > My idea is that, why not create chains of "struct security_ops" > (i.e. linked list of "struct security_ops") > and allow choosing which chain to use for per a "struct task_struct" basis > (i.e. add "struct security_ops" to "struct task_struct"). > That idea was in the Stacker module, and it was tabled until there is more than one upstream LSM. In particular, it requires 2 or more LSMs that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux are all exclusive of one another (in a running kernel) and real stacking is still pending useful component intrusion prevention modules. Such modules can be built, they just have not yet been built. > TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use > "struct security_ops" since SELinux is occupying it. > Just disable SELinux and load TOMOYO. Oh, you can't because someone has made modules not be loadable :( Hmmm, perhaps someone could fix that by reverting the static interface patch ... :) > May be we should consider stackable LSM again? > Exactly. Stacker was shelved, so to speak :) because of the lack of in-kernel modules. Soon it will be time to reconsider that. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface
Tetsuo Handa wrote: I think there are two other problems regarding LSM. (1) There is only one struct security_ops structure in the system. (2) There is only one void *security field in struct task_struct. Years ago, there was only one MAC implementation (i.e. SELinux) in the mainline kernel. But now, there are many MAC (or access control/tracking) implementations waiting for inclusion into the mainline kernel. The competition for occupying struct security_ops has started. My idea is that, why not create chains of struct security_ops (i.e. linked list of struct security_ops) and allow choosing which chain to use for per a struct task_struct basis (i.e. add struct security_ops to struct task_struct). That idea was in the Stacker module, and it was tabled until there is more than one upstream LSM. In particular, it requires 2 or more LSMs that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux are all exclusive of one another (in a running kernel) and real stacking is still pending useful component intrusion prevention modules. Such modules can be built, they just have not yet been built. TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use struct security_ops since SELinux is occupying it. Just disable SELinux and load TOMOYO. Oh, you can't because someone has made modules not be loadable :( Hmmm, perhaps someone could fix that by reverting the static interface patch ... :) May be we should consider stackable LSM again? Exactly. Stacker was shelved, so to speak :) because of the lack of in-kernel modules. Soon it will be time to reconsider that. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Peter Dolding wrote: > Lets end the bitrot. Start having bits go into the main OS security > features where they should be. > Linus categorically rejected this idea, several times, very clearly. He did so because the security community cannot agree on a one-true-standard for what that OS security feature set should be. From looking at this thread and many others, he is correct; there is no consensus on what the feature set should be. So you can wish for the "main OS security features" all you want, but it is not going to happen without a miraculous degree of consensus abruptly arising. On the contrary, security, done well, is a tight fitting suit. It must be tight, or it allows too much slack and attackers can exploit that. To make it tight, it must be tailored to the situation at hand. That means that there may *never* be a consensus on the "one true way", because it could be that there is no "one true way". It could be that SMACK is best in some cases, AppArmor in others, SELinux in others yet again, MLS in others, etc. etc. I agree with Casey; LSM may not be perfect, but it is a great deal more consensus than I have seen anywhere else in the security community. Your desire that AppArmor and SELinux should share code has already happened: LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and TOMOYO, and MultiADM, etc. It certainly can be improved, but it is not in need of wholesale replacement, and especially not without a clear design that addresses clearly stated problems that lots of people are having. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Jan Engelhardt wrote: > Apparmor tutorial (beats any FAQ at first): > ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi > Thanks for the high praise. Unfortunately that FTP site seems to not be working. Some alternatives: * My personal copy of the above video http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi * Similar talk at linux.conf.au 2007 http://youtube.com/watch?v=EgrfmSm0NWs * Similar talk at Defcon 2007 http://video.google.com/videoplay?docid=-1731833784646588861=en Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Defense in depth: LSM *modules*, not a static interface
Al Viro wrote: > On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote: > >> Defense in depth has long been recognised as an important secure design >> principle. Security is best achieved using a layered approach. >> > "Layered approach" is not a magic incantation to excuse any bit of snake > oil. Homeopathic remedies might not harm (pure water is pure water), > but that's not an excuse for quackery. And frankly, most of the > "security improvement" crowd sound exactly like woo-peddlers. > Frank's point was that the static interface makes layering somewhere between impractical and impossible. The static interface change should be dumped so that layering is at least possible. Whether any given security module is worth while is a separate issue. I.e. that there are bad medicines around is a poor excuse to ban syringes and demand that everyone be born with a strong immune system. Why is it that security flame wars always end up reasoning with absurd analogies? :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Defense in depth: LSM *modules*, not a static interface
Al Viro wrote: On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote: Defense in depth has long been recognised as an important secure design principle. Security is best achieved using a layered approach. Layered approach is not a magic incantation to excuse any bit of snake oil. Homeopathic remedies might not harm (pure water is pure water), but that's not an excuse for quackery. And frankly, most of the security improvement crowd sound exactly like woo-peddlers. Frank's point was that the static interface makes layering somewhere between impractical and impossible. The static interface change should be dumped so that layering is at least possible. Whether any given security module is worth while is a separate issue. I.e. that there are bad medicines around is a poor excuse to ban syringes and demand that everyone be born with a strong immune system. Why is it that security flame wars always end up reasoning with absurd analogies? :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Jan Engelhardt wrote: Apparmor tutorial (beats any FAQ at first): ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi Thanks for the high praise. Unfortunately that FTP site seems to not be working. Some alternatives: * My personal copy of the above video http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi * Similar talk at linux.conf.au 2007 http://youtube.com/watch?v=EgrfmSm0NWs * Similar talk at Defcon 2007 http://video.google.com/videoplay?docid=-1731833784646588861hl=en Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Peter Dolding wrote: Lets end the bitrot. Start having bits go into the main OS security features where they should be. Linus categorically rejected this idea, several times, very clearly. He did so because the security community cannot agree on a one-true-standard for what that OS security feature set should be. From looking at this thread and many others, he is correct; there is no consensus on what the feature set should be. So you can wish for the main OS security features all you want, but it is not going to happen without a miraculous degree of consensus abruptly arising. On the contrary, security, done well, is a tight fitting suit. It must be tight, or it allows too much slack and attackers can exploit that. To make it tight, it must be tailored to the situation at hand. That means that there may *never* be a consensus on the one true way, because it could be that there is no one true way. It could be that SMACK is best in some cases, AppArmor in others, SELinux in others yet again, MLS in others, etc. etc. I agree with Casey; LSM may not be perfect, but it is a great deal more consensus than I have seen anywhere else in the security community. Your desire that AppArmor and SELinux should share code has already happened: LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and TOMOYO, and MultiADM, etc. It certainly can be improved, but it is not in need of wholesale replacement, and especially not without a clear design that addresses clearly stated problems that lots of people are having. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Rob Meijer wrote:
> On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>
>>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>>> modules as proposed, alternatively a maintainer for each formal model
>>> may be more appropriate. This also would require module builders to
>>> first
>>> think about what formal model they are actualy using, thus resulting in
>>> cleaner module design.
>>>
>> I *really* dislike this idea. It seems to set up the situation that the
>> only acceptable modules are those that follow some "formal" model.
>> Problems:
>> ...
>> * The proposal only allows a single implementation of each formal
>> model. In theory, theory is just like practice, but in practice it
>> is not. SMACK and SELinux follow substantially similar formal
>> models (not exactly the same) so should we exclude one and keep
>> the other? No, of course not, because in practice they are very
>> different.
>>
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.
>
Ah! So the proposal really is to have an LSM maintainer for each
"family" of models, acting as a resource and arbiter for modules in a class.
I like that idea, and have no objection to it. However, it does have
resource problems, in that the pool of LSM maintainers is not that
large. There is also the likely objection that this degree of scale is
not needed until at least there are multiple families of models in the
upstream kernel, and possibly until there are multiple instances of a
single family in the upstream kernel.
It also begs the question of what constitutes a family.
* AppArmor, SELinux, and TOMOYO are all ambient capability systems
o AppArmor and TOMOYO are pathname based
o SELinux is label based
* SELinux and SMACK are label-based
o I don't know if SMACK is an ambient capability system
* Rob Meijer implicitly advocated for an object capability LSM
o would it be pathname or label based? You could do either or
both ...
* The LSPP work from RH, Tresys, and TCS is MLS based
o this is a subset of both label-based and ambient capability
based
* I have no clue what family to put MultiADM or Dazuko into
* Getting very formal, I could imagine a Clarke-Wilson module
* Getting very informal, I could imagine a module that is a
collection of cute intrusion prevention hacks, such as the Open
wall Linux symlink and hardlink restrictions, and my own RaceGuard
work
o Oh wait, I published
<http://citeseer.ist.psu.edu/cowan01raceguard.html>
RaceGuard. Does that make it formal? :-)
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Rob Meijer wrote: > What may be even more relevant are those concepts that couldn't be done > in SELinux, and how proposals that come from the theory of alternative > access controll models (like object capability modeling) are dismissed > by the aparently largely MLS/MAC oriented people on the list. Clearly what is needed here is for someone to actually implement an object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor, MultiADM, or TOMOYO can implement object capabilities, so there is clear justification for building such a module. I would argue strongly to include it. > Thus IMHO it may be a good idea to instead of a maintainer for LSM > modules as proposed, alternatively a maintainer for each formal model > may be more appropriate. This also would require module builders to first > think about what formal model they are actualy using, thus resulting in > cleaner module design. > I *really* dislike this idea. It seems to set up the situation that the only acceptable modules are those that follow some "formal" model. Problems: * What qualifies as a formal model? This becomes an arbitrary litmus test, depending on whether the model was originally published in a sufficiently snooty forum. * What if someone invents a new model that has not been "formalized" yet? Should Linux be forced to wait until the idea has been through the academic mill before we allow someone to try implementing a module for the idea? * The proposal only allows a single implementation of each formal model. In theory, theory is just like practice, but in practice it is not. SMACK and SELinux follow substantially similar formal models (not exactly the same) so should we exclude one and keep the other? No, of course not, because in practice they are very different. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Rob Meijer wrote: What may be even more relevant are those concepts that couldn't be done in SELinux, and how proposals that come from the theory of alternative access controll models (like object capability modeling) are dismissed by the aparently largely MLS/MAC oriented people on the list. Clearly what is needed here is for someone to actually implement an object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor, MultiADM, or TOMOYO can implement object capabilities, so there is clear justification for building such a module. I would argue strongly to include it. Thus IMHO it may be a good idea to instead of a maintainer for LSM modules as proposed, alternatively a maintainer for each formal model may be more appropriate. This also would require module builders to first think about what formal model they are actualy using, thus resulting in cleaner module design. I *really* dislike this idea. It seems to set up the situation that the only acceptable modules are those that follow some formal model. Problems: * What qualifies as a formal model? This becomes an arbitrary litmus test, depending on whether the model was originally published in a sufficiently snooty forum. * What if someone invents a new model that has not been formalized yet? Should Linux be forced to wait until the idea has been through the academic mill before we allow someone to try implementing a module for the idea? * The proposal only allows a single implementation of each formal model. In theory, theory is just like practice, but in practice it is not. SMACK and SELinux follow substantially similar formal models (not exactly the same) so should we exclude one and keep the other? No, of course not, because in practice they are very different. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Rob Meijer wrote: On Mon, October 29, 2007 11:24, Crispin Cowan wrote: Thus IMHO it may be a good idea to instead of a maintainer for LSM modules as proposed, alternatively a maintainer for each formal model may be more appropriate. This also would require module builders to first think about what formal model they are actualy using, thus resulting in cleaner module design. I *really* dislike this idea. It seems to set up the situation that the only acceptable modules are those that follow some formal model. Problems: ... * The proposal only allows a single implementation of each formal model. In theory, theory is just like practice, but in practice it is not. SMACK and SELinux follow substantially similar formal models (not exactly the same) so should we exclude one and keep the other? No, of course not, because in practice they are very different. I would think the two may benefit from a role as described above. But I was thinking more in the line of new modules that may again implement this same model, and would thus benefit from interaction with this 'model maintainer' role. Ah! So the proposal really is to have an LSM maintainer for each family of models, acting as a resource and arbiter for modules in a class. I like that idea, and have no objection to it. However, it does have resource problems, in that the pool of LSM maintainers is not that large. There is also the likely objection that this degree of scale is not needed until at least there are multiple families of models in the upstream kernel, and possibly until there are multiple instances of a single family in the upstream kernel. It also begs the question of what constitutes a family. * AppArmor, SELinux, and TOMOYO are all ambient capability systems o AppArmor and TOMOYO are pathname based o SELinux is label based * SELinux and SMACK are label-based o I don't know if SMACK is an ambient capability system * Rob Meijer implicitly advocated for an object capability LSM o would it be pathname or label based? You could do either or both ... * The LSPP work from RH, Tresys, and TCS is MLS based o this is a subset of both label-based and ambient capability based * I have no clue what family to put MultiADM or Dazuko into * Getting very formal, I could imagine a Clarke-Wilson module * Getting very informal, I could imagine a module that is a collection of cute intrusion prevention hacks, such as the Open wall Linux symlink and hardlink restrictions, and my own RaceGuard work o Oh wait, I published http://citeseer.ist.psu.edu/cowan01raceguard.html RaceGuard. Does that make it formal? :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Alan Cox wrote: >> The idea that poor security is worse than no security is fallacious, >> and not backed up by common experience. >> > There is a ton of evidence both in computing and outside of it which > shows that poor security can be very much worse than no security at all. > In particular stuff which makes users think they are secure but is > worthless is very dangerous indeed. > > When you know that security is limited you act appropriately, when you > believe security is good but it is not you take inappropriate risks and > get badly burned. > The "bad security is worse than no security" idea comes exactly from what Alan says above: it happens when the security is not as good as you think it is, and so you don't take adequate precautions. Using the ongoing bicycle lock example, the discovery a few years ago that a certain model of Kryptonite bike lock could be picked with a simple pen made the security on this otherwise very sturdy lock become abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987 Conversely, the case can also be made that "weak security is better than no security". It is better to secure your bike with a $10 lock than no lock. If someone insists on only "high" security bike locks that cost $1000 and weigh 30 lbs, then most people will choose to not lock their bikes, or skip biking all together. IMHO, much of the criticism leveled at proposed LSMs has been of the latter kind, or worse. That the security of the proposed LSM does not meet some particular use case does not make it "bad", it makes it not for that use case. To reject an LSM for providing "bad" security, IMHO you should have to show how it is possible to subvert the self-stated goals of that LSM. Complaints that the LSM fails to meet some goal outside of its stated purpose is irrelevant. Conjecture that it probably can be violated because of $contrivance is just so much FUD. Exception: it is valid to say that the self-stated goal is too narrow to be useful. But IMHO that bar of "too narrow" should be very, very low. Defenses against specific modes of attack would be a fine thing to build up in the library of LSMs, especially if we got a decent stacking module so that they could be composed. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Alan Cox wrote: The idea that poor security is worse than no security is fallacious, and not backed up by common experience. There is a ton of evidence both in computing and outside of it which shows that poor security can be very much worse than no security at all. In particular stuff which makes users think they are secure but is worthless is very dangerous indeed. When you know that security is limited you act appropriately, when you believe security is good but it is not you take inappropriate risks and get badly burned. The bad security is worse than no security idea comes exactly from what Alan says above: it happens when the security is not as good as you think it is, and so you don't take adequate precautions. Using the ongoing bicycle lock example, the discovery a few years ago that a certain model of Kryptonite bike lock could be picked with a simple pen made the security on this otherwise very sturdy lock become abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987 Conversely, the case can also be made that weak security is better than no security. It is better to secure your bike with a $10 lock than no lock. If someone insists on only high security bike locks that cost $1000 and weigh 30 lbs, then most people will choose to not lock their bikes, or skip biking all together. IMHO, much of the criticism leveled at proposed LSMs has been of the latter kind, or worse. That the security of the proposed LSM does not meet some particular use case does not make it bad, it makes it not for that use case. To reject an LSM for providing bad security, IMHO you should have to show how it is possible to subvert the self-stated goals of that LSM. Complaints that the LSM fails to meet some goal outside of its stated purpose is irrelevant. Conjecture that it probably can be violated because of $contrivance is just so much FUD. Exception: it is valid to say that the self-stated goal is too narrow to be useful. But IMHO that bar of too narrow should be very, very low. Defenses against specific modes of attack would be a fine thing to build up in the library of LSMs, especially if we got a decent stacking module so that they could be composed. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/45] AppArmor security module overview
Arjan van de Ven wrote: > My main concern for now is a description of what it tries to protect > against/in what cases you would expect to use it. THe reason for asking > this explicitly is simple: Until now the LSM discussions always ended > up in a nasty mixed up mess around disagreeing on the theoretical model > of what to protect against and the actual implementation of the threat > protection. THe only way I can think of to get out of this mess is to > have the submitter of the security model give a description of what his > protection model is (and unless it's silly, not argue about that), and > then only focus on how the code manages to achieve this model, to make > sure there's no big gaps in it, within its own goals/reference. > I really, really like this proposal. It is essentially what I have always wanted. > On the first part (discussion of the model) I doubt we can get people > to agree, that's pretty much phylosophical... on the second part (how > well the code/design lives up to its own goals) the analysis can be > objective and technical. > I will try to do that as soon as possible. While I will strive to be both clear and precise, achieving both is challenging. So, if someone discovers a mis-match between the description and the code, would a patch to the description be an acceptable resolution, if it did not render the model silly? Crispin -- Crispin Cowan, Ph.D. http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/45] AppArmor security module overview
Arjan van de Ven wrote: My main concern for now is a description of what it tries to protect against/in what cases you would expect to use it. THe reason for asking this explicitly is simple: Until now the LSM discussions always ended up in a nasty mixed up mess around disagreeing on the theoretical model of what to protect against and the actual implementation of the threat protection. THe only way I can think of to get out of this mess is to have the submitter of the security model give a description of what his protection model is (and unless it's silly, not argue about that), and then only focus on how the code manages to achieve this model, to make sure there's no big gaps in it, within its own goals/reference. I really, really like this proposal. It is essentially what I have always wanted. On the first part (discussion of the model) I doubt we can get people to agree, that's pretty much phylosophical... on the second part (how well the code/design lives up to its own goals) the analysis can be objective and technical. I will try to do that as soon as possible. While I will strive to be both clear and precise, achieving both is challenging. So, if someone discovers a mis-match between the description and the code, would a patch to the description be an acceptable resolution, if it did not render the model silly? Crispin -- Crispin Cowan, Ph.D. http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Jan Engelhardt wrote: > On Oct 24 2007 19:11, Simon Arlott wrote: > >> * (I've got a list of access rules which are scanned in order until one of >> them matches, and an array of one bit for every port for per-port default >> allow/deny - although the latter could be removed. >> http://svn.lp0.eu/simon/portac/trunk/) >> > Besides the 'feature' of inhibiting port binding, > is not this task of blocking connections something for a firewall? > So now you are criticizing his module. Arguing about the merits of security semantics. This is exactly why Linus wanted LSM, so we don't have to have these kinds of discussions, at least not on LKML :) It seems to me that LSM used to be an open API. Anyone could code to it, so you could at least try to ship a module that will load into a major vendor's stock kernel for an important release. Now with this change, it is effectively a closed API. You can only load the modules that the distro vendor shipped to you. If you want *anything* other than what RH or Novell or Canonical or Mandriva etc. says you should want, then you have to hack the source code for your kernel. Open source is great, and it is wonderful that you *can* hack the source if you need to, but demanding that end users patch their source code when all they want to do is load a module is really, really sad. Please revert this patch. Its benefits are no where near its costs. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
Jan Engelhardt wrote: On Oct 24 2007 19:11, Simon Arlott wrote: * (I've got a list of access rules which are scanned in order until one of them matches, and an array of one bit for every port for per-port default allow/deny - although the latter could be removed. http://svn.lp0.eu/simon/portac/trunk/) Besides the 'feature' of inhibiting port binding, is not this task of blocking connections something for a firewall? So now you are criticizing his module. Arguing about the merits of security semantics. This is exactly why Linus wanted LSM, so we don't have to have these kinds of discussions, at least not on LKML :) It seems to me that LSM used to be an open API. Anyone could code to it, so you could at least try to ship a module that will load into a major vendor's stock kernel for an important release. Now with this change, it is effectively a closed API. You can only load the modules that the distro vendor shipped to you. If you want *anything* other than what RH or Novell or Canonical or Mandriva etc. says you should want, then you have to hack the source code for your kernel. Open source is great, and it is wonderful that you *can* hack the source if you need to, but demanding that end users patch their source code when all they want to do is load a module is really, really sad. Please revert this patch. Its benefits are no where near its costs. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
Giacomo Catenazzi wrote: > What do technical and regulatory differences have "driver/LSM module" that > is build-in and one that is modular? > It seems to me silly to find difference. A kernel with a new kernel module > is a new kernel. > *I* understand that, from a security and logic integrity point of view, there is not much difference between a rebuilt-from-source kernel, and a standard kernel from the distro with a new module loaded. However, there is a big difference for other people, depending on their circumstances. * Some people live in organizations where the stock kernel is required, even if you are allowed to load modules. That may not make sense to you, but that doesn't change the rule. * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. Think of it like device drivers: Linux would be an enterprise failure if you had to re-compile the kernel from source every time you added a new kind of device and device driver. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
Giacomo Catenazzi wrote: What do technical and regulatory differences have driver/LSM module that is build-in and one that is modular? It seems to me silly to find difference. A kernel with a new kernel module is a new kernel. *I* understand that, from a security and logic integrity point of view, there is not much difference between a rebuilt-from-source kernel, and a standard kernel from the distro with a new module loaded. However, there is a big difference for other people, depending on their circumstances. * Some people live in organizations where the stock kernel is required, even if you are allowed to load modules. That may not make sense to you, but that doesn't change the rule. * Some people are not comfortable building kernels from source. It doesn't matter how easy *you* think it is, it is a significant barrier to entry for a lot of people. Especially if their day job is systems or security administration, and not kernel hacking. Think of it like device drivers: Linux would be an enterprise failure if you had to re-compile the kernel from source every time you added a new kind of device and device driver. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
Greg KH wrote: > On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: > >> Security is big business, as is compliance with regulatory law. Large >> enterprise customers are NOT going to either void their system support >> contracts, or place themselves in jeopardy of failing a SOX audit. >> > I agree, that is why customers do not load other random security modules > in their kernel today, That "random" module could be a module supplied by a vendor other than the distro supplier, such as a security vendor. It could be a research prototype that the user wants to try out on their enterprise-supported kernel. It could even be an in-house developed module that a local site wants to run on his larger organization's blessed kernel. So far from "random", these modules are motivated by circumstances radically different than yours. In particular, rebuilding a kernel for you (GregKH, many LKML developers) is a casual thing to be done before breakfast, but is a scary obstacle to many others. It is an obstacle to people who are skilled at computers but deliberately *not* kernel developers (the whole world does not need to be a Linux kernel developer) and it is an obstacle to large enterprise admins who have organizational pressure to use specific, pre-built kernels. > and why they will not do so tomorrow. So, > because of that, this whole point about compliance with regulatory law > seems kind of moot :) > I think the specific stuff about regulatory compliance is tangential. SarBox and friends don't specify Linux kernel versions, they are incredibly vague and subject to interpretation. But they are part of what drive organizations to have self-imposed rules about only running blessed kernel versions. Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. > Again, LSM isn't going away at all, this is just one config option for > allowing LSM to work as a module that is changing. If a customer > demands that this feature come back, I'm sure that the big distros will > be the first to push for it. But currently, given that there are no > known external LSMs being used by customers demanding support, I don't > see what the big issue here really is. > As I said, it is a medium issue, not a big one, which is why I didn't speak out before. I am opposed to this change because I see zero benefit to it, and a lot of down-side in loss of user choice. Because that is what this does: it does not help the kernel get better. It *definitely* does not help the kernel become more secure. It mostly just removes user's choice, by making it difficult to do things that some people don't approve of. As I've said, it doesn't hurt AppArmor, because 3 major distros ship it. But it will hurt user choice and innovation, by making anything not shipped by a distro more difficult to access. There is some performance gains to be had by doing something to the LSM interface. Certainly a configuration option that statically inlines all the hooks and points them at a compiled in module would yield some performance gain, but I don't know how much. But that raises 2 questions: 1. Was *performance* really the reason this patch was proposed? Or was it because James really did want the restrictive effect of preventing people from choosing after-market modules and dynamically unloading them if they want? I believe that James was well-intentioned in trying to block these actions because he believes them to be insecure, and he's right, they are insecure. However, these actions are also very practically useful in many circumstances. I disagree with the change because an individual LSM can block both such actions if you wish, so imposing it on all LSM modules is restricting choice unnecessarily. 2. Is the performance issue that this might address really big enough to bother fixing at all? Maybe, but I don't know. Again, I'm strictly opposed to the loss of flexibility until the performance issue is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
Alan Cox wrote: > On Sun, 21 Oct 2007 19:24:42 -0700 > "Thomas Fricaccia" <[EMAIL PROTECTED]> wrote >> Yes, I think Crispin has succinctly summed it up: irrevocably closing >> the LSM prevents commercial customers from using security modules other >> than that provided by their Linux distributor. As Sarbanes-Oxley and >> other regulatory laws require these customers to use "standard >> kernels", the result is a rather dreary form of vendor lock-in, where the >> security framework is coupled to the distribution. >> > Crispin at least is providing genuine discussion points. Sarbox has > nothing to say on "using vendor linux kernels". > I agree that SarBox is not really the issue here. Partially related is enterprise rules about what kernels one is allowed to load. More generally, this change forces users who want to use a different LSM than their vendor provides to recompile their kernel, where they did not have to recompile before. It forces LSM module developers who want to modify their LSM to reboot, where they didn't necessarily have to reboot before. That is not a catastrophe, it is just tedious. It does not kill baby seals, and it does not make Linux utterly useless. OTOH, I think it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is a net loss in Linux kernel capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
Alan Cox wrote: On Sun, 21 Oct 2007 19:24:42 -0700 Thomas Fricaccia [EMAIL PROTECTED] wrote Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use standard kernels, the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Crispin at least is providing genuine discussion points. Sarbox has nothing to say on using vendor linux kernels. I agree that SarBox is not really the issue here. Partially related is enterprise rules about what kernels one is allowed to load. More generally, this change forces users who want to use a different LSM than their vendor provides to recompile their kernel, where they did not have to recompile before. It forces LSM module developers who want to modify their LSM to reboot, where they didn't necessarily have to reboot before. That is not a catastrophe, it is just tedious. It does not kill baby seals, and it does not make Linux utterly useless. OTOH, I think it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is a net loss in Linux kernel capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
Greg KH wrote: On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: Security is big business, as is compliance with regulatory law. Large enterprise customers are NOT going to either void their system support contracts, or place themselves in jeopardy of failing a SOX audit. I agree, that is why customers do not load other random security modules in their kernel today, That random module could be a module supplied by a vendor other than the distro supplier, such as a security vendor. It could be a research prototype that the user wants to try out on their enterprise-supported kernel. It could even be an in-house developed module that a local site wants to run on his larger organization's blessed kernel. So far from random, these modules are motivated by circumstances radically different than yours. In particular, rebuilding a kernel for you (GregKH, many LKML developers) is a casual thing to be done before breakfast, but is a scary obstacle to many others. It is an obstacle to people who are skilled at computers but deliberately *not* kernel developers (the whole world does not need to be a Linux kernel developer) and it is an obstacle to large enterprise admins who have organizational pressure to use specific, pre-built kernels. and why they will not do so tomorrow. So, because of that, this whole point about compliance with regulatory law seems kind of moot :) I think the specific stuff about regulatory compliance is tangential. SarBox and friends don't specify Linux kernel versions, they are incredibly vague and subject to interpretation. But they are part of what drive organizations to have self-imposed rules about only running blessed kernel versions. Suffice it to say that there are a variety of reasons why someone either cannot re-compile a kernel, or just does not want to recompile a kernel. This change to LSM removes their choice to use modules others than those provided by their distro vendor. Again, LSM isn't going away at all, this is just one config option for allowing LSM to work as a module that is changing. If a customer demands that this feature come back, I'm sure that the big distros will be the first to push for it. But currently, given that there are no known external LSMs being used by customers demanding support, I don't see what the big issue here really is. As I said, it is a medium issue, not a big one, which is why I didn't speak out before. I am opposed to this change because I see zero benefit to it, and a lot of down-side in loss of user choice. Because that is what this does: it does not help the kernel get better. It *definitely* does not help the kernel become more secure. It mostly just removes user's choice, by making it difficult to do things that some people don't approve of. As I've said, it doesn't hurt AppArmor, because 3 major distros ship it. But it will hurt user choice and innovation, by making anything not shipped by a distro more difficult to access. There is some performance gains to be had by doing something to the LSM interface. Certainly a configuration option that statically inlines all the hooks and points them at a compiled in module would yield some performance gain, but I don't know how much. But that raises 2 questions: 1. Was *performance* really the reason this patch was proposed? Or was it because James really did want the restrictive effect of preventing people from choosing after-market modules and dynamically unloading them if they want? I believe that James was well-intentioned in trying to block these actions because he believes them to be insecure, and he's right, they are insecure. However, these actions are also very practically useful in many circumstances. I disagree with the change because an individual LSM can block both such actions if you wish, so imposing it on all LSM modules is restricting choice unnecessarily. 2. Is the performance issue that this might address really big enough to bother fixing at all? Maybe, but I don't know. Again, I'm strictly opposed to the loss of flexibility until the performance issue is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: LSM conversion to static interface
To discuss how LSM should work, it would have been really helpful if the OP had cc'd the LSM mailing list. I've cc'd the LSM list here ... Linus Torvalds wrote: > On Wed, 17 Oct 2007, Thomas Fricaccia wrote: > >> But then I noticed that, while the LSM would remain in existence, it was >> being closed to out-of-tree security frameworks. Yikes! Since then, >> I've been following the rush to put SMACK, TOMOYO and AppArmor >> "in-tree". >> > Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE > people were ok with it (AppArmor), but I'm with you - I applied it, but > I'm also perfectly willing to unapply it if there actually are valid > out-of-tree users that people push for not merging. > I did not speak up against this patch because it does not hurt AppArmor, and I was trying to reduce the amount of LKML flaming that I engage in :) but since you asked, IMHO this patch is extremely bad for Linux and bad for Linux users. The patch does have benefits, I just think those benefits are weak and unimportant. It prohibits dynamic loading of security modules (you must be compiled in) and prohibits unloading of security modules (because it is unsafe, and potentially insecure). What makes these benefits weak and unimportant is that you can have those benefits now without the patch by just writing your module that way: if you think that a security module should be compiled in and present when the kernel boots, and should never be unloaded. > For example, I do kind of see the point that a "real" security model might > want to be compiled-in, and not something you override from a module. Of > course, I'm personally trying to not use any modules at all, so I'm just > odd and contrary, so whatever.. > Why would you want to dynamically unload a module: because it is convenient for debugging. Ok, so it is unsafe, and sometimes wedges your kernel, which sometimes forces you to reboot. With this patch in place, it forces you to *always* reboot when you want to try a hack to the module. Why you would want to dynamically load a security module: because you are an enterprise user, required to use a specific build of a kernel, rather than compile your own kernel, but you also want to use (or even try out) a security module that your enterprise's vendor of choice has not chosen to bundle. In the current state, such a user can just go get a module and use it. With this patch, such a user is just screwed, they can't load and try the module without having to get into kernel building. So the net impact of this patch is: * It takes a deployment practice (static compiled-in security) that is arguably good in many circumstances and makes it mandatory at all times. * It takes a development practice that is very convenient and slightly risky, and forces you into the pessimal inconvenient development practice at all times. * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. This strikes me as a rather anti-choice position to take. It says that because candy is bad for you, you only ever get to eat vegetables. I don't understand why Linux would want to do this to its users. It doesn't hurt me or AppArmor. Since AppArmor is now shipping with SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: LSM conversion to static interface
To discuss how LSM should work, it would have been really helpful if the OP had cc'd the LSM mailing list. I've cc'd the LSM list here ... Linus Torvalds wrote: On Wed, 17 Oct 2007, Thomas Fricaccia wrote: But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor in-tree. Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. I did not speak up against this patch because it does not hurt AppArmor, and I was trying to reduce the amount of LKML flaming that I engage in :) but since you asked, IMHO this patch is extremely bad for Linux and bad for Linux users. The patch does have benefits, I just think those benefits are weak and unimportant. It prohibits dynamic loading of security modules (you must be compiled in) and prohibits unloading of security modules (because it is unsafe, and potentially insecure). What makes these benefits weak and unimportant is that you can have those benefits now without the patch by just writing your module that way: if you think that a security module should be compiled in and present when the kernel boots, and should never be unloaded. For example, I do kind of see the point that a real security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Why would you want to dynamically unload a module: because it is convenient for debugging. Ok, so it is unsafe, and sometimes wedges your kernel, which sometimes forces you to reboot. With this patch in place, it forces you to *always* reboot when you want to try a hack to the module. Why you would want to dynamically load a security module: because you are an enterprise user, required to use a specific build of a kernel, rather than compile your own kernel, but you also want to use (or even try out) a security module that your enterprise's vendor of choice has not chosen to bundle. In the current state, such a user can just go get a module and use it. With this patch, such a user is just screwed, they can't load and try the module without having to get into kernel building. So the net impact of this patch is: * It takes a deployment practice (static compiled-in security) that is arguably good in many circumstances and makes it mandatory at all times. * It takes a development practice that is very convenient and slightly risky, and forces you into the pessimal inconvenient development practice at all times. * It prevents enterprise users, and in fact anyone who isn't comfortable compiling their own kernel, from ever trying out any security module that their distro vendor of choice did not ship. This strikes me as a rather anti-choice position to take. It says that because candy is bad for you, you only ever get to eat vegetables. I don't understand why Linux would want to do this to its users. It doesn't hurt me or AppArmor. Since AppArmor is now shipping with SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Eric W. Biederman wrote: > My very practical question: How do I run selinux in one container, > and SMACK in another? > In AppArmor, we plan to 'containerize' (not sure what to call it) policy so that you can have an AppArmor policy per container. This is not currently the case, it is just the direction we want to go. We think it would be very useful for virtual hosts to be able to have their own AppArmor policy, independent of what other hosts are doing. The major step towards this goal so far is that AppArmor rules are now canonicalized to the name space. However, I have never considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Eric W. Biederman wrote: My very practical question: How do I run selinux in one container, and SMACK in another? In AppArmor, we plan to 'containerize' (not sure what to call it) policy so that you can have an AppArmor policy per container. This is not currently the case, it is just the direction we want to go. We think it would be very useful for virtual hosts to be able to have their own AppArmor policy, independent of what other hosts are doing. The major step towards this goal so far is that AppArmor rules are now canonicalized to the name space. However, I have never considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: > Security, on the other hand, very much does depend on the circumstances > and the wishes of the users (or policy-makers). And if we had one module > that everybody would be happy with, I'd not make it pluggable either. But > as it is, we _know_ that's not the case. > And you claim you are not a security expert :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Linus Torvalds wrote: Security, on the other hand, very much does depend on the circumstances and the wishes of the users (or policy-makers). And if we had one module that everybody would be happy with, I'd not make it pluggable either. But as it is, we _know_ that's not the case. And you claim you are not a security expert :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler wrote: > I respect the design decisions that SELinux has made regarding > granularity without agreeing with them myself. > It isn't even an exclusive decision: both design points can be "right", but aimed at different use cases. Which is why LSM exists, so users can decide on an appropriate mechanism. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler wrote: I respect the design decisions that SELinux has made regarding granularity without agreeing with them myself. It isn't even an exclusive decision: both design points can be right, but aimed at different use cases. Which is why LSM exists, so users can decide on an appropriate mechanism. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview
Sean wrote: > On Wed, 27 Jun 2007 14:06:04 -0700 > Crispin Cowan <[EMAIL PROTECTED]> wrote: > >> I am hoping for a reconciliation where the people who don't like >> AppArmor live with it by not using it. AppArmor is not intended to >> replace SELinux, it is intended to address a different set of goals. >> > You keep saying that. But for that to be true you'd have to believe > _everyone_ using Novell distributions has needs that align exactly > with AppArmor. Otherwise, how to explain that you don't offer and > support both SELinux and AppArmor to your users? > They are meant to co-exist in the Linux kernel source tree. It is a fact that there exist use cases where AppArmor is incapable of meeting the need and SELinux is just the right thing. It is Novell's business judgment that there are not enough of those situations in our customer base to be worth the additional expense at this time. But we do not want to prevent other people from using SELinux if it suits them. Linux is about choice, and that is especially vital in security. As Linus himself observed when LSM was started, there are a lot of security models, they have various strengths and weaknesses, and often are not compatible with each other. That is why it is important that LSM persist, that SELinux not be the only in-tree user of LSM, and why we think AppArmor should be included upstream, so that non-SUSE users can also use AppArmor if it suits them. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview
Adrian Bunk wrote: > On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote: > >> Do you agree with the "irreconcilable" part? I think I do. I am hoping for a reconciliation where the people who don't like AppArmor live with it by not using it. AppArmor is not intended to replace SELinux, it is intended to address a different set of goals. >> I suspect that we're at the stage of having to decide between >> >> a) set aside the technical issues and grudgingly merge this stuff as a >>service to Suse and to their users (both of which entities are very >>important to us) and leave it all as an object lesson in >>how-not-to-develop-kernel-features. >> >>Minimisation of the impact on the rest of the kernel is of course >>very important here. >> >> versus >> >> b) leave it out and require that Suse wear the permanent cost and >>quality impact of maintaining it out-of-tree. It will still be an >>object lesson in how-not-to-develop-kernel-features. >> ... > versus > > c) if [1] AppArmor is considered to be something that wouldn't >be merged if it wasn't already widely deployed by Suse: leave it out, >work on an ideal solution [2], and let Suse wear the one-time cost >of migrating their users to the ideal solution > We argue that the proposed patch is a viable solution for providing AppArmor functionality. We would be happy for specific suggestions on how to make it better. > I'm not claiming to understand the technical details, but from both > slightly reading over the previous discussions and the "What are the > advantages of AppArmor over SELinux?" section in the AppArmor FAQ [3] my > impression is that a main advantage of AppArmor are more user friendly > userspace tools. Therefore, if [1] AppArmor is considered technically > inferior to SELinux, it might still become more popular than SELinux > simply because it's easier to use - and although it's technically > inferior. AppArmor's advantages come from the model, not the tools. AppArmor is not inferior to SELinux, it is different than SELinux. Neither can replace the other without horrid kludges. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview
Adrian Bunk wrote: On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote: Do you agree with the irreconcilable part? I think I do. I am hoping for a reconciliation where the people who don't like AppArmor live with it by not using it. AppArmor is not intended to replace SELinux, it is intended to address a different set of goals. I suspect that we're at the stage of having to decide between a) set aside the technical issues and grudgingly merge this stuff as a service to Suse and to their users (both of which entities are very important to us) and leave it all as an object lesson in how-not-to-develop-kernel-features. Minimisation of the impact on the rest of the kernel is of course very important here. versus b) leave it out and require that Suse wear the permanent cost and quality impact of maintaining it out-of-tree. It will still be an object lesson in how-not-to-develop-kernel-features. ... versus c) if [1] AppArmor is considered to be something that wouldn't be merged if it wasn't already widely deployed by Suse: leave it out, work on an ideal solution [2], and let Suse wear the one-time cost of migrating their users to the ideal solution We argue that the proposed patch is a viable solution for providing AppArmor functionality. We would be happy for specific suggestions on how to make it better. I'm not claiming to understand the technical details, but from both slightly reading over the previous discussions and the What are the advantages of AppArmor over SELinux? section in the AppArmor FAQ [3] my impression is that a main advantage of AppArmor are more user friendly userspace tools. Therefore, if [1] AppArmor is considered technically inferior to SELinux, it might still become more popular than SELinux simply because it's easier to use - and although it's technically inferior. AppArmor's advantages come from the model, not the tools. AppArmor is not inferior to SELinux, it is different than SELinux. Neither can replace the other without horrid kludges. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 00/44] AppArmor security module overview
Sean wrote: On Wed, 27 Jun 2007 14:06:04 -0700 Crispin Cowan [EMAIL PROTECTED] wrote: I am hoping for a reconciliation where the people who don't like AppArmor live with it by not using it. AppArmor is not intended to replace SELinux, it is intended to address a different set of goals. You keep saying that. But for that to be true you'd have to believe _everyone_ using Novell distributions has needs that align exactly with AppArmor. Otherwise, how to explain that you don't offer and support both SELinux and AppArmor to your users? They are meant to co-exist in the Linux kernel source tree. It is a fact that there exist use cases where AppArmor is incapable of meeting the need and SELinux is just the right thing. It is Novell's business judgment that there are not enough of those situations in our customer base to be worth the additional expense at this time. But we do not want to prevent other people from using SELinux if it suits them. Linux is about choice, and that is especially vital in security. As Linus himself observed when LSM was started, there are a lot of security models, they have various strengths and weaknesses, and often are not compatible with each other. That is why it is important that LSM persist, that SELinux not be the only in-tree user of LSM, and why we think AppArmor should be included upstream, so that non-SUSE users can also use AppArmor if it suits them. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Kyle Moffett wrote: > Let's go over the differences between "my fs" and "my LSM", and the > similarities between "my VM" and "my LSM": Filesystems don't get > hooked from virtually every userspace-initiated operation, whereas > both VMs and LSMs do. VMs and LSMs attach anonymous state data to a > large percentage of the allocated objects in the system, whereas > filesystems allocate their own independent datastructure and use > that. Would you want to "rmmod ext3" and then "modprobe ext2" while > you have an ext2-as-ext3 filesystem *mounted*??? If you want a good > analogy, that's a better one than the "my fs can't be a module" crap. > > This whole discussion boils down to 2 points: > 1) As currently implemented, no LSM may be safely rmmod-ed > 2) Someone has submitted a patch which fixes that problem (you can't > rmmod them at all, so no crashes) > > If you really want to do modular LSMs, then you need to submit a patch > which fixes all the race conditions in LSM removal *without* adding > much extra overhead. I'm sure if your solutions works then everyone > will be much more open to modular LSMs. I said this before: Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module. Consider the use case of joe admin who is running enterprise-supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Without James's patch, he can do that, and at worst has a tainted kernel. RH or Novell or his favorite distro vendor can fix that with a wave of the hand and bless FooSecure as a module. With James's patch, he has to patch his kernels, and then enterprise support is hopeless, to say nothing of the barrier to entry that "patch and rebuild kernel" is more than many admins are willing to do. So to solve the problem James & Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Chris Wright wrote: > * Chris Mason ([EMAIL PROTECTED]) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. >> > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). To do pathname-based access control in any way, the LSM must be able to obtain the pathname of an accessed object. The discussion should be about the best way for an LSM to obtain the pathname of an object being accessed. To find the pathname of the object, LSM needs the VFS mount point data. The VFS owns this information, so the question is the best way to convey it from VFS to relevant LSM hooks. We are agnostic about how to get that mount point data, but AFAICT saying that LSM can't see the mount point data at all is equivalent to rejecting pathname based access control entirely. > Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > The reverse path construction has been criticized for being both broken and counter-intuitive. Our secure d_path patch fixes the "broken" part, it now securely reconstructs the path. The counter-intuitive is because forward construction of the pathname has unexpected costs, making the retroactive construction more attractive. > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). John Johansen posted a patch (written by Andreas Gruenbacher) that introduced a nameidata2 data structure to try to solve the conditional null passing problem, but it received no comment. A proper fix to this problem is clearly desirable, but it also is clearly a defect in NFS and fixing it is a lot of work; why does AA have to stay outside the kernel until NFS is fixed, when it can easily adapt to the problem until it is fixed properly? > You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. I think it is a little more fundamental than that. If you are going to do pathname based access control at all, you need access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Chris Wright wrote: * Chris Mason ([EMAIL PROTECTED]) wrote: I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then. Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). To do pathname-based access control in any way, the LSM must be able to obtain the pathname of an accessed object. The discussion should be about the best way for an LSM to obtain the pathname of an object being accessed. To find the pathname of the object, LSM needs the VFS mount point data. The VFS owns this information, so the question is the best way to convey it from VFS to relevant LSM hooks. We are agnostic about how to get that mount point data, but AFAICT saying that LSM can't see the mount point data at all is equivalent to rejecting pathname based access control entirely. Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity). The reverse path construction has been criticized for being both broken and counter-intuitive. Our secure d_path patch fixes the broken part, it now securely reconstructs the path. The counter-intuitive is because forward construction of the pathname has unexpected costs, making the retroactive construction more attractive. AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). John Johansen posted a patch (written by Andreas Gruenbacher) that introduced a nameidata2 data structure to try to solve the conditional null passing problem, but it received no comment. A proper fix to this problem is clearly desirable, but it also is clearly a defect in NFS and fixing it is a lot of work; why does AA have to stay outside the kernel until NFS is fixed, when it can easily adapt to the problem until it is fixed properly? You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours. I think it is a little more fundamental than that. If you are going to do pathname based access control at all, you need access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
Kyle Moffett wrote: Let's go over the differences between my fs and my LSM, and the similarities between my VM and my LSM: Filesystems don't get hooked from virtually every userspace-initiated operation, whereas both VMs and LSMs do. VMs and LSMs attach anonymous state data to a large percentage of the allocated objects in the system, whereas filesystems allocate their own independent datastructure and use that. Would you want to rmmod ext3 and then modprobe ext2 while you have an ext2-as-ext3 filesystem *mounted*??? If you want a good analogy, that's a better one than the my fs can't be a module crap. This whole discussion boils down to 2 points: 1) As currently implemented, no LSM may be safely rmmod-ed 2) Someone has submitted a patch which fixes that problem (you can't rmmod them at all, so no crashes) If you really want to do modular LSMs, then you need to submit a patch which fixes all the race conditions in LSM removal *without* adding much extra overhead. I'm sure if your solutions works then everyone will be much more open to modular LSMs. I said this before: Hmmm. You seem to be mostly concerned with safely rmmod'ing modules. In contrast, my main concern with the proposed patch is that it removes the ability to *insert* a module. Consider the use case of joe admin who is running enterprise-supported RHEL or SLES, and wants to try some newfangled LSM FooSecureMod thingie. So he grabs a machine, config's selinux=0 or apparmor=0 and loads his own module on boot, and plays with it. He even likes FooSecure, better than SELinux or AppArmor, and wants to roll it out across his data center. Without James's patch, he can do that, and at worst has a tainted kernel. RH or Novell or his favorite distro vendor can fix that with a wave of the hand and bless FooSecure as a module. With James's patch, he has to patch his kernels, and then enterprise support is hopeless, to say nothing of the barrier to entry that patch and rebuild kernel is more than many admins are willing to do. So to solve the problem James Kyle are concerned with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: > On Thu, 21 Jun 2007, Chris Mason wrote: >>> The incomplete mediation flows from the design, since the pathname-based >>> mediation doesn't generalize to cover all objects unlike label- or >>> attribute-based mediation. And the "use the natural abstraction for >>> each object type" approach likewise doesn't yield any general model or >>> anything that you can analyze systematically for data flow. >>> >> This feels quite a lot like a repeat of the discussion at the kernel >> summit. There are valid uses for path based security, and if they don't >> fit your needs, please don't use them. But, path based semantics alone >> are not a valid reason to shut out AA. >> > The validity or otherwise of pathname access control is not being > discussed here. > > The point is that the pathname model does not generalize, and that > AppArmor's inability to provide adequate coverage of the system is a > design issue arising from this. > The above two paragraphs appear to contradict each other. > Recall that the question asked by Lars was whether there were any > outstanding technical issues relating to AppArmor. > > AppArmor does not and can not provide the level of confinement claimed by > the documentation, and its policy does not reflect its actual confinement > properties. That's kind of a technical issue, right? > So if the document said "confinement with respect to direct file access and POSIX.1e capabilities" and that list got extended as AA got new confinement features, would that address your issue? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
James Morris wrote: On Thu, 21 Jun 2007, Chris Mason wrote: The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the use the natural abstraction for each object type approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow. This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA. The validity or otherwise of pathname access control is not being discussed here. The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this. The above two paragraphs appear to contradict each other. Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor. AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right? So if the document said confinement with respect to direct file access and POSIX.1e capabilities and that list got extended as AA got new confinement features, would that address your issue? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Greg KH wrote: > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: > >> Then there's all the other problems, such as file systems that don't >> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable >> to network attack, but that is not the threat AA is addressing. AA is >> preventing an application with access to an NFS mount from accessing the >> *entire* mount. There is lots of practical security value in this, and >> label schemes cannot do it. Well, mostly; you could do it with a dynamic >> labeling scheme that labels files as they are pulled into kernel memory, >> but that requires an AA-style regexp parser in the kernel to apply the >> labels. >> > You still haven't answered Stephen's response to NFSv3, so until then, > please don't trot out this horse. > Ok then ... Stephen Smalley wrote: > - File systems that do not support labels: I'm a bit surprised that you > would advocate this given your experience in developing EA and ACL > support for local filesystems and NFS. The pathname-based approach in > NFS seems even scarier than in the local case - the clients may have > different views of the namespace than one another or the server and the > potential for inconsistent views of the tree (particularly as it is > being modified) during access checks is only greater in the NFS case, > right? It may be more expedient to implement, but is it the right > technical approach? I'm actually unclear on what the question is. Stephen appears to be thinking of confining the NFS server daemon, and our intended use case is to use AppArmor to confine applications that access data on NFS clients. * Each NFS *client* machine has a view of the NFS mount point that is consistent for that client. * The AA confinement is of the application accessing the NFS mount on the client, *not* the NFS server daemon. * The fact that the views of multiple clients are different from each other is irrelevant, because we are confining applications on the client, not the NFS server daemon. * As noted in Andreas' technical document http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf there is no purpose to confining the NFS server daemon; it is a kernel process, and if it mis-behaves, it can completely subvert any kernel security policy, including AA and SELinux. Since this point seems to be subtle, here's a motivating example. Consider I have a diskless workstation, and my home dir /home/crispin is NFS mounted from a big NAS server over there. I like to run my FireFox confined, so that it only has access to /home/crispin/.mozilla/** and /home/crispin/Downloads/** so that if my browser is compromised, the attacker doesn't get to my /home/.ssh* stuff. Yes, the data served over NFS is vulnerable to a local network attack, but that is not what AA is preventing here. The threat is coming from attacks that make the web browser misbehave. Under SELinux, I either give the web browser access to all of /home/crispin (the entire mount point) or none of it. Under AA, the pathname specification works fine, we can control which directories on the mount point the application can access. The same argument applies to server applications that access data served NFS mount points. Consider a large application server that hosts all my enterprise resource management stuff, and a large NAS server that hosts the data. Perhaps the NAS server is a Network Appliance server, not even using a Linux file system, just supplying NFS3 mounts. The application server is hosting both the payroll system and the customer relationship application. The data for both are on the NetApp, serviced via NFS to the application server. I want to confine the payroll application to access only the payroll data, and the CRM application to access only CRM data. The only way SELinux could do this would be to have anticipated the problem and store my data on separate partitions, so you could supply separate mount points. AppArmor can just use path specifications to confine each application to its own part of a single NFS mount point. In a perfect world the admin would use separate mount points, AppArmor is a tool for an imperfect world. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Greg KH wrote: On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Then there's all the other problems, such as file systems that don't support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labeling scheme that labels files as they are pulled into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels. You still haven't answered Stephen's response to NFSv3, so until then, please don't trot out this horse. Ok then ... Stephen Smalley wrote: - File systems that do not support labels: I'm a bit surprised that you would advocate this given your experience in developing EA and ACL support for local filesystems and NFS. The pathname-based approach in NFS seems even scarier than in the local case - the clients may have different views of the namespace than one another or the server and the potential for inconsistent views of the tree (particularly as it is being modified) during access checks is only greater in the NFS case, right? It may be more expedient to implement, but is it the right technical approach? I'm actually unclear on what the question is. Stephen appears to be thinking of confining the NFS server daemon, and our intended use case is to use AppArmor to confine applications that access data on NFS clients. * Each NFS *client* machine has a view of the NFS mount point that is consistent for that client. * The AA confinement is of the application accessing the NFS mount on the client, *not* the NFS server daemon. * The fact that the views of multiple clients are different from each other is irrelevant, because we are confining applications on the client, not the NFS server daemon. * As noted in Andreas' technical document http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf there is no purpose to confining the NFS server daemon; it is a kernel process, and if it mis-behaves, it can completely subvert any kernel security policy, including AA and SELinux. Since this point seems to be subtle, here's a motivating example. Consider I have a diskless workstation, and my home dir /home/crispin is NFS mounted from a big NAS server over there. I like to run my FireFox confined, so that it only has access to /home/crispin/.mozilla/** and /home/crispin/Downloads/** so that if my browser is compromised, the attacker doesn't get to my /home/.ssh* stuff. Yes, the data served over NFS is vulnerable to a local network attack, but that is not what AA is preventing here. The threat is coming from attacks that make the web browser misbehave. Under SELinux, I either give the web browser access to all of /home/crispin (the entire mount point) or none of it. Under AA, the pathname specification works fine, we can control which directories on the mount point the application can access. The same argument applies to server applications that access data served NFS mount points. Consider a large application server that hosts all my enterprise resource management stuff, and a large NAS server that hosts the data. Perhaps the NAS server is a Network Appliance server, not even using a Linux file system, just supplying NFS3 mounts. The application server is hosting both the payroll system and the customer relationship application. The data for both are on the NetApp, serviced via NFS to the application server. I want to confine the payroll application to access only the payroll data, and the CRM application to access only CRM data. The only way SELinux could do this would be to have anticipated the problem and store my data on separate partitions, so you could supply separate mount points. AppArmor can just use path specifications to confine each application to its own part of a single NFS mount point. In a perfect world the admin would use separate mount points, AppArmor is a tool for an imperfect world. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
t labels in general are bad, just that they are a bad way to emulate the AppArmor model. And yes, I am working on a model paper that is more abstract than Andreas' paper <http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf>, but that takes time. Then there's all the other problems, such as file systems that don't support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labeling scheme that labels files as they are pulled into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labeling scheme that labels files as they are pulled into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
[EMAIL PROTECTED] wrote:
> On Fri, 8 Jun 2007, Greg KH wrote:
>> I still want to see a definition of the AA "model" that we can then use
>> to try to implement using whatever solution works best. As that seems
>> to be missing the current argument of if AA can or can not be
>> implemented using SELinux or something totally different should be
>> stopped.
> the way I would describe the difference betwen AA and SELinux is:
>
> SELinux is like a default allow IPS system, you have to describe
> EVERYTHING to the system so that it knows what to allow and what to stop.
>
> AA is like a default deny firewall, you describe what you want to
> happen, and it blocks everything else without you even having to
> realize that it's there.
That's not quite right:
* SELinux Strict Policy is a default-deny system: it specifies
everything that is permitted system wide, and all else is denied.
* AA and the SELinux Targeted Policy are hybrid systems:
o default-deny within a policy or profile: confined processes
are only permitted to do what the policy says, and all else
is denied.
o default-allow system wide: unconfined processes are allowed
to do anything that classic DAC permissions allow.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Casey Schaufler wrote: > --- [EMAIL PROTECTED] wrote: > >>> Yes, and in the process, AA stores compiled regular expressions in >>> kernel. Ouch. I'll take "each file it's own label" over _that_ any time. >>> >> and if each file has it's own label you are going to need regex or similar >> to deal with them as well. >> > Now that you're going to have to explain. Nothing like that > on any of the MLS systems I'm familiar with, and I think that > I know just about all of them. > I suspect that David meant that if you were using "unique label per file" as an implementation technique to implement AA on top of SELinux, that you would then need a regexp to discern labels. It's hard to recall with all the noise, but at this point in the thread the discussion is about the best way to implement AA. Some have alleged that AA layered on top of SELinux is the best way. I think that is clearly wrong; AA layered on top of SELinux is possible, but would require a bunch of enhancements to SELinux first, and the result would be more complex than the proposed AA patch and have weaker functionality and performance. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Andreas Gruenbacher wrote: > On Saturday 09 June 2007 02:17, Greg KH wrote: > >> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: >> >>> AppArmor is meant to be relatively easy to understand, manage, and >>> customize, and introducing a labels layer wouldn't help these goals. >>> >> Woah, that describes the userspace side of AA just fine, it means >> nothing when it comes to the in-kernel implementation. There is no >> reason that you can't implement the same functionality using some >> totally different in-kernel solution if possible. >> > I agree that the in-kernel implementation could use different abstractions > than user-space, provided that the underlying implementation details can be > hidden well enough. The key phrase here is "if possible", and in fact "if > possible" is much too strong: very many things in software are possible, > including user-space drives and a stable kernel module ABI. Some things make > sense; others are genuinely bad ideas while still possible. > In particular, to layer AppArmor on top of SELinux, the following problems must be addressed: * New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says "/home/*/.plan r" to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux. * Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename. * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. * New Policies: The SEEdit approach of compiling AA profiles into SELinux labels involves computing the partition set of files, so that each element of the partition set is unique, and corresponds to all the policies that treat every file in the element identically. If you create a new profile that touches *some* of the files in such an element, then you have to split that synthetic label, re-compute the partition set, and re-label the file system. * File Systems That Do Not Support Labels: The most important being NFS3 and FAT. Because they do not support labels at all, SELinux has to give you an all-or-nothing access control on the entire remote volume. AA can give you nuanced access control in these file systems. You could support all of these features in SELinux, but only by adding an in-kernel file matching mechanism similar to AppArmor. It would basically load an AppArmor policy into the kernel, label files as they are brought from disk into the cache, and then use SELinux to do the access controls. That doesn't make it a good idea: * The patch would be at least as complex and intrusive as the proposed AppArmor patch, there is no simplicity already-upstream savings here. * It would require the VFS and d_path patches that AppArmor needs to pass mount points down. * It would make AppArmor's ability to change policies on a live system more difficult. * The necessary extensions would not be appealing to the SELinux community. LSM is the common code that AA and SELinux have agreed to be mutually useful. Forcing AA to sit on top of SELinux would harm both AA and SELinux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Andreas Gruenbacher wrote: On Saturday 09 June 2007 02:17, Greg KH wrote: On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. Woah, that describes the userspace side of AA just fine, it means nothing when it comes to the in-kernel implementation. There is no reason that you can't implement the same functionality using some totally different in-kernel solution if possible. I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is if possible, and in fact if possible is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible. In particular, to layer AppArmor on top of SELinux, the following problems must be addressed: * New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says /home/*/.plan r to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux. * Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename. * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files. * New Policies: The SEEdit approach of compiling AA profiles into SELinux labels involves computing the partition set of files, so that each element of the partition set is unique, and corresponds to all the policies that treat every file in the element identically. If you create a new profile that touches *some* of the files in such an element, then you have to split that synthetic label, re-compute the partition set, and re-label the file system. * File Systems That Do Not Support Labels: The most important being NFS3 and FAT. Because they do not support labels at all, SELinux has to give you an all-or-nothing access control on the entire remote volume. AA can give you nuanced access control in these file systems. You could support all of these features in SELinux, but only by adding an in-kernel file matching mechanism similar to AppArmor. It would basically load an AppArmor policy into the kernel, label files as they are brought from disk into the cache, and then use SELinux to do the access controls. That doesn't make it a good idea: * The patch would be at least as complex and intrusive as the proposed AppArmor patch, there is no simplicity already-upstream savings here. * It would require the VFS and d_path patches that AppArmor needs to pass mount points down. * It would make AppArmor's ability to change policies on a live system more difficult. * The necessary extensions would not be appealing to the SELinux community. LSM is the common code that AA and SELinux have agreed to be mutually useful. Forcing AA to sit on top of SELinux would harm both AA and SELinux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Casey Schaufler wrote: --- [EMAIL PROTECTED] wrote: Yes, and in the process, AA stores compiled regular expressions in kernel. Ouch. I'll take each file it's own label over _that_ any time. and if each file has it's own label you are going to need regex or similar to deal with them as well. Now that you're going to have to explain. Nothing like that on any of the MLS systems I'm familiar with, and I think that I know just about all of them. I suspect that David meant that if you were using unique label per file as an implementation technique to implement AA on top of SELinux, that you would then need a regexp to discern labels. It's hard to recall with all the noise, but at this point in the thread the discussion is about the best way to implement AA. Some have alleged that AA layered on top of SELinux is the best way. I think that is clearly wrong; AA layered on top of SELinux is possible, but would require a bunch of enhancements to SELinux first, and the result would be more complex than the proposed AA patch and have weaker functionality and performance. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
[EMAIL PROTECTED] wrote: On Fri, 8 Jun 2007, Greg KH wrote: I still want to see a definition of the AA model that we can then use to try to implement using whatever solution works best. As that seems to be missing the current argument of if AA can or can not be implemented using SELinux or something totally different should be stopped. the way I would describe the difference betwen AA and SELinux is: SELinux is like a default allow IPS system, you have to describe EVERYTHING to the system so that it knows what to allow and what to stop. AA is like a default deny firewall, you describe what you want to happen, and it blocks everything else without you even having to realize that it's there. That's not quite right: * SELinux Strict Policy is a default-deny system: it specifies everything that is permitted system wide, and all else is denied. * AA and the SELinux Targeted Policy are hybrid systems: o default-deny within a policy or profile: confined processes are only permitted to do what the policy says, and all else is denied. o default-allow system wide: unconfined processes are allowed to do anything that classic DAC permissions allow. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
[EMAIL PROTECTED] wrote: > On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said: > >> Average users are not supposed to be writing security policy. To be >> honest, even average-level system administrators should not be >> writing security policy. That explains so much! "SELinux: you're too dumb to use it, so just keep your hands in your pockets." :-) AppArmor was designed to allow your average sys admin to write a security policy. It makes different design choices than SELinux to achieve that goal. As a result, AppArmor is an utter failure when compared to SELinux's goals, and SELinux in turn is an utter failure when compared to AppArmor's goals. Which is why we have LSM: so we don't have to have this argument here, again. >> It's OK for such sysadmins to tweak >> existing policy to give access to additional web-docs or such, but >> only expert sysadmin/developers or security professionals should be >> writing security policy. It's just too damn easy to get completely >> wrong. >> > The single biggest challenge in computer security at the present time is how > to > build *and deploy* servers that stay reasonably secure even when run by the > average wave-a-dead-chicken sysadmin, and desktop-class boxes that can survive > the best attempts of Joe Sixpack's "Ooh shiny" reflex, and Joe's kid's > attempts > to evade the nannyware that Joe had somebody install. > That is a tall order. You can mostly achieve it by not giving the user the root password, but I'm not sure you would like the result :-) Both SELinux and AppArmor can be configured so tightly that you are not going to get to install malware, by preventing the user from installing software. This isn't what users want, so they invariably bypass security and install shiny things if they own the box. SELinux and AppArmor can't help but fail if you put them in that kind of harm's way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Pavel Machek wrote: >> * Hard links: AppArmor explicitly mediates permission to make a hard >> > Unfortunately, aparmor is by design limited to subset of distro > (network daemons). That is not true. AppArmor is designed to confine any application you do not want to trust completely. This includes network daemons (Apache, Sendmail, BIND, etc.) network clients (Firefox, Thunderbird, GAIM/Pidgin, etc.) and any other application that mediates trust: where data on one side of the application is higher privilege than potential attackers on the other side of the application. > Unfortunately, some other programs (passwd, vi) > routinely make hardlinks. So AA mediating hardlink is not enough, as > vi will happily hardlink /etc/shadow into /etc/.vi-shadow-1234. > I have no idea what you are talking about. I routinely profile vim on stage in AppArmor presentations, and it presents no such problems. Caveat: the circumstances under which you would actually want to profile vi are rather limited, most users would not want to do that. In another post Pavel Machek wrote: > Hmm, I guess I'd love "it is useless on multiuser boxes" to become > standard part of AA advertising. That is usually around slide 7 of the standard AppArmor presentation, right next to the remarks about how mulituser boxes are nearly extinct dinosaurs. AppArmor gets some of its simplicity and ease of use by not considering that vanishing use case. Even so, AppArmor does have uses on multiuser boxes, just not the uses Pavel wishes for. Fine, use a different tool for a different task, AppArmor has plenty of use cases. The limitation Pavel is referring to is that AppArmor does not secure processes that are not profiled by AppArmor. We know, this is intentional, and contributes to AppArmor's ease of use, and does not generate a hole if you consider every process exposed to (say) network attack and confine it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Pavel Machek wrote: * Hard links: AppArmor explicitly mediates permission to make a hard Unfortunately, aparmor is by design limited to subset of distro (network daemons). That is not true. AppArmor is designed to confine any application you do not want to trust completely. This includes network daemons (Apache, Sendmail, BIND, etc.) network clients (Firefox, Thunderbird, GAIM/Pidgin, etc.) and any other application that mediates trust: where data on one side of the application is higher privilege than potential attackers on the other side of the application. Unfortunately, some other programs (passwd, vi) routinely make hardlinks. So AA mediating hardlink is not enough, as vi will happily hardlink /etc/shadow into /etc/.vi-shadow-1234. I have no idea what you are talking about. I routinely profile vim on stage in AppArmor presentations, and it presents no such problems. Caveat: the circumstances under which you would actually want to profile vi are rather limited, most users would not want to do that. In another post Pavel Machek wrote: Hmm, I guess I'd love it is useless on multiuser boxes to become standard part of AA advertising. That is usually around slide 7 of the standard AppArmor presentation, right next to the remarks about how mulituser boxes are nearly extinct dinosaurs. AppArmor gets some of its simplicity and ease of use by not considering that vanishing use case. Even so, AppArmor does have uses on multiuser boxes, just not the uses Pavel wishes for. Fine, use a different tool for a different task, AppArmor has plenty of use cases. The limitation Pavel is referring to is that AppArmor does not secure processes that are not profiled by AppArmor. We know, this is intentional, and contributes to AppArmor's ease of use, and does not generate a hole if you consider every process exposed to (say) network attack and confine it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
[EMAIL PROTECTED] wrote: On Mon, 28 May 2007 21:54:46 EDT, Kyle Moffett said: Average users are not supposed to be writing security policy. To be honest, even average-level system administrators should not be writing security policy. That explains so much! SELinux: you're too dumb to use it, so just keep your hands in your pockets. :-) AppArmor was designed to allow your average sys admin to write a security policy. It makes different design choices than SELinux to achieve that goal. As a result, AppArmor is an utter failure when compared to SELinux's goals, and SELinux in turn is an utter failure when compared to AppArmor's goals. Which is why we have LSM: so we don't have to have this argument here, again. It's OK for such sysadmins to tweak existing policy to give access to additional web-docs or such, but only expert sysadmin/developers or security professionals should be writing security policy. It's just too damn easy to get completely wrong. The single biggest challenge in computer security at the present time is how to build *and deploy* servers that stay reasonably secure even when run by the average wave-a-dead-chicken sysadmin, and desktop-class boxes that can survive the best attempts of Joe Sixpack's Ooh shiny reflex, and Joe's kid's attempts to evade the nannyware that Joe had somebody install. That is a tall order. You can mostly achieve it by not giving the user the root password, but I'm not sure you would like the result :-) Both SELinux and AppArmor can be configured so tightly that you are not going to get to install malware, by preventing the user from installing software. This isn't what users want, so they invariably bypass security and install shiny things if they own the box. SELinux and AppArmor can't help but fail if you put them in that kind of harm's way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
e label of a new file: * the label of the parent directory * the label of the creating process * the domain for the creating process can do conditional things based on the label of the parent directory and the creating process * applications that link to libselinux can overtly set the label according to application logic AppArmor, not using labels, doesn't have this problem. You can write an AA profile with respect to files and directories that don't exist at all. > * if this type of solution requires significant additional management > (as it seems to) it is probably not a suitable addition to a pathname > based confinement mechanism. As I explained above, a lot of it is already in place with our mediation of hard links. Our mediation of multiple mount points and name spaces is lame, but the extent to which this needs to be improved will largely be determined by how application developers choose to use these features. Because AppArmor is intended primarily to confine applications, an administrative approach of just using unconfined (completely trusted) shells to manipulate name spaces and multiple mount points suffices, and application manipulation of name spaces and multiple mount points is the only concern. > * A program creating a new file and copying the contents of the file > is outside of the scope of this solution. That is the information flow problem. While important, it is fairly separate from the alias problem. The information flow problem is general to all access control systems, while the alias problem is special to name-based access control systems. This is one of the name/label trade-offs. Aliasing is problematic in name based systems, while new file creation is problematic in label based systems. This follows directly from the semantics each system is using: * Names are references. Name based systems are really mediating access to references. Thus creating new references and who can access these new references is problematic. * Labels are equivalence classes of objects. Label based systems are really mediating access to objects, regardless of the reference. Thus creating new objects and who can access these new objects is problematic. > * Stoping a path from pointing to arbitrary data is also outside the > scope of this solution (for example "/etc/shadow" could be replaced > with another file). This depends on where you place the "may alias" access control. You can put it on the source (/tmp/harmless -> somewhere) on the target (somewhere -> /etc/shadow) or somewhere else (what AppArmor does, associating the policy with confined processes). > Could a name based policy include the pathname as well as an inode > number or some (more secure) identifying attribute (which could be > calculated based on the supplied pathname)? A one-way-hash would > identify but could not be used for each file a program accesses as > they can change... It could be done, but that has implications. That would mean that you get the "belt and suspenders" effect of all of the security benefits of (say) AppArmor and SELinux. But the non-overlapping security benefits are relatively small (SELinux advocates may dispute this, but whatever, it is some magnitude). On the other hand, you would get the management problems of both AppArmor and SELinux; you would have to solve both the new file problem, and the file alias problem. Think about what you would have to do to accommodate (say) a text editor's file save procedure of "write new file.tmp, rename oldfile to oldfile.old, rename newfile.tmp to oldfile, delete oldfile.old". So it could be done, but AFAICT, with small benefit and large cost. More security may be more secure, but it isn't necessarily better. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
process * applications that link to libselinux can overtly set the label according to application logic AppArmor, not using labels, doesn't have this problem. You can write an AA profile with respect to files and directories that don't exist at all. * if this type of solution requires significant additional management (as it seems to) it is probably not a suitable addition to a pathname based confinement mechanism. As I explained above, a lot of it is already in place with our mediation of hard links. Our mediation of multiple mount points and name spaces is lame, but the extent to which this needs to be improved will largely be determined by how application developers choose to use these features. Because AppArmor is intended primarily to confine applications, an administrative approach of just using unconfined (completely trusted) shells to manipulate name spaces and multiple mount points suffices, and application manipulation of name spaces and multiple mount points is the only concern. * A program creating a new file and copying the contents of the file is outside of the scope of this solution. That is the information flow problem. While important, it is fairly separate from the alias problem. The information flow problem is general to all access control systems, while the alias problem is special to name-based access control systems. This is one of the name/label trade-offs. Aliasing is problematic in name based systems, while new file creation is problematic in label based systems. This follows directly from the semantics each system is using: * Names are references. Name based systems are really mediating access to references. Thus creating new references and who can access these new references is problematic. * Labels are equivalence classes of objects. Label based systems are really mediating access to objects, regardless of the reference. Thus creating new objects and who can access these new objects is problematic. * Stoping a path from pointing to arbitrary data is also outside the scope of this solution (for example /etc/shadow could be replaced with another file). This depends on where you place the may alias access control. You can put it on the source (/tmp/harmless - somewhere) on the target (somewhere - /etc/shadow) or somewhere else (what AppArmor does, associating the policy with confined processes). Could a name based policy include the pathname as well as an inode number or some (more secure) identifying attribute (which could be calculated based on the supplied pathname)? A one-way-hash would identify but could not be used for each file a program accesses as they can change... It could be done, but that has implications. That would mean that you get the belt and suspenders effect of all of the security benefits of (say) AppArmor and SELinux. But the non-overlapping security benefits are relatively small (SELinux advocates may dispute this, but whatever, it is some magnitude). On the other hand, you would get the management problems of both AppArmor and SELinux; you would have to solve both the new file problem, and the file alias problem. Think about what you would have to do to accommodate (say) a text editor's file save procedure of write new file.tmp, rename oldfile to oldfile.old, rename newfile.tmp to oldfile, delete oldfile.old. So it could be done, but AFAICT, with small benefit and large cost. More security may be more secure, but it isn't necessarily better. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Casey Schaufler wrote:
> --- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
>
>> AppArmor cannot assume anything about argv[0],
>>
>> and it would be a really bad idea to change the well-established semantics of
>>
>> argv[0].
>>
>> There is no actual need for looking at argv[0], though: AppArmor decides
>> based
>> on the actual pathname of the executable...
>>
> Right. My point was that if you wanted to use the gzip/gunzip
> example of a file with two names being treated differently based
> on the name accessed as an argument for AppArmor you could.
AppArmor detects the pathname of the file exec'd at the time the parent
exec's it, and not anything inside the child involving argv[0].
As such, AA can detect whether you did exec("gzip") or exec("gunzip")
and apply the policy relevant to the program. It could apply different
policies to each of them, so whether it has access to /tmp/mumble/barf
depends on whether you called it 'gzip' or 'gunzip'. Caveat: it makes no
sense to profile either gzip or gunzip in the AppArmor model, so I won't
defend what kind of policy you would put on them.
Finally, AA doesn't care what the contents of the executable are. We
assume that it is a copy of metasploit or something, and confine it to
access only the resources that the policy says.
> If
> you don't want to, that's ok too. Jeremy raised a reasonable objection,
> and AppArmor could address it if y'all chose to do so. I seriously
> doubt that enforcing the argv[0] convention would break much, and I
> also expect that if it did there's a Consultant's Retirement to be
> made fixing the security hole it points out.
>
AppArmor does address it, and I hope this explains how we detect which
of multiple hard links to a file you used to access the file without
mucking about with argv[0].
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
Security: It's not linear
-
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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Casey Schaufler wrote: --- Andreas Gruenbacher [EMAIL PROTECTED] wrote: AppArmor cannot assume anything about argv[0], and it would be a really bad idea to change the well-established semantics of argv[0]. There is no actual need for looking at argv[0], though: AppArmor decides based on the actual pathname of the executable... Right. My point was that if you wanted to use the gzip/gunzip example of a file with two names being treated differently based on the name accessed as an argument for AppArmor you could. AppArmor detects the pathname of the file exec'd at the time the parent exec's it, and not anything inside the child involving argv[0]. As such, AA can detect whether you did exec(gzip) or exec(gunzip) and apply the policy relevant to the program. It could apply different policies to each of them, so whether it has access to /tmp/mumble/barf depends on whether you called it 'gzip' or 'gunzip'. Caveat: it makes no sense to profile either gzip or gunzip in the AppArmor model, so I won't defend what kind of policy you would put on them. Finally, AA doesn't care what the contents of the executable are. We assume that it is a copy of metasploit or something, and confine it to access only the resources that the policy says. If you don't want to, that's ok too. Jeremy raised a reasonable objection, and AppArmor could address it if y'all chose to do so. I seriously doubt that enforcing the argv[0] convention would break much, and I also expect that if it did there's a Consultant's Retirement to be made fixing the security hole it points out. AppArmor does address it, and I hope this explains how we detect which of multiple hard links to a file you used to access the file without mucking about with argv[0]. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - 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/
