Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Serge E. Hallyn]

(Sorry!  Meant to add extra recipients!)

Quoting Serge E. Hallyn (serue@us.ibm.com):
> Quoting Stephan Peijnik (stephan@peijnik.at):
> > On Wed, 2009-01-14 at 15:16 -0800, Greg KH wrote:
> > > On Wed, Jan 14, 2009 at 11:28:51PM +0100, Stephan Peijnik wrote:
> > > > But Tuxguardian provides a different set of features and works
> > > > differently. 
> > > 
> > > Not entirely, SELinux provides a lot of what it sounds like Tuxguardian
> > > provides, but in a different way.  If you were to mix them, it could get
> > > very messy, very quickly.
> > 
> > Well, maybe I don't understand the whole concept behind LSM and/or the
> > security concept in general. But from my understanding it could, in
> > theory, be safe to have at least multiple socket MAC modules running. 
> > If one denies access the others don't need to be consulted. On the other
> > hand, if all allow a specific call to be made it could be granted.
> > 
> > > > Maybe this can't be solved by using the LSM framework, but come up with
> > > > something different and independent.
> > > 
> > > Patches are always welcome.
> > 
> > Even though I have no patches prepared I have been playing around with
> > my ideas.
> > I haven't done a lot of testing on this yet, as it is meant to be a
> > prototype only, but two implementations of a possible Socket MAC
> > subsystem can be found at http://repo.or.cz/w/linux-2.6/sactl.git.
> > 
> > The subsystem is intended to be used by modules like Tuxguardian and
> > does only provide a limited set of information (ie. no direct access to
> > the relevant socket structures, only works for AF_INET and AF_INET6
> > sockets).
> 
> So do you think we could come up with a usable framework using the
> idea which Paul Menage suggests here:
> https://lists.linux-foundation.org/pipermail/containers/2009-January/015280.html
> ?
> 
> Basically, you would use a control group (cgroup) to track tasks.
> I.e. you might launch firefox in a separate 'webclient' cgroup.
> Traffic then gets controlled (and mangled) based on the cgroup
> of the sending/receiving task.
> 
> 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'?
> 
> Just wondering - and figuring these appear to be two completely distinct
> groups of people having very similar discussion...
> 
> -serge

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Stephan Peijnik]

Comments inline.

On Wed, 2009-01-14 at 18:44 -0600, Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn (serue@us.ibm.com):
> > Quoting Stephan Peijnik (stephan@peijnik.at):
> > > On Wed, 2009-01-14 at 15:16 -0800, Greg KH wrote:
> > > > On Wed, Jan 14, 2009 at 11:28:51PM +0100, Stephan Peijnik wrote:
> > > > > But Tuxguardian provides a different set of features and works
> > > > > differently. 
> > > > 
> > > > Not entirely, SELinux provides a lot of what it sounds like Tuxguardian
> > > > provides, but in a different way.  If you were to mix them, it could get
> > > > very messy, very quickly.
> > > 
> > > Well, maybe I don't understand the whole concept behind LSM and/or the
> > > security concept in general. But from my understanding it could, in
> > > theory, be safe to have at least multiple socket MAC modules running. 
> > > If one denies access the others don't need to be consulted. On the other
> > > hand, if all allow a specific call to be made it could be granted.
> > > 
> > > > > Maybe this can't be solved by using the LSM framework, but come up with
> > > > > something different and independent.
> > > > 
> > > > Patches are always welcome.
> > > 
> > > Even though I have no patches prepared I have been playing around with
> > > my ideas.
> > > I haven't done a lot of testing on this yet, as it is meant to be a
> > > prototype only, but two implementations of a possible Socket MAC
> > > subsystem can be found at http://repo.or.cz/w/linux-2.6/sactl.git.
> > > 
> > > The subsystem is intended to be used by modules like Tuxguardian and
> > > does only provide a limited set of information (ie. no direct access to
> > > the relevant socket structures, only works for AF_INET and AF_INET6
> > > sockets).
> > 
> > So do you think we could come up with a usable framework using the
> > idea which Paul Menage suggests here:
> > https://lists.linux-foundation.org/pipermail/containers/2009-January/015280.html
> > ?
> > 
> > Basically, you would use a control group (cgroup) to track tasks.
> > I.e. you might launch firefox in a separate 'webclient' cgroup.
> > Traffic then gets controlled (and mangled) based on the cgroup
> > of the sending/receiving task.

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.

So Paul, do you think the interface would be of any use to you? 

On the other hand the cgroup-based approach could provide a similar
interface to the userspace, which would also be an option.

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

-- Stephan

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Grzegorz Nosek]

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?

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

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

Best regards,
 Grzegorz Nosek

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Paul Menage]

On Thu, Jan 15, 2009 at 7:35 AM, Grzegorz Nosek <root@localdomain.pl> wrote:
>
> 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)
>

Right.

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

Use an approach similar to the net_cls cgroup subsystem in
net/sched/cls_cgroup.c. (Or possibly just expose and reuse the same
id).

Paul

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

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Paul Menage]

On Thu, Jan 15, 2009 at 5:57 AM, Stephan Peijnik <stephan@peijnik.at> wrote:
>
> So Paul, do you think the interface would be of any use to you?

Potentially, yes. My concern was that we not add another new
(incomplete) userspace API in cgroups for doing socket permissions -
hooking into iptables was one way to do it, but if sactl is going to
become the official way to do this, then hooking a cgroups filter into
that seems like a good alternative.

Paul

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Stephan Peijnik]

