linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1182512938.24664.19.camel@moss-spartans.epoch.ncsc.mil>
Date:	Fri, 22 Jun 2007 07:48:58 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Neil Brown <neilb@...e.de>
Cc:	Lars Marowsky-Bree <lmb@...e.de>, James Morris <jmorris@...ei.org>,
	Pavel Machek <pavel@....cz>,
	Crispin Cowan <crispin@...ell.com>, Greg KH <greg@...ah.com>,
	Andreas Gruenbacher <agruen@...e.de>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
	pathname matching

On Fri, 2007-06-22 at 21:34 +1000, Neil Brown wrote:
> On Friday June 22, sds@...ho.nsa.gov wrote:
> > > 
> > > Yes. Your use case is different than mine.
> > 
> > My use case is being able to protect data reliably.  Yours?
> 
> Saying "protect data" is nearly meaningless without a threat model.
> I bet you don't try to protect data from a direct nuclear hit, or a
> court order.
> 
> 
> AA has a fairly clear threat model.  It involves a flaw in a
> program being used by an external agent to cause it to use
> privileges it would not normally exercise to subvert privacy or
> integrity.
> I think this model matches a lot of real threats that real sysadmins
> have real concerns about.  I believe that the design of AA addresses
> this model quite well.
>  
> 
> What is your threat model?  Maybe it is just different.

The threat "model" you describe above is a subset of what SELinux
addresses.  And our argument is that AA does not meet that model well,
because it relies upon ambiguous and unstable identifiers for subjects
and objects (a violation of the fundamental requirements for access
control) and because it provides very incomplete mediation.

>>From http://www.nsa.gov/selinux/info/faq.cfm:
The Security-enhanced Linux's new features are designed to enforce the
separation of information based on confidentiality and integrity
requirements. They are designed for preventing processes from reading
data and programs, tampering with data and programs, bypassing
application security mechanisms, executing untrustworthy programs, or
interfering with other processes in violation of the system security
policy. They also help to confine the potential damage that can be
caused by malicious or flawed programs. They should also be useful for
enabling a single system to be used by users with differing security
authorizations to access multiple kinds of information with differing
security requirements without compromising those security requirements.

-- 
Stephen Smalley
National Security Agency

-
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/