RFC: Mandatory Access Control for sockets aka "personal firewalls"

RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Stephan Peijnik]

Hello all of you,

I am sending this email as a discussion about this topic has been going
on at linux-security-module@vger.kernel.org for some time now and I
believe that all parties affected or somehow related to this should be
involved in the discussion. We would like to hear your opinion on this
matter and would be glad if we could work together on finding a possible
solution. I have CC'ed linux-security-module, netfilter-devel and
netdev, but if you believe that I missed someone, feel free to forward
this email to the respective list.

Firstly, I would like to elaborate on what we more or less agreed on a
personal firewall should be able to do and what such a piece of software
is intended for.

A personal firewall should implement per-application mandatory access
control for sockets. In short this means that such a program decides
every time a call to either socket(), accept(), bind(), connect() or
listen() is made whether the invoking program is allowed to do so or
not. No per-packet filtering can be done and neither is connection
intercepting of any interest.

As personal firewalls are targeted at single-user, desktop systems the
decision on whether a call is allowed or not is usually made by the user
of that system (for example using a popup asking the user what to do).
This means personal firewalls should not enforce system security policy,
but rather a per-user security policy.
The implementations can then add caching of decisions made (ie.
"remember this decision") and thus not ask every time a call is made.
Also, the only protocols to be supported are IPv4 and IPv6. Adding
support for AF_UNIX and/or AF_NETLINK doesn't make much sense, as this
is not network-related and would only increase the amount of work a
personal firewall implementation has to do.

All proposed implementations of personal firewalls until now have made
it rather clear that the decision-making logic should be placed in
userspace, whilst only a small piece of code communicating with a
userspace daemon should be placed in the kernel itself.


Okay, enough of the (not so) brief description on what people want to do
and on to a summary of what has been discussed so far.

Most implementations started out using the LSM framework for creating a
personal firewall, that's also the reason the whole discussion started
out on the LSM mailing list.
Even though this looks like a good solution there is one main problem
with the LSM framework right now: only a single LSM module can be loaded
and enabled at a time. However, this was done intentionally as stacking
multiple LSMs proved to be complex and not entirely sane.
This means that if one decides to enable a personal firewall LSM at boot
time one will not be able to use a generic-purpose LSM, like SELinux or
AppArmor simultaneously. Additionally LSMs can only be enabled at boot
time and cannot be LKMs, they have to be linked statically into the
kernel. 

Another approach that has been suggested is using the netfilter
framework for this purpose. Even though this again sounds like a good
idea in the first place it also has its flaws.
netfilter was designed to work on the network level and, at least from
my understanding, is not process-context aware. Doing lookups to get the
process context on each and every connection/packet passing netfilter
could be done, but might have a negative effect on the overall system
performance.

And yet another approach was suggested: hooking socket-related calls
directly in net/socket.c. This would mean that the personal firewall
code is called directly from net/socket.c and can this way work in
process-context, without using the LSM framework.
On the other hand this would add, besides the LSM calls that are in
place in net/socket.c a few extra calls which might not be what we want.
One should also keep in mind that calls can (and may, this is
intentional) be blocked by the personal firewall system. This could be
seen as an advantage or disadvantage, but would allow waiting for user
input until proceeding with the execution of the caller.

What has not been agreed on yet is whether only a way of hooking these
calls should be made available to implementations or whether the whole
in-kernel part should be developed together and allow implementations of
personal firewalls in userspace only, for example using a netlink socket
to communicate with the shared in-kernel code.

Implementations using the LSM approach are TuxGuardian [0] and snet [1].
Code implementing the last mentioned approach can be found in git over
at [2] in the sactl-direct branch.
Please don't forget that these implementations are probably in either a
defunct state or are up to discussion themselves.

As a final note I would like to add that I believe that all lists this
mail has been sent to are somehow affected by the topic we are
discussing and I (or better said we) would love to hear your opinions.
Also, I hope I didn't miss anything that was discussed, but if I did
feel free to correct me.

-- Stephan

[0] http://tuxguardian.sourceforge.net/
[1] http://www.synack.fr/project/snet/snet.html
[2] http://repo.or.cz/w/linux-2.6/sactl.git

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jan Engelhardt]

On Tuesday 2009-01-20 18:48, Stephan Peijnik wrote:
>
>A personal firewall should implement per-application mandatory access
>control for sockets. In short this means that such a program decides
>every time a call to either socket(), accept(), bind(), connect() or
>listen()[...]

Without reading any further (yet), that sounds like
http://www.synack.fr/project/cn_net/cn_net.html

>All proposed implementations of personal firewalls until now have made
>it rather clear that the decision-making logic should be placed in
>userspace, whilst only a small piece of code communicating with a
>userspace daemon should be placed in the kernel itself.

Well of course. You want a personal firewall that asks the user,
it is going to involve userspace. Also because that is simpler
to implement and debug.

>Most implementations started out using the LSM framework for creating a
>personal firewall, that's also the reason the whole discussion started
>out on the LSM mailing list.
>Even though this looks like a good solution there is one main problem
>with the LSM framework right now: only a single LSM module can be loaded
>and enabled at a time.

Thank the guys who removed the modular LSM interface.

>However, this was done intentionally as stacking
>multiple LSMs proved to be complex and not entirely sane.

Yes, but each LSM could decide whether it supports stacking of
another module after it (either by invoking that module or not
doing so at all).

>And yet another approach was suggested: hooking socket-related calls
>directly in net/socket.c. This would mean that the personal firewall
>code is called directly from net/socket.c and can this way work in
>process-context, without using the LSM framework.
>On the other hand this would add, besides the LSM calls that are in
>place in net/socket.c a few extra calls which might not be what we want.[...]

My opinion up to here would be to split LSM into the LSM category
{selinux, apparmor, tomoyo} and the other, new LSM category
{networking stuff}, just as a potential idea to get over the
stacking / single LSM use  issue.

>What has not been agreed on yet is whether only a way of hooking these
>calls should be made available to implementations or whether the whole
>in-kernel part should be developed together and allow implementations of
>personal firewalls in userspace only, for example using a netlink socket
>to communicate with the shared in-kernel code.

That is what cn_net should be doing, I hear. So ... hmhm *dribble*.

>Implementations using the LSM approach are TuxGuardian [0] and snet [1].
>Code implementing the last mentioned approach can be found in git over
>at [2] in the sactl-direct branch.
>
>[0] http://tuxguardian.sourceforge.net/

tuxguardian is probably regardable as obsoleted by cn_net (if it's
finished someday, or is it?) -- Samir probably knows more.

>[1] http://www.synack.fr/project/snet/snet.html
>[2] http://repo.or.cz/w/linux-2.6/sactl.git

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Stephan Peijnik]

On Tue, 2009-01-20 at 19:24 +0100, Jan Engelhardt wrote:
> On Tuesday 2009-01-20 18:48, Stephan Peijnik wrote:
> >
> >A personal firewall should implement per-application mandatory access
> >control for sockets. In short this means that such a program decides
> >every time a call to either socket(), accept(), bind(), connect() or
> >listen()[...]
> 
> Without reading any further (yet), that sounds like
> http://www.synack.fr/project/cn_net/cn_net.html

Yes, it does, and it's exactly that. However, as a LSM it can only be
used whilst no other LSM is enabled. 
Samir Bellabes has been involved in the discussion at
linux-security-module too.
Even though I like the implementation personally I'm unsure about
whether this should be dubbed "the one" way to do this or whether there
should be an API for alternative implementations.

> >And yet another approach was suggested: hooking socket-related calls
> >directly in net/socket.c. This would mean that the personal firewall
> >code is called directly from net/socket.c and can this way work in
> >process-context, without using the LSM framework.
> >On the other hand this would add, besides the LSM calls that are in
> >place in net/socket.c a few extra calls which might not be what we want.[...]
> 
> My opinion up to here would be to split LSM into the LSM category
> {selinux, apparmor, tomoyo} and the other, new LSM category
> {networking stuff}, just as a potential idea to get over the
> stacking / single LSM use  issue.

The problem here is that all of your three examples do use the LSM
networking hooks too. If two functions are to be called from the LSM
core (ie. the generic LSM one and the networking-LSM one) we get pretty
much the same problem back as if we multiple generic LSMs enabled.

> >Implementations using the LSM approach are TuxGuardian [0] and snet [1].
> >Code implementing the last mentioned approach can be found in git over
> >at [2] in the sactl-direct branch.
> >
> >[0] http://tuxguardian.sourceforge.net/
> 
> tuxguardian is probably regardable as obsoleted by cn_net (if it's
> finished someday, or is it?) -- Samir probably knows more.

The tuxguardian developers seem to be interested in picking up
development again and as I wrote Samir has already been involved in this
discussion.

-- Stephan

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jonathan Day]

--- On Tue, 1/20/09, Stephan Peijnik <stephan@peijnik.at> wrote:
(snip)
> Firstly, I would like to elaborate on what we more or less
> agreed on a
> personal firewall should be able to do and what such a
> piece of software
> is intended for.
> 
> A personal firewall should implement per-application
> mandatory access
> control for sockets. In short this means that such a
> program decides
> every time a call to either socket(), accept(), bind(),
> connect() or
> listen() is made whether the invoking program is allowed to
> do so or
> not. No per-packet filtering can be done and neither is
> connection
> intercepting of any interest.

It depends on what what it is that the MAC is trying to accomplish.

Possibility 1: It's an enhanced tcpwrapper/firewall concept, which either blocks or allows any and all connections from named remote sources on identified ports. From your description of it being a "personal firewall", I am guessing this is what is being accomplished.

Possibility 2: It's being used the same way as all other mandatory access controls, so only connections from a source socket from a user/app combination that has been explicitly granted permission is permitted. This is how I would personally understand mandatory access controls over a network, as this provides a uniform view of what a MAC is.

Possibility 3: Some permutation of the above two, so that you can restrict connections both as a firewall and as a permissions concept.

