Re: Q: SECMARK controls on forwarded packets

[Paul Moore <paul.moore@hp.com>]

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.