DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

[Venkat Yekkirala]

DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS:

ON INBOUND:

1. PACKETS ENTERING SYSTEM FROM A NON-LOOPBACK DEVICE:

   Can a packet "carrying" external domain label x_t "flow_in" thru the
   security point with the peer domain label p_d_t?

	NOTE:
	a. x_t defaults to unlabeled_t, if no external label.
	b. p_d_t defaults to network_t in the absence of any applicable
	   [conn]secmark rules for the packet. If there are multiple
	   secmark rules applicable to a packet, the context on the LAST
	   rule will apply.

   NO: Drop packet.
   YES: If no external label, let packet "carry" p_d_t.

2. INPUT ONLY: Can a socket "recv" a packet from domain p_d_t?

   NO: Drop packet.
   YES: If setting up a tcp connection, set peer context to p_d_t.

ON OUTBOUND:

1. Let packet "carry" the originating socket domain label.

2. IPSEC Handling:

   LABELED IPSEC: If packet "polmatch"es to an otherwise applicable and
   labeled SPD entry, choose a Security Association (SA) with the SAME context
   as the domain label being carried by packet.
	NOTE: If no such SA present, call into IKE with context on packet.

   NON-LABELED (PLAIN/TRADITIONAL) IPSEC: If there's an applicable SPD entry
   that does NOT have an explicit context associated with it, an applicable SA
   that does NOT have an explicit context associated with it is chosen.
	NOTE: If no such SA present, call into IKE, but with NO context.

3. PACKETS DESTINED FOR NON-LOOPBACK DEVICE:

   a. IPTABLES Processing:
      As EACH applicable iptables [CONN]SECMARK rule with domain p_d_t is
      encountered, do the following:
   
      Can a packet carrying domain label a_t "flow_out" of the security point
      with the domain label p_d_t?
   
         NO: Drop packet.
         YES: Replace the domain label a_t on the packet with the security point
              label p_d_t.

   b. Before a packet is let out of the system:

      Can a packet with domain label p_d_t "flow_out" into the network domain
      network_t?

      NO: Drop packet.
      YES: Let packet out.

      NOTE: Ideally this check should be applicable only to packets that
            didn't go thru [conn]secmark checks for outbound, but there's
            currently no way to know this due to implementation constrains.
            Hence a blanket check for ALL packets leaving the system.


FORWARDED TRAFFIC:

Forwarded Traffic will undergo the following:

1. Step 1 under ON INBOUND.

2. Steps 2 and 3 under ON OUTBOUND.

--
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: DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

[Venkat Yekkirala]

Venkat Yekkirala wrote:
> DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS:
> 
> ON INBOUND:
> 
> 1. PACKETS ENTERING SYSTEM FROM A NON-LOOPBACK DEVICE:
> 
>    Can a packet "carrying" external domain label x_t "flow_in" thru the
>    security point with the peer domain label p_d_t?
> 
> 	NOTE:
> 	a. x_t defaults to unlabeled_t, if no external label.
> 	b. p_d_t defaults to network_t in the absence of any applicable
> 	   [conn]secmark rules for the packet. If there are multiple
> 	   secmark rules applicable to a packet, the context on the LAST
> 	   rule will apply.
> 
>    NO: Drop packet.
>    YES: If no external label, let packet "carry" p_d_t.
> 
> 2. INPUT ONLY: Can a socket "recv" a packet from domain p_d_t?
> 
>    NO: Drop packet.
>    YES: If setting up a tcp connection, set peer context to p_d_t.
> 
> ON OUTBOUND:
> 
> 1. Let packet "carry" the originating socket domain label.
> 
> 2. IPSEC Handling:
> 
>    LABELED IPSEC: If packet "polmatch"es to an otherwise applicable and
>    labeled SPD entry, choose a Security Association (SA) with the SAME context
>    as the domain label being carried by packet.
> 	NOTE: If no such SA present, call into IKE with context on packet.
> 
>    NON-LABELED (PLAIN/TRADITIONAL) IPSEC: If there's an applicable SPD entry
>    that does NOT have an explicit context associated with it, an applicable SA
>    that does NOT have an explicit context associated with it is chosen.
> 	NOTE: If no such SA present, call into IKE, but with NO context.
> 
> 3. PACKETS DESTINED FOR NON-LOOPBACK DEVICE:
> 
>    a. IPTABLES Processing:
>       As EACH applicable iptables [CONN]SECMARK rule with domain p_d_t is
>       encountered, do the following:
>    
>       Can a packet carrying domain label a_t "flow_out" of the security point
>       with the domain label p_d_t?
>    
>          NO: Drop packet.
>          YES: Replace the domain label a_t on the packet with the security point
>               label p_d_t.
> 
>    b. Before a packet is let out of the system:
> 
>       Can a packet with domain label p_d_t "flow_out" into the network domain
>       network_t?
> 
>       NO: Drop packet.
>       YES: Let packet out.
> 
>       NOTE: Ideally this check should be applicable only to packets that
>             didn't go thru [conn]secmark checks for outbound, but there's
>             currently no way to know this due to implementation constrains.
>             Hence a blanket check for ALL packets leaving the system.
> 
> 
> FORWARDED TRAFFIC:
> 
> Forwarded Traffic will undergo the following:
> 
> 1. Step 1 under ON INBOUND.
> 
> 2. Steps 2 and 3 under ON OUTBOUND.
      NOTE: The iptables FORWARD chain is treated as an outbound chain
            for flow control purposes. That means forwarded traffic would
            need to be flow-controlled/labeled when it comes into the system
            using an applicable rule in the PREROUTING chain, and flow-controlled
            before it leaves the system using rules either in the FORWARD chain
            or the POSTROUTING chain.
