Messages in this thread | | | Date | Thu, 27 Apr 2006 10:58:15 -0700 | From | "Ken Brush" <> | Subject | Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
On 4/27/06, Stephen Smalley <sds@tycho.nsa.gov> wrote: > On Wed, 2006-04-26 at 16:06 -0700, Ken Brush wrote: > > On 4/26/06, Neil Brown <neilb@suse.de> wrote: > > > > > > I feel we have reached the stage where the questions/comments being > > > made are actually directly relevant to AppArmor. I'm afraid I cannot > > > proceed any further now because I am not a security expert. > > > > > > I would like to summarise what I think are the key points that you > > > have raised, and hope that someone who has a deeper understanding of > > > these things might answer them, or point to answers. > > > > > > 1/ Does AppArmor's primary mechanism of confining an application to a > > > superset of it's expected behaviour actually achieve its secondary > > > gaol of protecting data? > > > > > > Possibly it would be better to ask "When does ..." as I think it is > > > easy to imagine application/profile pairs that clearly cannot allow > > > harm, and application/profile pairs that clearly could allow harm. > > > > Depends on the data. A properly constrained Apache webserver would be > > prevented from accessing data it shouldn't. > > No, it wouldn't. The question itself is flawed - it presumes that AA > does confine the application to its expected behavior.
I can confine a process to my idea of it's expected behavior.
> But with > incomplete mediation and ambiguous identifiers, there is no such > guarantee. No profile will meet the "clearly cannot allow harm" > definition, because not all operations are controlled by it and of the > operations that are controlled, the actual objects are not clearly > identified, so harm is still possible. >
I can guarantee that if my profile does not allow write access to /etc that apache's write to "/etc/new_file" will not be allowed.
The argument that somehow someone would setup a soft link or something so that apache could write to /etc via indirection is not my primary concern. That is systematic of a more concerted attack and a very determined attacker. Or at the very least, a mistake on my part. And in that case, I cannot protect myself from myself.
> > > 2/ What advantages does AppArmor provide over techniques involving > > > virtualisation or gaol mechanisms? Are these advantages worth > > > while? > > > > If you just wish to run every application in a chrooted jail. Would > > you still need a MAC solution? > > If your goal is purely isolation, then virtualization may fit your > needs. If you want to support controlled sharing of data while still > ensuring that certain confidentiality and integrity goals are met, then > you want a MAC mechanism. But AA really isn't a MAC mechanism, despite > what its documentation may say.
I have no requirements like that. I just would prefer that when people try to exploit my internet services, that the programs are not allowed to do things that I would rather it not do. AA seems to fulfill that requirement.
-Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |