linux-kernel - Re: [Apparmor-dev] Re: AppArmor Security Goal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <47395F00.6080507@crispincowan.com>
Date:	Tue, 13 Nov 2007 00:23:28 -0800
From:	Crispin Cowan <crispin@...spincowan.com>
To:	rmeijer@...all.nl, apparmor-dev@...ge.novell.com
CC:	Crispin Cowan <crispin@...spincowan.com>,
	LSM ML <linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/