> 


--
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: DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

[Venkat Yekkirala]

Fixed a bug in the doc to be in line with the current proposed implementation.

Venkat Yekkirala wrote:
> Venkat Yekkirala wrote:
>> DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS:
>>
>> ON INBOUND:
>>
>> 1. PACKETS ENTERING SYSTEM FROM A NON-LOOPBACK DEVICE:
>>
>>    Can a packet "carrying" external domain label x_t "flow_in" thru the
>>    security point with the peer domain label p_d_t?
>>
>> 	NOTE:
>> 	a. x_t defaults to unlabeled_t, if no external label.
>> 	b. p_d_t defaults to network_t in the absence of any applicable
>> 	   [conn]secmark rules for the packet. If there are multiple
>> 	   secmark rules applicable to a packet, the context on the LAST
>> 	   rule will apply.
>>
>>    NO: Drop packet.
>>    YES: If no external label, let packet "carry" p_d_t.

s/p_d_t/p_d_t if it didn't default to network_t/

>>
>> 2. INPUT ONLY: Can a socket "recv" a packet from domain p_d_t?
>>
>>    NO: Drop packet.
>>    YES: If setting up a tcp connection, set peer context to p_d_t.
>>
>> ON OUTBOUND:
>>
>> 1. Let packet "carry" the originating socket domain label.
>>
>> 2. IPSEC Handling:
>>
>>    LABELED IPSEC: If packet "polmatch"es to an otherwise applicable and
>>    labeled SPD entry, choose a Security Association (SA) with the SAME context
>>    as the domain label being carried by packet.
>> 	NOTE: If no such SA present, call into IKE with context on packet.
>>
>>    NON-LABELED (PLAIN/TRADITIONAL) IPSEC: If there's an applicable SPD entry
>>    that does NOT have an explicit context associated with it, an applicable SA
>>    that does NOT have an explicit context associated with it is chosen.
>> 	NOTE: If no such SA present, call into IKE, but with NO context.
>>
>> 3. PACKETS DESTINED FOR NON-LOOPBACK DEVICE:
>>
>>    a. IPTABLES Processing:
>>       As EACH applicable iptables [CONN]SECMARK rule with domain p_d_t is
>>       encountered, do the following:
>>    
>>       Can a packet carrying domain label a_t "flow_out" of the security point
>>       with the domain label p_d_t?
>>    
>>          NO: Drop packet.
>>          YES: Replace the domain label a_t on the packet with the security point
>>               label p_d_t.
>>
>>    b. Before a packet is let out of the system:
>>
>>       Can a packet with domain label p_d_t "flow_out" into the network domain
>>       network_t?
>>
>>       NO: Drop packet.
>>       YES: Let packet out.
>>
>>       NOTE: Ideally this check should be applicable only to packets that
>>             didn't go thru [conn]secmark checks for outbound, but there's
>>             currently no way to know this due to implementation constrains.
>>             Hence a blanket check for ALL packets leaving the system.
>>
>>
>> FORWARDED TRAFFIC:
>>
>> Forwarded Traffic will undergo the following:
>>
>> 1. Step 1 under ON INBOUND.
>>
>> 2. Steps 2 and 3 under ON OUTBOUND.
>       NOTE: The iptables FORWARD chain is treated as an outbound chain
>             for flow control purposes. That means forwarded traffic would
>             need to be flow-controlled/labeled when it comes into the system
>             using an applicable rule in the PREROUTING chain, and flow-controlled
>             before it leaves the system using rules either in the FORWARD chain
>             or the POSTROUTING chain.
> 
> 


