Q: SECMARK controls on forwarded packets

Q: SECMARK controls on forwarded packets

[Paul Moore]

Traditionally we have always checked a packet's secmark label against the 
receiving socket and granted access based on allow rules similar to the one 
below:

 allow socket_t secmark_t:packet recv;

... we performed a similar check when sending packets:

 allow socket_t secmark_t:packet send;

However, when we are dealing with forwarded traffic we do not have a sending 
or receiving socket to compare the packet's secmark label against to perform 
access control.  Despite the lack of a socket, I believe we can still provide 
useful access control with secmark labels by using the packet's peer label 
(quick refresher, the packet's peer label is taken/derived from the original 
sending socket and "attached" to the packet via NetLabel or labeled IPsec).  
Since the packet's peer label conveys the same label as the sending socket, 
using the packet's peer label in place of the sending socket seems to be a 
natural fit.

Agree?  Disagree?  Other ideas?

Working under the assumption that you all agree, do you think we should stick 
with the existing "packet { send recv }" permissions for forwarded traffic?  
The "send" permission still makes sense to me for outgoing forwarded traffic 
but the "recv" permission is all wrong since the forwarding host isn't 
consuming the packet like it is with the existing "recv" permission.  With 
that in mind, I'd suggest adding a new permission, "forward", which is used 
when checking inbound forwarded traffic.

Agree?  Disagree?  Other ideas?

So, in summary, here are the SECMARK permission checks applied to locally 
generated or consumed traffic [this is the status quo]:

 # inbound traffic
 allow socket_t secmark_t:packet recv;
 # outbound traffic
 allow socket_t secmark_t:packet send;

... and these are the proposed SECMARK permission checks applied to forwarded 
traffic as it enters and exists the forwarding-host/router:

 # inbound traffic to be forwarded
 allow peer_t secmark_t:packet forward;
 # outbound forwarded traffic
 allow peer_t secmark_t:packet send;

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Stephen Smalley]

On Tue, 2008-01-08 at 23:30 -0500, Paul Moore wrote:
> Traditionally we have always checked a packet's secmark label against the 
> receiving socket and granted access based on allow rules similar to the one 
> below:
> 
>  allow socket_t secmark_t:packet recv;
> 
> ... we performed a similar check when sending packets:
> 
>  allow socket_t secmark_t:packet send;
> 
> However, when we are dealing with forwarded traffic we do not have a sending 
> or receiving socket to compare the packet's secmark label against to perform 
> access control.  Despite the lack of a socket, I believe we can still provide 
> useful access control with secmark labels by using the packet's peer label 
> (quick refresher, the packet's peer label is taken/derived from the original 
> sending socket and "attached" to the packet via NetLabel or labeled IPsec).  
> Since the packet's peer label conveys the same label as the sending socket, 
> using the packet's peer label in place of the sending socket seems to be a 
> natural fit.
> 
> Agree?  Disagree?  Other ideas?

Agree.

> Working under the assumption that you all agree, do you think we should stick 
> with the existing "packet { send recv }" permissions for forwarded traffic?  
> The "send" permission still makes sense to me for outgoing forwarded traffic 
> but the "recv" permission is all wrong since the forwarding host isn't 
> consuming the packet like it is with the existing "recv" permission.  With 
> that in mind, I'd suggest adding a new permission, "forward", which is used 
> when checking inbound forwarded traffic.
> 
> Agree?  Disagree?  Other ideas?

Disagree with re-using send, as you then cannot distinguish in policy
between what you allow to be sent from local processes vs. what you
allow to be forwarded.

> So, in summary, here are the SECMARK permission checks applied to locally 
> generated or consumed traffic [this is the status quo]:
> 
>  # inbound traffic
>  allow socket_t secmark_t:packet recv;
>  # outbound traffic
>  allow socket_t secmark_t:packet send;
> 
> ... and these are the proposed SECMARK permission checks applied to forwarded 
> traffic as it enters and exists the forwarding-host/router:
> 
>  # inbound traffic to be forwarded
>  allow peer_t secmark_t:packet forward;
>  # outbound forwarded traffic
>  allow peer_t secmark_t:packet send;

