[apparmor] IPC syntax - again

[John Johansen]

On 07/03/2013 01:06 PM, Casey Schaufler wrote:
> On 7/2/2013 11:43 PM, Seth Arnold wrote:
>> I wrote a long detailed response to your questions but realized after a
>> while that I was relying on some pretty huge assumptions on how the LSM
>> networking hooks interact with the secmark hooks.
>>
>> So, rather than send a long email based on probably incorrect
>> assumptions, I figured I better address those assumptions first thing.
>>
>> What can we mediate with purely LSM hooks?
>>
>> - bind subject protocol
>> - bind subject address
>> - bind subject port
>> - bind subject interface
>> - listen
>> - listen queue length
>> - accept
>> - connect subject protocol
>> - connect subject address
>> - connect subject port
>> - connect subject interface
>> - connect peer protocol
>> - connect peer address
>> - connect peer port
>> - sendmsg subject protocol
>> - sendmsg subject address
>> - sendmsg subject port
>> - sendmsg subject interface
>> - sendmsg peer protocol
>> - sendmsg peer address
>> - sendmsg peer port
>> - recvmsg subject protocol
>> - recvmsg subject address
>> - recvmsg subject port
>> - recvmsg subject interface
>> - recvmsg peer protocol
>> - recvmsg peer address
>> - recvmsg peer port
>>
>> I've been assuming that the LSM networking hooks would allow us to get
>> either the subject xor the peer portions of these at various points, more
>> or less restricting us to "no pairing without secmark".
>>
>> Is this a fair assumption?
>>
>> Sadly, I'm serious when I say that my head goes around in circles with
>> thinking about partial policy reloads in the face of needing full policy
>> compiles to generate secmark labeling rules.
> 
> I'll repeat what I've been saying to the SELinux people for years.
> This level of granularity is incomprehensible and unmaintainable.
> Any service providing application that implements its own policy
> is going to be at odds with yours. The details of implementation
> will prevent the two from matching precisely.
> 
> I hope that the granularity gremlins don't take over AppArmor to
> the extent that they have SELinux. Just because you *can* break
> out a check doesn't mean you should.
> 
Hey Casey, that is to a large degree what the discussion is about.
We can do this, is it worth the trade off in complexity. Apparmor
certainly has its share of complexity gremlins, in some ways its
worse than SELinux.

By using paths/addresses as the primary mediation point it is already
more granular in some ways than what typing would be. It makes policy
very much behavioral based around those specifics, making apparmor
policy is brittle. So that if an applications changes, or its policy
changes then apparmor policy is likely to cause breakage.

This is both good and bad, it means the policy can reduce the attack
surface, and act like at an IDS system but at the cost of brittle
policy.

What we are aiming for is to extend apparmor to be a system that
retains compatibility with the past while at the same time allowing
for policy to be less brittle.

Just what the right mix is I don't really know but I do appreciate
the added voice of concerns over complexity