[lkml]   [2006]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)
Pavel Machek wrote:
> On Tue 18-04-06 13:13:03, Crispin Cowan wrote:
>> This has actually been one of the interesting developments in AppArmor.
>> I also had no use for POSIX.1e capabilities; I thought they were so
>> awkward as to be useless. That is, until we integrated capabilities into
>> AppArmor profiles.
>> Consider this profile for /bin/stty
>> /bin/stty {
>> #include <abstractions/base>
>> capability sys_tty_config,
>> /bin/stty r,
>> }
>> This policy basically allows stty to run, read its own text file, and
>> use the capability sys_tty_config. Even though it may run as root, this
>> profile confines it to *only* have sys_tty_config.
> What happens if I ln /bin/stty /tmp/evilstty, then exploit
> vulnerability in stty?
Two things:

1. You don't get to create such a link unless you have an unconfined
(trusted) shell or you have a policy that says you get to create
such a link, and
2. You don't have permission to execute /tmp/evilstty at all, unless
you have an unconfined (trusted) shell.

This is a really basic misunderstanding of AppArmor. All unconfined
processes are considered trusted, so attacks that suppose an unconfined
user did something very evil/stupid are not interesting. An AppArmor
policy is supposed to prevent the attacker from ever obtaining control
of an unconfined process, so just assuming that you have one doesn't
demonstrate breaking the model.

Crispin Cowan, Ph.D.
Director of Software Engineering, Novell

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-23 05:53    [W:0.155 / U:0.640 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site