There are probably other ways of constructing a MAC for sockets, but these are the two that spring to mind first. Admittedly because they also happen to be the types of greatest interest to me, but I'm not immune to bouts of fixation.

The two would logically be implemented in different ways at different levels in the stack, as they do completely different tasks. Both need to know about processes, but one only cares about local processes and the other cares about both local and remote.

> As personal firewalls are targeted at single-user, desktop
> systems the
> decision on whether a call is allowed or not is usually
> made by the user
> of that system (for example using a popup asking the user
> what to do).

I'm not sure that that's such a good target. There are plenty of server processes (BGP springs to mind) where you want per-process restrictions but can't necessarily trust the application's built-in restrictions on who/what can connect. This would be primarily an example of the first of the two forms of socket MAC, as you'd be more concerned with the connecting machine than the connecting user ID or process ID.

In cloud computing, it is especially important to prevent two systems running on the same cloud from interacting without prior permission. It would not be good if company A's software could interact with company B's database simply because B was foolish enough to use a cloud in the first place. Because here you are concerned very much with restrictions at the user/process level at both sides of the connection, this would need to be the second sort of socket MAC.

In both cases, you're definitely outside the desktop, so it seems clear that it's not a desktop-specific thing but an idea that would be extremely useful across the board, almost no matter how you envisage it.

> This means personal firewalls should not enforce system
> security policy,
> but rather a per-user security policy.
> The implementations can then add caching of decisions made
> (ie.
> "remember this decision") and thus not ask every
> time a call is made.
> Also, the only protocols to be supported are IPv4 and IPv6.
> Adding
> support for AF_UNIX and/or AF_NETLINK doesn't make much
> sense, as this
> is not network-related and would only increase the amount
> of work a
> personal firewall implementation has to do.

I agree that Unix and Netlink would not be useful, but there are other socket types that are LAN- or WAN-based, and I'd not be too quick to implement anything that precluded them being covered. (There's a difference between designing code in a way that makes extending it hard and actually implementing other network types, so only implementing IPv4 and IPv6 on a framework that could be extended by anyone deeply passionate about other protocls makes sense -- unless implementing it that way would be so much harder that it's pointless.)

> All proposed implementations of personal firewalls until
> now have made
> it rather clear that the decision-making logic should be
> placed in
> userspace, whilst only a small piece of code communicating
> with a
> userspace daemon should be placed in the kernel itself.

Well, it has probably not been a significant factor in anyone's decision, but it occurs to me that per-process firewalling within the kernel makes the "per-process" bit much more complicated and would not work at all using any of the zerocopy or kernel bypass networking mechanisms.

Ok, there are probably three people on the planet using either networking method, so if it didn't occur to anyone, there would be exceptionally good reason. On the other hand, if all proposed solutions would be just as useful to said magi as to Normal People, then that would seem to be a Good Idea.

(snipped remainer)



      

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Samir Bellabes]

Stephan Peijnik <stephan@peijnik.at> writes:

> On Tue, 2009-01-20 at 19:24 +0100, Jan Engelhardt wrote:
>> On Tuesday 2009-01-20 18:48, Stephan Peijnik wrote:
>> >
>> >A personal firewall should implement per-application mandatory access
>> >control for sockets. In short this means that such a program decides
>> >every time a call to either socket(), accept(), bind(), connect() or
>> >listen()[...]
>> 
>> Without reading any further (yet), that sounds like
>> http://www.synack.fr/project/cn_net/cn_net.html

I have updated cn_net, for supporting libnl and having a library in
userspace.
http://www.synack.fr/project/snet/snet.html
but you are perfectly right, this is exactly what I implemented.

> Yes, it does, and it's exactly that. However, as a LSM it can only be
> used whilst no other LSM is enabled. 
> Samir Bellabes has been involved in the discussion at
> linux-security-module too.
> Even though I like the implementation personally I'm unsure about
> whether this should be dubbed "the one" way to do this or whether there
> should be an API for alternative implementations.

be carefull, you are mixing 2 distincts questions in fact :

1. how to have differents security models in the kernel, dealing with
   the LSM hooks ?

2. how to build a 'personnal firewall', based on syscall applications ?

I have a answer for the second question, it's snet, as it's the simplest
way for the kernel to deal with this problem.

For the first question, you can build a personnal firewall with LSM
hooks, if, at compilation time, you don't choose other LSM
solutions. that's how I'm using snet.
But what you are asking is to have multiple security models at the same
time, with some kind of priority.
I don't know if it's ok or not, but what I'm sure is that snet will use
LSM hooks or your new framework without any problems in fact, as you are
going to make some kind of wrapper on the members of the struct
security_operations.

>> >And yet another approach was suggested: hooking socket-related calls
>> >directly in net/socket.c. This would mean that the personal firewall
>> >code is called directly from net/socket.c and can this way work in
>> >process-context, without using the LSM framework.
>> >On the other hand this would add, besides the LSM calls that are in
>> >place in net/socket.c a few extra calls which might not be what we want.[...]
>> 
>> My opinion up to here would be to split LSM into the LSM category
>> {selinux, apparmor, tomoyo} and the other, new LSM category
>> {networking stuff}, just as a potential idea to get over the
>> stacking / single LSM use  issue.

Indeed I thought about that when writing snet.

> The problem here is that all of your three examples do use the LSM
> networking hooks too. If two functions are to be called from the LSM
> core (ie. the generic LSM one and the networking-LSM one) we get pretty
> much the same problem back as if we multiple generic LSMs enabled.

I agree that can be issue, but this as nothing to do with implementing a
personnal firewall. you see, there are 2 questions beside your
thought.

You can ask yourself about having the same kind of subsystem for
syscalls related to filesystem (open, read, write, ..).
So you can build your own security model by picking-up a subsystem A
for networking part, and a subsystem X for the filesystem part.
in this way, you can let people writing differents models for networking,
or filesystem, and so on.

I won't fight for this idea, because I'm not sure it's right or not. I
just thought about when developping snet, because I wanted to plug the
same kind of code as snet, dealing with others security hooks (as
filesystem, ..), to complete the job of snet.
But I personnaly have no shame to said that, in the 'security' point of
view, I don't known if this model means something.

>> >Implementations using the LSM approach are TuxGuardian [0] and snet [1].
>> >Code implementing the last mentioned approach can be found in git over
>> >at [2] in the sactl-direct branch.
>> >
>> >[0] http://tuxguardian.sourceforge.net/
>> 
>> tuxguardian is probably regardable as obsoleted by cn_net (if it's
>> finished someday, or is it?) -- Samir probably knows more.

concerns about tuxguardian:
 - it is using sock_sendmsg/sock_recvmsg for userspace communication.
 - there is no timeout when waiting for userspace decision on the
   syscall
 - it is dealing only with members .socket_create and .socket_listen
   from the struct security_operations

> The tuxguardian developers seem to be interested in picking up
> development again and as I wrote Samir has already been involved in this
> discussion.
>
> -- Stephan

sam

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jan Engelhardt]

On Tuesday 2009-01-20 21:15, Samir Bellabes wrote this in IRC:
>
>be carefull, you are mixing 2 distincts questions in fact :
>
>1. how to have differents security models in the kernel, dealing with
>   the LSM hooks ?

A possible idea would be to not do the traditional LSM chaining,
but a parallel approach.

The problem with LSM chaining is that it somewhat imposed an order
on LSMs. The checks in SELinux for example could have decided
"it's forbidden" and not call out to the secondary module that was
registered with it. Similarly if my own module was primary and
selinux was the secondary -- this would potentially lead to me
having forgotten something in the primary and not calling the
secondary so selinux would have an inconsistent state of itself.
Therefore, how about doing a parallel LSM approach:

int security_create_inode(...)
{
	int ret == 0, x;
	list_for_each_entry(lsm, ...) {
		x = lsm->create_inode(...);
		if (x < 0 && ret == 0)
			ret = x;
	}
	return x;
}

That way, SElinux (which must serve as a beating sample now)
can update the security context associated with the inode as
required, but our own modules still has something to say in
whether the action is penultimately allowed.

There is still an order and would leave question open like
"if selinux does not like you at all, why bother showing
a window to the user asking for 'prog xyz tries to bind()'".

But I think it's the direction.

>But what you are asking is to have multiple security models at the same
>time, with some kind of priority.
>I don't know if it's ok or not, but what I'm sure is that snet will use
>LSM hooks or your new framework without any problems in fact, as you are
>going to make some kind of wrapper on the members of the struct
>security_operations.

jan>>> My opinion up to here would be to split LSM into the LSM category
>>> {selinux, apparmor, tomoyo} and the other, new LSM category
>>> {networking stuff}, just as a potential idea to get over the
>>> stacking / single LSM use  issue.
>
>Indeed I thought about that when writing snet.

For starters, the existing LSM interface and the LSM  modules themselves
could be split up so as to provide

 selinux.ko
  \_ selinux_net.ko
  \_ selinux_fs.ko
  ...

just a suggestion to ease the thinking process for now.
If a purely network-related LSM does not have to think about
"do I need to implement FS hooks that do chaining or not..."
it is a lot better off.

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Paul Moore]

On Tuesday 20 January 2009 12:48:39 pm Stephan Peijnik wrote:
> All proposed implementations of personal firewalls until now have
> made it rather clear that the decision-making logic should be placed
> in userspace, whilst only a small piece of code communicating with a
> userspace daemon should be placed in the kernel itself.
>
> Okay, enough of the (not so) brief description on what people want to
> do and on to a summary of what has been discussed so far.
>
> Most implementations started out using the LSM framework for creating
> a personal firewall, that's also the reason the whole discussion
> started out on the LSM mailing list.
> Even though this looks like a good solution there is one main problem
> with the LSM framework right now: only a single LSM module can be
> loaded and enabled at a time.

...

> Another approach that has been suggested is using the netfilter
> framework for this purpose. Even though this again sounds like a good
> idea in the first place it also has its flaws.

...

