[Apparmor-dev] Re: AppArmor Security Goal
Rob Meijer
capibara at xs4all.nl
Mon Nov 12 22:51:12 MST 2007
> 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.
More information about the Apparmor-dev
mailing list