[apparmor] Questions about apparmor

[Seth Arnold]

>>    3. Does it make sense to implement "per code segment profile"? i.e.
>> attach each executable VMA with a profile. Then it can make profiles for
>> libraries -- any program calls into a library, will apply the library's
>> profile (just like a implicit change_hat, should take care of static link
>> case, need a modified ld?). This can also be done by including profiles
>> provided by libraries, and call change_hat appropriately, but not
>> convenient.

> I can see the appeal to this, but it isn't possible at this time.  Nor do I
> see this being possible in the future do to technical limitations of the LSM.

When we last discussed automatically changing hats in a program based on
execution, we found it very difficult:

Nearly all programs, malicious and benign, will write into files via
write(2), pwrite(2), writev(2), or aio_write(3). It isn't really the
instruction pointer at the point of the system call (or LSM hook
points), it is the call chain stack that really matters.

But, a compromised program could easily have a completely fake stack
shoved into memory (or constructed in memory) entirely between LSM hook
points. The fake stack may either just be used to signal 'correct call
stack' to the LSM, or there may be faults injected into the call stack
to attempt to exploit stack walking code. (Either outright bugs, or
patterns to cause extremely slow walking.)

And, most compelling, a virtual machine (bash, ruby, python, perl, java,
erlang, awk, etc.) would show identical call stacks for both legitimate
and illegitimate write() calls for any bugs exploited above the virtual
machine layer.

Each VM would need to be modified to perform hat changes on its own.
(This is useful, the mod_apparmor Apache module and Tomcat change_hat
modifications provide some level of separation between untrusted
applications.)

I've come to the conclusion that manually spliting protection domains
based on expert knowledge of the application is a much better
approach than automated protection domain splitting. AppArmor
profiles for postfix or qmail is excellent because an expert has broken
apart the MTA and MDA problems into (many) smaller pieces, and AppArmor
can confine those pieces easily. It is much harder to separate sendmail
into MTA and MDA portions, and AppArmor can really just confine the
whole pile of 'sendmail things' into one profile as a result. If an
expert modifes sendmail into small constituent pieces, then profiling
the smaller pieces would be pretty straightforward. But using hueristics
to guess the divisions from inside the kernel won't ever give as good
results as expert knowledge.

Thanks