> And yet another approach was suggested: hooking socket-related calls
> directly in net/socket.c. This would mean that the personal firewall
> code is called directly from net/socket.c and can this way work in
> process-context, without using the LSM framework.

Another option that was brought up (although perhaps not very clearly 
since it isn't listed here) was the embedding of the personal firewall 
hooks into the individual LSMs roughly similar to how capabilities are 
handled with SELinux today (a separate security mechanism that has 
explicit calls within SELinux).  This approach enables the use of 
current LSMs (although minor modifications will be needed) and avoids 
the need to add new hooks to the core network stack.

> What has not been agreed on yet is whether only a way of hooking
> these calls should be made available to implementations or whether
> the whole in-kernel part should be developed together and allow
> implementations of personal firewalls in userspace only, for example
> using a netlink socket to communicate with the shared in-kernel code.

Since there will always be a significant userspace component to any 
personal firewall approach it seems reasonable to push the decision 
making into userspace and leave the kernel component relatively simple.  
The basic idea behind Samir's "snet" concept where the kernel simply 
passes messages to userspace and waits for a verdict seems like a 
reasonable approach in that it can be made to support different 
personal firewall implementations/designs without significant changes 
to the kernel.

-- 
paul moore
linux @ hp

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Paul Moore]

On Tuesday 20 January 2009 3:31:24 pm Jan Engelhardt wrote:
> On Tuesday 2009-01-20 21:15, Samir Bellabes wrote this in IRC:
> >be carefull, you are mixing 2 distincts questions in fact :
> >
> >1. how to have differents security models in the kernel, dealing
> > with the LSM hooks ?
>
> A possible idea would be to not do the traditional LSM chaining,
> but a parallel approach.
>
> The problem with LSM chaining is that it somewhat imposed an order
> on LSMs. The checks in SELinux for example could have decided
> "it's forbidden" and not call out to the secondary module that was
> registered with it. Similarly if my own module was primary and
> selinux was the secondary -- this would potentially lead to me
> having forgotten something in the primary and not calling the
> secondary so selinux would have an inconsistent state of itself.
> Therefore, how about doing a parallel LSM approach:
>
> int security_create_inode(...)
> {
> 	int ret == 0, x;
> 	list_for_each_entry(lsm, ...) {
> 		x = lsm->create_inode(...);
> 		if (x < 0 && ret == 0)
> 			ret = x;
> 	}
> 	return x;
> }
>
> That way, SElinux (which must serve as a beating sample now)
> can update the security context associated with the inode as
> required, but our own modules still has something to say in
> whether the action is penultimately allowed.
>
> There is still an order and would leave question open like
> "if selinux does not like you at all, why bother showing
> a window to the user asking for 'prog xyz tries to bind()'".
>
> But I think it's the direction.

As you noted, the particular problem of resolving the different LSMs 
still exists, including the issue of multiplexing per-object state 
which is likely to be one of the larger roadblocks to such an approach.  
However, in dealing with the issue of personal firewalls I think the 
biggest issue will be the user interaction as you described ... how do 
you explain to a user who clicked the "allow" button that the system 
rejected their traffic?

> >But what you are asking is to have multiple security models at the
> > same time, with some kind of priority.
> >I don't know if it's ok or not, but what I'm sure is that snet will
> > use LSM hooks or your new framework without any problems in fact,
> > as you are going to make some kind of wrapper on the members of the
> > struct security_operations.
>
> jan>>> My opinion up to here would be to split LSM into the LSM
> category
>
> >>> {selinux, apparmor, tomoyo} and the other, new LSM category
> >>> {networking stuff}, just as a potential idea to get over the
> >>> stacking / single LSM use  issue.
> >
> >Indeed I thought about that when writing snet.
>
> For starters, the existing LSM interface and the LSM  modules
> themselves could be split up so as to provide
>
>  selinux.ko
>   \_ selinux_net.ko
>   \_ selinux_fs.ko
>   ...
>
> just a suggestion to ease the thinking process for now.
> If a purely network-related LSM does not have to think about
> "do I need to implement FS hooks that do chaining or not..."
> it is a lot better off.

Unfortunately I don't think this solves the problem, it just changes it 
slightly.  It is no longer "How do I enable SELinux and XXX personal 
firewall?" but instead "How do I enable SELinux's network access 
controls and XXX personal firewall?"

-- 
paul moore
linux @ hp

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Paul Moore]

On Tuesday 20 January 2009 2:46:43 pm Jonathan Day wrote:
> --- On Tue, 1/20/09, Stephan Peijnik <stephan@peijnik.at> wrote:
> (snip)
>
> > Firstly, I would like to elaborate on what we more or less
> > agreed on a
> > personal firewall should be able to do and what such a
> > piece of software
> > is intended for.
> >
> > A personal firewall should implement per-application
> > mandatory access
> > control for sockets. In short this means that such a
> > program decides
> > every time a call to either socket(), accept(), bind(),
> > connect() or
> > listen() is made whether the invoking program is allowed to
> > do so or
> > not. No per-packet filtering can be done and neither is
> > connection
> > intercepting of any interest.
>
> It depends on what what it is that the MAC is trying to accomplish.
>
> Possibility 1: It's an enhanced tcpwrapper/firewall concept, which
> either blocks or allows any and all connections from named remote
> sources on identified ports. From your description of it being a
> "personal firewall", I am guessing this is what is being
> accomplished.
>
> Possibility 2: It's being used the same way as all other mandatory
> access controls, so only connections from a source socket from a
> user/app combination that has been explicitly granted permission is
> permitted. This is how I would personally understand mandatory access
> controls over a network, as this provides a uniform view of what a
> MAC is.
>
> Possibility 3: Some permutation of the above two, so that you can
> restrict connections both as a firewall and as a permissions concept.

Based on my understanding from previous discussions ... while the author 
chose to use the term MAC, what is being proposed is less of a 
mandatory solution and more of a discretionary solution as the ultimate 
access control decision resides with the user clicking on the 
allow/deny button versus the system's security policy.  I believe what 
Stephan is proposing is a mechanism which would prompt users (or some 
userspace application acting as a user) to make a decision on specific 
network events such as new connections.

> > This means personal firewalls should not enforce system
> > security policy,
> > but rather a per-user security policy.
> > The implementations can then add caching of decisions made
> > (ie.
> > "remember this decision") and thus not ask every
> > time a call is made.
> > Also, the only protocols to be supported are IPv4 and IPv6.
> > Adding
> > support for AF_UNIX and/or AF_NETLINK doesn't make much
> > sense, as this
> > is not network-related and would only increase the amount
> > of work a
> > personal firewall implementation has to do.
>
> I agree that Unix and Netlink would not be useful, but there are
> other socket types that are LAN- or WAN-based, and I'd not be too
> quick to implement anything that precluded them being covered.
> (There's a difference between designing code in a way that makes
> extending it hard and actually implementing other network types, so
> only implementing IPv4 and IPv6 on a framework that could be extended
> by anyone deeply passionate about other protocls makes sense --
> unless implementing it that way would be so much harder that it's
> pointless.)

I think it is reasonable to limit an initial implementation to just 
AF_INET[6] sockets.  As you note, if done properly it shouldn't be 
difficult to extend to other address/protocol families.

-- 
paul moore
linux @ hp

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Samir Bellabes]

Paul Moore <paul.moore@hp.com> writes:

> However, in dealing with the issue of personal firewalls I think the 
> biggest issue will be the user interaction as you described ... how do 
> you explain to a user who clicked the "allow" button that the system 
> rejected their traffic?

maybe because the personnal firewall is the only one which deal with the
LSM hook related to network (?)

>> >But what you are asking is to have multiple security models at the
>> > same time, with some kind of priority.
>> >I don't know if it's ok or not, but what I'm sure is that snet will
>> > use LSM hooks or your new framework without any problems in fact,
>> > as you are going to make some kind of wrapper on the members of the
>> > struct security_operations.
>>
>> jan>>> My opinion up to here would be to split LSM into the LSM
>> category
>>
>> >>> {selinux, apparmor, tomoyo} and the other, new LSM category
>> >>> {networking stuff}, just as a potential idea to get over the
>> >>> stacking / single LSM use  issue.
>> >
>> >Indeed I thought about that when writing snet.
>>
>> For starters, the existing LSM interface and the LSM  modules
>> themselves could be split up so as to provide
>>
>>  selinux.ko
>>   \_ selinux_net.ko
>>   \_ selinux_fs.ko
>>   ...
>>
>> just a suggestion to ease the thinking process for now.
>> If a purely network-related LSM does not have to think about
>> "do I need to implement FS hooks that do chaining or not..."
>> it is a lot better off.
>
> Unfortunately I don't think this solves the problem, it just changes it 
> slightly.  It is no longer "How do I enable SELinux and XXX personal 
> firewall?" but instead "How do I enable SELinux's network access 
> controls and XXX personal firewall?"

And introduce another one : "how do I make SElinux's network access
controls and Apparmor filesystem access controls working together ?"
this is the true deal in this kind of solution.

sam

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Paul Moore]

On Tuesday 20 January 2009 4:42:45 pm Samir Bellabes wrote:
> Paul Moore <paul.moore@hp.com> writes:
> > However, in dealing with the issue of personal firewalls I think
> > the biggest issue will be the user interaction as you described ...
> > how do you explain to a user who clicked the "allow" button that
> > the system rejected their traffic?
>
> maybe because the personnal firewall is the only one which deal with
> the LSM hook related to network (?)

In the particular case I was responding to there were multiple LSMs 
being executed in quasi-parallel fashion so the personal firewall (in 
this case assumed to be a separate LSM) would not be the only LSM 
implementing network access controls.

