[apparmor] IPC syntax - again

[John Johansen]

On 07/02/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?

More than you would hope for but less than you'd like :)

The issue with the LSM hooks in the past for us is that sockets are not
task based. We solved this problem by making compound labels and sticking
them on the socket. Now the socket is a proxy for the set of tasks and
their labeling.

So a message sent from a socket gets the sockets labeling (well in the
sending case we can generally do better and just use the tasks). When
a message is received we can check that it can be received by each of
the profiles in that label, even though we are in interrupt context
(ie not task context).

Receiving has been the big issue, as sockets are shared and policy is
task oriented. Actually not completely true accept was even worse.
There have been multiple discussion over the years on how to extend
accept to a task based model and the are always out right rejected.
At least with receive you can do things like, well if I am allowed
access to the socket I'll accept its messages.

With accept you get into the position of having to accept connections,
find out they will be serviced by a task they shouldn't and then
shut them down. Which is allowed for by the protocol as errors can
happen, but the networking guys will scream at you and you will
NEVER get it upstream.

So where does secmark come in then? Its infrastructure, it can carry
labeling, for some thing we may want to do some processing in the
postroute etc.

Also we can leverage connsecmark to provide better support for
protocols like ftp.

> 
> - 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".
> 
No, secmark helps deal with certain thing needing to take place in
interrupt context, and is the security interface to the connection tracker
via connsecmark.

It used to be that we would require it, the design has evolved and
improved. As it stands with the compound labels and sockets proxying I don't
think we actually "need" to use secmark anymore. Of course there is still a
lot of code to write here so I may hit a situation where it will be needed

> 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.
> 
think of it like caching. Each part adds a file to the cache. And at
load those files a compacted together into a single entity.

So the the individual pieces get added/updated/removed as a profile is
added. Then the set is combined and loaded for each profile load.

Its not pretty or fast but its not hard

> 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...
> 
only a partial compile, each profile would be compiled and optimized
separately. Then you only need to do a merge operation, and even
the results of merges could be cached.

And yes still-active connections are a pain but the information is
there.

> I still don't think that these recompiles would be fast enough for
> our liking.
> 
Of course not

> Compiling policy to secmark rules just feels like it's two years away.
> 
yes

> 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.
> 
That was always the plan, we would have multiple stages of deployment
1. improvements to networking
2. interaction with secmark where the mark is manually created
3. auto creation of iptables + secmark from policy

> 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..).
> 
possibly. But I am not really interested at this point in how hard it
is or when it will come. We can roll things out in stages we just need
to design for where we want to be, and what we can accept today


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