The problem with the last one is that it also allows the same thing to
happen for locally generated traffic, which might not be what the policy
writer wants to allow.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Wednesday 09 January 2008 7:51:44 am Stephen Smalley wrote:
> On Tue, 2008-01-08 at 23:30 -0500, Paul Moore wrote:
> > So, in summary, here are the SECMARK permission checks applied to locally
> > generated or consumed traffic [this is the status quo]:
> >
> >  # inbound traffic
> >  allow socket_t secmark_t:packet recv;
> >  # outbound traffic
> >  allow socket_t secmark_t:packet send;
> >
> > ... and these are the proposed SECMARK permission checks applied to
> > forwarded traffic as it enters and exists the forwarding-host/router:
> >
> >  # inbound traffic to be forwarded
> >  allow peer_t secmark_t:packet forward;
> >  # outbound forwarded traffic
> >  allow peer_t secmark_t:packet send;
>
> The problem with the last one is that it also allows the same thing to
> happen for locally generated traffic, which might not be what the policy
> writer wants to allow.

Fair enough.  I'll try to think of something catchy to replace the send 
permission in the forwarding outbound case ... if anybody has any great ideas 
I'd love to hear them.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Stephen Smalley]

On Wed, 2008-01-09 at 08:30 -0500, Paul Moore wrote:
> On Wednesday 09 January 2008 7:51:44 am Stephen Smalley wrote:
> > On Tue, 2008-01-08 at 23:30 -0500, Paul Moore wrote:
> > > So, in summary, here are the SECMARK permission checks applied to locally
> > > generated or consumed traffic [this is the status quo]:
> > >
> > >  # inbound traffic
> > >  allow socket_t secmark_t:packet recv;
> > >  # outbound traffic
> > >  allow socket_t secmark_t:packet send;
> > >
> > > ... and these are the proposed SECMARK permission checks applied to
> > > forwarded traffic as it enters and exists the forwarding-host/router:
> > >
> > >  # inbound traffic to be forwarded
> > >  allow peer_t secmark_t:packet forward;
> > >  # outbound forwarded traffic
> > >  allow peer_t secmark_t:packet send;
> >
> > The problem with the last one is that it also allows the same thing to
> > happen for locally generated traffic, which might not be what the policy
> > writer wants to allow.
> 
> Fair enough.  I'll try to think of something catchy to replace the send 
> permission in the forwarding outbound case ... if anybody has any great ideas 
> I'd love to hear them.

Well, you could just go with the obvious:
# inbound traffic to be forwarded
allow peer_t secmark_t:packet forward_in;
# outbound forwarded traffic
allow peer_t secmark_t:packet forward_out;

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[James Morris]

On Tue, 8 Jan 2008, Paul Moore wrote:

> (quick refresher, the packet's peer label is taken/derived from the original 
> sending socket and "attached" to the packet via NetLabel or labeled IPsec).  
> Since the packet's peer label conveys the same label as the sending socket, 
> using the packet's peer label in place of the sending socket seems to be a 
> natural fit.
> 
> Agree?  Disagree?  Other ideas?

Agree.

I think the forward_in/out thing works.

It'd be interesting to see what some fully worked network policy would 
look like for a couple of cases (e.g. secmark only, or secmark + ipsec).


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Wednesday 09 January 2008 8:39:41 am Stephen Smalley wrote:
> On Wed, 2008-01-09 at 08:30 -0500, Paul Moore wrote:
> > Fair enough.  I'll try to think of something catchy to replace the
> > send permission in the forwarding outbound case ... if anybody has
> > any great ideas I'd love to hear them.
>
> Well, you could just go with the obvious:
> # inbound traffic to be forwarded
> allow peer_t secmark_t:packet forward_in;
> # outbound forwarded traffic
> allow peer_t secmark_t:packet forward_out;

