Network flow controls and subj/obj ordering

Network flow controls and subj/obj ordering

[Paul Moore]

Hello everybody,

After a discussion with Venkat last week we decided that it was probably best 
if I took responsibility for the flow control patches and ported/cleaned them 
up for inclusion in the labeled networking patches for 2.6.25.  In the course 
of doing so I ran across the problem of subject/object "ordering" (probably 
not the best term, but it's all I can think of right now).  In both the "flow 
in" and "flow out" cases I'm tempted to use the packet's peer label as the 
object just for the sake of consistency and the ability to use the new "peer" 
object class for all network peer label access checks.  However, I wanted to 
make sure that is what everyone had in mind from a conceptual point of view.  
See the two simple policy examples below:

 * Packet "flows" into the system, peer label is the object

   allow netif_t peerlbl_t:peer flow_in;

 * Packet "flows" out of the system, peer label is the object

   allow netif_t peerlbl_t:peer flow_out;

Thoughts, opinions?

-- 
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: Network flow controls and subj/obj ordering

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> Hello everybody,
> 
> After a discussion with Venkat last week we decided that it was probably best
> 
> if I took responsibility for the flow control patches and ported/cleaned them
> 
> up for inclusion in the labeled networking patches for 2.6.25.  In the course
> 
> of doing so I ran across the problem of subject/object "ordering" (probably 
> not the best term, but it's all I can think of right now).  In both the "flow
> 
> in" and "flow out" cases I'm tempted to use the packet's peer label as the 
> object just for the sake of consistency and the ability to use the new "peer"
> 
> object class for all network peer label access checks.  However, I wanted to 
> make sure that is what everyone had in mind from a conceptual point of view. 
> 
> See the two simple policy examples below:
> 
>  * Packet "flows" into the system, peer label is the object
> 
>    allow netif_t peerlbl_t:peer flow_in;
> 
>  * Packet "flows" out of the system, peer label is the object
> 
>    allow netif_t peerlbl_t:peer flow_out;
> 
> Thoughts, opinions?

Networking policy is always fun to debate. I've gotten it wrong
so many times I've lost count. Let's see if I can add anything of
value.

A packet appears out of the ether and is attached to a flow. If the
packet is a labeled object and the flow is a labeled object, what
is the subject? If the packet moves on out of the system (it is
being forwarded) and the packet is a labeled object, what is the
subject? Do you even have a subject/object relationship in this case?
I think that if you can identify the subject involved in flow
processing the policy implications ought to be pretty clear. If
you don't, and you have nothing but objects to deal with, it gets
painfully difficult to produce a security model that can be described
using traditional methods.

I will point out that it is pretty difficult to associate a subject
with an action on a packet object in all cases, and that is one reason
the model of a packet as an object never caught on. Perhaps the flow
is your subject, performing read and write operations on the packets.
I don't know that it makes a lot of sense to consider a flow as a
subject, but I've made arguments from shakier premises myself.

Think about the notion that the flow is the object, and that the
subject is whatever created the packet, and the label on the packet
describes the subject. This makes the operation a write from the
packet creator to the flow. It makes the outflow a read from the
flow by whatever active entity (task? kthread? daemon?) sends the
packet along, and a write to the destination with the label on the
packet again describing that subject.

In any case, if you don't bring a subject into the picture you may
have processing to do, but you're not making access control decisions.


Casey Schaufler
casey@schaufler-ca.com

--
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: Network flow controls and subj/obj ordering

[Christopher J. PeBenito]

On Tue, 2007-12-11 at 12:02 -0500, Paul Moore wrote:
> After a discussion with Venkat last week we decided that it was probably best 
> if I took responsibility for the flow control patches and ported/cleaned them 
> up for inclusion in the labeled networking patches for 2.6.25.  In the course 
> of doing so I ran across the problem of subject/object "ordering" (probably 
> not the best term, but it's all I can think of right now).  In both the "flow 
> in" and "flow out" cases I'm tempted to use the packet's peer label as the 
> object just for the sake of consistency and the ability to use the new "peer" 
> object class for all network peer label access checks.  However, I wanted to 
> make sure that is what everyone had in mind from a conceptual point of view.  
> See the two simple policy examples below:
> 
>  * Packet "flows" into the system, peer label is the object
> 
>    allow netif_t peerlbl_t:peer flow_in;
> 
>  * Packet "flows" out of the system, peer label is the object
> 
>    allow netif_t peerlbl_t:peer flow_out;

Can you give an example for the forwarding case?  Also, how about in the
non-labeled networking case?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: Network flow controls and subj/obj ordering

[Paul Moore]

On Tuesday 11 December 2007 12:51:18 pm Casey Schaufler wrote:
> --- Paul Moore <paul.moore@hp.com> wrote:
> > Hello everybody,
> >
> > After a discussion with Venkat last week we decided that it was
> > probably best if I took responsibility for the flow control patches
> > and ported/cleaned them up for inclusion in the labeled networking
> > patches for 2.6.25.  In the course of doing so I ran across the
> > problem of subject/object "ordering" (probably not the best term,
> > but it's all I can think of right now).  In both the "flow in"
> > and "flow out" cases I'm tempted to use the packet's peer label as
> > the object just for the sake of consistency and the ability to use
> > the new "peer" object class for all network peer label access
> > checks.  However, I wanted to make sure that is what everyone had in
> > mind from a conceptual point of view.
> >
> > See the two simple policy examples below:
> >
> >  * Packet "flows" into the system, peer label is the object
> >
> >    allow netif_t peerlbl_t:peer flow_in;
> >
> >  * Packet "flows" out of the system, peer label is the object
> >
> >    allow netif_t peerlbl_t:peer flow_out;
> >
> > Thoughts, opinions?
>
> Networking policy is always fun to debate. I've gotten it wrong
> so many times I've lost count. Let's see if I can add anything of
> value.

[Sorry for the delay, I was distracted yesterday]

Yes indeed, hence the reason for my mail.  I'm trying to get it "right" 
this time around ... probably a bit naive, but I'm crazy like that.

> A packet appears out of the ether and is attached to a flow. If the
> packet is a labeled object and the flow is a labeled object, what
> is the subject? If the packet moves on out of the system (it is
> being forwarded) and the packet is a labeled object, what is the
> subject? Do you even have a subject/object relationship in this case?
> I think that if you can identify the subject involved in flow
> processing the policy implications ought to be pretty clear. If
> you don't, and you have nothing but objects to deal with, it gets
> painfully difficult to produce a security model that can be described
> using traditional methods.

Unfortunately we are talking about two different things here (although 
your argument above sorta fits in a strange way).  I'm talking about 
the "flow control" patches that Venkat posted back in September and it 
looks like you are talking about access controls involving the kernel 
flow constructs.  Somewhat related, but two different things.

We should probably pick a better name that "flow control" as it has a 
tendency to get associated with the kernel flow construct and the two 
are different.  I'm thinking of "packet ingress/egress controls" so 
unless anyone has any better ideas I'm gonna go with that for now ...

Your post was an interesting read that I think summed up a lot of the 
discussions around labeled network access controls that we have had on 
the list but I'm going to trim it from this reply to help eliminate 
the "flow" confusion from the rest of the thread.  However, I would 
like to keep discussion the subj/obj issues you talked about as that is 
the reason for my original email.

Currently the SELinux network access controls treats packets as objects 
and I'm in no hurry to change that unless there is a real compelling 
reason.  Keeping that in mind, there is a desire to add packet ingress 
and egress access controls and I'm trying to determine how we want to 
define these two new controls.  The packet ingress control will be 
placed such that _all_ IP traffic entering the system, regardless of 
the destination (local or remote), will be subject to the access check.  
In a similar manner, the packet egress control will be placed such that 
_all_ IP traffic exiting the system, regardless of the source (local or 
remote), will be subject to the access check.  In both cases, there is 
a user desire to have checks between the network interface (netif_t) 
and the packet's peer label (peer_t) as well as between the source 
address (netnode_t) and the packet's peer label (peer_t).

With all this in mind I'm currently leaning towards the following:

 * packet ingress (inbound)

   allow netif_t peer_t:peer ingress;
   allow netnode_t peer_t:peer ingress;

 * packet egress (outbound)

   allow netif_t peer_t:peer egress;
   allow netnode_t peer_t:peer egress;

You'll notice in both cases this continues the packet-as-an-object 
tradition while treating both the network interfaces and nodes as 
subjects.  This seems reasonable to me, but I could be convinced to go 
the other way if that is what everyone else thinks is best (I really 
like the idea of getting all the labeled networking access controls to 
use the "peer" object class).

With (hopefully) a better explanation this time, do you have any further 
thoughts/comments?

-- 
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: Network flow controls and subj/obj ordering

[Paul Moore]

On Tuesday 11 December 2007 3:23:22 pm Christopher J. PeBenito wrote:
> On Tue, 2007-12-11 at 12:02 -0500, Paul Moore wrote:
> > After a discussion with Venkat last week we decided that it was
> > probably best if I took responsibility for the flow control patches
> > and ported/cleaned them up for inclusion in the labeled networking
> > patches for 2.6.25.  In the course of doing so I ran across the
> > problem of subject/object "ordering" (probably not the best term,
> > but it's all I can think of right now).  In both the "flow in" and
> > "flow out" cases I'm tempted to use the packet's peer label as the
> > object just for the sake of consistency and the ability to use the
> > new "peer" object class for all network peer label access checks. 
> > However, I wanted to make sure that is what everyone had in mind
> > from a conceptual point of view. See the two simple policy examples
> > below:
> >
> >  * Packet "flows" into the system, peer label is the object
> >
> >    allow netif_t peerlbl_t:peer flow_in;
> >
> >  * Packet "flows" out of the system, peer label is the object
> >
> >    allow netif_t peerlbl_t:peer flow_out;
>
> Can you give an example for the forwarding case?  Also, how about in
> the non-labeled networking case?

Sorry, I wasn't trying to get into a detailed discussion about the 
policy involved in all this, but I understand it's probably necessary 
to get your head around it so I'll give it a shot.  If you haven't yet, 
go read my reply to Casey first as I'll build upon that here ...

First off, these access checks would only become active if labeled 
networking was "enabled".  This means that either labeled IPsec or 
NetLabel has some configuration loaded.  For labeled IPsec this means 
an entry was created in the SPD or SAD with a SELinux context assigned 
to it.  For NetLabel this means a CIPSO DOI configuration was loaded 
into the kernel.  If labeled networking is not "enabled" then these 
access checks will never happen; this was done to help reduce the 
impact of the network access controls on the common case.

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;

Does this help?

-- 
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: Network flow controls and subj/obj ordering

[Christopher J. PeBenito]

On Wed, 2007-12-12 at 15:18 -0500, Paul Moore wrote:
> On Tuesday 11 December 2007 3:23:22 pm Christopher J. PeBenito wrote:
> > On Tue, 2007-12-11 at 12:02 -0500, Paul Moore wrote:
> > > After a discussion with Venkat last week we decided that it was
> > > probably best if I took responsibility for the flow control patches
> > > and ported/cleaned them up for inclusion in the labeled networking
> > > patches for 2.6.25.  In the course of doing so I ran across the
> > > problem of subject/object "ordering" (probably not the best term,
> > > but it's all I can think of right now).  In both the "flow in" and
> > > "flow out" cases I'm tempted to use the packet's peer label as the
> > > object just for the sake of consistency and the ability to use the
> > > new "peer" object class for all network peer label access checks. 
> > > However, I wanted to make sure that is what everyone had in mind
> > > from a conceptual point of view. See the two simple policy examples
> > > below:
> > >
> > >  * Packet "flows" into the system, peer label is the object
> > >
> > >    allow netif_t peerlbl_t:peer flow_in;
> > >
> > >  * Packet "flows" out of the system, peer label is the object
> > >
> > >    allow netif_t peerlbl_t:peer flow_out;
> >
> > Can you give an example for the forwarding case?  Also, how about in
> > the non-labeled networking case?
> 
> Sorry, I wasn't trying to get into a detailed discussion about the 
> policy involved in all this, but I understand it's probably necessary 
> to get your head around it so I'll give it a shot.  If you haven't yet, 
> go read my reply to Casey first as I'll build upon that here ...

Sure; I find it useful to see the checks in the context of the whole
operation.

> First off, these access checks would only become active if labeled 
> networking was "enabled".  This means that either labeled IPsec or 
> NetLabel has some configuration loaded.  For labeled IPsec this means 
> an entry was created in the SPD or SAD with a SELinux context assigned 
> to it.  For NetLabel this means a CIPSO DOI configuration was loaded 
> into the kernel.  If labeled networking is not "enabled" then these 
> access checks will never happen; this was done to help reduce the 
> impact of the network access controls on the common case.
> 
> 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?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: Network flow controls and subj/obj ordering

[Paul Moore]

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 reason for the network interface, "netif_t", and node, "netnode_t", 
labels is that we want to be able to apply access controls to peer 
labeled network traffic based on the remote host and/or interface.  
Currently we have no way of doing this.

Hopefully this is starting to get a bit more clear 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: Network flow controls and subj/obj ordering

[Christopher J. PeBenito]

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.

So, with compat_net off, you'd still need the above policy, not the
packet type against the peer type?, e.g., not this:

allow ssh_client_packet_t peer_t:peer egress;

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: Network flow controls and subj/obj ordering

[Stephen Smalley]

On Fri, 2007-12-14 at 14:25 -0500, 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.
> 
> So, with compat_net off, you'd still need the above policy, not the
> packet type against the peer type?, e.g., not this:
> 
> allow ssh_client_packet_t peer_t:peer egress;

Correct, not that.  secmark remains a separate and orthogonal mechanism,
with permission checks against the packet class (not the peer class),
and the secmark label is only ever used for its checks.

-- 
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: Network flow controls and subj/obj ordering

[Christopher J. PeBenito]

On Fri, 2007-12-14 at 14:30 -0500, Stephen Smalley wrote:
> On Fri, 2007-12-14 at 14:25 -0500, 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.
> > 
> > So, with compat_net off, you'd still need the above policy, not the
> > packet type against the peer type?, e.g., not this:
> > 
> > allow ssh_client_packet_t peer_t:peer egress;
> 
> Correct, not that.  secmark remains a separate and orthogonal mechanism,
> with permission checks against the packet class (not the peer class),
> and the secmark label is only ever used for its checks.

The thing that confuses me is that I thought secmark was supposed to
replace netif/node for IP traffic.  So using the node/netif labels just
seems wrong to me.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: Network flow controls and subj/obj ordering

[Paul Moore]

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.
>
> So, with compat_net off, you'd still need the above policy, not the
> packet type against the peer type?

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.

Re: Network flow controls and subj/obj ordering

[Stephen Smalley]

On Fri, 2007-12-14 at 14:36 -0500, Christopher J. PeBenito wrote:
> On Fri, 2007-12-14 at 14:30 -0500, Stephen Smalley wrote:
> > On Fri, 2007-12-14 at 14:25 -0500, 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.
> > > 
> > > So, with compat_net off, you'd still need the above policy, not the
> > > packet type against the peer type?, e.g., not this:
> > > 
> > > allow ssh_client_packet_t peer_t:peer egress;
> > 
> > Correct, not that.  secmark remains a separate and orthogonal mechanism,
> > with permission checks against the packet class (not the peer class),
> > and the secmark label is only ever used for its checks.
> 
> The thing that confuses me is that I thought secmark was supposed to
> replace netif/node for IP traffic.  So using the node/netif labels just
> seems wrong to me.

secmark can replace the legacy netif/node checks.  It doesn't provide
the desired functionality for labeled networking.

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