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/