On Thu, 2009-01-15 at 09:25 -0800, Paul Menage wrote:
> On Thu, Jan 15, 2009 at 5:57 AM, Stephan Peijnik <stephan@peijnik.at> wrote:
> >
> > So Paul, do you think the interface would be of any use to you?
> 
> Potentially, yes. My concern was that we not add another new
> (incomplete) userspace API in cgroups for doing socket permissions -
> hooking into iptables was one way to do it, but if sactl is going to
> become the official way to do this, then hooking a cgroups filter into
> that seems like a good alternative.

Just to clarify that: sactl is my pet project and inclusion in
linux-next (or whenever) has not been discussed yet, but if enough
potential users pop up I would love try getting it included.

I rather meant to ask if this interface could be of any use to you (and
others) and whether you would want/need any modifications to it, if
there are any flaws in its design, bugs in the code, etc.

-- Stephan

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Paul Moore]

On Thursday 15 January 2009 12:25:34 pm Paul Menage wrote:
> On Thu, Jan 15, 2009 at 5:57 AM, Stephan Peijnik <stephan@peijnik.at> 
wrote:
> > So Paul, do you think the interface would be of any use to you?
>
> Potentially, yes. My concern was that we not add another new
> (incomplete) userspace API in cgroups for doing socket permissions -
> hooking into iptables was one way to do it, but if sactl is going to
> become the official way to do this, then hooking a cgroups filter
> into that seems like a good alternative.

I'll confess to knowing very little about cgroups and even less about 
Stephan's sactl concept (only what I've read so far in this thread), 
however, like Paul Menage I tend to prefer solutions which leverage 
existing mechanisms as much as possible.

Conceptually, I've always associated iptables/netfilter as more of a 
per-packet traffic control mechanism whereas the LSM approach was 
geared more towards per-connection and per-application traffic control 
mechanism; although I will be the first to admit this is a very fuzzy 
distinction and could easily be argued the other way as well.  Other 
than the issues around blocking due to userspace notification and 
potential conflicts with other LSMs are there any objections to using 
the LSM interface?

I know I've come out against the LSM networking hooks proposed by the 
TOMOYO developers in the past to address the blocking issues, and while 
I still believe this is not the "ideal" solution I recognize that there 
are certain use cases and "personal firewall" projects that could 
benefit from such LSM hooks.  While I stand by my original objections, 
I'm most interested in making sure that if we do decide to go forward 
with introducing such functionality into the mainline kernel that we do 
so in the most appropriate manner.

-- 
paul moore
linux @ hp

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

[Stephan Peijnik]

On Fri, 2009-01-16 at 15:43 -0500, Paul Moore wrote: 
> On Thursday 15 January 2009 12:25:34 pm Paul Menage wrote:
> > On Thu, Jan 15, 2009 at 5:57 AM, Stephan Peijnik <stephan@peijnik.at> 
> wrote:
> > > So Paul, do you think the interface would be of any use to you?
> >
> > Potentially, yes. My concern was that we not add another new
> > (incomplete) userspace API in cgroups for doing socket permissions -
> > hooking into iptables was one way to do it, but if sactl is going to
> > become the official way to do this, then hooking a cgroups filter
> > into that seems like a good alternative.
> 
> I'll confess to knowing very little about cgroups and even less about 
> Stephan's sactl concept (only what I've read so far in this thread), 
> however, like Paul Menage I tend to prefer solutions which leverage 
> existing mechanisms as much as possible.
> 
> Conceptually, I've always associated iptables/netfilter as more of a 
> per-packet traffic control mechanism whereas the LSM approach was 
> geared more towards per-connection and per-application traffic control 
> mechanism; although I will be the first to admit this is a very fuzzy 
> distinction and could easily be argued the other way as well.  Other 
> than the issues around blocking due to userspace notification and 
> potential conflicts with other LSMs are there any objections to using 
> the LSM interface?

The interface itself might be exactly what's needed, but as only one LSM
may be running at one time it is probably not the right one to use for
personal firewalls.
I just don't want users to get the problem of having to decide whether
they are going to use a general purpose LSM, like AppFilter or SELinux,
or if they are going to use a tiny personal firewall. Both at once are
not going to work using LSM.

Also, don't get me wrong here. I don't want LSM stacking back either. I
do see that there were problems with it and they cannot be solved
easily. Why shouldn't there be a new interface specifically for personal
firewalls? It seems there are a few possible use cases for such an
interface (tuxguardian, the cgroup-based MAC system, etc).

> I know I've come out against the LSM networking hooks proposed by the 
> TOMOYO developers in the past to address the blocking issues, and while 
> I still believe this is not the "ideal" solution I recognize that there 
> are certain use cases and "personal firewall" projects that could 
> benefit from such LSM hooks.  While I stand by my original objections, 
> I'm most interested in making sure that if we do decide to go forward 
> with introducing such functionality into the mainline kernel that we do 
> so in the most appropriate manner.

As I said, maybe it's a good idea to not use LSM for that. I tried using LSM
for my very own personal firewall project first, but it's not going to work.
Firstly LSM seems to be overkill for something like a personal firewall and
secondly I would love to have the ability to load/unload a personal firewall
at runtime, just like I can load netfilter or better said IPTables targets
at runtime.
That's why the latest sactl code doesn't use LSM at all, but rather calls 
its own functions directly from "net/socket.c".

Now maybe the LSM list isn't the right place to discuss this issue anymore. 
What I can see clearly is that there are several projects in need of a way
of doing MAC on sockets and that there is no solution available in the kernel
right now: that's why I wrote sactl.
The question that remains unanswered is whether a.) this is actually needed
in the kernel and b.) if the thing I've hacked together is the right solution
for this problem.

-- Stephan