> >> For starters, the existing LSM interface and the LSM  modules
> >> themselves could be split up so as to provide
> >>
> >>  selinux.ko
> >>   \_ selinux_net.ko
> >>   \_ selinux_fs.ko
> >>   ...
> >>
> >> just a suggestion to ease the thinking process for now.
> >> If a purely network-related LSM does not have to think about
> >> "do I need to implement FS hooks that do chaining or not..."
> >> it is a lot better off.
> >
> > Unfortunately I don't think this solves the problem, it just
> > changes it slightly.  It is no longer "How do I enable SELinux and
> > XXX personal firewall?" but instead "How do I enable SELinux's
> > network access controls and XXX personal firewall?"
>
> And introduce another one : "how do I make SElinux's network access
> controls and Apparmor filesystem access controls working together ?"
> this is the true deal in this kind of solution.

That is also an issue.  Needless to say I doubt the "choose your own 
adventure" approach to security is a good idea.

-- 
paul moore
linux @ hp

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Stephan Peijnik]

On Tue, 2009-01-20 at 15:47 -0500, Paul Moore wrote:
> Another option that was brought up (although perhaps not very clearly 
> since it isn't listed here) was the embedding of the personal firewall 
> hooks into the individual LSMs roughly similar to how capabilities are 
> handled with SELinux today (a separate security mechanism that has 
> explicit calls within SELinux).  This approach enables the use of 
> current LSMs (although minor modifications will be needed) and avoids 
> the need to add new hooks to the core network stack.

Sorry for not adding that one, I think you sent that email after I
finished writing the summary and that's why it wasn't included in the
first place.
This is another way of doing it, yes, but in the end we would probably
end up writing additional wrapper like code with the only purpose of
being called by <insert favorite LSM here> and then forwarding that call
to <insert favorite personal firewall here>.
To have multiple approaches working we would probably need
register/unregister functions for that wrapper and, to be honest, to me
this sounds like a more complicated version of doing the calls to the
wrapper directly from net/socket.c. The outcome is pretty much the same
though.

> > What has not been agreed on yet is whether only a way of hooking
> > these calls should be made available to implementations or whether
> > the whole in-kernel part should be developed together and allow
> > implementations of personal firewalls in userspace only, for example
> > using a netlink socket to communicate with the shared in-kernel code.
> 
> Since there will always be a significant userspace component to any 
> personal firewall approach it seems reasonable to push the decision 
> making into userspace and leave the kernel component relatively simple.  
> The basic idea behind Samir's "snet" concept where the kernel simply 
> passes messages to userspace and waits for a verdict seems like a 
> reasonable approach in that it can be made to support different 
> personal firewall implementations/designs without significant changes 
> to the kernel.

I can only agree on that. However, providing a single solution that
cannot be extended dynamically (think of adding support for additional
protocols, implementing some sort of policy caching, etc.) might be the
wrong way to go.
We would end up having a solution and whilst I really like the snet
approach we would lose some flexibility.
This very approach on the other hand seems to work very well for
netfilter and we would end up with keeping all those personal firewall
developers out of the kernel.

-- Stephan

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Samir Bellabes]

Stephan Peijnik <stephan@peijnik.at> writes:

> Hello all of you,
>
> I am sending this email as a discussion about this topic has been going
> on at linux-security-module@vger.kernel.org for some time now and I
> believe that all parties affected or somehow related to this should be
> involved in the discussion. We would like to hear your opinion on this
> matter and would be glad if we could work together on finding a possible
> solution. I have CC'ed linux-security-module, netfilter-devel and
> netdev, but if you believe that I missed someone, feel free to forward
> this email to the respective list.
>
> Firstly, I would like to elaborate on what we more or less agreed on a
> personal firewall should be able to do and what such a piece of software
> is intended for.
>
> A personal firewall should implement per-application mandatory access
> control for sockets. In short this means that such a program decides
> every time a call to either socket(), accept(), bind(), connect() or
> listen() is made whether the invoking program is allowed to do so or
> not. No per-packet filtering can be done and neither is connection
> intercepting of any interest.
>
> As personal firewalls are targeted at single-user, desktop systems the
> decision on whether a call is allowed or not is usually made by the user
> of that system (for example using a popup asking the user what to do).

No, we can't limit the thought to a single-user.
snet [1] is using the uid as one information provided to userspace.
it mean that you can make diffence between this 2 rules :

user 'clara' is 'allowed' to use the program 'firefox' to 'connect' to a
webserver - 'TCP port 80' - on the host - 'IP address'

user 'dirt' is 'denied' to use the program 'firefox' to 'connect' to the
webserver - 'TCP port 80' - on the (same) host - 'IP address'

in the same time, the admin of the box is the only one root. it's not
because the user is logged on X, that he can control network syscalls of
all the OS. (and how will it be possible anyway ?)

and more important, I wrote snet, mainly as a home feature as you are
thinking, but also for administrators, in order to set up a kind of
filtering in LAN for users. Here, nobody will click on accept/deny
buttons, but the decision is put in some databases, controlled by the
sysadmin of the LAN, and in LAN boxes, daemon plug to snet will ask
distant database on verdict for local syscalls.

It make also sens at home in order to avoid this config websites on SOHO
routers to controls NAT/ports redirection :
- start ekiga on a LAN machine, it will do listen()
- snet catch it, allow it and the admin added the feature : ask the SOHO
  routers to do a redirection of incoming call coming from the internet
  to this LAN box.
- stop ekiga, the port is no more in LISTEN state
- delete the redirection on the routeurs.

it's working int the same with DMZ servers.

Again, this is controlled by the admin, and of course, by the only one
user, if he is alone.

> This means personal firewalls should not enforce system security policy,
> but rather a per-user security policy.

I disagree on this, as explained, per-user is just the simple case of
'there is only one user'. this is a specific case, and can't be taken as
generic situation.

And this is not a problem at all, because, I'm already able to managed
uid with snet. 

> The implementations can then add caching of decisions made (ie.
> "remember this decision") and thus not ask every time a call is made.

here you are thinking already too far.
let some developpers who wants to play with such a tool, as you, do
what he wants ("remember this decision", caching, ..), independantly of
the kernel+low level tool.
that's why I moved the code to have a library, and a callback function
which will provide all matching requested syscalls.

> Also, the only protocols to be supported are IPv4 and IPv6. Adding
> support for AF_UNIX and/or AF_NETLINK doesn't make much sense, as this
> is not network-related and would only increase the amount of work a
> personal firewall implementation has to do.

again, why should we be limited to IPv4 or IPv6 ? we are at the socket
layer, the application layer, so this place is transparent regarding
network protocol or the family, just put the information in the netlink
socket for the userspace too, and let the developper decide what he want
to do (allow AF_INET6 by default entirely)

> All proposed implementations of personal firewalls until now have made
> it rather clear that the decision-making logic should be placed in
> userspace, whilst only a small piece of code communicating with a
> userspace daemon should be placed in the kernel itself.

Indeed

> Okay, enough of the (not so) brief description on what people want to do
> and on to a summary of what has been discussed so far.
>
> Most implementations started out using the LSM framework for creating a
> personal firewall, that's also the reason the whole discussion started
> out on the LSM mailing list.
> Even though this looks like a good solution there is one main problem
> with the LSM framework right now: only a single LSM module can be loaded
> and enabled at a time. However, this was done intentionally as stacking
> multiple LSMs proved to be complex and not entirely sane.
> This means that if one decides to enable a personal firewall LSM at boot
> time one will not be able to use a generic-purpose LSM, like SELinux or
> AppArmor simultaneously. Additionally LSMs can only be enabled at boot
> time and cannot be LKMs, they have to be linked statically into the
> kernel. 

Please, this has nothing to do with building personnal firewall.
Even if I agree with you, because snet is working by choosing it, at
compilation time, rather than SELinux or smack.., this issue as to be
discuss in the same way it has been done lots of time.

> Another approach that has been suggested is using the netfilter
> framework for this purpose. Even though this again sounds like a good
> idea in the first place it also has its flaws.
> netfilter was designed to work on the network level and, at least from
> my understanding, is not process-context aware. Doing lookups to get the
> process context on each and every connection/packet passing netfilter
> could be done, but might have a negative effect on the overall system
> performance.

netfilter (specialy libconntrack) will help us for checking in-bound
connection, as LSM seems to be little bit weak on this. people behide
TOMOYO linux have mainly push the problem, but the solution is clearly
not to change the LSM hooks in accept() or receive().

You can match a network packet (IPv4 TCP syn for port 80) to the
previous fact that httpd did a listen() on the port.
So, *your* userspace tool, can have a table, which will keep all
listening port (snet will provide you this information) and in the same
time, you are asking libconntrack to give you packets with NEW state,
and try to match it
IPv4 TCP syn for port 80 ? is there someone allowed (httpd listening on
TCP port 80) to received this ? Yes, great ! let's the packets
bypassing or asking the user if he wants to.

> And yet another approach was suggested: hooking socket-related calls
> directly in net/socket.c. This would mean that the personal firewall
> code is called directly from net/socket.c and can this way work in
> process-context, without using the LSM framework.

It was the first proposition. Now I understand why it was rejected. [3]

> On the other hand this would add, besides the LSM calls that are in
> place in net/socket.c a few extra calls which might not be what we want.
> One should also keep in mind that calls can (and may, this is
> intentional) be blocked by the personal firewall system. This could be
> seen as an advantage or disadvantage, but would allow waiting for user
> input until proceeding with the execution of the caller.
>
> What has not been agreed on yet is whether only a way of hooking these
> calls should be made available to implementations or whether the whole
> in-kernel part should be developed together and allow implementations of
> personal firewalls in userspace only, for example using a netlink socket
> to communicate with the shared in-kernel code.
>
> Implementations using the LSM approach are TuxGuardian [0] and snet [1].
> Code implementing the last mentioned approach can be found in git over
> at [2] in the sactl-direct branch.
> Please don't forget that these implementations are probably in either a
> defunct state or are up to discussion themselves.
>
> As a final note I would like to add that I believe that all lists this
> mail has been sent to are somehow affected by the topic we are
> discussing and I (or better said we) would love to hear your opinions.
> Also, I hope I didn't miss anything that was discussed, but if I did
> feel free to correct me.
>
> -- Stephan
>
> [0] http://tuxguardian.sourceforge.net/
> [1] http://www.synack.fr/project/snet/snet.html
> [2] http://repo.or.cz/w/linux-2.6/sactl.git
>

