> 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. > 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. > * 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. > * A process that is not permitted to directly access a resource can > influence some other process that does have access to the resource > may do so, if the "influence" is a permitted action. > * 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. - 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