--
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: DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

[Christopher J. PeBenito]

So I started testing the labeled networking kernel with no external
labeling and I have some questions.  I removed all packet rules to
observe the behavior of the controls via denials, and this is what I got
on the receive side:

avc:  denied  { flow_in } for  pid=1874 comm="yum-updatesd"
saddr=10.1.13.2 src=55737 daddr=10.1.13.105 dest=22 netif=eth0
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet

avc:  denied  { recv } for  pid=1991 comm="sshd" saddr=10.1.13.2
src=35562 daddr=10.1.13.105 dest=22 netif=eth0
scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet

and to allow this you would need:

allow unlabeled_t ssh_server_packet_t:packet flow_in;
allow unconfined_t ssh_server_packet_t:packet recv;

The first one doesn't make sense to me.  From the docs you said:

On Mon, 2006-10-09 at 07:24 -0500, Venkat Yekkirala wrote:
> 1. PACKETS ENTERING SYSTEM FROM A NON-LOOPBACK DEVICE:
> 
>    Can a packet "carrying" external domain label x_t "flow_in" thru the
>    security point with the peer domain label p_d_t?
> 
> 	NOTE:
> 	a. x_t defaults to unlabeled_t, if no external label.
> 	b. p_d_t defaults to network_t in the absence of any applicable
> 	   [conn]secmark rules for the packet. If there are multiple

Shouldn't the types in a and b above be switched (x_t->network_t,
p_d_t->unlabeled_t)?  In my opinion, network_t would make more sense
than unlabeled_t in the first denial.  Since outbound traffic eventually
flows out to network_t, it would also be more consistent since network_t
would flow in too.

I also can't help but feel the flow_in check is backwards.  If you
consider the phrase "flow in from" it makes more sense:
ssh_server_packet_t flow_in from unlabeled_t association.  In some sense
the association is a container of packets, so what I'm saying also makes
sense; consider file types associating to filesystem types:

allow file_t fs_t:filesystem associate;

This case is far clearer since there is no to/from words that cause
confusion, but the container is the object here (fs_t).

So if we start out with a receive that has no secmark or external label,
the current policy would be:

allow unlabeled_t network_t:packet flow_in;
allow unconfined_t network_t:packet recv;

If you swap the types, and then swap the perspective of the flow_in, you
get:

allow unlabeled_t network_t:packet flow_in;
allow unconfined_t unlabeled_t:packet recv;

And finally, perhaps we should replace the recv check with a flow_in
check?  It would make the checks similar to the send, since the packet
send permission was replaced with flow_out.

With these tweaks, the policy unconfined_t sending and receiving packets
with no secmark nor external label:

allow unlabeled_t network_t:packet flow_in;
allow unconfined_t network_t:packet recv;
allow unconfined_t unlabeled_t:packet flow_out;
allow unlabeled_t network_t:packet flow_out;

turns into:

allow unlabeled_t network_t:packet flow_in;
allow unconfined_t unlabeled_t:packet flow_in;
allow unconfined_t unlabeled_t:packet flow_out;
allow unlabeled_t network_t:packet flow_out;

which seems more correct to me and is clearer and more consistent.

-- 
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: DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

[Venkat Yekkirala]

> > 1. PACKETS ENTERING SYSTEM FROM A NON-LOOPBACK DEVICE:
> >
> >    Can a packet "carrying" external domain label x_t
> "flow_in" thru the
> >    security point with the peer domain label p_d_t?
> >
> > 	NOTE:
> > 	a. x_t defaults to unlabeled_t, if no external label.
> > 	b. p_d_t defaults to network_t in the absence of any applicable
> > 	   [conn]secmark rules for the packet. If there are multiple
>

There are really two "classes" of labels we are dealing with here:
1. security point domains including the all-encompassing security point
   represented by network_t.

2. external labels being carried by packets as they attempt to flow in.

In that sense, the label on the packet should aptly be deemed unlabeled_t
when
there's no label it comes in with.