[3] http://marc.info/?l=linux-netdev&m=115976955221633&w=2

sam

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Samir Bellabes]

Jonathan Day <imipak@yahoo.com> writes:

> --- On Tue, 1/20/09, Stephan Peijnik <stephan@peijnik.at> wrote:

[...]

>> This means personal firewalls should not enforce system
>> security policy,
>> but rather a per-user security policy.
>> The implementations can then add caching of decisions made
>> (ie.
>> "remember this decision") and thus not ask every
>> time a call is made.
>> Also, the only protocols to be supported are IPv4 and IPv6.
>> Adding
>> support for AF_UNIX and/or AF_NETLINK doesn't make much
>> sense, as this
>> is not network-related and would only increase the amount
>> of work a
>> personal firewall implementation has to do.
>
> I agree that Unix and Netlink would not be useful, but there are other socket types that are LAN- or WAN-based, and I'd not be too quick to implement anything that precluded them being covered. (There's a difference between designing code in a way that makes extending it hard and actually implementing other network types, so only implementing IPv4 and IPv6 on a framework that could be extended by anyone deeply passionate about other protocls makes sense -- unless implementing it that way would be so much harder that it's pointless.)

Exactly, and the cost for the kernel subsystem and the userspace low
level part should only be adding the new elements for sending usefull
informations to the userspace and wait for verdict, but the cost for the
'personnal firewall' developper is higher (how this protocol is
interacting with others ? etc etc)

>> All proposed implementations of personal firewalls until
>> now have made
>> it rather clear that the decision-making logic should be
>> placed in
>> userspace, whilst only a small piece of code communicating
>> with a
>> userspace daemon should be placed in the kernel itself.
>
> Well, it has probably not been a significant factor in anyone's decision, but it occurs to me that per-process firewalling within the kernel makes the "per-process" bit much more complicated and would not work at all using any of the zerocopy or kernel bypass networking mechanisms.

we don't need this at all, as we are in process context, syscall can
sleep.
Trust me, it's strange to have it's web browser freezing waiting for a
timeout if the userspace part doesn't reply, but if it's replying, it's
transparent.

sam

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Casey Schaufler]

Samir Bellabes wrote:
> Jonathan Day <imipak@yahoo.com> writes:
>
>   
>> --- On Tue, 1/20/09, Stephan Peijnik <stephan@peijnik.at> wrote:
>>     
>
> [...]
>
>   
>>> This means personal firewalls should not enforce system
>>> security policy,
>>> but rather a per-user security policy.
>>> The implementations can then add caching of decisions made
>>> (ie.
>>> "remember this decision") and thus not ask every
>>> time a call is made.
>>> Also, the only protocols to be supported are IPv4 and IPv6.
>>> Adding
>>> support for AF_UNIX and/or AF_NETLINK doesn't make much
>>> sense, as this
>>> is not network-related and would only increase the amount
>>> of work a
>>> personal firewall implementation has to do.
>>>       
>> I agree that Unix and Netlink would not be useful, but there are other socket types that are LAN- or WAN-based, and I'd not be too quick to implement anything that precluded them being covered. (There's a difference between designing code in a way that makes extending it hard and actually implementing other network types, so only implementing IPv4 and IPv6 on a framework that could be extended by anyone deeply passionate about other protocls makes sense -- unless implementing it that way would be so much harder that it's pointless.)
>>     
>
> Exactly, and the cost for the kernel subsystem and the userspace low
> level part should only be adding the new elements for sending usefull
> informations to the userspace and wait for verdict, but the cost for the
> 'personnal firewall' developper is higher (how this protocol is
> interacting with others ? etc etc)
>
>   
>>> All proposed implementations of personal firewalls until
>>> now have made
>>> it rather clear that the decision-making logic should be
>>> placed in
>>> userspace, whilst only a small piece of code communicating
>>> with a
>>> userspace daemon should be placed in the kernel itself.
>>>       
>> Well, it has probably not been a significant factor in anyone's decision, but it occurs to me that per-process firewalling within the kernel makes the "per-process" bit much more complicated and would not work at all using any of the zerocopy or kernel bypass networking mechanisms.
>>     
>
> we don't need this at all, as we are in process context, syscall can
> sleep.
> Trust me, it's strange to have it's web browser freezing waiting for a
> timeout if the userspace part doesn't reply, but if it's replying, it's
> transparent.

I hate to be the one to say this, but it looks to me as if the
easiest way to solve the problems that you have outlined would
be to create a new LSM based on SELinux with two important
changes. The first would be to have a separate policy for each
user (or process tree) and the second would be to make the policy
specification discretionary. SELinux has all the mechanism you're
talking about, but you want the policy being enforced to reflect
a set of "personal firewall" rules rather than "domain type" rules.
 From the lobby at LCA in Hobart these rule sets are pretty hard to
tell apart. And let's not have the "SELinux isn't designed to do
that" row. Of course it isn't. Nonetheless, the personal firewall
sure sounds a lot like SELinux if you ignore the MAC/DAC difference.

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Samir Bellabes]

Casey Schaufler <casey@schaufler-ca.com> writes:

> I hate to be the one to say this, but it looks to me as if the
> easiest way to solve the problems that you have outlined would
> be to create a new LSM based on SELinux with two important
> changes. 

Hi Casey,
I'm very interesting by this thought. because I don't have enough
background on security models.

> The first would be to have a separate policy for each
> user (or process tree) and the second would be to make the policy
> specification discretionary.

I got this, but I don't see what it's implying exactly.

> SELinux has all the mechanism you're
> talking about, but you want the policy being enforced to reflect
> a set of "personal firewall" rules rather than "domain type" rules.

ok, I understand the link with the domain type, and I agree.

> From the lobby at LCA in Hobart these rule sets are pretty hard to
> tell apart. 

By my experience on it, I fully agree.
At first, I jumped on how to build this rule sets, I just totally
failed. Specially for dropping rule, and worse: how to order rules.

Then we also need to join sets : (fixing a specific user)

     deny socket() for application X +
   + deny accept() for application X +
   + deny listen() for application X +
   + deny bind() for application X + .. (all syscalls)

 == deny all syscall for 'application X'

So the case of having all the denying rules, minus one, and the user
adding the missing rule, is not just adding the rule, but it's to 'add'
all of them to get only one.
and then we need to put priority/order on keys : filtering by uid first
? application first ?

I don't know how to do that. what I known for sure is that I don't want
to spend the next 20 years trying to solve this problem. 
that's why I focused on the better way to pass the informations to
userspace, at let someone who actually may implements a way to managed
this rules sets, with the simplest design to interact with the
kernel/API mechanism.

> And let's not have the "SELinux isn't designed to do
> that" row. Of course it isn't. Nonetheless, the personal firewall
> sure sounds a lot like SELinux if you ignore the MAC/DAC difference.

maybe, but for sure what SELinux is not doing is this :

1. I'm editing the sshd_config file to put the server to listen on the
   port 2222.
