[Devel] Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Stephan Peijnik]

On Thu, 2009-01-15 at 16:35 +0100, Grzegorz Nosek wrote:
> On Thu, Jan 15, 2009 at 02:57:12PM +0100, Stephan Peijnik wrote:
> > Okay, that idea does sound nice. However, to me it rather looks like
> > another use-case for the framework/interface I am proposing (ie. sactl).
> > 
> > Using sactl the cgroup-based approach could easily hook the relevant
> > socket calls. sactl might need some refining for this, but then again
> > it's just a proposal and not anywhere being a final interface.
> 
> How is sactl different from the iptables hooks Paul proposed? The "fake
> packet" abstraction is maybe not very natural (at least that was my
> first impression) but quite flexible, as it allows some degree of
> socket manipulation. My use case that sparked the discussion was
> transparently remapping bind() and connect() operations to use a
> per-cgroup source IP address. How do I do that with sactl?

Well, sactl is not limited to cgroups, that's about it. A LKM using
sactl could do pretty much anything, including cgroup matching, plain
uid/gid matching or something similar to what root_plug does, but for
network connections.

The hooks currently provided by sactl are of course in an RFC state.
It's pretty much like "tell me what's wrong and I'll fix it". 

However, if I am getting this right you would want to call
sk->ops->bind() manually, return the result to sys_connect/sys_bind and
prevent those from doing their bind() call, right?

I am unsure about whether this is just plain wrong, but what about
simply modifying the sockaddr structure you get passed (from sactl)? 
As the sactl hooks are invoked before the actual sk->ops->bind() takes
place (at least for for sys_bind) you could go ahead and modify the
structure as passed to sys_bind initially.

Now about connect(). Okay, this is a bit harder, as you don't have a
socket structure to work with. I did design the initial interface this
way intentionally so that mangling cannot be done (or at least not
easily). 
If nobody objects I could modify the interface to allow that which, in
short, means you could use sk->ops->bind() in your connect handler.

There is just one problem I see: error handling. I would have to modify
sactl so it lets you return any arbitary return code, instead of always
returning -EPERM on an error. Especially in the case of you calling
bind() inside the handler. I am also unsure about whether that's a good
idea. On the other hand I sactl maybe shouldn't care about the error
being returned and stop invoking other handlers as soon as a callback
returns non-zero.

> > On the other hand the cgroup-based approach could provide a similar
> > interface to the userspace, which would also be an option.
> 
> I guess the net result would comprise two parts:
>  - iptable_control, possibly based on Paul's code (hook
>    socket/connect/bind/accept calls into iptables)
>  - ipt_cgroup, matching the cgroup the requesting process is a member
>    of (I'd also need a target to remap the source address but it would
>    probably a minor thing to do)
> 
> One thing I'm not quite sure about is matching the cgroups. Should I
> attempt to match the cgroup path? Or some per-cgroup cookie stored in a
> virtual file? Both don't seem too pretty, need help :/

Well, what I would need is notification of a userspace program if there
is no rule (or even every time socket/accept/connect/bind/listen are
called). That's why I am working on the generic interface in the first
place, so I can use it and maybe create something that's of use to
others too.

> > > > Presumably one possible iptables target would be something which
> > > > launches a popup window to ask the user 'should task firefox in
> > > > cgroup webclient be allowed to access google.com'?
> > 
> > If such a target is implemented it could also be done this way. To be
> > honest I am not really sure about which road to take myself.
> 
> Wouldn't NFQUEUE and some userspace tool suffice without creating new
> interfaces (never used it, just guessing)? BTW, how are you going to
> know that I wanted to connect to foo.example.com, not bar.example.com
> (which share the IP address)?

NFQUEUE is probably way too low in the network layer. I would love to
handle socket calls when they happen and be able to block the calling
process meanwhile.

The example with google.com didn't come from me. That's not possible
without intercepting the connection, and I am well aware of that.

-- Stephan

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers