RE: ipsec, netlabels, secmark- How about a little usability?

RE: ipsec, netlabels, secmark- How about a little usability?

[Venkat Yekkirala]

> We have been having some meetings to discuss how we can use 
> this stuff 
> in the real world (IE Non MLS), and I think the current 
> implementation 
> is coming up short.  The discussions I have seen have talked 
> about using 
> getpeercon to look at the other end of the connections, but 
> this is not 
> in the spirit of SELinux where modification of the 
> applications should 
> not be necessary to secure the environment.
> 

I would like to start off with a reference to the Labeled Networking Design
doc at http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2

While secmark as currently implemented upstream "marks" packets,
the secid reconciliation patches being considered for upstream
turn secmark contexts that are defined using iptables, into contexts
on the respective "flow control points". This is a significant shift
in the paradigm and the benefits will be obvious in the later part of
the discussion:

Example (INCOMING PACKETS):

iptables -t mangle -A INPUT -p tcp --dport 22 -m state --state NEW -j
SEL_SSHD
iptables -t mangle -A SEL_SSHD -j SECMARK --selctx
system_u:object_r:sshd_t:s0
iptables -t mangle -A SEL_SSHD -j ACCEPT

The above is really defining the context on an "entry point".

Any packets not labeled externally using labeled IPSec, or CIPSO and
"flowing in" thru that entry point will assume the "entry point" context,
but only by virtue of the packets coming in thru that "entry point".

So, what happens if an externally labeled packet (e.g.: Labeled IPSec)
comes in thru the above entry point? First of all, a check is made to
see if a packet so labeled using IPSec (unlabeled if no IPSec) can
"flow in" thru the "entry point". If it can, and if there's an
IPSec label on the packet, a transition sid is computed between the
"entry point" label and the IPSec label and the packet will be marked
with this transition sid. The transition label will either be the IPSec
label (default) or any other label as defined by SELinux policy transition
rules.

The socket is then checked for packet.recv access to the packet before
the socket can receive the packet.

Example (OUTGOING PACKETS):

iptables -t mangle -A OUTPUT -p tcp --dport 22 -m state --state NEW -j
SEL_SSH_CLIENT
iptables -t mangle -A SEL_SSH_CLIENT -j SECMARK --selctx
system_u:object_r:ssh_client_t:s0
iptables -t mangle -A SEL_SSH_CLIENT -j ACCEPT

The above is really defining the context on an "exit point".

A locally generated packet will normally assume the label of the socket.
Next,
a check is made to see if the packet can "flow out" thru IPSec (unlabeled if
not using Labeled IPSec). If the packet uses labeled IPSec, a transition sid
is computed between the socket label and the IPSec label. The transition
label
will be the IPSec label (default) or any other label as defined by SELinux
policy rules.

The packet is then checked for "flow out" access to the "exit point"
defined using iptables output rules above.

> 
> Lets look at some real world situations where having better 
> controls on 
> the network would work and someone explain to me how Joe Average 
> SysAdmin will set them up.

I will try to show elements of policy for the below example, but
turning it into something useable by Joe Average will obviously
involve integration and policy abstractions that are currently
outside the scope of this discussion. I will let "policy experts"
out there to weigh in here with suggestions and ideas.

PERFORMANCE:

There were some concerns about iptables performance. While
I haven't done any testing in this regard, I would think that it would
atleast compare to the "compat" case where the contexts are looked up on
the node, netif, port individually. Also, bear in mind that the labeling
rules for "entry" and "exit" points as shown above could be placed AFTER
all other normal iptables rules that could drop a packet, so I do not
understand why a packet now has to go thru 400 or so more rules than
otherwise,
before being dropped.

I would imagine that iptabels lookups would be much more efficient than
the current individual lookups on node/netif/port. Another optimizing factor
would be that INPUT/FORWARD rules could be used instead of PREROUTING to
delay jumping to the (CONN)SECMARK target(s). The idea is that labeling
could come AFTER all the drop checks. i.e. one could replace appropriate
ACCEPTs with a jump to the appropriate labeling chain that in turn would
call into (CONN)SECMARK, for example.

> 
> 
> 1.  By default httpd has to be able to talk to itself in order to do 
> gracefull shutdown,
> service httpd graceful.
> 
> So I end up adding a rule allowing httpd to name_connect to the 
> httpd_port_t.    But I really only want to allow this for 
> localhost.  IE 
> I don't want to allow my httpd to name_connect to other 
> machines httpd 
> ports?  I can't do this now.

1. Define "exit" and "entry" point contexts, rather the "connection" context
   (specifically an "outgoing connection") in this case:

iptables -t mangle -A POSTROUTING -o lo -p tcp --sport 80 --dport 80 -m
state --state NEW -j SEL_HTTPD2HTTPD
iptables -t mangle -A SEL_HTTPD2HTTPD -j SECMARK --selctx
system_u:object_r:httpd2httpd_t:s0
iptables -t mangle -A SEL_HTTPD2HTTPD -j CONNSECMARK --save
iptables -t mangle -A SEL_HTTPD2HTTPD -j ACCEPT

# Common rules which copy connection labels to established
# and related packets.
iptables -t mangle -A INPUT -m state --state ESTABLISHED,RELATED -j
CONNSECMARK --restore
iptables -t mangle -A OUTPUT -m state --state ESTABLISHED,RELATED -j
CONNSECMARK --restore

2. Allow the "httpd_t" packets to exit thru the "exit point"

allow httpd_t httpd2httpd_t:packet { flow_out };

NOTE: Packet goes over loopback at this time.

3. Packet didn't use IPSec, so it is "unlabeled" in that "external
    labeling" sense. Allow the non-IPSec packets thru the "entry point".

allow unlabeled_t httpd2httpd_t:packet { flow_in };

NOTE1: If using Labeled IPSec SAs, "unlabeled_t" above would be substituted
with the Type associated with the IPSec SAs here.

NOTE2: Packet is labeled with httpd2httpd_t at this point.

4. Finally, allow the httpd_t socket to receive the packets.

allow httpd_t httpd2http_t:packet { recv };

I applied sorta linear thinking in the above, but the rules could perhaps
be optimized into a smaller rule set particularly in conjunction with
rules for other services.

Anyone see any unintended flows in the above?

Also, since I happened to reuse secmark with a shift in paradigm, the
current naming might be a little bit awkward or even confusing.

I am not well versed in the current policy design as far as useability
is concerned but I would think that the above could be made "useable" for
Joe Average by doing some smart policy interfaces, etc. Policy guys, please
weigh in here.

> 
> 2.  I as a sysadm have setup a apache web site that allows 
> connections 
> from the outside and needs to connect to three mysql servers on my 
> internal network. So I need to allow it to connect to those three 
> machines on the internal network only.  How am I as the 
> Sysadm going to 
> set this up.

