RE: SELinux Networking Enhancements

RE: SELinux Networking Enhancements

[Venkat Yekkirala]

 

-----Original Message-----
From: James Morris
To: Venkat Yekkirala
Cc: jbrindle@tresys.com; selinux@tycho.nsa.gov; sds@tycho.nsa.gov
Sent: 10/19/2006 5:27 PM
Subject: RE: SELinux Networking Enhancements

On Thu, 19 Oct 2006, Venkat Yekkirala wrote:

> You would have just as many "secpoints" as you currently
> would "secmarks". No difference there. Same level of flexibility
> and scalability. Nothing more, nothing less.
> 
> Example:
> 
> 1. An outbound connection to port 80 on machine 10.0.0.1
> 
> SECMARK:
> -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:http_client_packet_t:s2
> 
> SECPOINT:
> -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:httpd_t:s0
> 
> Reason for the change in Type from http_client_packet_t to httpd_t:
> 
> All incoming packets on this connection would be from a web-server so
should
> be carrying httpd_t as opposed to http_client_packet_t. Also, all
outbound
> traffic on this connection carries the originating socket context
> (firefox_t)
> which would be flow-controlled against httpd_t.
> 
> So, just a change in semantics. Whereas you formerly had
> allow firefox_t http_client_packet_t:packet { send recv }
> 
> you would now have:
> 
> allow firefox_t httpd_t:packet { recv }
> allow firefox_t httpd_t:packet { flow_out }
> 
> For the forwarding case:
> 
> -A PREROUTING -p tcp -s 10.0.0.5  -j SECMARK --selctx
> system_u:object_r:webonly_t:s0
> 
> -A FORWARD -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:httpd_t:s0
> -A PREROUTING -p tcp -s 10.0.0.1 --sport 80 -j SECMARK --selctx
> system_u:object_r:httpd_t:s0
> (can also use CONNSECMARK to save from FORWARD and restore it at
PREROUTING
> to label all traffic back from
> the webserver)
> 
> allow webonly_t httpd_t:packet { flow_out }
> allow httpd_t webonly_t:packet { flow_out }
> 
> I have only given the main rules and there are ofcourse other
supporting
> rules required
> to get things going.

This is too complicated, most people will not understand it.  I think
it's 
also a security risk, because of the complexity of composing these 
labeling mechanisms and the chance that mistakes will be made in 
deployment, as well as scaring people away from using the technology 
altogether.

Venkat's response:
Hi James, can you please tell me exactly what rules (and only those)
that one should be able to specify in the forwarding case in the
following example:

I have a machine 192.168.16.10 that needs to be able to do web-browsing
only, via the router.

Thanks.

Thanks.

--
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: SELinux Networking Enhancements

[James Morris]

On Fri, 20 Oct 2006, Venkat Yekkirala wrote:

> Venkat's response:
> Hi James, can you please tell me exactly what rules (and only those)
> that one should be able to specify in the forwarding case in the
> following example:
> 
> I have a machine 192.168.16.10 that needs to be able to do web-browsing
> only, via the router.

You mean rules on thr router to to enforce MAC between two other systems?

I think this is currently out of scope.


-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > Hi James, can you please tell me exactly what rules (and only those)
> > that one should be able to specify in the forwarding case in the
> > following example:
> > 
> > I have a machine 192.168.16.10 that needs to be able to do
> web-browsing
> > only, via the router.
> 
> You mean rules on thr router to to enforce MAC between two other
> systems?
> 
> I think this is currently out of scope.

Yes. Currently you can't do it. But I would like to get ideas on
a "less confusing" way to do forwarding controls. Specifically,
what would be an ideal allow-rule-set look like for forwarding
controls?

--
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: SELinux Networking Enhancements

[James Morris]

On Mon, 23 Oct 2006, Venkat Yekkirala wrote:

> Yes. Currently you can't do it. But I would like to get ideas on
> a "less confusing" way to do forwarding controls. Specifically,
> what would be an ideal allow-rule-set look like for forwarding
> controls?

I really don't know at this stage.  It seems like a generally complex 
problem which needs a comprehensive solution itself, assuming it's worth 
solving, and I don't believe we need to wait for that to implement 
protected paths for host to host networking.



-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > Yes. Currently you can't do it. But I would like to get ideas on
> > a "less confusing" way to do forwarding controls. Specifically,
> > what would be an ideal allow-rule-set look like for forwarding
> > controls?
> 
> I really don't know at this stage.  It seems like a generally complex 
> problem which needs a comprehensive solution itself, assuming 
> it's worth 
> solving,

We have needs for forwarding controls now.

> and I don't believe we need to wait for that to implement 
> protected paths for host to host networking.

Can you please lay out the kind of controls you have in mind
for "protected paths for host to host networking". I want to
see what (modified) portions I can present for upstreaming.

For the rest, I guess we will have to just patch our kernel.

--
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: SELinux Networking Enhancements

[James Morris]

On Tue, 24 Oct 2006, Venkat Yekkirala wrote:

> > I really don't know at this stage.  It seems like a generally complex 
> > problem which needs a comprehensive solution itself, assuming 
> > it's worth 
> > solving,
> 
> We have needs for forwarding controls now.

I know -- but the forwarding in this case is limited to a specific case, 
and it's not clear how generally useful this is, and what needs to be done 
for the general case.  Its presence also appears to add significant 
complexity which impacts on the common case.

> > and I don't believe we need to wait for that to implement protected 
> > paths for host to host networking.
> 
> Can you please lay out the kind of controls you have in mind
> for "protected paths for host to host networking". I want to
> see what (modified) portions I can present for upstreaming.

Let's start with the common case for non-MLS general use scenarios, then
once we have that nailed down, look at what else is needed to meaningfully
support MLS (and possibly concurrent CIPSO).

What are we currently missing, in terms of being able to label SAs, 
authorize their use, enforce flow policy, and allow applications to 
determine peer labels ?

For flow enforcement, I would like to see this done as simply as possible.  
e.g.:

# Server policy
allow httpd_server_t httpd_client_t:peer { recv send };

# Client policy
allow httpd_client_t httpd_server_t:peer { recv send };




- James
-- 
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: James Morris [mailto:jmorris@namei.org] 
> 
> On Tue, 24 Oct 2006, Venkat Yekkirala wrote:
>  
> Let's start with the common case for non-MLS general use 
> scenarios, then once we have that nailed down, look at what 
> else is needed to meaningfully support MLS (and possibly 
> concurrent CIPSO).
> 
> What are we currently missing, in terms of being able to 
> label SAs, authorize their use, enforce flow policy, and 
> allow applications to determine peer labels ?
> 
> For flow enforcement, I would like to see this done as simply 
> as possible.  
> e.g.:
> 
> # Server policy
> allow httpd_server_t httpd_client_t:peer { recv send };
> 
> # Client policy
> allow httpd_client_t httpd_server_t:peer { recv send };
> 

I don't think this is enough. For end-to-end control via MAC we need to
bind domain to socket (already done), socket to SA, SA to peer, peer to
SA, SA to socket, and socket to domain. The way to do this "simply" is
unclear but I think the common case for using labeled IPSec will be to
get end to end control (else why is it useful?)


--
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: SELinux Networking Enhancements

[James Morris]

On Mon, 30 Oct 2006, Joshua Brindle wrote:

> I don't think this is enough. For end-to-end control via MAC we need to
> bind domain to socket (already done), socket to SA, SA to peer, peer to
> SA, SA to socket, and socket to domain. The way to do this "simply" is
> unclear but I think the common case for using labeled IPSec will be to
> get end to end control (else why is it useful?)

I think this can be managed via IPsec policy, where the admin binds the SA 
to the peer with SPD/SADB rules so that the SA label is the same as the 
process label.


-- 
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: James Morris [mailto:jmorris@namei.org] 
> 
> On Mon, 30 Oct 2006, Joshua Brindle wrote:
> 
> > I don't think this is enough. For end-to-end control via 
> MAC we need 
> > to bind domain to socket (already done), socket to SA, SA to peer, 
> > peer to SA, SA to socket, and socket to domain. The way to do this 
> > "simply" is unclear but I think the common case for using labeled 
> > IPSec will be to get end to end control (else why is it useful?)
> 
> I think this can be managed via IPsec policy, where the admin 
> binds the SA to the peer with SPD/SADB rules so that the SA 
> label is the same as the process label.
> 

AH! No, it needs to be MAC, not MAC + SPD.


--
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: SELinux Networking Enhancements

[James Morris]

On Mon, 30 Oct 2006, Joshua Brindle wrote:

> > From: James Morris [mailto:jmorris@namei.org] 
> > 
> > On Mon, 30 Oct 2006, Joshua Brindle wrote:
> > 
> > > I don't think this is enough. For end-to-end control via 
> > MAC we need 
> > > to bind domain to socket (already done), socket to SA, SA to peer, 
> > > peer to SA, SA to socket, and socket to domain. The way to do this 
> > > "simply" is unclear but I think the common case for using labeled 
> > > IPSec will be to get end to end control (else why is it useful?)
> > 
> > I think this can be managed via IPsec policy, where the admin 
> > binds the SA to the peer with SPD/SADB rules so that the SA 
> > label is the same as the process label.
> > 
> 
> AH! No, it needs to be MAC, not MAC + SPD.

SPD becomes part of the MAC labeling infrastructure, like the SECMARK 
target.


- James
-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > > and I don't believe we need to wait for that to implement 
> protected 
> > > paths for host to host networking.
> > 
> > Can you please lay out the kind of controls you have in mind
> > for "protected paths for host to host networking". I want to
> > see what (modified) portions I can present for upstreaming.
> 
> Let's start with the common case for non-MLS general use 
> scenarios, then
> once we have that nailed down, look at what else is needed to 
> meaningfully
> support MLS (and possibly concurrent CIPSO).
> 
> What are we currently missing, in terms of being able to label SAs, 
> authorize their use, enforce flow policy, and allow applications to 
> determine peer labels ?
> 
> For flow enforcement, I would like to see this done as simply 
> as possible.  
> e.g.:
> 
> # Server policy
> allow httpd_server_t httpd_client_t:peer { recv send };

This is already effectively covered in the following checks:

allow httpd_server_t httpd_client_t:association { recvfrom };

allow httpd_server_t http_client_packet_t:packet { send };

> 
> # Client policy
> allow httpd_client_t httpd_server_t:peer { recv send };
> 

In the "peer" abstraction above, the problem is how would we define a
peer? A "peer" is only available when you receive something. A peer
isn't available currently when you are sending to the peer. We can't
use SAs for this purpose since an SA is a unidirectional thing. The
now-dead secpoint attempted to define peer secpoints.

There's the main issue of what "peers" (external labels) can enter
the system.

Implementation issues aside, lately I have been wondering about doing
something in the filter table using something we could call secfilter
or so.

You would still use secmark to label the packets, but they (along with
any external labels) could get filtered in the secfilter module. This
way we could control what external labels could come thru from what peers.
For internal labels it would be more of an assurance thing. This would also
automatically take care of forwarding controls.

--
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: SELinux Networking Enhancements

[James Morris]

On Tue, 31 Oct 2006, Venkat Yekkirala wrote:

> Implementation issues aside, lately I have been wondering about doing
> something in the filter table using something we could call secfilter
> or so.
> 
> You would still use secmark to label the packets, but they (along with
> any external labels) could get filtered in the secfilter module. This
> way we could control what external labels could come thru from what peers.
> For internal labels it would be more of an assurance thing. This would also
> automatically take care of forwarding controls.

Ok, so, there'd be an iptables match which looked up the security context 
on the SA the packet arrives/departs on?  Sounds like it could work.  
Perhaps call it xfrmlabel ?



- James
-- 
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: SELinux Networking Enhancements

[Paul Moore]

James Morris wrote:
> On Tue, 31 Oct 2006, Venkat Yekkirala wrote:
> 
>>Implementation issues aside, lately I have been wondering about doing
>>something in the filter table using something we could call secfilter
>>or so.
>>
>>You would still use secmark to label the packets, but they (along with
>>any external labels) could get filtered in the secfilter module. This
>>way we could control what external labels could come thru from what peers.
>>For internal labels it would be more of an assurance thing. This would also
>>automatically take care of forwarding controls.
> 
> Ok, so, there'd be an iptables match which looked up the security context 
> on the SA the packet arrives/departs on?  Sounds like it could work.  
> Perhaps call it xfrmlabel ?

What we name it probably isn't that important, but I sorta prefer Venkat's
original suggestion of secfilter (or secidfilter, or <generic security
token>filter) since it sounds like this new component would be strictly for
filtering and not labeling.

-- 
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: SELinux Networking Enhancements

[James Morris]

On Wed, 1 Nov 2006, Paul Moore wrote:

> > Ok, so, there'd be an iptables match which looked up the security context 
> > on the SA the packet arrives/departs on?  Sounds like it could work.  
> > Perhaps call it xfrmlabel ?
> 
> What we name it probably isn't that important, but I sorta prefer Venkat's
> original suggestion of secfilter (or secidfilter, or <generic security
> token>filter) since it sounds like this new component would be strictly for
> filtering and not labeling.

Well, it's matching labels on xfrms.  The filtering concept is implicit in 
it being an iptables match, and secid/sec is vague.



-- 
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: SELinux Networking Enhancements

[Paul Moore]