2. starting server
3. SELinux is not aware of that, it's not working
4. I have to put another conf inside SELinux to allow it (but actually
   didn't I already do it in 1 ?)

then it will work.

with the idea of userspace interaction (asking user, check a database)
1. I'm editing the sshd_config file to put the server to listen on the
   port 2222.
2. staring server -> listen() -> catch it in userspace, ask (X user,
   remote admin, automatic mecanism/database

only one config, tool is focusing on providing security : is this
allowed or not ? that's all.

And snet API can be used by others programs. As actually I'm developping
a opengl tool that is representing network informations, in real
time. This can't be done with SELinux.
But the main goal to achieve, is to make all boxes running in a LAN
aware of themselves and interact also with the main firewall, according
to the admin decisions. 

sam

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Samir Bellabes]

Stephan Peijnik <stephan@peijnik.at> writes:

> On Tue, 2009-01-20 at 15:47 -0500, Paul Moore wrote:
>> Another option that was brought up (although perhaps not very clearly 
>> since it isn't listed here) was the embedding of the personal firewall 
>> hooks into the individual LSMs roughly similar to how capabilities are 
>> handled with SELinux today (a separate security mechanism that has 
>> explicit calls within SELinux).  This approach enables the use of 
>> current LSMs (although minor modifications will be needed) and avoids 
>> the need to add new hooks to the core network stack.
>
> Sorry for not adding that one, I think you sent that email after I
> finished writing the summary and that's why it wasn't included in the
> first place.
> This is another way of doing it, yes, but in the end we would probably
> end up writing additional wrapper like code with the only purpose of
> being called by <insert favorite LSM here> and then forwarding that call
> to <insert favorite personal firewall here>.
> To have multiple approaches working we would probably need
> register/unregister functions for that wrapper and, to be honest, to me
> this sounds like a more complicated version of doing the calls to the
> wrapper directly from net/socket.c. The outcome is pretty much the same
> though.

Please, again, this as nothing to do with personal firewall.
The same problem remain if I want to write the same tool related to
filesystem.
We should definitly stop using 'personal firewall' as a excuse.
We just want a simple way to enable another security model. And you
should known that we already have the "security=" boot param [1]

So now the good question is what are we going to do when using a
personal firewall based on LSM, for the others non-related network
syscalls ? 

>> > What has not been agreed on yet is whether only a way of hooking
>> > these calls should be made available to implementations or whether
>> > the whole in-kernel part should be developed together and allow
>> > implementations of personal firewalls in userspace only, for example
>> > using a netlink socket to communicate with the shared in-kernel code.
>> 
>> Since there will always be a significant userspace component to any 
>> personal firewall approach it seems reasonable to push the decision 
>> making into userspace and leave the kernel component relatively simple.  
>> The basic idea behind Samir's "snet" concept where the kernel simply 
>> passes messages to userspace and waits for a verdict seems like a 
>> reasonable approach in that it can be made to support different 
>> personal firewall implementations/designs without significant changes 
>> to the kernel.
>
> I can only agree on that. However, providing a single solution that
> cannot be extended dynamically (think of adding support for additional
> protocols, implementing some sort of policy caching, etc.) might be the
> wrong way to go.

Providing dynamical support for next unknown protocols ?.. hum I'm
losing myself, and I hope to misunderstand you thought.

anyway, you can propose patches on snet to do that.

I already thought about a policy caching, even a 'verdict to rules'
caching. But you can implement the policy caching from the userspace.
And this won't work:

1. syscall A on protocol Y
2. look inside cache for verdict -> found nothing
3. ask userspace
4. kernel get a verdict, apply the verdict, put the verdict on cache.
5. same syscall and protocol as in 1
6. look inside cache -> apply cache verdict

what if the user changes it's rules between 4 and 5 ?
Yes, I known we won't change rules every seconds. we can clear the
cache. 
But this are implementation details, and we can easy move snet to have
this feature.

Also, how will you build a cache for a such informations ?
We surely want to cache the rule we match.

But anyway caching is regarding only some syscalls (as connect(),
recvmsg(), sendmsg())

And here we start speaking about how to build a personal firewall. And
this is exactly what I don't want. snet is here to let you have all the
freedom for this question. What if someone else don't want a policy
cache ? we put some param to enable or disable it ? No, the best way is
to let userspace do what he wants. 

sam

[1] http://lwn.net/Articles/271585/

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Paul Moore]

On Tuesday 20 January 2009 6:48:41 pm Stephan Peijnik wrote:
> On Tue, 2009-01-20 at 15:47 -0500, Paul Moore wrote:
> > Another option that was brought up (although perhaps not very
> > clearly since it isn't listed here) was the embedding of the
> > personal firewall hooks into the individual LSMs roughly similar to
> > how capabilities are handled with SELinux today (a separate
> > security mechanism that has explicit calls within SELinux).  This
> > approach enables the use of current LSMs (although minor
> > modifications will be needed) and avoids the need to add new hooks
> > to the core network stack.
>
> Sorry for not adding that one, I think you sent that email after I
> finished writing the summary and that's why it wasn't included in the
> first place.
> This is another way of doing it, yes, but in the end we would
> probably end up writing additional wrapper like code with the only
> purpose of being called by <insert favorite LSM here> and then
> forwarding that call to <insert favorite personal firewall here>.

That is pretty much my point.  Provide a personal firewall mechanism 
with a well defined API that LSMs can call as necessary.  The personal 
firewall code then notifies a userspace agent over another well defined 
API (netfilter, etc.) and waits for a verdict response.

I've mentioned this approach several times now (perhaps poorly?), if 
there is something you don't understand in my suggestion please let me 
know.  I'm also getting sick of typing "personal firewall" all the 
time, we need a shorter name and I'm going to start calling 
it "pfwall" :)

> To have multiple approaches working we would probably need
> register/unregister functions ...

Why?  You don't need to "register" with the LSM and you don't need 
to "register" with userspace.

> for that wrapper and, to be honest, to me this sounds like a more
> complicated version of doing the calls to the wrapper directly from
> net/socket.c ...

Personal preference I suppose, although I am very confident that the 
option described above (LSM calling the pfwall) has a much better 
chance of acceptance that an option which involves hooking the core 
network stack.

> > > What has not been agreed on yet is whether only a way of hooking
> > > these calls should be made available to implementations or
> > > whether the whole in-kernel part should be developed together and
> > > allow implementations of personal firewalls in userspace only,
> > > for example using a netlink socket to communicate with the shared
> > > in-kernel code.
> >
> > Since there will always be a significant userspace component to any
> > personal firewall approach it seems reasonable to push the decision
> > making into userspace and leave the kernel component relatively
> > simple. The basic idea behind Samir's "snet" concept where the
> > kernel simply passes messages to userspace and waits for a verdict
> > seems like a reasonable approach in that it can be made to support
> > different personal firewall implementations/designs without
> > significant changes to the kernel.
>
> I can only agree on that. However, providing a single solution that
> cannot be extended dynamically (think of adding support for
> additional protocols, implementing some sort of policy caching, etc.)
> might be the wrong way to go.

Explain what you mean by "dynamically" and give an example.

> We would end up having a solution and whilst I really like the snet
> approach we would lose some flexibility.

As I mentioned before in the previous thread, please list and explain 
all your requirements and we can work to arrive at a solution which 
meets those needs.  When possible we should work to develop solutions 
which are as flexible as possible, but flexibility for the sake of 
flexibility often results in unnecessary complexity which is rarely a 
good thing.

-- 
paul moore
linux @ hp

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jonathan Day]

--- On Thu, 1/22/09, Peter Dolding <oiaohm@gmail.com> wrote:
(snip)
> Worked with IPv4/6 hardware stacks.   Most of ones I have
> handled have
> had built in firewall processing.  Letting them feed
> directly into
> userspace becomes very uncontrollable very quickly. 
> Netfilter can be
> altered to operate like ALSA with hardware mixer.  Yes
> slower but you
> can filter.   Doing it at LSM you still have to place it in
> middle.
> Big issue with IPv4/6 hardware direct feeding into user
> space you have
> to get in middle to apply any forms of filters anyhow.

Ok, the LSM argument is certainly true, the direct feed I can see, and the ALSAfication of filtering is a highly intriguing solution that does answer the questions I had. From where I'm sitting (and I have no idea whatsoever whether that's remotely close to where anyone else sits), you've made a convincing argument.

(snip)
> Its not a completely different set of problems.   Please
> stop trying
> to draw lines in the sand between different groups.   Most
> critical
> thing for a firewall is that it works.

You'll get no argument from me on that.

(snip)
> Its just like the old idea that realtime OS's have
> nothing the same
> with supercomputers.   It turns out they have a lot in
> common lot of
> alterations to improve realtime support in Linux has
> increased
> supercomputer though put massively.

There, I 100% agree. Having worked for a supercomputer startup, I went through the bouncing-rocks-off-heads stage of getting people to see realtime and high-performance were not mutually-exclusive and did indeed have a lot in common.

> Desktop User needs a firewall that works correctly.   
> Server
> Administrators need the same.   Server Administrators do
> want simple
> to configure and be sure the firewall is right.   Same with
> Desktop
> users.

Again, you'll get no argument from me on that.

> When you get right down to it there is no much difference.

You've convinced me.

(snip)
> Linux network stack was very much designed with these evils
> in mind.
> Its highly modular it is the only way you can take this
> problem on.
> No matter what there will be events where you need to
> change the
> processing path completely by being modular you can.  
> These
> corner-cases are some of the reason why I keep on saying
> LSM is not
> the place.  Worst nightmares of the some of the
> corner-cases where
> some applications need treatment by a completely different
> processing
> stack to everything else.  LSM does not allow loading two
> modules/more
> safely without risking standing on the other LSM toes.
> 
> Basically if you cannot load multiable and assign them to
> different
> applications the design is not going to cut it in some of
> the corner
> cases.  Realtime vs Normal is fun enough.

This is probably the part of the argument that really made the case for me, as it covers both the weird paths problem and the modularity you need to make sure everything does get covered. The "everything gets covered" problem is the toughest part of any kind of access control on sockets and having gone hunting for as many weird and wonderful networking patches, I've seen some truly strange stuff.

> With clusters and shipping applications between processes
> supporting
> it gets a little pain in but.  Most likely putting the
> information in
> task credentials would be the sane solution then have when
> application
> is sent between machines its task credentials go with it.

Yes, it is a pain, and that makes it an excellent test. Almost anyone can write code that works under the most mainstream of normal conditions, so those simply aren't that useful in telling different methods apart. Things get fun when you start looking around the fringes, because that's when you really get an idea for when something can be readily extended or is going to be hitting a brick wall.

(snip)

It seems to me that the netfilter proponents have managed to solve everything I've thrown in their direction and have raised some good points regarding LSM. (And apologies if any of my prior posts got on anyone's nerves. I tend to be good at that.) This looks like it's going to be a fascinating and very well-argued debate, which can only be good news for whatever Linux ends up with.

Jonathan Day


      

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Peter Dolding]

On Thu, Jan 22, 2009 at 10:50 AM, Jonathan Day <imipak@yahoo.com> wrote:
> --- On Wed, 1/21/09, Peter Dolding <oiaohm@gmail.com> wrote:
> (snip)
>> There are many ways though the Linux kernel.  This is part
>> of the
>> reason why I am asking why they are wanting LSM so much.
>> LSM was
>> decided to be only one thing.   Not something to make more
>> of if it
>> can be avoided.   First rule should be seeing if API and
>> Internal
>> structs of Linux need fixing.  This case yes there are
>> quite a few
>> weaknesses in netfilter that could do with fixing.   If
>> after fixing
>> netfilter up it still turns out you need LSM support then
>> you do have
>> a valid reason.
> (snip)
>
> I agree with most of your argument (both what is quoted and what is snipped) but would be wary of any kernel-based solution for the reason I outlined in an earlier post - there are IPv4/6 stacks that sit in hardware and feed direct to userspace, and others that sit in userspace and use the zerocopy patches to minimize kernel entanglement. True, these are not the most common methods in use, and equally true, they would be just as complex to serve via LSM as by netfilter.

Worked with IPv4/6 hardware stacks.   Most of ones I have handled have
had built in firewall processing.  Letting them feed directly into
userspace becomes very uncontrollable very quickly.  Netfilter can be
altered to operate like ALSA with hardware mixer.  Yes slower but you
can filter.   Doing it at LSM you still have to place it in middle.
Big issue with IPv4/6 hardware direct feeding into user space you have
to get in middle to apply any forms of filters anyhow.