'forward_in' and 'forward_out'?  I thought I said "something catchy"?

 :)

Seriously though, I can't think of anything better so { forward_in 
forward_out } it is.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Wednesday 09 January 2008 9:04:43 am James Morris wrote:
> It'd be interesting to see what some fully worked network policy
> would look like ...

Everything below is based on the patches found here (the very observant 
will notice slight differences in permission ordering from previous 
mailing list patch postings):

 * http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing

The following is an example of what permissions are needed for the 
various send/receive/forward network tasks using the "new and improved" 
network controls.  In addition, while policy is not ordered, I've 
ordered the allow rules in the order in which the kernel performs the 
access checks.  I've also left out the labeled IPsec SA polmatch checks 
since those are unchanged and add some noise to the rules below.

If anyone has any comments/problems/objections please speak up quickly 
so we can get everything straightened out as soon as possible.

 - basic subj/obj definitions

   socket_t  = socket's label
   peer_t    = peer label as determined by NetLabel and/or labeled IPsec
   secmark_t = secmark/iptables label
   netif_t   = network interface label
   node_t    = network address label

 - inbound locally consumed traffic permissions

   # is TOP_SECRET traffic allowed on this network?
   allow peer_t netif_t:netif ingress;
   allow peer_t node_t:node recvfrom;
   # is apache allowed to receive traffic from firefox?
   allow socket_t peer_t:peer recv;
   # is apache allowed to receive web traffic?
   allow socket_t secmark_t:packet recv;

 - outbound locally generated traffic permissions
   
   # is apache allowed to send web traffic?
   allow socket_t secmark_t:packet send;
   # is TOP_SECRET traffic allowed on this network?
   allow socket_t netif_t:netif egress;
   allow socket_t node_t:node sendto;

 - inbound forwaded traffic permissions

   # is TOP_SECRET traffic allowed on this network?   
   allow peer_t netif_t:netif ingress;
   allow peer_t node_t:node recvfrom;
   # is apache allowed to forward web traffic through this system?
   allow peer_t secmark_t:packet forward_in;

 - outbound forwarded traffic permissions

   # is apache allowed to forward web traffic through this system?
   allow peer_t secmark_t:packet forward_out;
   # is TOP_SECRET traffic allowed on this network?
   allow peer_t netif_t:netif egress;
   allow peer_t node_t:node sendto;

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Wednesday 09 January 2008 3:48:10 pm Paul Moore wrote:
>  - inbound locally consumed traffic permissions
>
>    # is TOP_SECRET traffic allowed on this network?
>    allow peer_t netif_t:netif ingress;
>    allow peer_t node_t:node recvfrom;
>    # is apache allowed to receive traffic from firefox?
>    allow socket_t peer_t:peer recv;
>    # is apache allowed to receive web traffic?
>    allow socket_t secmark_t:packet recv;
>
>  - outbound locally generated traffic permissions
>
>    # is apache allowed to send web traffic?
>    allow socket_t secmark_t:packet send;
>    # is TOP_SECRET traffic allowed on this network?
>    allow socket_t netif_t:netif egress;
>    allow socket_t node_t:node sendto;
>
>  - inbound forwaded traffic permissions
>
>    # is TOP_SECRET traffic allowed on this network?
>    allow peer_t netif_t:netif ingress;
>    allow peer_t node_t:node recvfrom;
>    # is apache allowed to forward web traffic through this system?
>    allow peer_t secmark_t:packet forward_in;
>
>  - outbound forwarded traffic permissions
>
>    # is apache allowed to forward web traffic through this system?
>    allow peer_t secmark_t:packet forward_out;
>    # is TOP_SECRET traffic allowed on this network?
>    allow peer_t netif_t:netif egress;
>    allow peer_t node_t:node sendto;

While it doesn't have a big impact on policy, it's probably also worth 
mentioning that all of the above access checks are now dynamically 
enabled/disabled based on the presence of user configuration at 
runtime.  What this means is that if you have not configured NetLabel, 
labeled IPsec, or SECMARK all of the checks above will be skipped which 
should result in significantly less per-packet overhead in most cases.