James Morris wrote:
> On Wed, 1 Nov 2006, Paul Moore wrote:
> 
>>>Ok, so, there'd be an iptables match which looked up the security context 
>>>on the SA the packet arrives/departs on?  Sounds like it could work.  
>>>Perhaps call it xfrmlabel ?
>>
>>What we name it probably isn't that important, but I sorta prefer Venkat's
>>original suggestion of secfilter (or secidfilter, or <generic security
>>token>filter) since it sounds like this new component would be strictly for
>>filtering and not labeling.
> 
> Well, it's matching labels on xfrms.  The filtering concept is implicit in 
> it being an iptables match, and secid/sec is vague.

I got the impression that Venkat was intending this to work for external labels
(both XFRM and NetLabel) as well as internal labels (SECMARK).  I would be a lot
happier if the name didn't limit it to just XFRM labeling.

-- 
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: SELinux Networking Enhancements

[James Morris]

On Wed, 1 Nov 2006, Paul Moore wrote:

> I got the impression that Venkat was intending this to work for external labels
> (both XFRM and NetLabel) as well as internal labels (SECMARK).  I would be a lot
> happier if the name didn't limit it to just XFRM labeling.

If you want a secmark match, make it a separate module.


-- 
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: SELinux Networking Enhancements

[Paul Moore]

James Morris wrote:
> On Wed, 1 Nov 2006, Paul Moore wrote:
>  
>>I got the impression that Venkat was intending this to work for external labels
>>(both XFRM and NetLabel) as well as internal labels (SECMARK).  I would be a lot
>>happier if the name didn't limit it to just XFRM labeling.
> 
> If you want a secmark match, make it a separate module.

Okay, the argument about multiple external labeling mechanisms still applies.

-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> On Wed, 1 Nov 2006, Paul Moore wrote:
>
> > > Ok, so, there'd be an iptables match which looked up the
> security context
> > > on the SA the packet arrives/departs on?  Sounds like it
> could work.
> > > Perhaps call it xfrmlabel ?
> >
> > What we name it probably isn't that important, but I sorta
> prefer Venkat's
> > original suggestion of secfilter (or secidfilter, or
> <generic security
> > token>filter) since it sounds like this new component would
> be strictly for
> > filtering and not labeling.
>
> Well, it's matching labels on xfrms.  The filtering concept
> is implicit in
> it being an iptables match, and secid/sec is vague.

Actually I meant for the filtering to be explicit as in the following
example:

Label filter points:

iptables -t filter -A INPUT -s client1 -j SECFILTER --selctx
"system_u:object_r:client1_t:s4-s5"
iptables -t filter -A OUTPUT -s client1 -j SECFILTER --selctx
"system_u:object_r:client1_t:s4-s5"

Policy rules:

allow mozilla_t client1_t:secfilter { flow_in };
allow apache_t client1_t:secfilter { flow_out };

If you are also using secmark:

Labeling:
<Normal secmark rules to mark http_server_packet_t and dns_client_packet_t>

Additional Policy rules:
allow http_server_packet_t client1_t:secfilter { flow_in flow_out };
allow dns_client_packet_t dns_server_t:secfilter { flow_in flow_out };

You could just as easily define rules for forwarded traffic.

This essentially parallels secmark from an implementation standpoint,
only here we are labeling filter points while still enforcing in the
SELinux module/policy.


--
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: SELinux Networking Enhancements

[Paul Moore]

>>Well, it's matching labels on xfrms.  The filtering concept
>>is implicit in
>>it being an iptables match, and secid/sec is vague.
> 
> Actually I meant for the filtering to be explicit as in the following
> example:
> 
> Label filter points:
> 
> iptables -t filter -A INPUT -s client1 -j SECFILTER --selctx
> "system_u:object_r:client1_t:s4-s5"
> iptables -t filter -A OUTPUT -s client1 -j SECFILTER --selctx
> "system_u:object_r:client1_t:s4-s5"
> 
> Policy rules:
> 
> allow mozilla_t client1_t:secfilter { flow_in };
> allow apache_t client1_t:secfilter { flow_out };

Am I correct is stating that this is basically your "secpoint" idea with the
following changes:

1. The "secpoint" is no longer the skb->secmark field but rather the context
specified in the iptables command (using the 'selctx' option) above.
2. There is no longer a need to override/overload/etc. the skb->secmark context.

Yes?

> If you are also using secmark:
> 
> Labeling:
> <Normal secmark rules to mark http_server_packet_t and dns_client_packet_t>
> 
> Additional Policy rules:
> allow http_server_packet_t client1_t:secfilter { flow_in flow_out };
> allow dns_client_packet_t dns_server_t:secfilter { flow_in flow_out };

In order to simplify things a bit I wonder if it would be best to hash out the
"secfilter" concept using external labels at first, and then add internal labels
later.  I understand the desire to have the same/similar access controls for
both external and internal labels but I think a smaller, more iterative approach
might be a little easier to get understood and accepted.  Plus, as you stated
earlier, using 'secfilter' with 'secmark' really only adds to your assurance
level; equivalent access controls already exist for internal labeling.

> You could just as easily define rules for forwarded traffic.

Can you help me understand the forwarding case as you envision it (using
external labeling)?  The things I am interested in are:

1. What would the policy look like?
2. Where would the access control points be in the code?
3. Does this require segmenting the skb->secmark field?
4. What would the iptables command(s) look like?

-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> Am I correct is stating that this is basically your 
> "secpoint" idea with the
> following changes:
> 
> 1. The "secpoint" is no longer the skb->secmark field but 
> rather the context
> specified in the iptables command (using the 'selctx' option) above.

Correct. This aims to solve the same flow control issues that
secpoint tried to solve but leaving secmark alone as purely a
marking facility.

> 2. There is no longer a need to override/overload/etc. the 
> skb->secmark context.
> 
> Yes?

No overriding per se. I can't really say anything about overloading
since I haven't really thought about the implementation details yet.

Secmark will retain its current behavior (packets marked with Type in
secmark and independently access-controlled at the socket level like it
is currently). Only additional filtering at the network level.

The attempt here is to approach things from top to bottom this time, so
we need to first agree on things at the user level and then we can think
about specific implementation details.

> 
> > If you are also using secmark:
> > 
> > Labeling:
> > <Normal secmark rules to mark http_server_packet_t and 
> dns_client_packet_t>
> > 
> > Additional Policy rules:
> > allow http_server_packet_t client1_t:secfilter { flow_in flow_out };
> > allow dns_client_packet_t dns_server_t:secfilter { flow_in 
> flow_out };
> 
> In order to simplify things a bit I wonder if it would be 
> best to hash out the
> "secfilter" concept using external labels at first,

We wouldn't want to do that for the simple reason that we wan't a
comprehensive set of controls that would also work for forwarded
traffic and for this, we would need to subject secmark also to the
secfilter controls.

> and then 
> add internal labels
> later.  I understand the desire to have the same/similar 
> access controls for
> both external and internal labels but I think a smaller, more 
> iterative approach
> might be a little easier to get understood and accepted.  
> Plus, as you stated
> earlier, using 'secfilter' with 'secmark' really only adds to 
> your assurance
> level

more for the locally generated/destined traffic, but for forwarded
traffic this is a necessity.

>; equivalent access controls already exist for internal labeling.
> 
> > You could just as easily define rules for forwarded traffic.
> 
> Can you help me understand the forwarding case as you 
> envision it (using
> external labeling)?  The things I am interested in are:
> 
> 1. What would the policy look like?

Let's say you secmark a packet coming from a certain host with
webonly_packet_t.

You could have a filter point defined as:

iptables -t filter -A FORWARD -d webserver -dport 80 -j SECFILTER --selctx
"system_u:object_r:webserver_t:s4-s5"

Your policy could say:

allow webonly_t webserver_t:secfilter { flow_out }

> 2. Where would the access control points be in the code?
> 3. Does this require segmenting the skb->secmark field?

Implementation specifics ...

> 4. What would the iptables command(s) look like?

--
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: SELinux Networking Enhancements

[Paul Moore]

Venkat Yekkirala wrote:
> The attempt here is to approach things from top to bottom this time, so
> we need to first agree on things at the user level and then we can think
> about specific implementation details.

That sounds fine.  We can put the implementation discussion off for a bit, but I
think it would be a good idea to have an implementation discussion before
churning out the patches (I'm old fashioned that way).

Also, on an unrelated topic - what email address should we use when trying to
reach you?  I've noticed that for the last couple weeks you have been using two
different addresses ...

-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > The attempt here is to approach things from top to bottom 
> this time, so
> > we need to first agree on things at the user level and then 
> we can think
> > about specific implementation details.
> 
> That sounds fine.  We can put the implementation discussion 
> off for a bit, but I
> think it would be a good idea
> to have an implementation 
> discussion before
> churning out the patches (I'm old fashioned that way).

Not just a good idea. That's how things ought to be.

> 
> Also, on an unrelated topic - what email address should we 
> use when trying to
> reach you?  I've noticed that for the last couple weeks you 
> have been using two
> different addresses ...

I wonder how it happened. It should be: vyekkirala@TrustedCS.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: SELinux Networking Enhancements

[James Morris]

On Thu, 2 Nov 2006, Venkat Yekkirala wrote:

> > 1. What would the policy look like?
> 
> Let's say you secmark a packet coming from a certain host with
> webonly_packet_t.
> 
> You could have a filter point defined as:
> 
> iptables -t filter -A FORWARD -d webserver -dport 80 -j SECFILTER --selctx
> "system_u:object_r:webserver_t:s4-s5"
> 
> Your policy could say:
> 
> allow webonly_t webserver_t:secfilter { flow_out }

Is this contstruct needed for anything other than the forwarding case?  
If not, why don't we solve it specifically for that case?



- James
-- 
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: SELinux Networking Enhancements

[James Morris]

On Thu, 2 Nov 2006, James Morris wrote:

> On Thu, 2 Nov 2006, Venkat Yekkirala wrote:
> 
> > > 1. What would the policy look like?
> > 
> > Let's say you secmark a packet coming from a certain host with
> > webonly_packet_t.
> > 
> > You could have a filter point defined as:
> > 
> > iptables -t filter -A FORWARD -d webserver -dport 80 -j SECFILTER --selctx
> > "system_u:object_r:webserver_t:s4-s5"
> > 
> > Your policy could say:
> > 
> > allow webonly_t webserver_t:secfilter { flow_out }
> 
> Is this contstruct needed for anything other than the forwarding case?  

In fact, this appears to be entirely indepdent to xfrm labeling...



-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > > Let's say you secmark a packet coming from a certain host with
> > > webonly_packet_t.
> > >
> > > You could have a filter point defined as:
> > >
> > > iptables -t filter -A FORWARD -d webserver -dport 80 -j
> SECFILTER --selctx
> > > "system_u:object_r:webserver_t:s4-s5"
> > >
> > > Your policy could say:
> > >
> > > allow webonly_t webserver_t:secfilter { flow_out }
> >
> > Is this contstruct needed for anything other than the
> forwarding case?

One could certainly find uses for it in the non-forwarding case as
well. e.g.:

secmark all incoming packets destined for port 80 with http_server_packet_t
regardless of source.

Define a filter point with all incoming from interface eth1 with eth1_t (or
a group of clients or whatever).

allow http_server_packet_t eth1_t:secfilter { flow_in };

Essentially, the flexibility offered by an additional layer of indirection.

>
> In fact, this appears to be entirely indepdent to xfrm labeling...

Correct. This is really labeling-mechanism-agnostic in that it filters
all.


--
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: SELinux Networking Enhancements

[James Morris]

On Thu, 2 Nov 2006, Venkat Yekkirala wrote:

> Define a filter point with all incoming from interface eth1 with eth1_t (or
> a group of clients or whatever).
> 
> allow http_server_packet_t eth1_t:secfilter { flow_in };
> 
> Essentially, the flexibility offered by an additional layer of indirection.

I think what we'd really want in a case like this is to just use secmark, 
and create new compound types for labeling packets (which is part of the 
idea of the design).

So, eth1 is thought of as "internal", and you use iptables to label 
packets with --dport 80 and -i eth1 as httpd_internal_t.

> > In fact, this appears to be entirely indepdent to xfrm labeling...
> 
> Correct. This is really labeling-mechanism-agnostic in that it filters
> all.

Then I'm not sure I understand why it's part of a discussion about 
protected path labeling.


- James
-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> I think what we'd really want in a case like this is to just 
> use secmark, 
> and create new compound types for labeling packets (which is 
> part of the 
> idea of the design).
> 
> So, eth1 is thought of as "internal", and you use iptables to label 
> packets with --dport 80 and -i eth1 as httpd_internal_t.

Yes, but where such compounding is not desired, one could simply
identify all httpd packets as of Type httpd_t and go from there.

This essentially could result in a more readable policy where you
worry strictly about packet Types with secmark and express whether
you expect those Types from a certain source using secfilter.

> 
> > > In fact, this appears to be entirely indepdent to xfrm labeling...
> > 
> > Correct. This is really labeling-mechanism-agnostic in that 
> it filters
> > all.
> 
> Then I'm not sure I understand why it's part of a discussion about 
> protected path labeling.

Only the nature of the protected paths proposed here is generic
enough that it could cover all sorts of labeling.

--
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
> 

> > Can you help me understand the forwarding case as you envision it 
> > (using external labeling)?  The things I am interested in are:
> > 
> > 1. What would the policy look like?
> 
> Let's say you secmark a packet coming from a certain host 
> with webonly_packet_t.
> 
> You could have a filter point defined as:
> 
> iptables -t filter -A FORWARD -d webserver -dport 80 -j 
> SECFILTER --selctx "system_u:object_r:webserver_t:s4-s5"
> 
> Your policy could say:
> 
> allow webonly_t webserver_t:secfilter { flow_out }

Ok, I don't think I understand. Are you using the filter table to
relabel a packet? What is the subject here? 

If this is indeed relabeling (which it appears to be from here) then
there should be a relabel permission, shouldn't it also be in the
FORWARD mangle table instead of filter? How is it different from secmark
at all? (eg., why not just have a secmark rule in the mangle table that
relabels its secmark for doing forward access control?)


--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > Let's say you secmark a packet coming from a certain host
> > with webonly_packet_t.
> >
> > You could have a filter point defined as:
> >
> > iptables -t filter -A FORWARD -d webserver -dport 80 -j
> > SECFILTER --selctx "system_u:object_r:webserver_t:s4-s5"
> >
> > Your policy could say:
> >
> > allow webonly_t webserver_t:secfilter { flow_out }
>
> Ok, I don't think I understand. Are you using the filter table to
> relabel a packet?

No. I am using the FILTER table to FILTER a packet.

> What is the subject here?

The subject is the secmark/external label and the target is the filter point
label.

>
> If this is indeed relabeling (which it appears to be from here) then
> there should be a relabel permission, shouldn't it also be in the
> FORWARD mangle table instead of filter? How is it different
> from secmark
> at all?

secmark to mark the packets and secfilter to filter them at the system
level (in addition to socket).

> (eg., why not just have a secmark rule in the mangle
> table that
> relabels its secmark for doing forward access control?)
>


--
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
> 
> > > Let's say you secmark a packet coming from a certain host with 
> > > webonly_packet_t.
> > >
> > > You could have a filter point defined as:
> > >
> > > iptables -t filter -A FORWARD -d webserver -dport 80 -j SECFILTER 
> > > --selctx "system_u:object_r:webserver_t:s4-s5"
> > >
> > > Your policy could say:
> > >
> > > allow webonly_t webserver_t:secfilter { flow_out }
> >
> > Ok, I don't think I understand. Are you using the filter table to 
> > relabel a packet?
> 
> No. I am using the FILTER table to FILTER a packet.
> 

Ok, I think I'm beginning to get it (I'm a bit slow lately :\).. You are
defining a condition where iptables will call into the security server
using the packet label (either secmark or external, how do you decide?)
and some abstract object to see if it should drop (or is it reject? Can
you choose?). 

It is interesting, I'm a little dubious, iptables basically becomes an
object manager and uses iptables rules to determine whether or not to
call into the security server, which isn't inappropriate, per se. The
iptables filter rules must be included as part of the policy or the
expected filtering would occur, the same is true for secmark though. The
difference is that secmark is labeling packets and if the labels aren't
in place a restrictive policy will drop them. With these filter rules if
they aren't in place the policy becomes less restrictive (right?)..

> > What is the subject here?
> 
> The subject is the secmark/external label and the target is 
> the filter point label.
> 
> >
> > If this is indeed relabeling (which it appears to be from 
> here) then 
> > there should be a relabel permission, shouldn't it also be in the 
> > FORWARD mangle table instead of filter? How is it different from 
> > secmark at all?
> 
> secmark to mark the packets and secfilter to filter them at 
> the system level (in addition to socket).
> 

gotcha


--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > No. I am using the FILTER table to FILTER a packet.
> > 
> 
> Ok, I think I'm beginning to get it (I'm a bit slow lately 
> :\).. You are
> defining a condition where iptables will call into the security server

