[apparmor] IPC syntax - again

Seth Arnold seth.arnold at canonical.com
Wed Jul 3 22:24:00 UTC 2013


On Wed, Jul 03, 2013 at 01:06:50PM -0700, Casey Schaufler wrote:
> > 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'll repeat what I've been saying to the SELinux people for years.
> This level of granularity is incomprehensible and unmaintainable.
> [...]
> 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.

Casey, good to hear from you :)

That email was primarily for me to understand better the features
available without breaking out secmark. John knows this far better than
I do, it'd take me hours of reading code to answer the above questions,
and I hoped he'd have them on the tip of his fingers, as he so often does.

I realized while writing a more nuanced mail that I just didn't know
what I was writing about and decided to go fishing for information
instead.

Users certainly don't need to know these details but I do. :)

> 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.

This is definitely a problem and perhaps one (small) reason why we've
not made a stronger push to get more AppArmor-aware applications. Having
applications manipulate their security domain at runtime enforces some
decisions on what the policy as a whole looks like which in turn makes
adapting policy to individual site requirements more difficult. Or, at
least, adds some additional constraints.

I've got at least three different viewpoints here:

- AppArmor upstream me says any policy we ship is just an example and
  ought to be replaced with something more appropriate.

- Distribution me says any policy we ship should provide enough
  security improvement to make shipping it worthwhile but not overly
  inconvenience the millions of users who don't care how the security
  on their system is implemented.

- End user me says the shipped policies are far too loose and need some
  tightening or more granularity.

Thanks again Casey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130703/75d7547a/attachment.pgp>


More information about the AppArmor mailing list