Ok witch zerocopy.   The one that just changes ownship between kernel
and userspace without coping.   Because that does boost performance
but makes zero alteration to how Netfilter works.  Reason when
transfered to kernel space userspace no longer can edit it anyhow.
>
> One of the first questions I would want answered is whether Socket-level MAC should be a generic solution (ie: be present regardless of what socket method the user code is using and be easily extendible across any protocol sockets support), a lightly-focussed solution (ie: be present for most socket methods and be moderately extendible across a fairly broad range of protocols) or be tightly-focussed (ie: be present on very specific types of sockets and protocols, perhaps be very tightly optimized for those, but ultimately be a royal pain to extend to anything else).
>
> Which type of solution you want will determine where would be the appropriate place to put the code. It's no use putting the code where it can't do what you want, but the only way to know that is to decide what it is you want the code to do in the first place.
>
> At present, I've seen a lot of discussion that basically agrees implementing IPv[46] for the standard case is a sensible first-pass. What I have not seen is any agreement that that should be the only pass. Linux' network stack supports a whole lot of LAN/WAN protocols besides those two and again that only covers what is supplied in the kernel as standard.
>
> This is not a trivial or academic question, because you have interdependencies in there. No matter what you pick as the right solution, there will be scenarios that solution cannot solve. Those scenarios differ between the different solutions. The danger is ignoring important cases by making assumptions that might not be valid about what the code will be used for.
>
> For example, the argument that desktop users would be the primary users of personal firewalls clearly goes against the dictum of server administration which states that servers should offer the least rights possible to get the job done, for security reasons. If servers are going to use the code as much (or more) than general users, then you are working in a completely different space with a different set of problems.

Sorry history has shown Desktop users on windows run with high user
rights.   Desktop users on Mac and Linux don't.

Its not a completely different set of problems.   Please stop trying
to draw lines in the sand between different groups.   Most critical
thing for a firewall is that it works.

Its just like the old idea that realtime OS's have nothing the same
with supercomputers.   It turns out they have a lot in common lot of
alterations to improve realtime support in Linux has increased
supercomputer though put massively.

Desktop User needs a firewall that works correctly.    Server
Administrators need the same.   Server Administrators do want simple
to configure and be sure the firewall is right.   Same with Desktop
users.

When you get right down to it there is no much difference.
>
> Orthogonal to that, are the firewalled accounts more likely to be concerned with low latency or high bandwidth? Each type of implementation has its own overheads and its own limitations, which will dictate what sort of service it can best support.
>
> Then you have the corner-cases and peculiarities. These would definitely include patches like RTNet, but also weirdness like MobileIP, Anycasting (which is asymetric - multicast one way, unicast the other, thus a different set of filters applies), clustered environments (where the firewall rules on the machine the process is active on won't be guaranteed the same as the rules on the machine the process appears to be on), Infiniband (which is extending into WAN environments, acts a lot like IPv6 and is getting a fair bit of attention at the moment) and so on.

Linux network stack was very much designed with these evils in mind.
Its highly modular it is the only way you can take this problem on.
No matter what there will be events where you need to change the
processing path completely by being modular you can.   These
corner-cases are some of the reason why I keep on saying LSM is not
the place.  Worst nightmares of the some of the corner-cases where
some applications need treatment by a completely different processing
stack to everything else.  LSM does not allow loading two modules/more
safely without risking standing on the other LSM toes.

Basically if you cannot load multiable and assign them to different
applications the design is not going to cut it in some of the corner
cases.  Realtime vs Normal is fun enough.

With clusters and shipping applications between processes supporting
it gets a little pain in but.  Most likely putting the information in
task credentials would be the sane solution then have when application
is sent between machines its task credentials go with it.
>
> Some of these we can ignore, some we will need to take into consideration, but if we don't know what Socket MAC is going to be used for, how do we know which is which?
>
I am sorry you are making exactly the same kind of argument when
people said Linux kernel could not run on desktops servers and
supercomputers from the same kernel source.   Being modular is
critical.

Way Linux network stack works you can swap the QoS section and keep on
going.   Swap every module out of netfilter and keep on going.

Unless you can make a really good argument how in heck LSM firewall
version is going to have many of its type running side by side you are
in trouble when can see another path that will allow running many side
by side.

Peter Dolding

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jonathan Day]

--- On Wed, 1/21/09, Casey Schaufler <casey@schaufler-ca.com> wrote:
> Jonathan Day wrote:
> > p.s. Which poster is going to be evil and start
> calling this Project MAC first?
> >   
> Careful, it can get much worse. What about mandatory access
> controls
> based on the NIC address, not the IP address? That would be
> MAC based
> MAC. Ack.

Then I would NACK your ACK for the bigMAC MAC/MAC.


      

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Casey Schaufler]

Jonathan Day wrote:
> p.s. Which poster is going to be evil and start calling this Project MAC first?
>   
Careful, it can get much worse. What about mandatory access controls
based on the NIC address, not the IP address? That would be MAC based
MAC. Ack.

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jonathan Day]

--- On Wed, 1/21/09, Peter Dolding <oiaohm@gmail.com> wrote:
(snip)
> There are many ways though the Linux kernel.  This is part
> of the
> reason why I am asking why they are wanting LSM so much. 
> LSM was
> decided to be only one thing.   Not something to make more
> of if it
> can be avoided.   First rule should be seeing if API and
> Internal
> structs of Linux need fixing.  This case yes there are
> quite a few
> weaknesses in netfilter that could do with fixing.   If
> after fixing
> netfilter up it still turns out you need LSM support then
> you do have
> a valid reason.
(snip)

I agree with most of your argument (both what is quoted and what is snipped) but would be wary of any kernel-based solution for the reason I outlined in an earlier post - there are IPv4/6 stacks that sit in hardware and feed direct to userspace, and others that sit in userspace and use the zerocopy patches to minimize kernel entanglement. True, these are not the most common methods in use, and equally true, they would be just as complex to serve via LSM as by netfilter.

One of the first questions I would want answered is whether Socket-level MAC should be a generic solution (ie: be present regardless of what socket method the user code is using and be easily extendible across any protocol sockets support), a lightly-focussed solution (ie: be present for most socket methods and be moderately extendible across a fairly broad range of protocols) or be tightly-focussed (ie: be present on very specific types of sockets and protocols, perhaps be very tightly optimized for those, but ultimately be a royal pain to extend to anything else).

Which type of solution you want will determine where would be the appropriate place to put the code. It's no use putting the code where it can't do what you want, but the only way to know that is to decide what it is you want the code to do in the first place.

At present, I've seen a lot of discussion that basically agrees implementing IPv[46] for the standard case is a sensible first-pass. What I have not seen is any agreement that that should be the only pass. Linux' network stack supports a whole lot of LAN/WAN protocols besides those two and again that only covers what is supplied in the kernel as standard.

This is not a trivial or academic question, because you have interdependencies in there. No matter what you pick as the right solution, there will be scenarios that solution cannot solve. Those scenarios differ between the different solutions. The danger is ignoring important cases by making assumptions that might not be valid about what the code will be used for.

For example, the argument that desktop users would be the primary users of personal firewalls clearly goes against the dictum of server administration which states that servers should offer the least rights possible to get the job done, for security reasons. If servers are going to use the code as much (or more) than general users, then you are working in a completely different space with a different set of problems.

Orthogonal to that, are the firewalled accounts more likely to be concerned with low latency or high bandwidth? Each type of implementation has its own overheads and its own limitations, which will dictate what sort of service it can best support.

Then you have the corner-cases and peculiarities. These would definitely include patches like RTNet, but also weirdness like MobileIP, Anycasting (which is asymetric - multicast one way, unicast the other, thus a different set of filters applies), clustered environments (where the firewall rules on the machine the process is active on won't be guaranteed the same as the rules on the machine the process appears to be on), Infiniband (which is extending into WAN environments, acts a lot like IPv6 and is getting a fair bit of attention at the moment) and so on.

Some of these we can ignore, some we will need to take into consideration, but if we don't know what Socket MAC is going to be used for, how do we know which is which?

p.s. Which poster is going to be evil and start calling this Project MAC first?


      

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Peter Dolding]

On Wed, Jan 21, 2009 at 7:32 PM, Rob Meijer <capibara@xs4all.nl> wrote:
> On Wed, January 21, 2009 09:15, Peter Dolding wrote:
>
>> Netfilter can already reject or approve out going packets from
>> applications on the base of user id process id and so on.  This is
>> before packets enter the Netfilter processing stack.   Cost of looking
>> up if applicaiton is approved or not appoved is out weight be the cost
>> of rejected packets going trough netfilter.
>>
>> Sorry netfilter is already sorting out how sockets can be used.   What
>> you are basically talking about is two layors doing exactly the same
>> thing.   Half of what tuxguardian does can be done in a iptables
>> module.  Ie filtering out going traffic based on application.
>>
>> Please explain why expanding netfilter is not a option.   Expanding
>> netfilter avoids conflicts with LSM's.
>>
>
> Agreed patches to Netfilter might get you a long way. Along the lines of
> --owner-uid you may extend it with something like --owner-exe and possibly
> --owner-callchainid. That could take care of:
>
> * connection-full-protocol like TCP
> * outgoing connection-less-protocol packets like UDP or ICMP
>
> The one thing that would remain would be incoming connection-less-protocol
> packets. If Netfilter could be patched in such a way that incoming packets
> could be filtered based on receiving process meta, that would be a great
> way to go. If not, maybe LSM would need to just mediate 'bind'.
>
> A second issue comes with user level administration. If Netfilter would be
> patched to allow a user to administrate her 'private' table, that could
> get called from the system wide Netfilter rules, some MAC framework would
> still be needed to make sure the user has a way to change the rules in her
> private table, but her browser, pdf reader, mail client etc have not.
>
> That is, you could define some system wide ruleset like:
>
> System wide:
>  * deny any packet from executables under '/home/*'
>  * deny any packet from user 'localuser'
>  * for any packet from an executable under /usr/bin/networkingtools/ jump
>    to the users USERPRIVATE table.
>  * deny all other trafic.
>
> User alice USERPRIVATE:
>  * allow all packets from /usr/bin/webbrowser to anything on tcp port 80.
>
> User bob USERPRIVATE:
>  * allow all packets from /usr/bin/webbrowser to the socks port of the
>    socks server.
>
> Would a solution like that be feasible?
>
> You would want alice or bob to be able to change their USERPRIVATE table,
> but you wouldn't want /usr/bin/webbrowser or any other program to do so
> independently. At least for that you would need close cooperation with
> for example SeLinux or AppArmor.
>
> Further it seems that 'bind' for connection less sockets will still be
> important a candidate for mediation by LSM IMHO.
>
More than feasible.   Look at cgroup's network stack work.   Stick
each user in there own Cgroup and they can even have there own IP
number and table if they like.   Of course cannot effect the table
outside the Cgroup.   Its the one of the major reasons why I said
fixing up netfilter to provide what is required makes doing multi user
simple.