Correct.

> using the packet label (either secmark or external, how do 
> you decide?)

Both.

> and some abstract object

a filter point defined in the filter table

> to see if it should drop (or is it 
> reject? Can
> you choose?). 

Yes. You should be able to.

> 
> It is interesting, I'm a little dubious, iptables basically becomes an
> object manager and uses iptables rules to determine whether or not to
> call into the security server, which isn't inappropriate, per se. The
> iptables filter rules must be included as part of the policy or the
> expected filtering would occur, the same is true for secmark 
> though.

Yes.

> The
> difference is that secmark is labeling packets and if the 
> labels aren't
> in place a restrictive policy will drop them.

this will continue to hold true.

> With these 
> filter rules if
> they aren't in place the policy becomes less restrictive (right?)..

We could also be restrictive or leave it up to the policy entirely.

--
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: SELinux Networking Enhancements

[Paul Moore]

Venkat Yekkirala wrote:
>>Ok, I think I'm beginning to get it (I'm a bit slow lately 
>>:\).. You are
>>defining a condition where iptables will call into the security server
> 
> Correct.
> 
>>using the packet label (either secmark or external, how do 
>>you decide?)
> 
> Both.

If we use secfilter to do access controls for both internal and external
labeling using the same class/permission I think we might have a problem similar
to what we ran into with the secid reconciliation approach: internal labeling
mechanisms (SECMARK) assign labels based on packet properties while the external
mechanisms (XFRM, NetLabel) assign labels based on the sending socket's context.

>>With these 
>>filter rules if
>>they aren't in place the policy becomes less restrictive (right?)..
> 
> We could also be restrictive or leave it up to the policy entirely.

More explanation please.

I don't understand how secfilter could be made restrictive in the same manner as
SECMARK.  How can you know if the netfilter rules are missing?  What would you
compare the loaded netfilter rules against?  I guess you could compare them
against something maintained inside the SELinux security server, but I think you
would need to put some rather invasive hooks into the netfilter management code
to ensure that the required secfilter netfilter rules are not subverted.

-- 
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
> 
> > using the packet label (either secmark or external, how do you 
> > decide?)
> 
> Both.

It calls avc_has_perm for both labels? How will netlabel fit in? What do
you expect the performance hit to be with so many avc lookups?

> > to see if it should drop (or is it
> > reject? Can
> > you choose?). 
> 
> Yes. You should be able to.
> 

So you just pass an additional parameter to the selinux module? I assume
you aren't going to try to use TE policy to choose.

<snip>
> 
> > With these
> > filter rules if
> > they aren't in place the policy becomes less restrictive (right?)..
> 
> We could also be restrictive or leave it up to the policy entirely.
> 

So if there is no rule present it would always check against unlabeled
(or some initial SID)? Can you force the selinux module to be called
under all circumstances? 

This is starting to sound pretty reasonable. The filter rules really are
policy they just aren't TE policy, and they are also tightly bound to a
particular TE policy.

This is different from other object managers because their "policy" is
static, they always ask the question at some point in the codepath
wheras you want to implement a dynamic policy to query the security
server. I don't think there is anything wrong with it but the
ramifications need to be examined, synchronicity is probably going to be
the hardest thing to solve. 



--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > > using the packet label (either secmark or external, how do you
> > > decide?)
> >
> > Both.
>
> It calls avc_has_perm for both labels? How will netlabel fit
> in?

Yes.

> What do
> you expect the performance hit to be with so many avc lookups?
>

I believe the avc has been well-optimized lately.

> > > to see if it should drop (or is it
> > > reject? Can
> > > you choose?).
> >
> > Yes. You should be able to.
> >
>
> So you just pass an additional parameter to the selinux
> module? I assume
> you aren't going to try to use TE policy to choose.

Can you reframe your original question? I am afraid I misunderstood
it when I answered.

>
> <snip>
> >
> > > With these
> > > filter rules if
> > > they aren't in place the policy becomes less restrictive
> (right?)..
> >
> > We could also be restrictive or leave it up to the policy entirely.
> >
>
> So if there is no rule present it would always check against unlabeled
> (or some initial SID)?

Yes. I think this would be the simpler approach for now.

> Can you force the selinux module to be called
> under all circumstances?

Yes, in the proposal we are looking at here, the module will be called
from within netfilter when there are explicit secfilter rules as well as
when none have been found in which case there would be a check against
unlabeled. Is this what you meant to ask?

>
> This is starting to sound pretty reasonable. The filter rules
> really are
> policy

They are a really a labeling policy just like in the secmark case.
Here we would label the filter points as opposed to packets.

> they just aren't TE policy, and they are also tightly
> bound to a
> particular TE policy.

If you meant the "particular" portion of the policy that would
have the allow rules, etc., to enforce secfilter, yes.

>
> This is different from other object managers because their "policy" is
> static, they always ask the question at some point in the codepath
> wheras you want to implement a dynamic policy to query the security
> server.

I am not sure I understand. This is completely analogous to how the
filesystem
checks work. Just like how file contexts live on the File System, secfilter
contexts live (just like secmark labels) in the netfilter subsystem
efficiently
looked up by the iptables framework. Just like how the various portions of
the
FS code call into LSM, so would netfilter/secfilter.

> I don't think there is anything wrong with it but the
> ramifications need to be examined, synchronicity is probably
> going to be
> the hardest thing to solve.

Could you please eleborate on the synchronicity issues and how these are
absent/resolved for the FS case?


--
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: SELinux Networking Enhancements

[Joshua Brindle]

Venkat Yekkirala wrote:
>>>
>> So you just pass an additional parameter to the selinux
>> module? I assume
>> you aren't going to try to use TE policy to choose.
> 
> Can you reframe your original question? I am afraid I misunderstood
> it when I answered.
> 

How do you tell it to drop on one peer label but reject another?

>> <snip>
>>>> With these
>>>> filter rules if
>>>> they aren't in place the policy becomes less restrictive
>> (right?)..
>>> We could also be restrictive or leave it up to the policy entirely.
>>>
>> So if there is no rule present it would always check against unlabeled
>> (or some initial SID)?
> 
> Yes. I think this would be the simpler approach for now.
> 
>> Can you force the selinux module to be called
>> under all circumstances?
> 
> Yes, in the proposal we are looking at here, the module will be called
> from within netfilter when there are explicit secfilter rules as well as
> when none have been found in which case there would be a check against
> unlabeled. Is this what you meant to ask?
> 

Right, would the module always be 'on', even if iptables has an accept 
policy.

>> This is starting to sound pretty reasonable. The filter rules
>> really are
>> policy
> 
> They are a really a labeling policy just like in the secmark case.
> Here we would label the filter points as opposed to packets.
> 

Maybe, if the unlabeled check is really there then it is labeling, if it 
  isn't then you are using filter rules to set up an external policy.

>> they just aren't TE policy, and they are also tightly
>> bound to a
>> particular TE policy.
> 
> If you meant the "particular" portion of the policy that would
> have the allow rules, etc., to enforce secfilter, yes.
> 

mostly types..

>> This is different from other object managers because their "policy" is
>> static, they always ask the question at some point in the codepath
>> wheras you want to implement a dynamic policy to query the security
>> server.
> 
> I am not sure I understand. This is completely analogous to how the
> filesystem
> checks work. Just like how file contexts live on the File System, secfilter
> contexts live (just like secmark labels) in the netfilter subsystem
> efficiently
> looked up by the iptables framework. Just like how the various portions of
> the
> FS code call into LSM, so would netfilter/secfilter.
> 

Same as above.. if the unlabeled check is done then fine, otherwise you 
are using iptables as an enforcer with a dynamic policy (eg., its only 
checked if there is an iptables rule present instead of every single 
time in a static code path like the filesystem).

>> I don't think there is anything wrong with it but the
>> ramifications need to be examined, synchronicity is probably
>> going to be
>> the hardest thing to solve.
> 
> Could you please eleborate on the synchronicity issues and how these are
> absent/resolved for the FS case?
> 

Mainly applying the rules at the same time as a policy update and 
keeping them synchronized. It is easier for files because you merely 
overwrite the label there, with iptables there are ordering issues so 
you have to apply them in the right order, including any rules that are 
already there. If any module has a rule that shadows another there are 
problems, you'll never know which gets put in the chain first, etc.


--
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: SELinux Networking Enhancements

[Christopher J. PeBenito]

On Mon, 2006-10-30 at 13:27 -0500, James Morris wrote:
> # Server policy
> allow httpd_server_t httpd_client_t:peer { recv send };
> 
> # Client policy
> allow httpd_client_t httpd_server_t:peer { recv send };

Since we're talking about how policy, here is how I think the policy
should look like ideally, using the server side as example:

# service http requests (ipsec):
allow apache_t self:tcp_socket create_stream_socket_perms;
allow apache_t http_server_packet_t:packet { send recv };
allow apache_t http_spd_t:association polmatch;
allow apache_t mozilla_t:association { sendto recvfrom };
allow http_server_packet_t mozilla_t:association { flow_in flow_out };

# do dns lookups (non ipsec):
allow apache_t self:tcp_socket create_stream_socket_perms;
allow apache_t dns_client_packet_t:packet { send recv };
allow apache_t no_extlabel_t:association { sendto recvfrom };
allow dns_client_packet_t no_extlabel_t:association { flow_in flow_out };

This has the requirement that the type of the association is the same as
the type of the domain on the other side and no_extlabel_t (or
unlabeled_t) for unencrypted communications.

-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> On Mon, 2006-10-30 at 13:27 -0500, James Morris wrote:
> > # Server policy
> > allow httpd_server_t httpd_client_t:peer { recv send };
> >
> > # Client policy
> > allow httpd_client_t httpd_server_t:peer { recv send };
>
> Since we're talking about how policy, here is how I think the policy
> should look like ideally, using the server side as example:
>
> # service http requests (ipsec):
> allow apache_t self:tcp_socket create_stream_socket_perms;
> allow apache_t http_server_packet_t:packet { send recv };
> allow apache_t http_spd_t:association polmatch;
> allow apache_t mozilla_t:association { sendto recvfrom };

