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. 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
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