For those of you who only make use of some of the labeled networking 
functionality, as you configure the system to use the labeled 
networking features you want, the relevant access checks are 
automatically enabled by the kernel.  For example, if you only have 
SECMARK configured you will only hit the following access checks:

 - inbound locally consumed traffic permissions

   allow socket_t secmark_t:packet recv;

 - outbound locally generated traffic permissions
   
   allow socket_t secmark_t:packet send;

 - inbound forwaded traffic permissions

   allow unlabeled_t secmark_t:packet forward_in;

 - outbound forwarded traffic permissions

   allow unlabeled_t secmark_t:packet forward_out;

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Q: SECMARK controls on forwarded packets

[Chad Hanson]

These controls look good to us... 

-Chad

> 
> On Wednesday 09 January 2008 9:04:43 am James Morris wrote:
> > It'd be interesting to see what some fully worked network policy
> > would look like ...
> 
> Everything below is based on the patches found here (the very 
> observant 
> will notice slight differences in permission ordering from previous 
> mailing list patch postings):
> 
>  * http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing
> 
> The following is an example of what permissions are needed for the 
> various send/receive/forward network tasks using the "new and 
> improved" 
> network controls.  In addition, while policy is not ordered, I've 
> ordered the allow rules in the order in which the kernel performs the 
> access checks.  I've also left out the labeled IPsec SA 
> polmatch checks 
> since those are unchanged and add some noise to the rules below.
> 
> If anyone has any comments/problems/objections please speak 
> up quickly 
> so we can get everything straightened out as soon as possible.
> 
>  - basic subj/obj definitions
> 
>    socket_t  = socket's label
>    peer_t    = peer label as determined by NetLabel and/or 
> labeled IPsec
>    secmark_t = secmark/iptables label
>    netif_t   = network interface label
>    node_t    = network address label
> 
>  - inbound locally consumed traffic permissions
> 
>    # is TOP_SECRET traffic allowed on this network?
>    allow peer_t netif_t:netif ingress;
>    allow peer_t node_t:node recvfrom;
>    # is apache allowed to receive traffic from firefox?
>    allow socket_t peer_t:peer recv;
>    # is apache allowed to receive web traffic?
>    allow socket_t secmark_t:packet recv;
> 
>  - outbound locally generated traffic permissions
>    
>    # is apache allowed to send web traffic?
>    allow socket_t secmark_t:packet send;
>    # is TOP_SECRET traffic allowed on this network?
>    allow socket_t netif_t:netif egress;
>    allow socket_t node_t:node sendto;
> 
>  - inbound forwaded traffic permissions
> 
>    # is TOP_SECRET traffic allowed on this network?   
>    allow peer_t netif_t:netif ingress;
>    allow peer_t node_t:node recvfrom;
>    # is apache allowed to forward web traffic through this system?
>    allow peer_t secmark_t:packet forward_in;
> 
>  - outbound forwarded traffic permissions
> 
>    # is apache allowed to forward web traffic through this system?
>    allow peer_t secmark_t:packet forward_out;
>    # is TOP_SECRET traffic allowed on this network?
>    allow peer_t netif_t:netif egress;
>    allow peer_t node_t:node sendto;
> 
> -- 
> paul moore
> linux security @ hp
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Thursday 10 January 2008 10:32:10 am Chad Hanson wrote:
> These controls look good to us...

Great.  I'm assuming the lack of complaints means others are happy with 
this as well.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Joshua Brindle]

Paul Moore wrote:
> On Thursday 10 January 2008 10:32:10 am Chad Hanson wrote:
>> These controls look good to us...
> 
> Great.  I'm assuming the lack of complaints means others are happy with 
> this as well.
> 