Since an association is a uni-directional object and since having
mozilla_t as the label on associations in BOTH directions would
mess-up the getpeercon semantics (it would return mozilla_t when
invoked by the client as well as the server which isn't what we want)
the above rule will have to be broken into:

allow apache_t mozilla_t:association { recvfrom };
allow apache_t self:association { sendto };

with the client having the following rules:

allow mozilla_t apache_t:association { recvfrom };
allow mozilla_t self:association { sendto };

> allow http_server_packet_t mozilla_t:association { flow_in flow_out };

This won't always work since at least from the MLS standpoint, an
association
could be looked at as being more fine-grained than a packet type.

As may have been noticed, I am currently thinking of a separate generic
filtering module in the filter table that would filter packets based on
the label (internal as well as external) on the packet and the label on
the filtering point. So you would still happily secmark packets, but also
have control over what labels (be they internal or external) can come into
or leave the system. Being a generic mechanism this would also seemlessly
cover the forwarding case.

People can look at "Chapter 6. Traversing of tables and chains" at:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTA
BLES
to see where the filtering happens for the input, output and forward cases.

>
> # do dns lookups (non ipsec):
> allow apache_t self:tcp_socket create_stream_socket_perms;
> allow apache_t dns_client_packet_t:packet { send recv };
> allow apache_t no_extlabel_t:association { sendto recvfrom };

This currently would be (as you also indicate later):
allow apache_t unlabeled_t:association { sendto recvfrom };

> allow dns_client_packet_t no_extlabel_t:association { flow_in
> flow_out };
>
> This has the requirement that the type of the association is
> the same as
> the type of the domain on the other side

For recvfrom this is how it is; the association is the same as
the type of the domain on the OTHER side. For sendto, we would
currently allow use of the same association as the sending socket.

So, "sendto" is more like a "use" permission.

> and no_extlabel_t (or
> unlabeled_t) for unencrypted communications.
>
> --
> 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: SELinux Networking Enhancements

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
> 
<snip>
> 
> As may have been noticed, I am currently thinking of a 
> separate generic filtering module in the filter table that 
> would filter packets based on the label (internal as well as 
> external) on the packet and the label on the filtering point. 

This is not appropriate, the TE/MLS policy should be in the SELinux
policy, not in the SELinux policy and the filter tables(or anywhere
else). Policy should be centralized and analyzable to be part of the MAC
policy at all.


--
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: SELinux Networking Enhancements

[Paul Moore]

Joshua Brindle wrote:
>>From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
>>
> 
> <snip>
> 
>>As may have been noticed, I am currently thinking of a 
>>separate generic filtering module in the filter table that 
>>would filter packets based on the label (internal as well as 
>>external) on the packet and the label on the filtering point. 
> 
> This is not appropriate, the TE/MLS policy should be in the SELinux
> policy, not in the SELinux policy and the filter tables(or anywhere
> else). Policy should be centralized and analyzable to be part of the MAC
> policy at all.

Maybe I'm missing something, but I think you could make this part of the SELinux
policy much like SECMARK rules are part of the policy now, right?

-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> >>As may have been noticed, I am currently thinking of a 
> >>separate generic filtering module in the filter table that 
> >>would filter packets based on the label (internal as well as 
> >>external) on the packet and the label on the filtering point. 
> > 
> > This is not appropriate, the TE/MLS policy should be in the SELinux
> > policy, not in the SELinux policy and the filter tables(or anywhere
> > else). Policy should be centralized and analyzable to be 
> part of the MAC
> > policy at all.
> 
> Maybe I'm missing something, but I think you could make this 
> part of the SELinux
> policy much like SECMARK rules are part of the policy now, right?

That's correct. The filtering rules as well as the policy that goes
with them would all be part of the policy like with secmark.

--
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
> 
> > >>As may have been noticed, I am currently thinking of a separate 
> > >>generic filtering module in the filter table that would filter 
> > >>packets based on the label (internal as well as
> > >>external) on the packet and the label on the filtering point. 
> > > 
> > > This is not appropriate, the TE/MLS policy should be in 
> the SELinux 
> > > policy, not in the SELinux policy and the filter 
> tables(or anywhere 
> > > else). Policy should be centralized and analyzable to be
> > part of the MAC
> > > policy at all.
> > 
> > Maybe I'm missing something, but I think you could make 
> this part of 
> > the SELinux policy much like SECMARK rules are part of the 
> policy now, 
> > right?
> 
> That's correct. The filtering rules as well as the policy 
> that goes with them would all be part of the policy like with secmark.
> 

This is a misunderstanding. Secmark is not enforcement policy, secmark
is labeling policy. You want to put enforcement policy into iptables
which is not appropriate since it splits the enforcement policy into 2
separate places.


--
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: SELinux Networking Enhancements

[Christopher J. PeBenito]

On Wed, 2006-11-01 at 09:58 -0600, Venkat Yekkirala wrote:
> > On Mon, 2006-10-30 at 13:27 -0500, James Morris wrote:
> > > # Server policy
> > > allow httpd_server_t httpd_client_t:peer { recv send };
> > >
> > > # Client policy
> > > allow httpd_client_t httpd_server_t:peer { recv send };
> >
> > Since we're talking about how policy, here is how I think the policy
> > should look like ideally, using the server side as example:
> >
> > # service http requests (ipsec):
> > allow apache_t self:tcp_socket create_stream_socket_perms;
> > allow apache_t http_server_packet_t:packet { send recv };
> > allow apache_t http_spd_t:association polmatch;
> > allow apache_t mozilla_t:association { sendto recvfrom };
> 
> Since an association is a uni-directional object and since having
> mozilla_t as the label on associations in BOTH directions would
> mess-up the getpeercon semantics (it would return mozilla_t when
> invoked by the client as well as the server which isn't what we want)
> the above rule will have to be broken into:

It wouldn't break the getpeercon semantics.  The association would be
labeled mozilla_t on the apache machine, and apache_t on the mozilla
machine.

> allow apache_t mozilla_t:association { recvfrom };
> allow apache_t self:association { sendto };
> 
> with the client having the following rules:
> 
> allow mozilla_t apache_t:association { recvfrom };
> allow mozilla_t self:association { sendto };

This doesn't cut it because you have no control who you are sending to.

> > allow http_server_packet_t mozilla_t:association { flow_in flow_out };
> 
> This won't always work since at least from the MLS standpoint, an
> association
> could be looked at as being more fine-grained than a packet type.

I don't understand what the problem is.  MLS constraints still apply.

> As may have been noticed, I am currently thinking of a separate generic
> filtering module in the filter table that would filter packets based on
> the label (internal as well as external) on the packet and the label on
> the filtering point. So you would still happily secmark packets, but also
> have control over what labels (be they internal or external) can come into
> or leave the system. Being a generic mechanism this would also seemlessly
> cover the forwarding case.

This is not acceptable for SELinux because the rules would be in
netfilter instead of MAC policy.

-- 
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: SELinux Networking Enhancements

[Paul Moore]

Christopher J. PeBenito wrote:
> On Wed, 2006-11-01 at 09:58 -0600, Venkat Yekkirala wrote:
>
>>allow apache_t mozilla_t:association { recvfrom };
>>allow apache_t self:association { sendto };
>>
>>with the client having the following rules:
>>
>>allow mozilla_t apache_t:association { recvfrom };
>>allow mozilla_t self:association { sendto };
>  
> This doesn't cut it because you have no control who you are sending to.

Now, this would only work for connected stream sockets, but I imagine you could
always do an access check against the peer's context which you could obtain
using a process similar to getpeercon().

-- 
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: SELinux Networking Enhancements

[James Morris]

On Wed, 1 Nov 2006, Christopher J. PeBenito wrote:

> This is not acceptable for SELinux because the rules would be in
> netfilter instead of MAC policy.

Not necessarily -- an iptables module can call into the AVC for a policy 
decision if needed.



- James
-- 
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: James Morris [mailto:jmorris@namei.org] 
> 
> On Wed, 1 Nov 2006, Christopher J. PeBenito wrote:
> 
> > This is not acceptable for SELinux because the rules would be in 
> > netfilter instead of MAC policy.
> 
> Not necessarily -- an iptables module can call into the AVC 
> for a policy decision if needed.
> 

Then what would the filter rules look like? It sounded like Venkat
wanted something that would drop a packet based on a label (from secmark
or external) which would be enforcement. I don't know what the iptables
rule would look like if it was just going to call into the security
server.


--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > Since an association is a uni-directional object and since having
> > mozilla_t as the label on associations in BOTH directions would
> > mess-up the getpeercon semantics (it would return mozilla_t when
> > invoked by the client as well as the server which isn't 
> what we want)
> > the above rule will have to be broken into:
> 
> It wouldn't break the getpeercon semantics.  The association would be
> labeled mozilla_t on the apache machine, and apache_t on the mozilla
> machine.

Yes, but the thing to realize with these SAs is that they are
uni-directional. So there's no mozilla_t SA involved when mozilla
is sending to apache (if you ignore the transport here).
IOW, using SAs you can broadly only control "who can talk to you",
not "who you can talk to". The latter can currently be achieved by
using secmark controls where you would mark the packet in a
fine-grained manner and see if the socket can send that Type of
packet.

> 
> > allow apache_t mozilla_t:association { recvfrom };
> > allow apache_t self:association { sendto };
> > 
> > with the client having the following rules:
> > 
> > allow mozilla_t apache_t:association { recvfrom };
> > allow mozilla_t self:association { sendto };
> 
> This doesn't cut it because you have no control who you are 
> sending to.

Secmark ouught to come to your rescue here as explained above.

> 
> > > allow http_server_packet_t mozilla_t:association { 
> flow_in flow_out };
> > 
> > This won't always work since at least from the MLS standpoint, an
> > association
> > could be looked at as being more fine-grained than a packet type.
> 
> I don't understand what the problem is.  MLS constraints still apply.

Yes MLS constraints apply. But consider the following:

secmark: s2-s4
SA: s3

> 
> > As may have been noticed, I am currently thinking of a 
> separate generic
> > filtering module in the filter table that would filter 
> packets based on
> > the label (internal as well as external) on the packet and 
> the label on
> > the filtering point. So you would still happily secmark 
> packets, but also
> > have control over what labels (be they internal or 
> external) can come into
> > or leave the system. Being a generic mechanism this would 
> also seemlessly
> > cover the forwarding case.
> 
> This is not acceptable for SELinux because the rules would be in
> netfilter instead of MAC policy.

The labeling rules (just like in the secmark case) will be in
netfilter, but policy and enforcement would still be in SELinux
(just like in the secmark case).

--
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: SELinux Networking Enhancements

[Christopher J. PeBenito]

On Thu, 2006-11-02 at 10:20 -0600, Venkat Yekkirala wrote:
> > > Since an association is a uni-directional object and since having
> > > mozilla_t as the label on associations in BOTH directions would
> > > mess-up the getpeercon semantics (it would return mozilla_t when
> > > invoked by the client as well as the server which isn't 
> > what we want)
> > > the above rule will have to be broken into:
> > 
> > It wouldn't break the getpeercon semantics.  The association would be
> > labeled mozilla_t on the apache machine, and apache_t on the mozilla
> > machine.
> 
> Yes, but the thing to realize with these SAs is that they are
> uni-directional. So there's no mozilla_t SA involved when mozilla
> is sending to apache (if you ignore the transport here).
> IOW, using SAs you can broadly only control "who can talk to you",
> not "who you can talk to". The latter can currently be achieved by
> using secmark controls where you would mark the packet in a
> fine-grained manner and see if the socket can send that Type of
> packet.

No, secmark does not help here.  It has nothing to do with the domain on
the other machine.  It only represents ports, nodes and netifs.

> > > > allow http_server_packet_t mozilla_t:association { 
> > flow_in flow_out };
> > > 
> > > This won't always work since at least from the MLS standpoint, an
> > > association
> > > could be looked at as being more fine-grained than a packet type.
> > 
> > I don't understand what the problem is.  MLS constraints still apply.
> 
> Yes MLS constraints apply. But consider the following:
> 
> secmark: s2-s4
> SA: s3

I still don't see what the problem is.  If this packet shouldn't go over
the association, the MLS constraints would be written for the above
permissions to express that goal and it would get denied.

> > > As may have been noticed, I am currently thinking of a 
> > separate generic
> > > filtering module in the filter table that would filter 
> > packets based on
> > > the label (internal as well as external) on the packet and 
> > the label on
> > > the filtering point. So you would still happily secmark 
> > packets, but also
> > > have control over what labels (be they internal or 
> > external) can come into
> > > or leave the system. Being a generic mechanism this would 
> > also seemlessly
> > > cover the forwarding case.
> > 
> > This is not acceptable for SELinux because the rules would be in
> > netfilter instead of MAC policy.
> 
> The labeling rules (just like in the secmark case) will be in
> netfilter, but policy and enforcement would still be in SELinux
> (just like in the secmark case).

I'm not yet convinced, but I need to review the other points you've made
in the other threads.

-- 
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> No, secmark does not help here.  It has nothing to do with 
> the domain on
> the other machine.  It only represents ports, nodes and netifs.

That's correct, but currently that's as close as you can get to
representing a form of the remote peer on the local machine. The
remote peer domain simply isn't available on the local machine
at the time you are trying to determine if a local process can
talk TO a remote peer.

> 
> > > > > allow http_server_packet_t mozilla_t:association { 
> > > flow_in flow_out };
> > > > 
> > > > This won't always work since at least from the MLS 
> standpoint, an
> > > > association
> > > > could be looked at as being more fine-grained than a 
> packet type.
> > > 
> > > I don't understand what the problem is.  MLS constraints 
> still apply.
> > 
> > Yes MLS constraints apply. But consider the following:
> > 
> > secmark: s2-s4
> > SA: s3
> 
> I still don't see what the problem is.  If this packet 
> shouldn't go over
> the association, the MLS constraints would be written for the above
> permissions to express that goal and it would get denied.

Yes, you could frame MLS constraints accordingly, but I suspect
they may look awkward.

Could you please give an example or two where this would be useful?

--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > > Since an association is a uni-directional object and since having
> > > mozilla_t as the label on associations in BOTH directions would
> > > mess-up the getpeercon semantics (it would return mozilla_t when
> > > invoked by the client as well as the server which isn't 
> > what we want)
> > > the above rule will have to be broken into:
> > 
> > It wouldn't break the getpeercon semantics.  The 
> association would be
> > labeled mozilla_t on the apache machine, and apache_t on the mozilla
> > machine.
> 
> Yes, but the thing to realize with these SAs is that they are
> uni-directional. So there's no mozilla_t SA involved when mozilla

s/mozilla_t/apache_t/

> is sending to apache (if you ignore the transport here).
> IOW, using SAs you can broadly only control "who can talk to you",
> not "who you can talk to". The latter can currently be achieved by
> using secmark controls where you would mark the packet in a
> fine-grained manner and see if the socket can send that Type of
> packet.
> 

--
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: SELinux Networking Enhancements

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com] 
> 
> > > > Since an association is a uni-directional object and 
> since having 
> > > > mozilla_t as the label on associations in BOTH directions would 
> > > > mess-up the getpeercon semantics (it would return 
> mozilla_t when 
> > > > invoked by the client as well as the server which isn't
> > > what we want)
> > > > the above rule will have to be broken into:
> > > 
> > > It wouldn't break the getpeercon semantics.  The
> > association would be
> > > labeled mozilla_t on the apache machine, and apache_t on 
> the mozilla 
> > > machine.
> > 
> > Yes, but the thing to realize with these SAs is that they are 
> > uni-directional. So there's no mozilla_t SA involved when mozilla
> 
> s/mozilla_t/apache_t/
> 

I think he's asking why both SA's aren't labeled as the peer on each
side:

Side 1: socket client_t
Outgoing SA: server_t
Incomging SA: server_t

Side 2: socket server_t
Outgoing SA: client_t
Incoming SA: client_t

That way client_t has to be able to send to and recv from server_t, 
Likewise server_t has to be able to send to and recv from client_t.

The SA labeling semantics can be changed at this point, they are just
userland drive, correct? Last time I used them the labeling semantics
weren't what AFAIK they are suppose to be anyway (eg., every SA was
labeled client_t, not one labeled clien_t and the other labeled
server_t)