You would pretty much do the same as in the previous scenario except
you would also allow connection packets (NEW, ESTABLISHED, RELATED)
from httpd_t to those 3 servers (or a subset of these as can be defined
by standard iptables selection criteria) by defining appropriate
"connection contexts" (which encompass the entry and exit contexts
as described 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: ipsec, netlabels, secmark- How about a little usability?

[Joshua Brindle]

Venkat Yekkirala wrote:
>> We have been having some meetings to discuss how we can use 
>> this stuff 
>> in the real world (IE Non MLS), and I think the current 
>> implementation 
>> is coming up short.  The discussions I have seen have talked 
>> about using 
>> getpeercon to look at the other end of the connections, but 
>> this is not 
>> in the spirit of SELinux where modification of the 
>> applications should 
>> not be necessary to secure the environment.
>>
>>     
>
>
> So, what happens if an externally labeled packet (e.g.: Labeled IPSec)
> comes in thru the above entry point? First of all, a check is made to
> see if a packet so labeled using IPSec (unlabeled if no IPSec) can
> "flow in" thru the "entry point". If it can, and if there's an
> IPSec label on the packet, a transition sid is computed between the
> "entry point" label and the IPSec label and the packet will be marked
> with this transition sid. The transition label will either be the IPSec
> label (default) or any other label as defined by SELinux policy transition
> rules.
>
>   
What if there are 2 external labels (ipsec and cipso) ?


--
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: ipsec, netlabels, secmark- How about a little usability?

[Venkat Yekkirala]

> > So, what happens if an externally labeled packet (e.g.: 
> Labeled IPSec)
> > comes in thru the above entry point? First of all, a check 
> is made to
> > see if a packet so labeled using IPSec (unlabeled if no IPSec) can
> > "flow in" thru the "entry point". If it can, and if there's an
> > IPSec label on the packet, a transition sid is computed between the
> > "entry point" label and the IPSec label and the packet will 
> be marked
> > with this transition sid. The transition label will either 
> be the IPSec
> > label (default) or any other label as defined by SELinux 
> policy transition
> > rules.
> >
> >   
> What if there are 2 external labels (ipsec and cipso) ?

A "cipso label" will be constructed using the transition label,
determined in the above process, or in it's absence (i.e., no labeled IPSec)
the "entry point" label, as the base sid. A check is made to see
if a packet with this "cipso label" can "flow in" thru
the transition label (or the "entry point" label if no labeled IPSec)
and if it can, then the packet is marked with this cipso label.

--
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: ipsec, netlabels, secmark- How about a little usability?

[Venkat Yekkirala]

> > > > 1.  By default httpd has to be able to talk to itself 
> in order to do 
> > > > gracefull shutdown,
> > > > service httpd graceful.
> > > >
> > > > So I end up adding a rule allowing httpd to name_connect to the 
> > > > httpd_port_t.    But I really only want to allow this 
> for localhost.  
> > > > IE I don't want to allow my httpd to name_connect to 
> other machines 
> > > > httpd ports?  I can't do this now.
> > > >
> > > you can with secmark can't you?
> > > iptables -I -p tcp -d localhost -s localhost -i lo 
> --dport 80 -j SECMARK 
> > > --selctx system_u:object_r:httpd_client_packet_t
> > 
> >  This one rule, both allows httpd_t to connect to localhost:80 and
> > disallows it from connecting to anything-else:80 ?
> > 
> >  From the documentation --selctx just sets the "SELinux security
> > context" ... so you presumably _also_ need some bit of 
> policy code that
> > says "httpd_t can only name_bind(?) with httpd_client_packet_t"?
> 
> The iptables rule only deals with labeling the packet with a 
> type.  The
> policy deals with what domains can send/recv a given packet via allow
> rules like:
> 	allow httpd_t http_client_packet_t:packet { send recv };
> encapsulated in interfaces like:
> 	corenet_sendrecv_http_client_packet(httpd_t)
> 
> But the problem I see with the above example is that refpolicy already
> generates a netfilter contexts entry that maps _everything_ going to
> port 80 with http_client_packet_t, so we would need to delete 
> that entry
> to make the above work, or use a different type
> (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> generic http_client_packet_t.  All of which gets back to proper
> integration.

In the secid patch sent to netdev last week, all packets leaving httpd
would be labeled with the label of the source socket (httpd_t). This
label is currently overridable by the above "secmark" rule, but we could
alternatively allow a packet to retain the label if it already has one,
in which case, the allow rule would be like:

allow httpd_t httpd_t:packet { send recv};

Comments?

--
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: ipsec, netlabels, secmark- How about a little usability?

[Stuart James]

On Thu, 14 Sep 2006 18:52:13 -0400
Venkat Yekkirala <vyekkirala@TrustedCS.com> wrote:

> > > > > 1.  By default httpd has to be able to talk to itself 
> > in order to do 
> > > > > gracefull shutdown,
> > > > > service httpd graceful.
> > > > >
> > > > > So I end up adding a rule allowing httpd to name_connect to
> > > > > the httpd_port_t.    But I really only want to allow this 
> > for localhost.  
> > > > > IE I don't want to allow my httpd to name_connect to 
> > other machines 
> > > > > httpd ports?  I can't do this now.
> > > > >
> > > > you can with secmark can't you?
> > > > iptables -I -p tcp -d localhost -s localhost -i lo 
> > --dport 80 -j SECMARK 
> > > > --selctx system_u:object_r:httpd_client_packet_t
> > > 
> > >  This one rule, both allows httpd_t to connect to localhost:80 and
> > > disallows it from connecting to anything-else:80 ?
> > > 
> > >  From the documentation --selctx just sets the "SELinux security
> > > context" ... so you presumably _also_ need some bit of 
> > policy code that
> > > says "httpd_t can only name_bind(?) with httpd_client_packet_t"?
> > 
> > The iptables rule only deals with labeling the packet with a 
> > type.  The
> > policy deals with what domains can send/recv a given packet via
> > allow rules like:
> > 	allow httpd_t http_client_packet_t:packet { send recv };
> > encapsulated in interfaces like:
> > 	corenet_sendrecv_http_client_packet(httpd_t)
> > 
> > But the problem I see with the above example is that refpolicy
> > already generates a netfilter contexts entry that maps _everything_
> > going to port 80 with http_client_packet_t, so we would need to
> > delete that entry
> > to make the above work, or use a different type
> > (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> > generic http_client_packet_t.  All of which gets back to proper
> > integration.
> 
> In the secid patch sent to netdev last week, all packets leaving httpd
> would be labeled with the label of the source socket (httpd_t). This
> label is currently overridable by the above "secmark" rule, but we
> could alternatively allow a packet to retain the label if it already
> has one, in which case, the allow rule would be like:
> 
> allow httpd_t httpd_t:packet { send recv};
> 

Would these rules also work on a packet forwarding device rather then
on the host that the packet is actually destined for?




-- 
Stuart James
Systems Administrator
DDI - (44) 0 1723 300205

--
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: ipsec, netlabels, secmark- How about a little usability?

[Stuart James]

On Thu, 14 Sep 2006 08:52:34 -0400
Daniel J Walsh <dwalsh@redhat.com> wrote:

> We have been having some meetings to discuss how we can use this
> stuff in the real world (IE Non MLS), and I think the current
> implementation is coming up short.  The discussions I have seen have
> talked about using getpeercon to look at the other end of the
> connections, but this is not in the spirit of SELinux where
> modification of the applications should not be necessary to secure
> the environment.
> 
> 
> Lets look at some real world situations where having better controls
> on the network would work and someone explain to me how Joe Average 
> SysAdmin will set them up.
> 

> 
> =======================================================
> 
> If someone was to pass a law and make me the King of SELinux, The way 
> this would happen is that iptables would be extended to add a -t 
> SecurityContext flag, which I then could simple SELinux rules to set 
> this up in a lanquage that most Sysadmins of Linux boxes could
> readily understand.
> 

If I understand it correctly, secmark is an additional type of
selinux context that needs to be modified in the selinux policy
to add the ability for the iptables rule to function correctly? 

Is there currently a way of labeling the type of iptable ruleset? such
as if i were to create a chain called "iptables -N mychain", could i
then label then chain when creating it, such as with 
"iptables -A mychain -p tcp -m tcp --dport 80 -j SecurityContext"
and would SecurityContext take over from the -j ACCEPT ?

As i was looking through the
http://people.redhat.com/jmorris/selinux/secmark/ this tends to make
agree with your statement of having the ability to add the context into
the iptables rule, is this a current ability of iptables or only on
patched systems?

Another issue which has arisen while moving from Fedora core 3 to
above, was prior to newer versions of kernel / openswan and iptables,
if you were using the IPsec device as also a Masquerading device,
complex rulesets to exclude masquerading to destination networks
provided by the ipsec tunnel have to be specified specifically as
ACCEPT for POSTROUTING prior to POSTROUTING of outbound traffic
destined to the internet. 

Assuming now you have ipsec tunnels to 192.168.0.0/16
For example now we currently use this on FC4/5

-A POSTROUTING -d 192.168.0.0/16 -o eth0 -j ACCEPT

Prior to Fedora core 4
-A POSTROUTING -s x.x.x.x/24 -d !
192.168.0.0/255.255.0.0 -o eth0 -j MASQUERADE

Assuming now you tunnels to 192.168.0.0/16 and 10.10.10.0/24
The following works on FC4/5, not on FC3
-A POSTROUTING -d 192.168.0.0/16 -o eth0 -j ACCEPT
-A POSTROUTING -d 10.10.10.0/24 -o eth0 -j ACCEPT

And on FC3 you are limited to
-A POSTROUTING -s x.x.x.x/24 -d !
192.168.0.0/255.255.0.0 -o eth0 -j MASQUERADE
-A POSTROUTING -s x.x.x.x/24 -d !
192.168.0.0/255.255.0.0 -o eth0 -j MASQUERADE


Although this is an improvement with the older way, if you had
multiple ipsec connections to more then just the 192.168.0.0/16
network your initial POSTROUTING rule would match, and traffic destined
for say 10.10.10.0/24 for would also get masqueraded to the internet

With the current distribution of Fedora latest selinux policy two IPsec
devices connected running in enforcing mode will not talk across the
network. I have added these audit2allows to my policy for it to work
but unfortunately i will have to redo it to provide you with the
correct avc messages to hopefully get ipsec(openswan) running in
enforcing mode for fc5 and above, as currently if you were trying to
set it up it would not work as required.


-- 
Stuart James
Systems Administrator
DDI - (44) 0 1723 300205
RHCE - RHEL4
CERT# 804005316914471 

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

ipsec, netlabels, secmark- How about a little usability?

[Daniel J Walsh]

We have been having some meetings to discuss how we can use this stuff 
in the real world (IE Non MLS), and I think the current implementation 
is coming up short.  The discussions I have seen have talked about using 
getpeercon to look at the other end of the connections, but this is not 
in the spirit of SELinux where modification of the applications should 
not be necessary to secure the environment.


Lets look at some real world situations where having better controls on 
the network would work and someone explain to me how Joe Average 
SysAdmin will set them up.


1.  By default httpd has to be able to talk to itself in order to do 
gracefull shutdown,
service httpd graceful.

So I end up adding a rule allowing httpd to name_connect to the 
httpd_port_t.    But I really only want to allow this for localhost.  IE 
I don't want to allow my httpd to name_connect to other machines httpd 
ports?  I can't do this now.

2.  I as a sysadm have setup a apache web site that allows connections 
from the outside and needs to connect to three mysql servers on my 
internal network. So I need to allow it to connect to those three 
machines on the internal network only.  How am I as the Sysadm going to 
set this up.

3.  I want to setup two machines in my environment with bind running on 
them.  One, Machine A,  is a bind master the other, Machine B,  is a 
bind slave.  I want to allow bind zone transfer from Machine A to 
Machine B, but I want to guarantee that the process kicking off the zone 
transfer on Machine A is running as named_t and the process receiving 
the zone transfer on Machine B is running as named_t. 
How do I do that?

4.  I have a machine that is running two bind domains, one on my 
internal network needs to listen on eth0, the other on the externel 
network needs to listen on eth1.  How do I set this up?

=======================================================

If someone was to pass a law and make me the King of SELinux, The way 
this would happen is that iptables would be extended to add a -t 
SecurityContext flag, which I then could simple SELinux rules to set 
this up in a lanquage that most Sysadmins of Linux boxes could readily 
understand.





--
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: ipsec, netlabels, secmark- How about a little usability?

[Joshua Brindle]

Daniel J Walsh wrote:
> We have been having some meetings to discuss how we can use this stuff 
> in the real world (IE Non MLS), and I think the current implementation 
> is coming up short.  The discussions I have seen have talked about 
> using getpeercon to look at the other end of the connections, but this 
> is not in the spirit of SELinux where modification of the applications 
> should not be necessary to secure the environment.
>

I disagree, the conversations for these things are centered around 
security aware apps (eg., I'm talking about it because of policy server)

>
> Lets look at some real world situations where having better controls 
> on the network would work and someone explain to me how Joe Average 
> SysAdmin will set them up.
>
the world is bigger than you think it seems..

>
> 1.  By default httpd has to be able to talk to itself in order to do 
> gracefull shutdown,
> service httpd graceful.
>
> So I end up adding a rule allowing httpd to name_connect to the 
> httpd_port_t.    But I really only want to allow this for localhost.  
> IE I don't want to allow my httpd to name_connect to other machines 
> httpd ports?  I can't do this now.
>
you can with secmark can't you?
iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
--selctx system_u:object_r:httpd_client_packet_t


> 2.  I as a sysadm have setup a apache web site that allows connections 
> from the outside and needs to connect to three mysql servers on my 
> internal network. So I need to allow it to connect to those three 
> machines on the internal network only.  How am I as the Sysadm going 
> to set this up.
>
again, secmark

> 3.  I want to setup two machines in my environment with bind running 
> on them.  One, Machine A,  is a bind master the other, Machine B,  is 
> a bind slave.  I want to allow bind zone transfer from Machine A to 
> Machine B, but I want to guarantee that the process kicking off the 
> zone transfer on Machine A is running as named_t and the process 
> receiving the zone transfer on Machine B is running as named_t. How do 
> I do that?
>
It sounds like bind might need to be modified to read an ipsec socket 
label and then you'll add spd rules to both machines. Not sure how you 
expect bind to treat some connections as special without modifying it.

> 4.  I have a machine that is running two bind domains, one on my 
> internal network needs to listen on eth0, the other on the externel 
> network needs to listen on eth1.  How do I set this up?
>
this would require 2 bind domains.. non-trivial right now unfortunately.

> =======================================================
>
> If someone was to pass a law and make me the King of SELinux, The way 
> this would happen is that iptables would be extended to add a -t 
> SecurityContext flag, which I then could simple SELinux rules to set 
> this up in a lanquage that most Sysadmins of Linux boxes could readily 
> understand.
umm, -j SECMARK --selctx?

--
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: ipsec, netlabels, secmark- How about a little usability?

[Joshua Brindle]

Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> =======================================================
>>
>> If someone was to pass a law and make me the King of SELinux, The way 
>> this would happen is that iptables would be extended to add a -t 
>> SecurityContext flag, which I then could simple SELinux rules to set 
>> this up in a lanquage that most Sysadmins of Linux boxes could 
>> readily understand.
> umm, -j SECMARK --selctx?
>
Actually I see what you are saying now, you want to match based on 
context, not label packets. This is not in the spirit of SELinux because 
it spreads the policy out into 2 places and makes it much harder to 
audit. We want labeling spread out but policy centralized.

It would make management of the policy even harder than it is now.


--
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: ipsec, netlabels, secmark- How about a little usability?

[Stephen Smalley]

On Thu, 2006-09-14 at 09:50 -0400, Joshua Brindle wrote:
> > 1.  By default httpd has to be able to talk to itself in order to do 
> > gracefull shutdown,
> > service httpd graceful.
> >
> > So I end up adding a rule allowing httpd to name_connect to the 
> > httpd_port_t.    But I really only want to allow this for localhost.  
> > IE I don't want to allow my httpd to name_connect to other machines 
> > httpd ports?  I can't do this now.
> >
> you can with secmark can't you?
> iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
> --selctx system_u:object_r:httpd_client_packet_t

IIUC, the mechanism is there, but the necessary integration is not.  How
do we intend to manage local secmark rules, via semanage as with
port/node/netif contexts or via iptables?  How does one express this
kind of goal in refpolicy itself, going beyond just the support for auto
generation of dport-based rules?  Where do we stand on iptables
integration?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: ipsec, netlabels, secmark- How about a little usability?

[Daniel J Walsh]

Stephen Smalley wrote:
> On Thu, 2006-09-14 at 09:50 -0400, Joshua Brindle wrote:
>   
>>> 1.  By default httpd has to be able to talk to itself in order to do 
>>> gracefull shutdown,
>>> service httpd graceful.
>>>
>>> So I end up adding a rule allowing httpd to name_connect to the 
>>> httpd_port_t.    But I really only want to allow this for localhost.  
>>> IE I don't want to allow my httpd to name_connect to other machines 
>>> httpd ports?  I can't do this now.
>>>
>>>       
>> you can with secmark can't you?
>> iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
>> --selctx system_u:object_r:httpd_client_packet_t
>>     
>
> IIUC, the mechanism is there, but the necessary integration is not.  How
> do we intend to manage local secmark rules, via semanage as with
> port/node/netif contexts or via iptables?  How does one express this
> kind of goal in refpolicy itself, going beyond just the support for auto
> generation of dport-based rules?  Where do we stand on iptables
> integration?
>
>   
I still think this is not fully thought out. We have a lot of booleans 
that this stuff will blow out of the water.  setsebool -A 
allow_ypbind=1  for example,  httpd_can_connect_any ...  Are these 
things going to have to replace iptables rules when they get set?  I 
find the hole thing unmanagable and I think we are going to see 
performance problems when we start adding hundreds (thousands) of rules 
to iptables.

I believe we need an integrated solution that can setup full networking 
support, in which I state that
Domain X on Host Y can talk to Domain A on Host B.  This needs to be 
able to setup the proper network requirements to make this happen.  If 
this is a combination of secmark rules, and netlabel/ipsec that is 
fine.  But I don't expect many admins in to be able to set this up on 
their own.




--
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: ipsec, netlabels, secmark- How about a little usability?

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

On Thu, 2006-09-14 at 09:50 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > 1.  By default httpd has to be able to talk to itself in order to do 
> > gracefull shutdown,
> > service httpd graceful.
> >
> > So I end up adding a rule allowing httpd to name_connect to the 
> > httpd_port_t.    But I really only want to allow this for localhost.  
> > IE I don't want to allow my httpd to name_connect to other machines 
> > httpd ports?  I can't do this now.
> >
> you can with secmark can't you?
> iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
> --selctx system_u:object_r:httpd_client_packet_t

 This one rule, both allows httpd_t to connect to localhost:80 and
disallows it from connecting to anything-else:80 ?

 From the documentation --selctx just sets the "SELinux security
context" ... so you presumably _also_ need some bit of policy code that
says "httpd_t can only name_bind(?) with httpd_client_packet_t"?

> > 2.  I as a sysadm have setup a apache web site that allows connections 
> > from the outside and needs to connect to three mysql servers on my 
> > internal network. So I need to allow it to connect to those three 
> > machines on the internal network only.  How am I as the Sysadm going 
> > to set this up.
> >
> again, secmark

 Err, no. The requirement here is that:

1. httpd_t on one machine is only allowed to connect to mysqld_t(?) on
one of these 3 machines.

...AIUI secmark doesn't know the label of the proc. on the other
machines, even when using ipsec/netlabel.

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipsec, netlabels, secmark- How about a little usability?

[Stephen Smalley]

On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> On Thu, 2006-09-14 at 09:50 -0400, Joshua Brindle wrote:
> > Daniel J Walsh wrote:
> > > 1.  By default httpd has to be able to talk to itself in order to do 
> > > gracefull shutdown,
> > > service httpd graceful.
> > >
> > > So I end up adding a rule allowing httpd to name_connect to the 
> > > httpd_port_t.    But I really only want to allow this for localhost.  
> > > IE I don't want to allow my httpd to name_connect to other machines 
> > > httpd ports?  I can't do this now.
> > >
> > you can with secmark can't you?
> > iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
> > --selctx system_u:object_r:httpd_client_packet_t
> 
>  This one rule, both allows httpd_t to connect to localhost:80 and
> disallows it from connecting to anything-else:80 ?
> 
>  From the documentation --selctx just sets the "SELinux security
> context" ... so you presumably _also_ need some bit of policy code that
> says "httpd_t can only name_bind(?) with httpd_client_packet_t"?

The iptables rule only deals with labeling the packet with a type.  The
policy deals with what domains can send/recv a given packet via allow
rules like:
	allow httpd_t http_client_packet_t:packet { send recv };
encapsulated in interfaces like:
	corenet_sendrecv_http_client_packet(httpd_t)

But the problem I see with the above example is that refpolicy already
generates a netfilter contexts entry that maps _everything_ going to
port 80 with http_client_packet_t, so we would need to delete that entry
to make the above work, or use a different type
(http_client_packet_lo_t) and only allow httpd_t to send it, not the
generic http_client_packet_t.  All of which gets back to proper
integration.

> 
> > > 2.  I as a sysadm have setup a apache web site that allows connections 
> > > from the outside and needs to connect to three mysql servers on my 
> > > internal network. So I need to allow it to connect to those three 
> > > machines on the internal network only.  How am I as the Sysadm going 
> > > to set this up.
> > >
> > again, secmark
> 
>  Err, no. The requirement here is that:
> 
> 1. httpd_t on one machine is only allowed to connect to mysqld_t(?) on
> one of these 3 machines.
> 
> ...AIUI secmark doesn't know the label of the proc. on the other
> machines, even when using ipsec/netlabel.

Yes, but you can label the output packet via secmark with one type if it
is destined for the mysql port on one of the "good" machines and a
different type otherwise, and only allow httpd_t to send the "good"
type.   On the internal machines, you can ensure that only mysqld_t can
bind to that port.  That doesn't really require a network labeling
mechanism like ipsec or netlabel per se.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: ipsec, netlabels, secmark- How about a little usability?

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]

On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:

> The iptables rule only deals with labeling the packet with a type.  The
> policy deals with what domains can send/recv a given packet via allow
> rules like:
> 	allow httpd_t http_client_packet_t:packet { send recv };
> encapsulated in interfaces like:
> 	corenet_sendrecv_http_client_packet(httpd_t)
> 
> But the problem I see with the above example is that refpolicy already
> generates a netfilter contexts entry that maps _everything_ going to
> port 80 with http_client_packet_t, so we would need to delete that entry
> to make the above work, or use a different type
> (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> generic http_client_packet_t.  All of which gets back to proper
> integration.

 The problem is you can't just use "send recv", because httpd_t needs to
call send on sockets it receives from all over the place. So you need an
interface specifically for connect (which, I understood, was called 
something like name_bind)?
 Think of the difference between something coming to port X:80 from Y:Z,
being accepted, processed and a response being sent against some
attacker in httpd_t doing a connect from X:80 to Y:Z as part of some
botnet.

> > 1. httpd_t on one machine is only allowed to connect to mysqld_t(?) on
> > one of these 3 machines.
> > 
> > ...AIUI secmark doesn't know the label of the proc. on the other
> > machines, even when using ipsec/netlabel.
> 
> Yes, but you can label the output packet via secmark with one type if it
> is destined for the mysql port on one of the "good" machines and a
> different type otherwise, and only allow httpd_t to send the "good"
> type.   On the internal machines, you can ensure that only mysqld_t can
> bind to that port.  That doesn't really require a network labeling
> mechanism like ipsec or netlabel per se.

 That works, but is significantly more interdependent. From a useability
POV it would be much nicer to just be able to say something like
"httpd_t can only connect to mysqld_t, and also only on these
machines/networks".

 Also I can pretty much guarantee that if the accepted practice is "just
trust the port number on the other machines". The solution will be to
just use iptables to REJECT packets without that port (as that works
with or without SELinux).

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ipsec, netlabels, secmark- How about a little usability?

[Stephen Smalley]

On Thu, 2006-09-14 at 13:24 -0400, James Antill wrote:
> On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> > On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> 
> > The iptables rule only deals with labeling the packet with a type.  The
> > policy deals with what domains can send/recv a given packet via allow
> > rules like:
> > 	allow httpd_t http_client_packet_t:packet { send recv };
> > encapsulated in interfaces like:
> > 	corenet_sendrecv_http_client_packet(httpd_t)
> > 
> > But the problem I see with the above example is that refpolicy already
> > generates a netfilter contexts entry that maps _everything_ going to
> > port 80 with http_client_packet_t, so we would need to delete that entry
> > to make the above work, or use a different type
> > (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> > generic http_client_packet_t.  All of which gets back to proper
> > integration.
> 
>  The problem is you can't just use "send recv", because httpd_t needs to
> call send on sockets it receives from all over the place. So you need an
> interface specifically for connect (which, I understood, was called 
> something like name_bind)?

name_connect is just a pairwise check between the socket and the port.
It has nothing to do with secmark.

Are you aware of the CONNSECMARK target?  See
http://james-morris.livejournal.com/11010.html

>  Think of the difference between something coming to port X:80 from Y:Z,
> being accepted, processed and a response being sent against some
> attacker in httpd_t doing a connect from X:80 to Y:Z as part of some
> botnet.

Yes, that can be distinguished.   The issue is not send/recv, but the
labels of the packets, as initially established via secmark and
propagated via connsecmark to all traffic on the connection.

> > > 1. httpd_t on one machine is only allowed to connect to mysqld_t(?) on
> > > one of these 3 machines.
> > > 
> > > ...AIUI secmark doesn't know the label of the proc. on the other
> > > machines, even when using ipsec/netlabel.
> > 
> > Yes, but you can label the output packet via secmark with one type if it
> > is destined for the mysql port on one of the "good" machines and a
> > different type otherwise, and only allow httpd_t to send the "good"
> > type.   On the internal machines, you can ensure that only mysqld_t can
> > bind to that port.  That doesn't really require a network labeling
> > mechanism like ipsec or netlabel per se.
> 
>  That works, but is significantly more interdependent. From a useability
> POV it would be much nicer to just be able to say something like
> "httpd_t can only connect to mysqld_t, and also only on these
> machines/networks".

That's your high level goal - you can implement it in different ways.
Not sure why it is more interdependent.  

>  Also I can pretty much guarantee that if the accepted practice is "just
> trust the port number on the other machines". The solution will be to
> just use iptables to REJECT packets without that port (as that works
> with or without SELinux).

Not sure I see that. You are using SELinux on the web server to enforce
the restriction that httpd can only initiate connections to the mysql
port of certain hosts, and you are using SELinux on those hosts to
enforce the restriction that only the approved mysqld can bind to that
port.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: ipsec, netlabels, secmark- How about a little usability?

[Karl MacMillan]

On Thu, 2006-09-14 at 15:45 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-14 at 13:24 -0400, James Antill wrote:
> > On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> > > On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> > 
> > > The iptables rule only deals with labeling the packet with a type.  The
> > > policy deals with what domains can send/recv a given packet via allow
> > > rules like:
> > > 	allow httpd_t http_client_packet_t:packet { send recv };
> > > encapsulated in interfaces like:
> > > 	corenet_sendrecv_http_client_packet(httpd_t)
> > > 
> > > But the problem I see with the above example is that refpolicy already
> > > generates a netfilter contexts entry that maps _everything_ going to
> > > port 80 with http_client_packet_t, so we would need to delete that entry
> > > to make the above work, or use a different type
> > > (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> > > generic http_client_packet_t.  All of which gets back to proper
> > > integration.
> > 
> >  The problem is you can't just use "send recv", because httpd_t needs to
> > call send on sockets it receives from all over the place. So you need an
> > interface specifically for connect (which, I understood, was called 
> > something like name_bind)?
> 
> name_connect is just a pairwise check between the socket and the port.
> It has nothing to do with secmark.
> 

[Trying to restart this conversation again]

Yes, but it is not clear (at least to me) how to allow apache to connect
to certain hosts but send and receive to all other hosts using secmark.
The mention of name_connect was just asking for something similar with
secmark I believe.

> Are you aware of the CONNSECMARK target?  See
> http://james-morris.livejournal.com/11010.html
> 
> >  Think of the difference between something coming to port X:80 from Y:Z,
> > being accepted, processed and a response being sent against some
> > attacker in httpd_t doing a connect from X:80 to Y:Z as part of some
> > botnet.
> 
> Yes, that can be distinguished.   The issue is not send/recv, but the
> labels of the packets, as initially established via secmark and
> propagated via connsecmark to all traffic on the connection.
> 

I never saw a working example of sorting this all out - I'd be
interested if someone with more iptables experience could demonstrate
how this can be achieved.

Even if it can be achieved I'm concerned that it will be overly complex
and not idiomatic for iptables rules. One of the main advantages to
using iptables is that it is familiar to admins, but if it must be used
in strange new ways much of that advantage might be lost.

> > > > 1. httpd_t on one machine is only allowed to connect to mysqld_t(?) on
> > > > one of these 3 machines.
> > > > 
> > > > ...AIUI secmark doesn't know the label of the proc. on the other
> > > > machines, even when using ipsec/netlabel.
> > > 
> > > Yes, but you can label the output packet via secmark with one type if it
> > > is destined for the mysql port on one of the "good" machines and a
> > > different type otherwise, and only allow httpd_t to send the "good"
> > > type.   On the internal machines, you can ensure that only mysqld_t can
> > > bind to that port.  That doesn't really require a network labeling
> > > mechanism like ipsec or netlabel per se.
> > 
> >  That works, but is significantly more interdependent. From a useability
> > POV it would be much nicer to just be able to say something like
> > "httpd_t can only connect to mysqld_t, and also only on these
> > machines/networks".
> 
> That's your high level goal - you can implement it in different ways.
> Not sure why it is more interdependent.  
> 

Leaving aside interdependence, I'm having a lot of trouble connecting
high level goals to implementations using _any_ of the new networking
controls. I'd like to see some examples where this is done so that we
can:

a) smooth out the process using tools,
b) document things sufficiently,
c) or (least desirable) change the implementation

So much of the discussion until now has centered around implementation
issues and use cases that I don't think are as interesting as unmodified
networking applications (selinux aware apps and MLS).

Karl


--
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: ipsec, netlabels, secmark- How about a little usability?

[Christopher J. PeBenito]

On Tue, 2006-09-19 at 16:13 -0400, Karl MacMillan wrote:
> On Thu, 2006-09-14 at 15:45 -0400, Stephen Smalley wrote:
> > On Thu, 2006-09-14 at 13:24 -0400, James Antill wrote:
> > > On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> > > > On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> > > 
> > > > The iptables rule only deals with labeling the packet with a type.  The
> > > > policy deals with what domains can send/recv a given packet via allow
> > > > rules like:
> > > > 	allow httpd_t http_client_packet_t:packet { send recv };
> > > > encapsulated in interfaces like:
> > > > 	corenet_sendrecv_http_client_packet(httpd_t)
> > > > 
> > > > But the problem I see with the above example is that refpolicy already
> > > > generates a netfilter contexts entry that maps _everything_ going to
> > > > port 80 with http_client_packet_t, so we would need to delete that entry
> > > > to make the above work, or use a different type
> > > > (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> > > > generic http_client_packet_t.  All of which gets back to proper
> > > > integration.
> > > 
> > >  The problem is you can't just use "send recv", because httpd_t needs to
> > > call send on sockets it receives from all over the place. So you need an
> > > interface specifically for connect (which, I understood, was called 
> > > something like name_bind)?
> > 
> > name_connect is just a pairwise check between the socket and the port.
> > It has nothing to do with secmark.
> > 
> 
> [Trying to restart this conversation again]
> 
> Yes, but it is not clear (at least to me) how to allow apache to connect
> to certain hosts but send and receive to all other hosts using secmark.
> The mention of name_connect was just asking for something similar with
> secmark I believe.

Lets make the example more concrete.  From what I understand what we're
trying to distinguish is from requests made to apache (incoming from
anywhere), and outgoing apache connections (say a php script is
connecting to a mysql server).  This can be done, and is currently done
by the refpolicy rules.  From the perspective of the server, incoming
requests are all httpd_server_packet_t connections.  New connections
made to mysql from the apache server would be mysql_client_packet_t.
The default refpolicy rule already handles labeling incoming connections
to port 80 from everywhere as httpd_server_packet_t.  If we only wanted
to allow mysql client connections to be to 1.2.3.4:3306, then the
mysql_client_packet_t netfilter rule would have to be changed to include
that as the destination ip/port.  Connections to mysql on another ip
would fall through to client_packet_t.

-- 
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: ipsec, netlabels, secmark- How about a little usability?

[Karl MacMillan]

On Tue, 2006-09-19 at 16:35 -0400, Christopher J. PeBenito wrote:
> On Tue, 2006-09-19 at 16:13 -0400, Karl MacMillan wrote:
> > On Thu, 2006-09-14 at 15:45 -0400, Stephen Smalley wrote:
> > > On Thu, 2006-09-14 at 13:24 -0400, James Antill wrote:
> > > > On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> > > > > On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> > > > 
> > > > > The iptables rule only deals with labeling the packet with a type.  The
> > > > > policy deals with what domains can send/recv a given packet via allow
> > > > > rules like:
> > > > > 	allow httpd_t http_client_packet_t:packet { send recv };
> > > > > encapsulated in interfaces like:
> > > > > 	corenet_sendrecv_http_client_packet(httpd_t)
> > > > > 
> > > > > But the problem I see with the above example is that refpolicy already
> > > > > generates a netfilter contexts entry that maps _everything_ going to
> > > > > port 80 with http_client_packet_t, so we would need to delete that entry
> > > > > to make the above work, or use a different type
> > > > > (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> > > > > generic http_client_packet_t.  All of which gets back to proper
> > > > > integration.
> > > > 
> > > >  The problem is you can't just use "send recv", because httpd_t needs to
> > > > call send on sockets it receives from all over the place. So you need an
> > > > interface specifically for connect (which, I understood, was called 
> > > > something like name_bind)?
> > > 
> > > name_connect is just a pairwise check between the socket and the port.
> > > It has nothing to do with secmark.
> > > 
> > 
> > [Trying to restart this conversation again]
> > 
> > Yes, but it is not clear (at least to me) how to allow apache to connect
> > to certain hosts but send and receive to all other hosts using secmark.
> > The mention of name_connect was just asking for something similar with
> > secmark I believe.
> 
> Lets make the example more concrete.  From what I understand what we're
> trying to distinguish is from requests made to apache (incoming from
> anywhere), and outgoing apache connections (say a php script is
> connecting to a mysql server).  This can be done, and is currently done
> by the refpolicy rules.  From the perspective of the server, incoming
> requests are all httpd_server_packet_t connections.  New connections
> made to mysql from the apache server would be mysql_client_packet_t.
> The default refpolicy rule already handles labeling incoming connections
> to port 80 from everywhere as httpd_server_packet_t.  If we only wanted
> to allow mysql client connections to be to 1.2.3.4:3306, then the
> mysql_client_packet_t netfilter rule would have to be changed to include
> that as the destination ip/port.  Connections to mysql on another ip
> would fall through to client_packet_t.
> 

I assume that you mean these two rules (reverting back to Dan's example
- only allow apache to initiate connections to port 80 over localhost
but otherwise send and receive on port 80):

-A selinux_new_output -p tcp --dport 80 -j SECMARK --selctx
system_u:object_r:http_client_packet_t:s0
-A selinux_new_input -p tcp --dport 80 -j SECMARK --selctx
system_u:object_r:http_server_packet_t:s0

And the difference is which chain based set up at the top, which
differentiates betweein incoming and outgoing packets, correct?

-A selinux_input -m state --state NEW -j selinux_new_input
-A selinux_output -m state --state NEW -j selinux_new_output

I guess the real magic, though, is the following which means that a
packet associated with an established connections gets labeled the same
as the initial connection:

-A selinux_input -m state --state RELATED,ESTABLISHED -j CONNSECMARK
--restore
-A selinux_output -m state --state RELATED,ESTABLISHED -j CONNSECMARK
--restore

So the initial packet comes in as http_server_packet_t because it is on
the incoming chain and, even though the reply packet goes through the
output side, it is connection tracked and labeled http_server_packet_t,
correct? I can only assume that this is obvious to an iptables admin.

Good so far - I can then add:

-A selinux_new_output -p tcp --dport 80 --out-interface lo -j SECMARK
--selctx system_u:object_r:http_local_client_packet_t:s0

So assuming that I only allow send and receive for http_server_packet_t
and http_local_client_packet_t (and not http_client_packet_t) then this
seems to solve Dan's original question.

Now we just need to figure out how add the policy and iptables rules in
a manageable way.

Thanks Chris,

Karl



--
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: ipsec, netlabels, secmark- How about a little usability?

[Karl MacMillan]

On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> > On Thu, 2006-09-14 at 09:50 -0400, Joshua Brindle wrote:
> > > Daniel J Walsh wrote:
> > > > 1.  By default httpd has to be able to talk to itself in order to do 
> > > > gracefull shutdown,
> > > > service httpd graceful.
> > > >
> > > > So I end up adding a rule allowing httpd to name_connect to the 
> > > > httpd_port_t.    But I really only want to allow this for localhost.  
> > > > IE I don't want to allow my httpd to name_connect to other machines 
> > > > httpd ports?  I can't do this now.
> > > >
> > > you can with secmark can't you?
> > > iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
> > > --selctx system_u:object_r:httpd_client_packet_t
> > 
> >  This one rule, both allows httpd_t to connect to localhost:80 and
> > disallows it from connecting to anything-else:80 ?
> > 
> >  From the documentation --selctx just sets the "SELinux security
> > context" ... so you presumably _also_ need some bit of policy code that
> > says "httpd_t can only name_bind(?) with httpd_client_packet_t"?
> 
> The iptables rule only deals with labeling the packet with a type.  The
> policy deals with what domains can send/recv a given packet via allow
> rules like:
> 	allow httpd_t http_client_packet_t:packet { send recv };
> encapsulated in interfaces like:
> 	corenet_sendrecv_http_client_packet(httpd_t)
> 
> But the problem I see with the above example is that refpolicy already
> generates a netfilter contexts entry that maps _everything_ going to
> port 80 with http_client_packet_t, so we would need to delete that entry
> to make the above work, or use a different type
> (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> generic http_client_packet_t.  All of which gets back to proper
> integration.
> 

I'm beginning to think that this integration is a mistake, which is one
of the reasons it has not been enabled in rawhide. The problems are:

1) This generates _many_ rules - most of which are unnecessary - that
are going to have an adverse effect on performance. This is made worse
by the fact they are mangle rules and will be run even if the other
iptables rules ultimately drop the packet.

2) The policy doesn't allow expressing the full iptables semantics (as
it probably shouldn't).

3) It is not clear how users should override the defaults - using
semanage has the disadvantage of forcing full iptables syntax into
semanage. Adding rules later with iptables means that some rules come
from the policy and some from iptables (it also leaves unused rules
further hurting performance).

Of course, leaving this all up to iptables is hard as well. I don't have
a good answer - all the management options we have evaluated so far have
serious drawbacks. Any suggestions?

> > 
> > > > 2.  I as a sysadm have setup a apache web site that allows connections 
> > > > from the outside and needs to connect to three mysql servers on my 
> > > > internal network. So I need to allow it to connect to those three 
> > > > machines on the internal network only.  How am I as the Sysadm going 
> > > > to set this up.
> > > >
> > > again, secmark
> > 
> >  Err, no. The requirement here is that:
> > 
> > 1. httpd_t on one machine is only allowed to connect to mysqld_t(?) on
> > one of these 3 machines.
> > 
> > ...AIUI secmark doesn't know the label of the proc. on the other
> > machines, even when using ipsec/netlabel.
> 

This brings up another problem with secmark / ipsec / netlabel. Secmark
will be labeling the packets with a derived type (e.g., mysql_packet_t)
while netlabel / ipsec will label them with the process type (mysql_t).
Assuming that the packet object class permissions are enforced with
netlabel / ipsec (is this true?), then how are we going to manage
policy?

One of the nice parts of separating the labeling from the enforcement is
that the policy shouldn't change. Currently, though, it looks like that
won't be the case.

> Yes, but you can label the output packet via secmark with one type if it
> is destined for the mysql port on one of the "good" machines and a
> different type otherwise, and only allow httpd_t to send the "good"
> type.   On the internal machines, you can ensure that only mysqld_t can
> bind to that port.  That doesn't really require a network labeling
> mechanism like ipsec or netlabel per se.
> 

Given the fact that for ipsec or netlabel to work correctly you must
have two trusted machines with similar or the same policies, what
advantage is there to labeling the packets? Why not just have
complimentary secmark configurations? Does this help with non-tcp
protocols?

Karl


--
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: ipsec, netlabels, secmark- How about a little usability?

[Christopher J. PeBenito]

On Tue, 2006-09-19 at 16:47 -0400, Karl MacMillan wrote:
> On Thu, 2006-09-14 at 12:49 -0400, Stephen Smalley wrote:
> > On Thu, 2006-09-14 at 12:02 -0400, James Antill wrote:
> > > On Thu, 2006-09-14 at 09:50 -0400, Joshua Brindle wrote:
> > > > Daniel J Walsh wrote:
> > > > > 1.  By default httpd has to be able to talk to itself in order to do 
> > > > > gracefull shutdown,
> > > > > service httpd graceful.
> > > > >
> > > > > So I end up adding a rule allowing httpd to name_connect to the 
> > > > > httpd_port_t.    But I really only want to allow this for localhost.  
> > > > > IE I don't want to allow my httpd to name_connect to other machines 
> > > > > httpd ports?  I can't do this now.
> > > > >
> > > > you can with secmark can't you?
> > > > iptables -I -p tcp -d localhost -s localhost -i lo --dport 80 -j SECMARK 
> > > > --selctx system_u:object_r:httpd_client_packet_t
> > > 
> > >  This one rule, both allows httpd_t to connect to localhost:80 and
> > > disallows it from connecting to anything-else:80 ?
> > > 
> > >  From the documentation --selctx just sets the "SELinux security
> > > context" ... so you presumably _also_ need some bit of policy code that
> > > says "httpd_t can only name_bind(?) with httpd_client_packet_t"?
> > 
> > The iptables rule only deals with labeling the packet with a type.  The
> > policy deals with what domains can send/recv a given packet via allow
> > rules like:
> > 	allow httpd_t http_client_packet_t:packet { send recv };
> > encapsulated in interfaces like:
> > 	corenet_sendrecv_http_client_packet(httpd_t)
> > 
> > But the problem I see with the above example is that refpolicy already
> > generates a netfilter contexts entry that maps _everything_ going to
> > port 80 with http_client_packet_t, so we would need to delete that entry
> > to make the above work, or use a different type
> > (http_client_packet_lo_t) and only allow httpd_t to send it, not the
> > generic http_client_packet_t.  All of which gets back to proper
> > integration.
> > 
> 
> I'm beginning to think that this integration is a mistake, which is one
> of the reasons it has not been enabled in rawhide. The problems are:
> 
> 1) This generates _many_ rules - most of which are unnecessary - that
> are going to have an adverse effect on performance. This is made worse
> by the fact they are mangle rules and will be run even if the other
> iptables rules ultimately drop the packet.

I don't agree with the first part of this point.  This isn't really any
different than the old networking where you hand to look up the context
of the ports, nodes, and netif (the ports being the one with a similar
amount entries) on every packet.  Second, the cost of going through the
chain with all of the rules is only on new connections.  Established
connections will skip that and just get the connection tracking label
w/CONNSECMARK --restore.

-- 
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: ipsec, netlabels, secmark- How about a little usability?

[James Morris]

On Wed, 20 Sep 2006, Christopher J. PeBenito wrote:

> I don't agree with the first part of this point.  This isn't really any
> different than the old networking where you hand to look up the context
> of the ports, nodes, and netif (the ports being the one with a similar
> amount entries) on every packet.  Second, the cost of going through the
> chain with all of the rules is only on new connections.  Established
> connections will skip that and just get the connection tracking label
> w/CONNSECMARK --restore.

Agreed.  The discussion of performance impact when no performance testing 
has been done seems premature.  People probably don't realize that 
previously, three fully non-cached policyb lookups were being performed 
for every single packet flowing through the system.

>From what I can tell, too, the examples I provided in may where each 
service has its own chain has not been followed.  The point of that was to 
allow a matching packet to then bypass the rest of the rules because a 
verdict has been issued.

There are port ranges and the multiport match which can reduce the 
number of iptables rule lookups for a packet.

Also, very importantly, rules should only be loaded for services which are 
active.  This should be clear from the examples provided, where the 
rule for each example service was in its own script module.

It should also be possible to automatically retune the rules on a regular 
basis by looking at the packet counters and reloading the rules so that 
the highest hit rules are listed first.

This is not rocket science.


- 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: ipsec, netlabels, secmark- How about a little usability?

[Christopher J. PeBenito]

On Wed, 2006-09-20 at 09:45 -0400, James Morris wrote:
> On Wed, 20 Sep 2006, Christopher J. PeBenito wrote:
> 
> > I don't agree with the first part of this point.  This isn't really any
> > different than the old networking where you hand to look up the context
> > of the ports, nodes, and netif (the ports being the one with a similar
> > amount entries) on every packet.  Second, the cost of going through the
> > chain with all of the rules is only on new connections.  Established
> > connections will skip that and just get the connection tracking label
> > w/CONNSECMARK --restore.
> 
> Agreed.  The discussion of performance impact when no performance testing 
> has been done seems premature.  People probably don't realize that 
> previously, three fully non-cached policyb lookups were being performed 
> for every single packet flowing through the system.
> 
> From what I can tell, too, the examples I provided in may where each 
> service has its own chain has not been followed.  The point of that was to 
> allow a matching packet to then bypass the rest of the rules because a 
> verdict has been issued.
> 
> There are port ranges and the multiport match which can reduce the 
> number of iptables rule lookups for a packet.
> 
> Also, very importantly, rules should only be loaded for services which are 
> active.  This should be clear from the examples provided, where the 
> rule for each example service was in its own script module.
> 
> It should also be possible to automatically retune the rules on a regular 
> basis by looking at the packet counters and reloading the rules so that 
> the highest hit rules are listed first.

In the past we decided to enable all ports regardless of whether or not
the service was on or its policy was loaded (not just refpolicy, the old
example policy too).  Connections to port 80 are http connections, even
if the local machine doesn't have apache installed.  Since the netfilter
labeling replaces the old networking, refpolicy will have all of the
netfilter labeling rules enabled too.  I didn't follow your example
because of that, otherwise we would have about 180 chains.  Since the
cost of going through the labeling chain only happens on the first
packet of a connection, it didn't seem like a problem that the remainder
of the rules were not bypassed once a match was made.

-- 
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: ipsec, netlabels, secmark- How about a little usability?

[James Morris]

On Wed, 20 Sep 2006, Christopher J. PeBenito wrote:

> netfilter labeling rules enabled too.  I didn't follow your example
> because of that, otherwise we would have about 180 chains.

Not sure why this is a problem.

> Since the cost of going through the labeling chain only happens on the 
> first packet of a connection, it didn't seem like a problem that the 
> remainder of the rules were not bypassed once a match was made.

This will be an issue for things like web servers, where you have high 
connection rates and there will be lots of syn packets needing to be 
matched and traversing each rule.

On such a server, you should have the port 80 match first and jump to a 
chain which applies the secmark and then returns a verdict, so the packet 
does not traverse any more rules in that table.


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