[apparmor] IPC syntax - again

[Casey Schaufler]

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.


>
> The best I can think of is a full networking policy recompile every
> time any profile's networking is modified. We could recompile all the
> networking rules and skip all the other rule types and provide some
> mechanism to replace the networking rules in the kernel load, and the
> necessary hand-waving around the binary cache to keep it updated. And
> the hand-waving about also loading policy rules for the old secmark
> labels for still-active connections that are still allowed...
>
> I still don't think that these recompiles would be fast enough for
> our liking.
>
> Compiling policy to secmark rules just feels like it's two years away.
>
> But, if my assumption about being able to provide an improvement on our
> existing mediation is possible -- resorting to secmark only for pairing
> -- I'd be content to ask the administrator to write the secmark rules
> for the more complicated cases.
>
> The list I made is where I thought pairing would be useful. I expect
> most deployments won't need pairing. It seems fair to ask complicated
> deployments to use iptables or ufw (or ferm or shorewall or whatever..).
>
> But, of course, my entire suggestion to use secmark only for the
> 'pairing'-level of complication depends upon LSM-provided hooks being
> sufficient for all but a few cases...
>
> Thanks
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130703/1f0dffb1/attachment.html>