--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> I think he's asking why both SA's aren't labeled as the peer on each
> side:
> 
> Side 1: socket client_t
> Outgoing SA: server_t
> Incomging SA: server_t
> 
> Side 2: socket server_t
> Outgoing SA: client_t
> Incoming SA: client_t
> 
> That way client_t has to be able to send to and recv from server_t, 
> Likewise server_t has to be able to send to and recv from client_t.

The problem is that when a client requires an SA to talk to the server,
there's currently no way to know that the server is at server_t. There's
currently no way for the IKE daemon (racoon) to figure this out when
negotiating an SA.

> 
> The SA labeling semantics can be changed at this point, they are just
> userland drive, correct?

Not entirely. racoon currently receives the context to use from the
spd (upstream kernel) or the sending socket (lspp kernel, soon to be
submitted for upstreaming).

> Last time I used them the labeling semantics
> weren't what AFAIK they are suppose to be anyway (eg., every SA was
> labeled client_t, not one labeled clien_t and the other labeled
> server_t)

This shouldn't be the case with the lastest lspp kernel.

--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > While you still disagree, I think most of us believe that secmarks
> 
> Only there are no secmarks in the new design to begin with. The word
> is a holdover from the current secmark design.
> 
> > should be _local only_ enforcement, not peer labeling, an 
> > ipsec rule is
> > in no way a "peer",
> 
> Agreed. But I fail to see where having a "default" peer on a 
> netfilter rule/secpoint
> would hurt. FYI- this is how MLS implementations work. You 
> have an interface
> that you would label everything coming thru by default with "Secret".
> 
> Also, don't we deem all data on a filesystem that doesn't 
> support individual
> file labeling to be at the label it's mounted at?
> 
> > a remote socket is a peer and a peer should
> > represent that.
> 
> Sure. That's also allowed in secpoint.

If it would serve your needs any better, we can have getpeercon return only
a "true" (meaning external) peer like you like to call it. We can find
someother way to retrieve the default as well (for MLS). Is that better?

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

SELinux Networking Enhancements

[Venkat Yekkirala]

There has been a lot of confusion for some time on the new
proposed controls vis a vis the controls past and present.

So I wanted to lay out briefly the past, present and the
proposed future of SELinux networking controls on 2.6 kernels
to put things in perpective.

PAST:

One could control network access based on node, netif
and port contexts. Specifically, sockets were subject
to access checks against the 3 contexts mentioned.

No controls on forwarded traffic available. Also,
no way to retrieve the peer context on TCP sockets and
the security context on IP datagrams.


PRESENT:

secmark enables contexts to be specified on packets
based on attributes on a packet (src, dst addresses,
ports, etc.) that are selectable via iptables rules.
Access checks are socket Vs. packet.

Also, labeled networking via IPSec xfrms and NetLabel/CIPSO
has become available. Also implemented is a way to retrieve
the peer context on TCP sockets and the security context on
datagrams.

But still no controls on forwarded traffic are available.
Also, still no easy way to retrieve the peer context on
TCP sockets and the security context on datagrams, in a
transparent fashion in localhost (loopback) communications.
While one could use NetLabel/CIPSO (MLS only) and in theory
IPSec xfrms to do this for localhost communications, it's
awkward, entails undue overhead and something that needs to
be configured via policy to work.


NEW CONTROLS (SECPOINT):

The implementation of secmark paves the way, from an implementation
standpoint, for the implementation of a different set of controls
that seemlessly and comprehensively provide a way to impose controls
on forwarded traffic as well as traffic destined for and generated on
the local machine. It also paves the way for carrying the peer/datagram
contexts for localhost traffic.

Specifically the following objects are defined/used:

1. Fine-grained security filter points defined using iptables rules.
   These points carry the following contexts:
        a. A set of domains that can flow-in and/or flow_out the secpoint.
        b. A default context to be associated with all traffic that enters
           the secpoint without carrying an explicit label such as NetLabel,
           labeled-ipsec-SA, etc, iff such "unlabeled" domain can actually
           flow thru that secpoint.

        NOTE: The way these 2 contexts are specified in this implementation
        is by specifying the default context with the iptables rule and then
        using SELinux policy to specify the set of domains that can
        flow_in/flow_out of a secpoint with such a default context.

2. Packets: These carry the socket label in the outbound case, or the label
        they came in with, in the inbound case. The label in the inbound
case
        can either be an externally specified label (label over the wire) or
        in it's absence the default label from the secpoint it came in thru.

3. Sockets.

Access Control:

1. Packets are filtered at the security points they pass thru.

   Forwarded traffic: This is filtered on the way in like any other
   traffic and filtered on the way out like any other traffic as well.

   Peer/datagram context: These are transparently available for localhost
   traffic without needing any special configuration or use of specific
   labeling protocols.

2. Access control checks come into play (like they currently do)
   when a socket receives a packet.

--
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: SELinux Networking Enhancements

[Joshua Brindle]

On Sun, 2006-10-15 at 23:14 -0400, Venkat Yekkirala wrote:
> There has been a lot of confusion for some time on the new
> proposed controls vis a vis the controls past and present.
> 
<snip>
> 
> 
> NEW CONTROLS (SECPOINT):
> 
> The implementation of secmark paves the way, from an implementation
> standpoint, for the implementation of a different set of controls
> that seemlessly and comprehensively provide a way to impose controls
> on forwarded traffic as well as traffic destined for and generated on
> the local machine. It also paves the way for carrying the peer/datagram
> contexts for localhost traffic.
> 

Its not that we don't understand it, its just that we don't agree. The
secpoint "paradigm" is convoluted IMO and we need something simple. I
basically bailed on this conversation because it wasn't going anywhere.

While you still disagree, I think most of us believe that secmarks
should be _local only_ enforcement, not peer labeling, an ipsec rule is
in no way a "peer", a remote socket is a peer and a peer should
represent that.

I believe the secpoint paradigm is very complicated to understand and
use, for example, you'll have to have a number of flow_in and flow_out
rules not necessarily related to the domain and socket being used.
You'll get a flow_out for the domain->socket->secmark->(any other
secmark that we happen to hit which is non-ideal)->association.

There is not an intuitive way of binding a domain to an association.
Rather than doing a string of checks like this it should be laid out and
obvious:

allow domain socket : tcp_sock { write read };
allow socket secmark : packet { send recv };
allow secmark association : association { flow_out flow_in };
allow domain association : association { sendto recvfrom };

this effectively (and obviously) binds the domain type to the socket and
the association, binds the socket to the packet and binds the packet to
the association. 

Without having to follow a trail of flow_in rules this effectively does
the access control that that we want.

Network labeling should be very simple: you use the network label if its
present. If some reconciliation needs to happen between ipsec and
Netlabel thats fine but the bottom line is peer contexts are external
and have nothing to do with the local labeling (except for access
control).

What is the problem with what I have above (which is what I thought we
were going to do after the conf call..)

> Specifically the following objects are defined/used:
> 
> 1. Fine-grained security filter points defined using iptables rules.
>    These points carry the following contexts:
>         a. A set of domains that can flow-in and/or flow_out the secpoint.
>         b. A default context to be associated with all traffic that enters
>            the secpoint without carrying an explicit label such as NetLabel,
>            labeled-ipsec-SA, etc, iff such "unlabeled" domain can actually
>            flow thru that secpoint.
> 
>         NOTE: The way these 2 contexts are specified in this implementation
>         is by specifying the default context with the iptables rule and then
>         using SELinux policy to specify the set of domains that can
>         flow_in/flow_out of a secpoint with such a default context.
> 
> 2. Packets: These carry the socket label in the outbound case, or the label
>         they came in with, in the inbound case. The label in the inbound
> case
>         can either be an externally specified label (label over the wire) or
>         in it's absence the default label from the secpoint it came in thru.
> 
> 3. Sockets.
> 
> Access Control:
> 
> 1. Packets are filtered at the security points they pass thru.
> 
>    Forwarded traffic: This is filtered on the way in like any other
>    traffic and filtered on the way out like any other traffic as well.
> 
>    Peer/datagram context: These are transparently available for localhost
>    traffic without needing any special configuration or use of specific
>    labeling protocols.
> 
> 2. Access control checks come into play (like they currently do)
>    when a socket receives a packet.



--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> Its not that we don't understand it, its just that we don't agree. The
> secpoint "paradigm" is convoluted IMO and we need something simple.

But no one has comeup with a "simpler" alternative that
also addresses the shortcomings of secmark.

> I
> basically bailed on this conversation because it wasn't going
> anywhere.
>
> While you still disagree, I think most of us believe that secmarks

Only there are no secmarks in the new design to begin with. The word
is a holdover from the current secmark design.

> should be _local only_ enforcement, not peer labeling, an
> ipsec rule is
> in no way a "peer",

Agreed. But I fail to see where having a "default" peer on a netfilter
rule/secpoint
would hurt. FYI- this is how MLS implementations work. You have an interface
that you would label everything coming thru by default with "Secret".

Also, don't we deem all data on a filesystem that doesn't support individual
file labeling to be at the label it's mounted at?

> a remote socket is a peer and a peer should
> represent that.

Sure. That's also allowed in secpoint.

>
> I believe the secpoint paradigm is very complicated to understand and
> use, for example, you'll have to have a number of flow_in and flow_out
> rules not necessarily related to the domain and socket being used.

Exactly the kind of stuff needed for "comprehensive" flow-control that
would also accommodate forwarded traffic. And we seem to have just run
away from it so far.

> You'll get a flow_out for the domain->socket->secmark->(any other
> secmark that we happen to hit which is non-ideal)->association.

Have you never gone thru multiple security check points at airports
and such?

>
> There is not an intuitive way of binding a domain to an association.

I think we have mixup on terminology here. An "association" is traditionally
used to refer to an IPSec SA and it has nothing innately to do with
flow-control.

> Rather than doing a string of checks like this it should be
> laid out and
> obvious:
>
> allow domain socket : tcp_sock { write read };

Available.

> allow socket secmark : packet { send recv };

This is VERY NARROW in that it doesn't accommodate the forwarding
case. If one were to take a broader view of things, it would be:

allow packet secpoint { flow_out }

where packet carries the socket's label in the socket case, and
for the inbound:

allow packet secpoint { flow_in }
allow socket packet { recv }

> allow secmark association : association { flow_out flow_in };

Can't do this. Too late in the chain to base IPSec associations based
on secmark. And we don't need to. You just let the association
"trasparently" chosen to correspond to the label of the packet (socket
indirectly).

> allow domain association : association { sendto recvfrom };

The sendto happens "transparently". The recvfrom is redundant when
you already have a packet assume the SA label, and are doing (as mentioned
above as well):

allow socket packet { recv }

