Re: Network flow controls and subj/obj ordering

On Friday 14 December 2007 2:25:12 pm Christopher J. PeBenito wrote:
> On Thu, 2007-12-13 at 10:45 -0500, Paul Moore wrote:
> > On Thursday 13 December 2007 9:12:08 am Christopher J. PeBenito wrote:
> > > On Wed, 2007-12-12 at 15:18 -0500, Paul Moore wrote:
> > > > Assuming labeled networking is enabled, a forwarded packet would
> > > > hit four checks:
> > > >
> > > > # inbound checks
> > > > allow netif_t peer_t:peer ingress;
> > > > allow netnode_t peer_t:peer ingress;
> > > > # outbound checks
> > > > allow netif_t peer_t:peer egress;
> > > > allow netnode_t peer_t:peer egress;
> > >
> > > This helps. But this seems to be for the old networking, how does it
> > > work with the secmark stuff?
> >
> > It doesn't work with the SECMARK stuff, or rather it works in parallel
> > with the SECMARK stuff. We've debated integrating the peer labeling
> > protocols (labeled IPsec, NetLabel) with the SECMARK mechanism many
> > times but in the end we always end up deciding it doesn't make sense.

>

The compat_net setting has no effect on the peer object class permissions. The only thing that will cause the any of the access controls above (the ones I listed) to go into affect is the netpeer policy capability bit/flag.

> ... not this:

>
> allow ssh_client_packet_t peer_t:peer egress;

There should never be a check between the iptables/secmark label, "ssh_client_packet_t", and the network peer label, "peer_t". Ever. Well, unless I screwed up the code somewhere ;)

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