[apparmor] some urgent questions

[John Johansen]

On 02/13/2011 03:56 PM, Seth Arnold wrote:
> On Sun, Feb 13, 2011 at 7:13 AM, alexofen at gmail.com <alexofen at gmail.com> wrote:
>> Hi everybody and people enthusiastic about system security,
>>
>> let me right away "beg you pardon" for directly asking some question.
>> This is  because I have NOT found some conclusive answers by browsing the
>> archives.
>> ANY help and comment and hint is appreciated.
> 
> There rarely are conclusive answers. :) We all have different security goals.
> 
>> (1) concurrency vulnerability and Apparmor(AA)?
>> ->your opinion, is AA safe against vulnerability arrising from execution
>> concurrency in Multiprocessor environments?
>> www.cl.cam.ac.uk/teaching/0809/Security/concurrency.pdf - gives a good
>> introduction to this tread.
> 
> The kernel team has worked extensively to ensure that all system calls
> _copy_ data from userspace before performing any operations with the
> data, to ensure that silly syscall-interposition bugs don't arise. The
> sparse tool can read source code that has been instrumented with
> __user indicators to report when data comes from a user, and must be
> run through a function to copy the data into the kernel before it can
> be safely used. I'm not sure how often 'sparse' is run, but hopefully
> often enough to find accidental mistakes.
> 
>> (2) What is the deal with the complain(I), enforced(II) ,
>> "not-yet-enabled"(III) states a executable can be in?
>> So to say a root executed executable not having a profile is allowed
>> everything, right?
>> Im a sorry for this stupid question, but as I understand AA is not build
>> according to the
>> "everything that is not exprlecitely allowed is forbidden" but rather
>> "everything that is not exprlecitely forbidden is allowed", true?
> 
> It's a little bit of both: in the context of a confined process,
> AppArmor is a whitelist solution (with a 'deny' keyword to both silent
> known access attempts and to tighten policy by subtracting allowed
> accesses; still, only listed items are allowed). However, AppArmor is
> a lot like a blacklist from a system perspective: you as an
> administrator may distrust specific programs, daemons, or users, and
> wish to confine them specifically. This could be as small as just
> confining your nginx webserver, or it could be as comprehensive as
> confining nearly every process on the system. It's up to you to
> determine your levels of distrust. But 'init', kernel threads, and so
> forth will almost certainly never be confined by AppArmor policy.
> 
hehe, well init can be confined if that is your cup of tea, but beyond
propagating labels there really isn't any point in confining kernel
threads in linux.

> If you really want an entire-system security policy, then one of the
> other models such as TOMOYO, SELinux (without the 'unconfined' domain,
> obviously :), or SMACK may be a better fit.
most likely but I will point out this is actually quite feasible now with
AppArmor, where in the past it was problematic.