> Shouldn't the types in a and b above be switched (x_t->network_t,
> p_d_t->unlabeled_t)?
>  In my opinion, network_t would make more sense
> than unlabeled_t in the first denial.  Since outbound traffic
> eventually
> flows out to network_t, it would also be more consistent
> since network_t
> would flow in too.

But not as the source. It's used as the target in the flow_out case
and so we should use it as the target in the flow_in case as well (which
also means we couldn't do p_d_t->unlabeled_t as you ask above).

>
> I also can't help but feel the flow_in check is backwards.  If you
> consider the phrase "flow in from" it makes more sense:
> ssh_server_packet_t flow_in from unlabeled_t association.

You have it backwards though:). It should be read as:

unlabeled_t domain flow_in thru the security point labeled "ssh_client_t".

ssh_client_t or such instead of ssh_server_packet_t since the idea is to
represent the "communication peer".

The naming time and again is throwing us off here. I will at least try
to get the packet class replaced with a "secpoint" class. So
your rule would read:

allow unlabeled_t sp_ssh_client_t:secpoint { flow_in };

Would that be any better?

>  In
> some sense
> the association is a container of packets, so what I'm saying
> also makes
> sense; consider file types associating to filesystem types:
>
> allow file_t fs_t:filesystem associate;
>
> This case is far clearer since there is no to/from words that cause
> confusion, but the container is the object here (fs_t).

But in our case, we happen to have 2 sub-containers within the whole
"communication peers" container:

1. A sub-container of all external domains.
2. A sub-container of security point domains.

and neither of them mixes with the other (at least in the inbound case).

>
> So if we start out with a receive that has no secmark or
> external label,
> the current policy would be:
>
> allow unlabeled_t network_t:packet flow_in;
> allow unconfined_t network_t:packet recv;

actually allow unconfined_t unlabeled_t:packet recv;
(I just posted a fix to a bug in the doc as you may have noticed).

>
> If you swap the types, and then swap the perspective of the
> flow_in, you
> get:
>
> allow unlabeled_t network_t:packet flow_in;

same as before.

> allow unconfined_t unlabeled_t:packet recv;
>

which is in fact what you should already be seeing.

> And finally, perhaps we should replace the recv check with a flow_in
> check?  It would make the checks similar to the send, since the packet
> send permission was replaced with flow_out.

A socket is a "container" in this case (since it's essentially receiving
the packets) whereas the others are like gates. Also having as many distinct
labels for perms as possible might help in better readability of the logs
right?

>
> With these tweaks, the policy unconfined_t sending and
> receiving packets
> with no secmark nor external label:
>
> allow unlabeled_t network_t:packet flow_in;
> allow unconfined_t network_t:packet recv;

actually: allow unconfined_t unlabeled_t:packet recv;
(as corrected before as well; had a bug in the doc)

> allow unconfined_t unlabeled_t:packet flow_out;

No such check since there are no secpoints defined. Just
the check against network_t as the next one shows.

> allow unlabeled_t network_t:packet flow_out;
>
> turns into:
>
> allow unlabeled_t network_t:packet flow_in;

as it happens currently.

> allow unconfined_t unlabeled_t:packet flow_in;

as it happens currently.

> allow unconfined_t unlabeled_t:packet flow_out;

Not needed since we have a check against network_t
as mentioned next.

> allow unlabeled_t network_t:packet flow_out;
>
> which seems more correct to me and is clearer and more consistent.

which, after all said and done is what in fact is (should be) happening.

But the fights in the earlier part still hold true, which makes me wonder
where did you/I get off the track?


--
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: DOCUMENTATION OF SECID RECONCILIATION AND FLOW CONTROL FOR POLICY WRITERS

[Venkat Yekkirala]

> > turns into:
> > 
> > allow unlabeled_t network_t:packet flow_in;
> 
> as it happens currently.
> 
> > allow unconfined_t unlabeled_t:packet flow_in;
> 
> as it happens currently.

Well, as: allow unconfined_t unlabeled_t:packet recv;

> 
> > allow unconfined_t unlabeled_t:packet flow_out;
> 
> Not needed since we have a check against network_t
> as mentioned next.
> 
> > allow unlabeled_t network_t:packet flow_out;
> > 
> > which seems more correct to me and is clearer and more consistent.
> 
> which, after all said and done is what in fact is (should be) 
> happening.
> 
> But the fights in the earlier part still hold true, which 
> makes me wonder
> where did you/I get off the track?
> 

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