Re: [Apparmor-dev] Re: AppArmor Security Goal
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? 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. Comtainers allow overriding / in chroot style. This needs file or label based protection no matter the security framework. So we don't have the chroot problems of applications breaking out. Apparmors file access control features along with selinux's as a combined into a cgroup would be good. Same is required for device control. 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. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Apparmor-dev] Re: AppArmor Security Goal
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-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
