linux-kernel - Re: AppArmor FAQ

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: <Pine.LNX.4.63.0704180001160.2442@qynat.qvtvafvgr.pbz>
Date:	Wed, 18 Apr 2007 00:08:43 -0700 (PDT)
From:	David Lang <david.lang@...italinsight.com>
To:	Rob Meijer <capibara@...all.nl>
cc:	Karl MacMillan <kmacmill@...hat.com>,
	James Morris <jmorris@...ei.org>,
	John Johansen <jjohansen@...e.de>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: AppArmor FAQ

remember that the windows NT permission model is theoreticly superior to the 
Unix permission model.

however there are far more insecure windows boxes out there then Unix boxes 
(even if taken as a percentage of the installed base)

I don't think that anyone is claiming that AA is superior to SELinux

what people are claiming is that the model AA is proposing can improve security 
in some cases.

to use the example from this thread /etc/resolv.conf

if you have a webserver that wants to do a name lookup you can do one of two 
things

1. in AA configure the webserver to have ro access to /etc/resolv.conf

2. in SELinux tag /etc/resolv.conf, figure out every program on the sytem that 
accesses it, and then tag those programs with the right permissions.

SELinux is designed to be able to make the box safe against root, AA is designed 
to let the admin harden exposed apps without having to think about the other 
things on the system.

allow people to use each tool for the appropriate task.

David Lang

On Wed, 18 Apr 2007, Rob Meijer wrote:

> Date: Wed, 18 Apr 2007 09:21:13 +0200 (CEST)
> From: Rob Meijer <capibara@...all.nl>
> To: Karl MacMillan <kmacmill@...hat.com>
> Cc: James Morris <jmorris@...ei.org>, John Johansen <jjohansen@...e.de>,
>     linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
>     linux-fsdevel@...r.kernel.org
> Subject: Re: AppArmor FAQ
> 
> On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
>> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>>> On Mon, 16 Apr 2007, John Johansen wrote:
>>>
>>>> Label-based security (exemplified by SELinux, and its predecessors in
>>>> MLS systems) attaches security policy to the data. As the data flows
>>>> through the system, the label sticks to the data, and so security
>>>> policy with respect to this data stays intact. This is a good approach
>>>> for ensuring secrecy, the kind of problem that intelligence agencies
>>> have.
>>>
>>> Labels are also a good approach for ensuring integrity, which is one of
>>> the most fundamental aspects of the security model implemented by
>>> SELinux.
>>>
>>> Some may infer otherwise from your document.
>>>
>>
>> Not only that, the implication that secrecy is only useful to
>> intelligence agencies is pretty funny. Personally, I think that
>> protecting the confidentiality of my data is important (and my bank and
>> health care providers protecting the data they have about me). Type
>> Enforcement was specifically designed to be able to address integrity
>> _and_ confidentiality in a way acceptable to commercial organizations.
>>
>> Karl
>
> Shouldn't that be _OR_, as I have always understood confidentialy
> models like BLP are by their very nature incompatible with integrity
> models like Biba. Given this incompatibity, I think the idea that
> BLP style use of lables (ss/* property and the likes) is only usefull
> to intelligence agencies may well be correct, while usage for integrity
> models like Biba and CW would be much broader than that.
>
> A path based 'least priviledge' (POLP) solution would I think on its own
> address neither integity nor confidentiality, and next to this would
> proof to be yet an other 'fat profile' administration hell.
>
> Having said that, I feel a path based solution could have great potential
> if it could be used in conjunction with the object capability model, that
> I would consider a simple and practical alternative integrity model that
> does not require lables in an MLS maner, and that extends on the POLP
> concept in a way that would be largely more practical.
> That is, using 'thin' path based profiles would become very practical if
> all further authority can be communicated using handles in the same way
> that an open file handle can be communicated.
>
> Rob
>
> -
> 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/
>
-
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/