>
> this effectively (and obviously) binds the domain type to the
> socket and
> the association, binds the socket to the packet and binds the
> packet to
> the association.
>
> Without having to follow a trail of flow_in rules this

Not any more difficult than following a trail of context transitions
and such for processes when doing policy. Perhaps even simpler.

> effectively does
> the access control that that we want.
>
> Network labeling should be very simple:

AND COMPREHENSIVE.

> you use the network
> label if its
> present. If some reconciliation needs to happen between ipsec and
> Netlabel thats fine but the bottom line is peer contexts are external
> and have nothing to do with the local labeling

For MLS the "default" labeling is needed and if you can't leverage
it for TE then no one is forcing you to do so. You would just frame
your policy accordingly where the "default" labels fail to operate
like explicit peer contexts.

> (except for access
> control).
>
> What is the problem with what I have above (which is what I thought we
> were going to do after the conf call..)

Not comprehensive as explained above.
>


--
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: SELinux Networking Enhancements

[Joshua Brindle]

On Mon, 2006-10-16 at 09:31 -0500, Venkat Yekkirala wrote:
> > Its not that we don't understand it, its just that we don't agree. The
> > secpoint "paradigm" is convoluted IMO and we need something simple.
> 
> But no one has comeup with a "simpler" alternative that
> also addresses the shortcomings of secmark.
> 
> > I
> > basically bailed on this conversation because it wasn't going
> > anywhere.
> >
> > While you still disagree, I think most of us believe that secmarks
> 
> Only there are no secmarks in the new design to begin with. The word
> is a holdover from the current secmark design.
> 

the point is that the new design is being challenged, you can't fall
back on "that isn't what it means anymore" because it is what it means
until your changes go in. 

> > should be _local only_ enforcement, not peer labeling, an
> > ipsec rule is
> > in no way a "peer",
> 
> Agreed. But I fail to see where having a "default" peer on a netfilter
> rule/secpoint
> would hurt. FYI- this is how MLS implementations work. You have an interface
> that you would label everything coming thru by default with "Secret".
> 

first, getpeercon() returning something that isn't an external label is
not good, how are applications to cope with this behavior?

Second, MLS implementations work this way because they are hard coded
to. We aren't hard coded to do anything, there is no "default" in this
case, you'd have to specify defaults with iptables and I question how
scalable that is anyway. You either have really course grained secmarks
(one per interface with 1 type and an MLS range) or if you start
breaking it down into protocol, port, etc you have a full set for every
interface with a different type and the mls range. There doesn't seem to
be alot of flexibility here.

> Also, don't we deem all data on a filesystem that doesn't support individual
> file labeling to be at the label it's mounted at?
> 

no, it gets a label based on genfscon (eg., cd's get iso9660_t no matter
where it is mounted)

> > a remote socket is a peer and a peer should
> > represent that.
> 
> Sure. That's also allowed in secpoint.
> 

secpoint supports that by mutating labels. If there is no labeled
networking present getpeercon() returns a totally different label from a
totally different place that represents a totally different thing
(secpoint isn't the same as remote peer IMO)

> >
> > I believe the secpoint paradigm is very complicated to understand and
> > use, for example, you'll have to have a number of flow_in and flow_out
> > rules not necessarily related to the domain and socket being used.
> 
> Exactly the kind of stuff needed for "comprehensive" flow-control that
> would also accommodate forwarded traffic. And we seem to have just run
> away from it so far.
> 

So I never heard about this requirement until now. I'll grant that it is
an interesting problem but if it is truly a requirement why wasn't it
part of prior conversations? Perhaps we can come up with a good solution
that addresses it as well.

> > You'll get a flow_out for the domain->socket->secmark->(any other
> > secmark that we happen to hit which is non-ideal)->association.
> 
> Have you never gone thru multiple security check points at airports
> and such?
> 

Yes, and my name stays the same after each one.

> >
> > There is not an intuitive way of binding a domain to an association.
> 
> I think we have mixup on terminology here. An "association" is traditionally
> used to refer to an IPSec SA and it has nothing innately to do with
> flow-control.
> 

It does, the association has a label, policy should allow me to say
"this domain can write data to only this association". That puts the
ability to enforce confidentiality at the network level inside SELinux
policy, where we want it.

Meaning, for policy analysis we need to show that certain domains can
only speak to domains on other machines via certain associations. 


I see that James responded on LSPP yesterday with same basic
requirements that I'm trying to allude to here so I'll just wrap this
up.. 


--
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: SELinux Networking Enhancements

[Joe Nall]

On Oct 18, 2006, at 8:23 AM, Joshua Brindle wrote:

> On Mon, 2006-10-16 at 09:31 -0500, Venkat Yekkirala wrote:
>> Agreed. But I fail to see where having a "default" peer on a  
>> netfilter
>> rule/secpoint
>> would hurt. FYI- this is how MLS implementations work. You have an  
>> interface
>> that you would label everything coming thru by default with "Secret".
>>
>
> first, getpeercon() returning something that isn't an external  
> label is
> not good, how are applications to cope with this behavior?
>
> Second, MLS implementations work this way because they are hard coded
> to. We aren't hard coded to do anything, there is no "default" in this
> case, you'd have to specify defaults with iptables and I question how
> scalable that is anyway. You either have really course grained  
> secmarks
> (one per interface with 1 type and an MLS range) or if you start
> breaking it down into protocol, port, etc you have a full set for  
> every
> interface with a different type and the mls range. There doesn't  
> seem to
> be alot of flexibility here.

When we hook up to a WAN in a data center that connects to an allied
network full of Windows boxes, the whole WAN has a sensitivity label,
regardless of the port/protocol. Setting the interface to a particular
SL is a simple way to ensure that we don't make the mistake of
sending inappropriate data to that interface.

It also matches the 'real world' in that the installation guidance is
'the cables with the read/black stripes on the connector are S/REL XXX.'

That said, given the limited number of ports/protocols allowed in these
cases, writing a script to generate policy/iptables setups on a per
interface basis should not be too difficult.