I haven't gotten around to looking at the rfc in detail but it looks 
like the secmark/external labeling concepts are being merged again when 
we already decided to keep them as separate systems. Is the claim here 
that it isn't possible to do forwarding controls without interaction 
between them?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Thursday 10 January 2008 1:56:32 pm Joshua Brindle wrote:
> Paul Moore wrote:
> > On Thursday 10 January 2008 10:32:10 am Chad Hanson wrote:
> >> These controls look good to us...
> >
> > Great.  I'm assuming the lack of complaints means others are happy
> > with this as well.
>
> I haven't gotten around to looking at the rfc in detail but it looks
> like the secmark/external labeling concepts are being merged again
> when we already decided to keep them as separate systems.

No, the secmark and peer/external labeling concepts are _not_ being 
merged.  The peer/external label will continue to represent the label 
of the socket that sent the data (peer label = firefox_t) while the 
secmark label will continue to represent the packet's IP attributes 
such as port information (secmark label = http_packet_t).  Nothing has 
changed in this regard and I don't expect it to anytime soon.

I assume the source of confusion are the following permissions:

 - inbound forwaded traffic permissions

   # is apache allowed to forward web traffic through this system?
   allow peer_t secmark_t:packet forward_in;
 
 - outbound forwarded traffic permissions
 
   # is apache allowed to forward web traffic through this system?
   allow peer_t secmark_t:packet forward_out;

In both cases we cannot use the socket's label as this packet is neither 
generated by or consumed by a local socket (forwarded traffic).  
However, we can still perform a meaningful secmark access check by 
checking the secmark label against the peer label; this is similar to 
how we check the secmark label against the socket label for regular 
(non-forwarded) traffic.  The key here is to remember that the peer 
label represents the original socket's label even though in the 
forwarded case the socket happens to be located on a different machine.

Make more sense now?

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Q: SECMARK controls on forwarded packets

[Joshua Brindle]

Paul Moore wrote:
> On Thursday 10 January 2008 1:56:32 pm Joshua Brindle wrote:
>> Paul Moore wrote:
>>> On Thursday 10 January 2008 10:32:10 am Chad Hanson wrote:
>>>> These controls look good to us...
>>> 
>>> Great.  I'm assuming the lack of complaints means others are happy
>>> with this as well.
>> 
>> I haven't gotten around to looking at the rfc in detail but it looks
>> like the secmark/external labeling concepts are being merged again
>> when we already decided to keep them as separate systems.
> 
> No, the secmark and peer/external labeling concepts are _not_
> being merged.  The peer/external label will continue to
> represent the label of the socket that sent the data (peer
> label = firefox_t) while the secmark label will continue to
> represent the packet's IP attributes such as port information
> (secmark label = http_packet_t).  Nothing has changed in this
> regard and I don't expect it to anytime soon.
> 
> I assume the source of confusion are the following permissions:
> 
>  - inbound forwaded traffic permissions
> 
>    # is apache allowed to forward web traffic through this system?
>    allow peer_t secmark_t:packet forward_in;
> 
>  - outbound forwarded traffic permissions
> 
>    # is apache allowed to forward web traffic through this system?
>    allow peer_t secmark_t:packet forward_out;
> 
> In both cases we cannot use the socket's label as this packet
> is neither generated by or consumed by a local socket (forwarded
> traffic). However, we can still perform a meaningful secmark access
> check by checking the secmark label against the peer label;
> this is similar to how we check the secmark label against the socket
> label for regular (non-forwarded) traffic.  The key here is to
> remember that 
> the peer label represents the original socket's label even
> though in the forwarded case the socket happens to be located
> on a different machine.
> 
> Make more sense now?

Sure, as long as the secmark label isn't mutating to accomidate
forwarding checks it sounds reasonable to me.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Q: SECMARK controls on forwarded packets

[Paul Moore]

On Thursday 10 January 2008 3:04:59 pm Joshua Brindle wrote:
> Paul Moore wrote:
> > Make more sense now?
>
> Sure, as long as the secmark label isn't mutating to accomidate
> forwarding checks it sounds reasonable to me.

Great, thanks.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.