Message-ID: <12573.213.222.28.155.1176905146.squirrel@webmail.xs4all.nl>
Date:	Wed, 18 Apr 2007 16:05:46 +0200 (CEST)
From:	"Rob Meijer" <capibara@...all.nl>
To:	"Joshua Brindle" <jbrindle@...sys.com>
Cc:	capibara@...all.nl, "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

On Wed, April 18, 2007 14:15, Joshua Brindle wrote:

>> 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.
>>
> This would be combining two bad systems to get a worse one IMO.
> Capability systems are inherently discretionary since propagated
> capabilities must be removed at the discretion of the possessor of the
> capabilities.

That is assuming there is no caretaker or membrane implementation in the
delegation chain, but I don't think we need to get into such details of
object capabilities here. Point is there are ways to delegate revocable
capabilities when using the OC model when required.

> The argument that labels are not practical has yet to be shown but is
> thrown around as if it is fact. Path based systems are inferior to label
> based systems based if for no other reason than path based systems can't
> control transient objects. With policy based type transition in SELinux
> when my ssh client writes my agent socket to /tmp/ssh-xxxxxxxxxx SELinux
> calculates a type transition based off my domain to label it
> sysadm_ssh_t (or whatever is appropriate) whereas path based systems
> can't possibly control access to these objects. The same goes for any
> files written to home directories by user apps.

I fully agree that path based security is inferior 'when used on its own'.

>> 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.
>>
>
> Once again, this creates a discretionary system that would not work
> without modifying every single application that uses such authority

It creates a discretionary enviroment that makes it much more natural
for developers to create cooperating subsystems that are designed
from an least authority perspective. And it creates the means to
configure the system for such programs with a minimum amounth of
profile information.

Next to this, but a bit more complicated, path based security could in
theory be used to make required authority explicitly designated. That is
calling :

  cp ~/foo.txt ~/bar_directory/

could ultimately explicitly transfer the user his authorities to both
~/foo.txt and ~/bar_directory/ to this instance of 'cp', but without
transfering any other ambient authority. This example may be a bit
out of the current range for AppArmor, but I feel it demonstrates that
path based security may have potential added value in a least authority
context.

That is if Allice has authority to ~/, and ~/ contains ~/important.doc
and allice has rw access to ~/important.doc, than ultimately invoking 'cp
~/foo.txt ~/bar_directory/' should not give the 'cp' instance the
authority to read/write ~/important.doc, but invoking 'cp ~/foo.doc
~/important.doc'
should. That is, if we want cp to work unmodified.

> (and
> trusting the code is bug free so that it does the right thing)

I think the abouve shows that it actualy requeres 'less' trust in
code if implemented right.

> and gives
> you an inflexible, decentralized, unmaintainable, unanalyzable policy
> since it is distributed throughout code all over the system, you give
> users no way to change the security characteristics of the system.

I agree with the decentralized part, but in my view accomodating and
allowing free and optionaly revocable delegation (you can always proxy
anyway, so we know blocking it is misguided) makes for a much more
flexible and esspecialy usable form of security.
Systems designed according to POLA are definetely the most easy to
do formal analysis of security properties on.

I am not saying that path-based + OC would be 'better' than label based,
I feel both would have their own level of granularity where they are
usefull, and in some cases they could be complementary.

I feel path based would be useless when possitioned purely as MAC, but
when possitioned more as least authority bootstrap and designation
mechanism complementary to least authority design ant usage of the OC model,
I think path based may have some concrete use.

sidenote: it is amusing to see that many OC advocates use many of your
arguments (inflexible, unmaintainable, hard to analyze) to dismiss many
label based MLS models as viable security models;-)

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/

Powered by blists - more mailing lists