I'm much more concerned about not having the capability at all right  
now :(

joe

--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> On Mon, 2006-10-16 at 09:31 -0500, Venkat Yekkirala wrote:
> > > Its not that we don't understand it, its just that we
> don't agree. The
> > > secpoint "paradigm" is convoluted IMO and we need
> something simple.
> >
> > But no one has comeup with a "simpler" alternative that
> > also addresses the shortcomings of secmark.
> >
> > > I
> > > basically bailed on this conversation because it wasn't going
> > > anywhere.
> > >
> > > While you still disagree, I think most of us believe that secmarks
> >
> > Only there are no secmarks in the new design to begin with. The word
> > is a holdover from the current secmark design.
> >
>
> the point is that the new design is being challenged, you can't fall
> back on "that isn't what it means anymore" because it is what it means
> until your changes go in.

But you don't look at elements of any new design as elements of an
old design with old meanings. When you do that you will not only be
confused,
you will have also missed the goals the new design is attempting to satisfy.

For example, you don't look at the design of an airplane and complain the
yoke
isn't a steering. You ought to look to see what an airplane accomplishes and
objectively determine whether it meets the needs.

If you don't have a runway in your backyard :) then you can't have an
airplane
and you reject it. But if you do and all the destinations do as well (some
of
which you can't reach by car), there's no reason to reject the airplane on
the
premise it doesn't have a steering like in a car.

>
> > > should be _local only_ enforcement, not peer labeling, an
> > > ipsec rule is
> > > in no way a "peer",
> >
> > Agreed. But I fail to see where having a "default" peer on
> a netfilter
> > rule/secpoint
> > would hurt. FYI- this is how MLS implementations work. You
> have an interface
> > that you would label everything coming thru by default with
> "Secret".
> >
>
> first, getpeercon() returning something that isn't an
> external label is
> not good, how are applications to cope with this behavior?

I thought you had a point there, so I did offer to have it return
only a true peer.

>
> Second, MLS implementations work this way because they are hard coded
> to. We aren't hard coded to do anything, there is no "default" in this
> case, you'd have to specify defaults with iptables and I question how
> scalable that is anyway. You either have really course
> grained secmarks
> (one per interface with 1 type and an MLS range) or if you start
> breaking it down into protocol, port, etc you have a full set
> for every
> interface with a different type and the mls range.

based on your needs...
> There
> doesn't seem to
> be alot of flexibility here.

>From an MLS point of view, more flexibility than is needed; for example,
you would still have fine-grained rules down to port, etc., but where you
need to treat all the traffic as secret, you would just have secret on
each one of those rules.

>
> > Also, don't we deem all data on a filesystem that doesn't
> support individual
> > file labeling to be at the label it's mounted at?
> >
>
> no, it gets a label based on genfscon (eg., cd's get
> iso9660_t no matter
> where it is mounted)

The mechanism doesn't matter. The fact still remains you have
a "default" label (or you could in the future) where all the
files on a filesystem that don't have an explicit label would
assume that label.

>
> > > a remote socket is a peer and a peer should
> > > represent that.
> >
> > Sure. That's also allowed in secpoint.
> >
>
> secpoint supports that by mutating labels. If there is no labeled
> networking present getpeercon() returns a totally different
> label from a
> totally different place that represents a totally different thing
> (secpoint isn't the same as remote peer IMO)

There CAN be use cases where you can in fact leverage this, but I
did offer to restrict getpeercon to strictly an explicit peer label
since you seemed to have a need for an explicitly labeled peer.

>
> > >
> > > I believe the secpoint paradigm is very complicated to
> understand and
> > > use, for example, you'll have to have a number of flow_in
> and flow_out
> > > rules not necessarily related to the domain and socket being used.
> >
> > Exactly the kind of stuff needed for "comprehensive"
> flow-control that
> > would also accommodate forwarded traffic. And we seem to
> have just run
> > away from it so far.
> >
>
> So I never heard about this requirement until now.

I am very sorry to say this, but that's because you weren't paying
enough attention. I mentioned this as one of the drawbacks as recently
as this past weekend in this very same thread, but it was also a part
of my original design proposal for labeled networking pointed out from
time to time in the conversations we had the past several months.

> I'll grant
> that it is
> an interesting problem but if it is truly a requirement why wasn't it
> part of prior conversations? Perhaps we can come up with a
> good solution
> that addresses it as well.

Which secpoint set out to solve (remember: it allowed for all the
security goals that were possible in secmark and then some. Now if people
are getting confused that they don't find a steering wheel in the airplane
and simply refuse to use the yoke, it's not my problem).

>
> > > You'll get a flow_out for the domain->socket->secmark->(any other
> > > secmark that we happen to hit which is non-ideal)->association.
> >
> > Have you never gone thru multiple security check points at airports
> > and such?
> >
>
> Yes, and my name stays the same after each one.

But you could also be "labeled" differently if there were a trustworthy
mechanism to carry the label and have fine-grained security points where
they woould process only "transferring passengers" as opposed to those
that are initially boarding. I am not saying they couldn't also use your
name (in addition to the label), the question is what would you objectively
need to satisfy the particular set of security goals at hand.

>
> > >
> > > There is not an intuitive way of binding a domain to an
> association.
> >
> > I think we have mixup on terminology here. An "association"
> is traditionally
> > used to refer to an IPSec SA and it has nothing innately to do with
> > flow-control.
> >
>
> It does, the association has a label, policy should allow me to say
> "this domain can write data to only this association". That puts the
> ability to enforce confidentiality at the network level inside SELinux
> policy, where we want it.

FYI- associations don't operate entirely the way you like them to. For
example,
ALL traffic between 2 machines ordinarily shares the same association.
This is because of the nature of the association (encryption,
authentication,
compress). You could also specify that each and every communication between
a
pair of machines use a different association, but that would be a
performance bummer.
What we have done is to make sure apache_t traffic can only use the apache_t
association.
So both the DNS queries and http service replies going to the SAME machine
would use
the SAME association with the context apache_t (rightfully so since it's ALL
apache traffic).
But if the DNS traffic is going to a different machine then it would use a
different
association, but still labeled apache_t. Unless ofcourse you set it up to
use a unique
association for each communication channel.

Also, as mentioned in the past, the netfilter hooks come into play AFTER the
xfrms are chosen. So, one couldn't base the association on the netfilter
context.

>
> Meaning, for policy analysis we need to show that certain domains can
> only speak to domains on other machines via certain associations.

You can ONLY show what associations a proc can recv from in your policy.
Whether a remote domain can receive your traffic or not is dictated on
the remote machine.

>
>
> I see that James responded on LSPP yesterday with same basic
> requirements that I'm trying to allude to here so I'll just wrap this
> up..

A natural result when people (sadly a couple or so) refuse to objectively
assess a design based on what it can accomplish. I have the satisfaction of
knowing though that I gave it my best shot.


--
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: SELinux Networking Enhancements

[Joshua Brindle]

On Wed, 2006-10-18 at 10:10 -0500, Venkat Yekkirala wrote:
<snip>
> >
> > first, getpeercon() returning something that isn't an
> > external label is
> > not good, how are applications to cope with this behavior?
> 
> I thought you had a point there, so I did offer to have it return
> only a true peer.
> 

Right, ok :)

> >
> > Second, MLS implementations work this way because they are hard coded
> > to. We aren't hard coded to do anything, there is no "default" in this
> > case, you'd have to specify defaults with iptables and I question how
> > scalable that is anyway. You either have really course
> > grained secmarks
> > (one per interface with 1 type and an MLS range) or if you start
> > breaking it down into protocol, port, etc you have a full set
> > for every
> > interface with a different type and the mls range.
> 
> based on your needs...
> > There
> > doesn't seem to
> > be alot of flexibility here.
> 
> From an MLS point of view, more flexibility than is needed; for example,
> you would still have fine-grained rules down to port, etc., but where you
> need to treat all the traffic as secret, you would just have secret on
> each one of those rules.
> 

Fine.. if MLS doesn't need the flexibility we should consider it a done
deal and try to address the flexibility necessary for TE.

> >
> > > Also, don't we deem all data on a filesystem that doesn't
> > support individual
> > > file labeling to be at the label it's mounted at?
> > >
> >
> > no, it gets a label based on genfscon (eg., cd's get
> > iso9660_t no matter
> > where it is mounted)
> 
> The mechanism doesn't matter. The fact still remains you have
> a "default" label (or you could in the future) where all the
> files on a filesystem that don't have an explicit label would
> assume that label.
> 

no, all files on that filesystem get that label regardless. Your
proposal has fallbacks on a per-packet basis, not analogous to an entire
filesystem being labeled something. (eg., when a filesystem has a mount
label there is no possiblity of 'refining' the label if present, which
is what you are trying to do. 

> >
<snip>
> > >
> >
> > So I never heard about this requirement until now.
> 
> I am very sorry to say this, but that's because you weren't paying
> enough attention. I mentioned this as one of the drawbacks as recently
> as this past weekend in this very same thread, but it was also a part
> of my original design proposal for labeled networking pointed out from
> time to time in the conversations we had the past several months.
> 

I know this, what I meant was it was never added as a requirement on the
old system or the conference call or for a couple weeks after the call,
it was added last week as a justification for the new design. 

Which is fine, most of my arguments until now haven't taken it into
account because it was new, I have no problem trying to facilitate that
in the design but the fact that secpoint covers it doesn't automatically
make it good. 

> > I'll grant
> > that it is
> > an interesting problem but if it is truly a requirement why wasn't it
> > part of prior conversations? Perhaps we can come up with a
> > good solution
> > that addresses it as well.
> 
> Which secpoint set out to solve (remember: it allowed for all the
> security goals that were possible in secmark and then some. Now if people
> are getting confused that they don't find a steering wheel in the airplane
> and simply refuse to use the yoke, it's not my problem).
> 

see above.

> >
> > > > You'll get a flow_out for the domain->socket->secmark->(any other
> > > > secmark that we happen to hit which is non-ideal)->association.
> > >
> > > Have you never gone thru multiple security check points at airports
> > > and such?
> > >
> >
> > Yes, and my name stays the same after each one.
> 
> But you could also be "labeled" differently if there were a trustworthy
> mechanism to carry the label and have fine-grained security points where
> they woould process only "transferring passengers" as opposed to those
> that are initially boarding. I am not saying they couldn't also use your
> name (in addition to the label), the question is what would you objectively
> need to satisfy the particular set of security goals at hand.
> 

fine, I don't have a problem with the additional checks but the
implementation now is strange. With secpeer I start out as Joshua, then
change to passed_first_secpoint then passed_second_secpoint and finally
passed_plane_gate and the access checks are implemented that way:

allow joshua passed_first_secpoint flow_out
allow passed_first_secpoint passed_second_secpoint flow_out
allow passed_second_secpoint passed_plane_gate flow_out

What needs to happen is that I'm Joshua the entire time..

allow joshua passed_first_secpoint flow_out
allow joshua passed_second_secpoint flow_out
allow joshua passed_plane_gate flow_out

this maintains me as the subject, which is appropriate.


> >
> > > >
> > > > There is not an intuitive way of binding a domain to an
> > association.
> > >
> > > I think we have mixup on terminology here. An "association"
> > is traditionally
> > > used to refer to an IPSec SA and it has nothing innately to do with
> > > flow-control.
> > >
> >
> > It does, the association has a label, policy should allow me to say
> > "this domain can write data to only this association". That puts the
> > ability to enforce confidentiality at the network level inside SELinux
> > policy, where we want it.
> 
> FYI- associations don't operate entirely the way you like them to. For
> example,
> ALL traffic between 2 machines ordinarily shares the same association.
> This is because of the nature of the association (encryption,
> authentication,
> compress). You could also specify that each and every communication between
> a
> pair of machines use a different association, but that would be a
> performance bummer.
> What we have done is to make sure apache_t traffic can only use the apache_t
> association.
> So both the DNS queries and http service replies going to the SAME machine
> would use
> the SAME association with the context apache_t (rightfully so since it's ALL
> apache traffic).
> But if the DNS traffic is going to a different machine then it would use a
> different
> association, but still labeled apache_t. Unless ofcourse you set it up to
> use a unique
> association for each communication channel.
> 
> Also, as mentioned in the past, the netfilter hooks come into play AFTER the
> xfrms are chosen. So, one couldn't base the association on the netfilter
> context.

Right, I'm aware of this limitation and it's very inconvenient (I
believe its what Chris is mainly objecting to)

> >
> > Meaning, for policy analysis we need to show that certain domains can
> > only speak to domains on other machines via certain associations.
> 
> You can ONLY show what associations a proc can recv from in your policy.
> Whether a remote domain can receive your traffic or not is dictated on
> the remote machine.
> 

I think this seriously limits the usefulness of this. I *must* be able
to specify locally who can talk to me from a remote machine. Without
being able to do this I implicitly have to trust the remote entirely (no
possibility of limited trust)

> >
> >
> > I see that James responded on LSPP yesterday with same basic
> > requirements that I'm trying to allude to here so I'll just wrap this
> > up..
> 
> A natural result when people (sadly a couple or so) refuse to objectively
> assess a design based on what it can accomplish. I have the satisfaction of
> knowing though that I gave it my best shot.
> 

That doesn't mean we can't come up with a design that addresses the
limitations and still does what we want, hopefully... 

I know this is frustrating but a better model in the end is better for
everyone, please don't give up :( .. I wish I knew more about the actual
implementation, it feels like I might be missing some subtle details
because of this.


--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

[My apoligies for the nearly unnavigable post but had to keep context]

> > > Second, MLS implementations work this way because they
> are hard coded
> > > to. We aren't hard coded to do anything, there is no
> "default" in this
> > > case, you'd have to specify defaults with iptables and I
> question how
> > > scalable that is anyway. You either have really course
> > > grained secmarks
> > > (one per interface with 1 type and an MLS range) or if you start
> > > breaking it down into protocol, port, etc you have a full set
> > > for every
> > > interface with a different type and the mls range.
> >
> > based on your needs...
> > > There
> > > doesn't seem to
> > > be alot of flexibility here.
> >
> > From an MLS point of view, more flexibility than is needed;
> for example,
> > you would still have fine-grained rules down to port, etc.,
> but where you
> > need to treat all the traffic as secret, you would just
> have secret on
> > each one of those rules.
> >
>
> Fine.. if MLS doesn't need the flexibility we should consider
> it a done
> deal and try to address the flexibility necessary for TE.

You would have just as many "secpoints" as you currently
would "secmarks". No difference there. Same level of flexibility
and scalability. Nothing more, nothing less.

Example:

1. An outbound connection to port 80 on machine 10.0.0.1

SECMARK:
-A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
SECMARK --selctx system_u:object_r:http_client_packet_t:s2

SECPOINT:
-A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
SECMARK --selctx system_u:object_r:httpd_t:s0

Reason for the change in Type from http_client_packet_t to httpd_t:

All incoming packets on this connection would be from a web-server so should
be carrying httpd_t as opposed to http_client_packet_t. Also, all outbound
traffic on this connection carries the originating socket context
(firefox_t)
which would be flow-controlled against httpd_t.

So, just a change in semantics. Whereas you formerly had
allow firefox_t http_client_packet_t:packet { send recv }

you would now have:

allow firefox_t httpd_t:packet { recv }
allow firefox_t httpd_t:packet { flow_out }

For the forwarding case:

-A PREROUTING -p tcp -s 10.0.0.5  -j SECMARK --selctx
system_u:object_r:webonly_t:s0

-A FORWARD -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
SECMARK --selctx system_u:object_r:httpd_t:s0
-A PREROUTING -p tcp -s 10.0.0.1 --sport 80 -j SECMARK --selctx
system_u:object_r:httpd_t:s0
(can also use CONNSECMARK to save from FORWARD and restore it at PREROUTING
to label all traffic back from
the webserver)

allow webonly_t httpd_t:packet { flow_out }
allow httpd_t webonly_t:packet { flow_out }

I have only given the main rules and there are ofcourse other supporting
rules required
to get things going.

>
> > >
> > > > Also, don't we deem all data on a filesystem that doesn't
> > > support individual
> > > > file labeling to be at the label it's mounted at?
> > > >
> > >
> > > no, it gets a label based on genfscon (eg., cd's get
> > > iso9660_t no matter
> > > where it is mounted)
> >
> > The mechanism doesn't matter. The fact still remains you have
> > a "default" label (or you could in the future) where all the
> > files on a filesystem that don't have an explicit label would
> > assume that label.
> >
>
> no, all files on that filesystem get that label regardless. Your
> proposal has fallbacks on a per-packet basis, not analogous
> to an entire
> filesystem being labeled something. (eg., when a filesystem
> has a mount
> label there is no possiblity of 'refining' the label if present, which
> is what you are trying to do.

And who says you can't have a sophisticated filesystem that would allow
for such a refining? I am not an expert on Linux filesystems, but this
can be a nice feature for the future :)

>
> > >
> <snip>
> > > >
> > >
> > > So I never heard about this requirement until now.
> >
> > I am very sorry to say this, but that's because you weren't paying
> > enough attention. I mentioned this as one of the drawbacks
> as recently
> > as this past weekend in this very same thread, but it was
> also a part
> > of my original design proposal for labeled networking
> pointed out from
> > time to time in the conversations we had the past several months.
> >
>
> I know this, what I meant was it was never added as a
> requirement on the
> old system or the conference call or for a couple weeks after
> the call,
> it was added last week as a justification for the new design.

Forwarding was what started me off several months ago. See:
https://www.redhat.com/archives/redhat-lspp/2006-June/msg00011.html
https://www.redhat.com/archives/redhat-lspp/2006-June/msg00012.html

>
> Which is fine, most of my arguments until now haven't taken it into
> account because it was new, I have no problem trying to
> facilitate that
> in the design but the fact that secpoint covers it doesn't
> automatically
> make it good.

True. And this is why the design has undergone several refinements
and simplifications (no trasitions for example) and we already were
looking at another refinement for getpeercon in the past couple days.

>
> > > I'll grant
> > > that it is
> > > an interesting problem but if it is truly a requirement
> why wasn't it
> > > part of prior conversations? Perhaps we can come up with a
> > > good solution
> > > that addresses it as well.
> >
> > Which secpoint set out to solve (remember: it allowed for all the
> > security goals that were possible in secmark and then some.
> Now if people
> > are getting confused that they don't find a steering wheel
> in the airplane
> > and simply refuse to use the yoke, it's not my problem).
> >
>
> see above.

see above :)

>
> > >
> > > > > You'll get a flow_out for the
> domain->socket->secmark->(any other
> > > > > secmark that we happen to hit which is
> non-ideal)->association.
> > > >
> > > > Have you never gone thru multiple security check points
> at airports
> > > > and such?
> > > >
> > >
> > > Yes, and my name stays the same after each one.
> >
> > But you could also be "labeled" differently if there were a
> trustworthy
> > mechanism to carry the label and have fine-grained security
> points where
> > they woould process only "transferring passengers" as
> opposed to those
> > that are initially boarding. I am not saying they couldn't
> also use your
> > name (in addition to the label), the question is what would
> you objectively
> > need to satisfy the particular set of security goals at hand.
> >
>
> fine, I don't have a problem with the additional checks but the
> implementation now is strange. With secpeer I start out as
> Joshua, then
> change to passed_first_secpoint then passed_second_secpoint
> and finally
> passed_plane_gate and the access checks are implemented that way:
>
> allow joshua passed_first_secpoint flow_out
> allow passed_first_secpoint passed_second_secpoint flow_out
> allow passed_second_secpoint passed_plane_gate flow_out
>
> What needs to happen is that I'm Joshua the entire time..
>
> allow joshua passed_first_secpoint flow_out
> allow joshua passed_second_secpoint flow_out
> allow joshua passed_plane_gate flow_out
>
> this maintains me as the subject, which is appropriate.
>

This is what I set out to do and couldn't due to constraints.
My argument has been that you could manage it in the policy
and Chris seemed to agree (see
http://marc.theaimsgroup.com/?l=selinux&m=116075228014626&w=2).
But since this keeps coming up we will try to explore some "bad"
options and see what happens. Stay tuned on this, but I doubt
we can get this currently.

>
> > >
> > > > >
> > > > > There is not an intuitive way of binding a domain to an
> > > association.
> > > >
> > > > I think we have mixup on terminology here. An "association"
> > > is traditionally
> > > > used to refer to an IPSec SA and it has nothing
> innately to do with
> > > > flow-control.
> > > >
> > >
> > > It does, the association has a label, policy should allow
> me to say
> > > "this domain can write data to only this association".
> That puts the
> > > ability to enforce confidentiality at the network level
> inside SELinux
> > > policy, where we want it.
> >
> > FYI- associations don't operate entirely the way you like
> them to. For
> > example,
> > ALL traffic between 2 machines ordinarily shares the same
> association.
> > This is because of the nature of the association (encryption,
> > authentication,
> > compress). You could also specify that each and every
> communication between
> > a
> > pair of machines use a different association, but that would be a
> > performance bummer.
> > What we have done is to make sure apache_t traffic can only
> use the apache_t
> > association.
> > So both the DNS queries and http service replies going to
> the SAME machine
> > would use
> > the SAME association with the context apache_t (rightfully
> so since it's ALL
> > apache traffic).
> > But if the DNS traffic is going to a different machine then
> it would use a
> > different
> > association, but still labeled apache_t. Unless ofcourse
> you set it up to
> > use a unique
> > association for each communication channel.
> >
> > Also, as mentioned in the past, the netfilter hooks come
> into play AFTER the
> > xfrms are chosen. So, one couldn't base the association on
> the netfilter
> > context.
>
> Right, I'm aware of this limitation and it's very inconvenient (I
> believe its what Chris is mainly objecting to)

Yes. I believe so as well and unfortunately we can't do anything here.

>
> > >
> > > Meaning, for policy analysis we need to show that certain
> domains can
> > > only speak to domains on other machines via certain associations.
> >
> > You can ONLY show what associations a proc can recv from in
> your policy.
> > Whether a remote domain can receive your traffic or not is
> dictated on
> > the remote machine.
> >
>
> I think this seriously limits the usefulness of this. I *must* be able
> to specify locally who can talk to me from a remote machine.

Yes and this is indeed what you can acomplish what "remote" domains
a sock can recv.

If this isn't what you meant, please give me an example and we will try
again.

> Without
> being able to do this I implicitly have to trust the remote
> entirely (no
> possibility of limited trust)

No, you aren't trusting the remote entirely. Your local policy
is deciding whether you can receive packets from a such and such
remote peer.

>
> > >
> > >
> > > I see that James responded on LSPP yesterday with same basic
> > > requirements that I'm trying to allude to here so I'll
> just wrap this
> > > up..
> >
> > A natural result when people (sadly a couple or so) refuse
> to objectively
> > assess a design based on what it can accomplish. I have the
> satisfaction of
> > knowing though that I gave it my best shot.
> >
>
> That doesn't mean we can't come up with a design that addresses the
> limitations and still does what we want, hopefully...

We would need to first understand the specific limitations though
and these are what I have been trying to understand, but in vain.

>
> I know this is frustrating but a better model in the end is better for
> everyone, please don't give up :( .. I wish I knew more about
> the actual
> implementation, it feels like I might be missing some subtle details
> because of this.
>

The biggest shift in the design is coming from here:
If you want to flow control forwarded traffic, you would necessarily
have to look at the current secmarking points for the outbound as
flowcontrol points (which I have sought to characterize as secpoints
to mark the distinction). And when you do look at the outbound secmarking
points as flow-control points, you would then want to look at the inbound
ones as flow-control points as well for consistency. Everything else pretty
much draws from here.

Hope that helps.


--
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: SELinux Networking Enhancements

[Joshua Brindle]

Venkat Yekkirala wrote:
>>>       
>> Fine.. if MLS doesn't need the flexibility we should consider
>> it a done
>> deal and try to address the flexibility necessary for TE.
>>     
>
> You would have just as many "secpoints" as you currently
> would "secmarks". No difference there. Same level of flexibility
> and scalability. Nothing more, nothing less.
>
>   
 Not if you have to differentiate the level on the interfaces, which was 
my point but it's moot now anyway

> Example:
>
> 1. An outbound connection to port 80 on machine 10.0.0.1
>
> SECMARK:
> -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:http_client_packet_t:s2
>
> SECPOINT:
> -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:httpd_t:s0
>
> Reason for the change in Type from http_client_packet_t to httpd_t:
>
>   
so what about all the other apps that use port 80 like yum, rss 
aggregators, email clients (when image links are on the body), etc, 
etc.. there are probably hundreds. I don't think you want them all 
sending packets labeled with firefox_t

>> I know this, what I meant was it was never added as a
>> requirement on the
>> old system or the conference call or for a couple weeks after
>> the call,
>> it was added last week as a justification for the new design.
>>     
>
> Forwarding was what started me off several months ago. See:
> https://www.redhat.com/archives/redhat-lspp/2006-June/msg00011.html
> https://www.redhat.com/archives/redhat-lspp/2006-June/msg00012.html
>
>   
Well that explains it.. I'm not on the LSPP list..
>> Which is fine, most of my arguments until now haven't taken it into
>> account because it was new, I have no problem trying to
>> facilitate that
>> in the design but the fact that secpoint covers it doesn't
>> automatically
>> make it good.
>>     
>
> True. And this is why the design has undergone several refinements
> and simplifications (no trasitions for example) and we already were
> looking at another refinement for getpeercon in the past couple days.
>   
Fair enough, I think we are all starting to understand one another much 
better now so hopefully we can get something that works for everyone :)
>> fine, I don't have a problem with the additional checks but the
>> implementation now is strange. With secpeer I start out as
>> Joshua, then
>> change to passed_first_secpoint then passed_second_secpoint
>> and finally
>> passed_plane_gate and the access checks are implemented that way:
>>
>> allow joshua passed_first_secpoint flow_out
>> allow passed_first_secpoint passed_second_secpoint flow_out
>> allow passed_second_secpoint passed_plane_gate flow_out
>>
>> What needs to happen is that I'm Joshua the entire time..
>>
>> allow joshua passed_first_secpoint flow_out
>> allow joshua passed_second_secpoint flow_out
>> allow joshua passed_plane_gate flow_out
>>
>> this maintains me as the subject, which is appropriate.
>>
>>     
>
> This is what I set out to do and couldn't due to constraints.
> My argument has been that you could manage it in the policy
> and Chris seemed to agree (see
> http://marc.theaimsgroup.com/?l=selinux&m=116075228014626&w=2).
> But since this keeps coming up we will try to explore some "bad"
> options and see what happens. Stay tuned on this, but I doubt
> we can get this currently.
>
>   
hrm, ok. So it sounds like we are mostly on the same page but the 
implementation constraints are killing us?
>> Right, I'm aware of this limitation and it's very inconvenient (I
>> believe its what Chris is mainly objecting to)
>>     
>
> Yes. I believe so as well and unfortunately we can't do anything here.
>
>   
ok.
>> I think this seriously limits the usefulness of this. I *must* be able
>> to specify locally who can talk to me from a remote machine.
>>     
>
> Yes and this is indeed what you can acomplish what "remote" domains
> a sock can recv.
>
> If this isn't what you meant, please give me an example and we will try
> again.
>
>   
it may be. What would the rules look like for the client running as 
semanage_t and the server running as pms_t ?
>> That doesn't mean we can't come up with a design that addresses the
>> limitations and still does what we want, hopefully...
>>     
>
> We would need to first understand the specific limitations though
> and these are what I have been trying to understand, but in vain.
>
>   
Ok, good.
>> I know this is frustrating but a better model in the end is better for
>> everyone, please don't give up :( .. I wish I knew more about
>> the actual
>> implementation, it feels like I might be missing some subtle details
>> because of this.
>>
>>     
>
> The biggest shift in the design is coming from here:
> If you want to flow control forwarded traffic, you would necessarily
> have to look at the current secmarking points for the outbound as
> flowcontrol points (which I have sought to characterize as secpoints
> to mark the distinction). And when you do look at the outbound secmarking
> points as flow-control points, you would then want to look at the inbound
> ones as flow-control points as well for consistency. Everything else pretty
> much draws from here.
>   
That is fine, the current design loses a ton of granularity by doing 
this though. Where you say the label gets 'refined' I believe it becomes 
ambiguous. When something is joshua_t and then turns into a generic 
pass_some_secpoint_t you've lost alot of information.

--
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: SELinux Networking Enhancements

[Venkat Yekkirala]

> > Example:
> >
> > 1. An outbound connection to port 80 on machine 10.0.0.1
> >
> > SECMARK:
> > -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> > SECMARK --selctx system_u:object_r:http_client_packet_t:s2
> >
> > SECPOINT:
> > -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> > SECMARK --selctx system_u:object_r:httpd_t:s0
> >
> > Reason for the change in Type from http_client_packet_t to httpd_t:
> >
> >
> so what about all the other apps that use port 80 like yum, rss
> aggregators, email clients (when image links are on the body), etc,
> etc.. there are probably hundreds. I don't think you want them all
> sending packets labeled with firefox_t

No. You already have these running as yum_t, rss_aggregator_t,
email_client_t,
etc., don't you? The packet will just carry the label from the socket
instead
of from the secmark.

SECMARK:
allow yum_t http_client_packet_t:packet { send };
allow rss_aggregator_t http_client_packet_t:packet { send };
allow email_client_t http_client_packet_t:packet { send };
...

SECPOINT:
allow yum_t httpd_t:packet { flow_out };
allow rss_aggregator_t httpd_t:packet { flow_out };
allow email_client_t httpd_t:packet { flow_out };
...

Same number of rules in both cases. IOW:

SECMARK:
Can a socket send a http_client_packet_t?
Forwarded traffic: NA (Not Applicable)

SECPOINT:
Can a packet from a socket (firefox_t) flow_out to httpd_t?
Forwarded traffic: Can a packet carrying a specific domain label (webonly_t)
flow_out to httpd_t?

> >> I think this seriously limits the usefulness of this. I
> *must* be able
> >> to specify locally who can talk to me from a remote machine.
> >>
> >
> > Yes and this is indeed what you can acomplish what "remote" domains
> > a sock can recv.
> >
> > If this isn't what you meant, please give me an example and
> we will try
> > again.
> >
> >
> it may be. What would the rules look like for the client running as
> semanage_t and the server running as pms_t ?

On the server:

allow pms_t semanage_t:packet { recv }

On the client:

allow semanage_t pms_t:packet { flow_out } [ Assuming you have secpoint
defined as pms_t on the client ]
allow semanage_t pms_t:packet { recv }

You now have assurance, on the server, that no one else but semanage_t
can talk to pms_t, and you have assurance on the client that semanage_t
can only correspond with pms_t.

The associations used will be based on the socket context (all traffic
from pms_t will use pms_t association and all traffic from semanage_t
will use the semanage_t assoc; this will happen transparently once I
move the "equality" constraint from the constraints file into the kernel.

Once you have labeled-ipsec being used, you will additionally need the
following rules for flow-control:

SERVER:

allow semanage_t pms_client_t:packet { flow_in }
allow pms_t pms_client_t:packet { flow_out }

CLIENT:

allow semanage_t pms_server_t:packet { flow_out }
allow pms_t pms_server_t:packet { flow_in }

> That is fine, the current design loses a ton of granularity

Not totally though. You are guaranteed to use joshua_t as the
subject at the first security point on the way out. But after
this you are right, you are losing the granularity, although
the question to be asked is if this loss of granularity will
in practice matter? The reason I ask is that assuming we somehow
let the last secpoint prevail and do just one check, you are
then still doing only one check where joshua_t is the subject
(with the target being the last secpoint). So the difference
is:

allow joshua_t secpoint1_t:packet { flow_out }
allow secpoint1_t secpoint2_t:packet { flow_out }
allow secpoint2_t network_t:packet { flow_out }

versus

allow joshua_t secpoint2_t:packet { flow_out }

> by doing
> this though. Where you say the label gets 'refined' I believe
> it becomes
> ambiguous. When something is joshua_t and then turns into a generic
> pass_some_secpoint_t you've lost alot of information.
>

PS: Our office is moving between today/tomorrow but should be back up
running sometime Monday.


--
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: SELinux Networking Enhancements

[James Morris]

On Thu, 19 Oct 2006, Venkat Yekkirala wrote:

> You would have just as many "secpoints" as you currently
> would "secmarks". No difference there. Same level of flexibility
> and scalability. Nothing more, nothing less.
> 
> Example:
> 
> 1. An outbound connection to port 80 on machine 10.0.0.1
> 
> SECMARK:
> -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:http_client_packet_t:s2
> 
> SECPOINT:
> -A OUTPUT -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:httpd_t:s0
> 
> Reason for the change in Type from http_client_packet_t to httpd_t:
> 
> All incoming packets on this connection would be from a web-server so should
> be carrying httpd_t as opposed to http_client_packet_t. Also, all outbound
> traffic on this connection carries the originating socket context
> (firefox_t)
> which would be flow-controlled against httpd_t.
> 
> So, just a change in semantics. Whereas you formerly had
> allow firefox_t http_client_packet_t:packet { send recv }
> 
> you would now have:
> 
> allow firefox_t httpd_t:packet { recv }
> allow firefox_t httpd_t:packet { flow_out }
> 
> For the forwarding case:
> 
> -A PREROUTING -p tcp -s 10.0.0.5  -j SECMARK --selctx
> system_u:object_r:webonly_t:s0
> 
> -A FORWARD -m state --state NEW -p tcp -d 10.0.0.1 --dport 80 -j
> SECMARK --selctx system_u:object_r:httpd_t:s0
> -A PREROUTING -p tcp -s 10.0.0.1 --sport 80 -j SECMARK --selctx
> system_u:object_r:httpd_t:s0
> (can also use CONNSECMARK to save from FORWARD and restore it at PREROUTING
> to label all traffic back from
> the webserver)
> 
> allow webonly_t httpd_t:packet { flow_out }
> allow httpd_t webonly_t:packet { flow_out }
> 
> I have only given the main rules and there are ofcourse other supporting
> rules required
> to get things going.

This is too complicated, most people will not understand it.  I think it's 
also a security risk, because of the complexity of composing these 
labeling mechanisms and the chance that mistakes will be made in 
deployment, as well as scaring people away from using the technology 
altogether.



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