Rules there would only be a extension to what cgroup networking and
netfilter.  Yes no LSM involvement required.

There are many ways though the Linux kernel.  This is part of the
reason why I am asking why they are wanting LSM so much.  LSM was
decided to be only one thing.   Not something to make more of if it
can be avoided.   First rule should be seeing if API and Internal
structs of Linux need fixing.  This case yes there are quite a few
weaknesses in netfilter that could do with fixing.   If after fixing
netfilter up it still turns out you need LSM support then you do have
a valid reason.

Bind not blocking is a defect in netfilter.   Bind call informs
netfilter that the traffic to that location is wanted.   One problem
netfilter cannot answer blocked.   Bind is not a LSM issue really.
Its a API issue between bind and netfilter.   Currently netfilter just
cuts the traffic off on the other side.  Ie you have binded to a port
and will receive nothing because no traffic will get to you.  Its also
not per application its global.    Yes netfilter rules store the
information need for blocking bind just no way of informing
application that it is.

Peter Dolding

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Rob Meijer]

On Wed, January 21, 2009 09:15, Peter Dolding wrote:

> Netfilter can already reject or approve out going packets from
> applications on the base of user id process id and so on.  This is
> before packets enter the Netfilter processing stack.   Cost of looking
> up if applicaiton is approved or not appoved is out weight be the cost
> of rejected packets going trough netfilter.
>
> Sorry netfilter is already sorting out how sockets can be used.   What
> you are basically talking about is two layors doing exactly the same
> thing.   Half of what tuxguardian does can be done in a iptables
> module.  Ie filtering out going traffic based on application.
>
> Please explain why expanding netfilter is not a option.   Expanding
> netfilter avoids conflicts with LSM's.
>

Agreed patches to Netfilter might get you a long way. Along the lines of
--owner-uid you may extend it with something like --owner-exe and possibly
--owner-callchainid. That could take care of:

* connection-full-protocol like TCP
* outgoing connection-less-protocol packets like UDP or ICMP

The one thing that would remain would be incoming connection-less-protocol
packets. If Netfilter could be patched in such a way that incoming packets
could be filtered based on receiving process meta, that would be a great
way to go. If not, maybe LSM would need to just mediate 'bind'.

A second issue comes with user level administration. If Netfilter would be
patched to allow a user to administrate her 'private' table, that could
get called from the system wide Netfilter rules, some MAC framework would
still be needed to make sure the user has a way to change the rules in her
private table, but her browser, pdf reader, mail client etc have not.

That is, you could define some system wide ruleset like:

System wide:
  * deny any packet from executables under '/home/*'
  * deny any packet from user 'localuser'
  * for any packet from an executable under /usr/bin/networkingtools/ jump
    to the users USERPRIVATE table.
  * deny all other trafic.

User alice USERPRIVATE:
  * allow all packets from /usr/bin/webbrowser to anything on tcp port 80.

User bob USERPRIVATE:
  * allow all packets from /usr/bin/webbrowser to the socks port of the
    socks server.

Would a solution like that be feasible?

You would want alice or bob to be able to change their USERPRIVATE table,
but you wouldn't want /usr/bin/webbrowser or any other program to do so
independently. At least for that you would need close cooperation with
for example SeLinux or AppArmor.

Further it seems that 'bind' for connection less sockets will still be
important a candidate for mediation by LSM IMHO.

Rob.

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Jan Engelhardt]

On Wednesday 2009-01-21 09:15, Peter Dolding wrote:
>
>I really don't see the need for special here other than improving iptables.
>
>LSM module is over kill.  This leads to double processing of packet requests.
>
>netfilter already can operate as either MAC or DAC all depending on
>the rules passed into it and the outside LSM applied.

But it cannot be used for personal firewalls at this time.
Incoming packets have no process context because they are
processed before that is determined, and similarly,
outgoing packets have already left most of the process
context behind them. Additionally, Netfilter cannot reject
bind() calls *at all*. That is the reason this is done
as an LSM in the first place.

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Peter Dolding]

On Wed, Jan 21, 2009 at 5:25 PM, Rob Meijer <capibara@xs4all.nl> wrote:
> On Wed, January 21, 2009 02:18, Casey Schaufler wrote:
>>
>>> we don't need this at all, as we are in process context, syscall can
>>> sleep.
>>> Trust me, it's strange to have it's web browser freezing waiting for a
>>> timeout if the userspace part doesn't reply, but if it's replying, it's
>>> transparent.
>>
>> I hate to be the one to say this, but it looks to me as if the
>> easiest way to solve the problems that you have outlined would
>> be to create a new LSM based on SELinux with two important
>> changes. The first would be to have a separate policy for each
>> user (or process tree) and the second would be to make the policy
>> specification discretionary. SELinux has all the mechanism you're
>> talking about, but you want the policy being enforced to reflect
>> a set of "personal firewall" rules rather than "domain type" rules.
>>  From the lobby at LCA in Hobart these rule sets are pretty hard to
>> tell apart. And let's not have the "SELinux isn't designed to do
>> that" row. Of course it isn't. Nonetheless, the personal firewall
>> sure sounds a lot like SELinux if you ignore the MAC/DAC difference.
>
> I think this is a perfect example of where using MAC 'and' DAC or rather
> centrally 'and' user managed profiles would be very fruitful. If you can
> create a purely permissive centrally managed per user profile, in fact
> delegating a permission set and allow each user to decompose and
> discretionary delegate parts of this profile to programs run by this same
> user, but with MAC restrictions when delegating to a process run by a
> different user, you would IMHO have a very powerful combination of MAC and
> DAC.
>
> I'm not sure however a label based MAC system would be best suited for
> combining MAC and DAC in such a way.
>
>
>
I really don't see the need for special here other than improving iptables.

LSM module is over kill.  This leads to double processing of packet requests.

netfilter already can operate as either MAC or DAC all depending on
the rules passed into it and the outside LSM applied.  selinux and
other lsm's can stop applications from changing the netfilter.  So
basic filtering of what can be changed in iptables basically turns
iptables from a DAC to a MAC.  Advantage added no more layors for
network packets to go though.

Only cost for outgoing really is changing the rules.  Once rules are
set cost compare to normal disappears.

Yes there will be a cost on incoming since application level incoming
filtering is not done at the moment.  There is a major problem here
for tuxguardian idea of being at the application API interface how in
heck are you going to block something before it has to travel all the
way threw the net-filter stack.  [network
card]-[netfilter]-[applicaiton]  Idea makes it [network
card]-[netfilter]-[application filter]-[application]  Really a bad
outcome.   If user say on X port they don't want traffic from X IP but
they want to let other IP's tuxguardian still has to netfilter so its
stoped soon enough.   No point processing items you are just dropping.

Netfilter can already reject or approve out going packets from
applications on the base of user id process id and so on.  This is
before packets enter the Netfilter processing stack.   Cost of looking
up if applicaiton is approved or not appoved is out weight be the cost
of rejected packets going trough netfilter.

Sorry netfilter is already sorting out how sockets can be used.   What
you are basically talking about is two layors doing exactly the same
thing.   Half of what tuxguardian does can be done in a iptables
module.  Ie filtering out going traffic based on application.

Please explain why expanding netfilter is not a option.   Expanding
netfilter avoids conflicts with LSM's.

Filtering traffic coming into applications is missing.  I am also
sorry tuxguardian over looks something using i7filter would allow
applications to share the same port number or block invalid type
packets being sent to an application.

True solid home firewall solution really should be able to use
i7filtering where needed.   Same with multi user-support.

The idea that personal firewall does not need to filter packets is
foolish.   Also the idea that machines that are always single user
exist is also foolish.  More and more Linux distributions are
supporting user switching.  Linux is completely designed as an multi
user OS.   So design need to take that into account.

Peter Dolding

Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

[Rob Meijer]

On Wed, January 21, 2009 02:18, Casey Schaufler wrote:
>
>> we don't need this at all, as we are in process context, syscall can
>> sleep.
>> Trust me, it's strange to have it's web browser freezing waiting for a
>> timeout if the userspace part doesn't reply, but if it's replying, it's
>> transparent.
>
> I hate to be the one to say this, but it looks to me as if the
> easiest way to solve the problems that you have outlined would
> be to create a new LSM based on SELinux with two important
> changes. The first would be to have a separate policy for each
> user (or process tree) and the second would be to make the policy
> specification discretionary. SELinux has all the mechanism you're
> talking about, but you want the policy being enforced to reflect
> a set of "personal firewall" rules rather than "domain type" rules.
>  From the lobby at LCA in Hobart these rule sets are pretty hard to
> tell apart. And let's not have the "SELinux isn't designed to do
> that" row. Of course it isn't. Nonetheless, the personal firewall
> sure sounds a lot like SELinux if you ignore the MAC/DAC difference.

I think this is a perfect example of where using MAC 'and' DAC or rather
centrally 'and' user managed profiles would be very fruitful. If you can
create a purely permissive centrally managed per user profile, in fact
delegating a permission set and allow each user to decompose and
discretionary delegate parts of this profile to programs run by this same
user, but with MAC restrictions when delegating to a process run by a
different user, you would IMHO have a very powerful combination of MAC and
DAC.

I'm not sure however a label based MAC system would be best suited for
combining MAC and DAC in such a way.



Rob