Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Crispin Cowan <crispin@novell.com>]

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
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

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