All of lore.kernel.org
 help / color / mirror / Atom feed
* Denials from newest kernel
@ 2006-10-06 13:31 Joshua Brindle
  2006-10-06 17:32 ` James Morris
  2006-10-06 19:02 ` Paul Moore
  0 siblings, 2 replies; 76+ messages in thread
From: Joshua Brindle @ 2006-10-06 13:31 UTC (permalink / raw)
  To: selinux@tycho.nsa.gov, Venkat Yekkirala

I grabbed Erics new kernel builds and installed them and got some
interesting denials. I started with no secmark rules whatsoever on the
machine.

avc:  denied  { flow_out } for  pid=1815 comm="avahi-daemon" saddr=10.1.13.105 daddr=224.0.0.22 netif=eth0 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet

the target seems reasonable (unlabeled_t since there are no secmark
rules) but the target should have been network_t (the unlabeled
association) right?

avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:system_r:avahi_t:s0 tclass=packet

don't understand this one at all, source should be network_t (i thought)
and target should be a packet object (and there aren't any). Why is it
getting the domain context?

avc:  denied  { recv } for  pid=1815 comm="avahi-daemon" src=5353 dest=5353 netif=eth0 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:system_r:avahi_t:s0 tclass=packet

So the source here seems correct but the target is avahi_t again..


I'm going to load up some secmark rules as soon as I get an iptables
build that lets me (wonder why rawhides doesn't come with SECMARK :\ )
and try this again.


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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 13:45 Venkat Yekkirala
  2006-10-06 13:55 ` Joshua Brindle
  2006-10-06 14:39 ` Paul Moore
  0 siblings, 2 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 13:45 UTC (permalink / raw)
  To: Joshua Brindle, selinux, Venkat Yekkirala

> -----Original Message-----
> From: Joshua Brindle [mailto:jbrindle@tresys.com]
> Sent: Friday, October 06, 2006 8:32 AM
> To: selinux@tycho.nsa.gov; Venkat Yekkirala
> Subject: Denials from newest kernel
> 
> 
> I grabbed Erics new kernel builds and installed them and got some
> interesting denials. I started with no secmark rules whatsoever on the
> machine.
> 
> avc:  denied  { flow_out } for  pid=1815 comm="avahi-daemon" 
> saddr=10.1.13.105 daddr=224.0.0.22 netif=eth0 
> scontext=system_u:object_r:unlabeled_t:s0 
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
> 
> the target seems reasonable (unlabeled_t since there are no secmark
> rules) but the target should have been network_t (the unlabeled
> association) right?

Actually, the source should have read avahi_t and the target network_t.

network_t refers to the "network cloud" so to speak.

IOW, "can a packet from domain avahi_t flow_out to the network?".

> 
> avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon" 
> scontext=system_u:object_r:unlabeled_t:s0 
> tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> 
> don't understand this one at all, source should be network_t 
> (i thought)
> and target should be a packet object (and there aren't any). Why is it
> getting the domain context?

Source seems fine (unlabeled since no secmark and no labeled-ipsec I
suppose), but target should have been network_t.

I would like Paul to first clear the netlabel changes as the culprit.

> 
> avc:  denied  { recv } for  pid=1815 comm="avahi-daemon" 
> src=5353 dest=5353 netif=eth0 
> scontext=system_u:system_r:avahi_t:s0 
> tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> 
> So the source here seems correct but the target is avahi_t again..

Bizarre...

> 
> 
> I'm going to load up some secmark rules as soon as I get an iptables
> build that lets me (wonder why rawhides doesn't come with SECMARK :\ )
> and try this again.
> 

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 14:23 Venkat Yekkirala
  2006-10-06 14:50 ` Joshua Brindle
  0 siblings, 1 reply; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 14:23 UTC (permalink / raw)
  To: Joshua Brindle, Venkat Yekkirala; +Cc: selinux

> -----Original Message-----
> From: Joshua Brindle [mailto:jbrindle@tresys.com]
> Sent: Friday, October 06, 2006 8:56 AM
> To: Venkat Yekkirala
> Cc: selinux@tycho.nsa.gov
> Subject: RE: Denials from newest kernel
> 
> 
> On Fri, 2006-10-06 at 09:45 -0400, Venkat Yekkirala wrote:
> > > -----Original Message-----
> > > From: Joshua Brindle [mailto:jbrindle@tresys.com]
> > > Sent: Friday, October 06, 2006 8:32 AM
> > > To: selinux@tycho.nsa.gov; Venkat Yekkirala
> > > Subject: Denials from newest kernel
> > > 
> > > 
> > > I grabbed Erics new kernel builds and installed them and got some
> > > interesting denials. I started with no secmark rules 
> whatsoever on the
> > > machine.
> > > 
> > > avc:  denied  { flow_out } for  pid=1815 comm="avahi-daemon" 
> > > saddr=10.1.13.105 daddr=224.0.0.22 netif=eth0 
> > > scontext=system_u:object_r:unlabeled_t:s0 
> > > tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
> > > 
> > > the target seems reasonable (unlabeled_t since there are 
> no secmark
> > > rules) but the target should have been network_t (the unlabeled
> > > association) right?
> > 
> > Actually, the source should have read avahi_t and the 
> target network_t.
> > 
> > network_t refers to the "network cloud" so to speak.
> > 
> > IOW, "can a packet from domain avahi_t flow_out to the network?".
> > 
> 
> I was under the impression that the flow_out permissions referred to a
> packet object (you are claiming that the association label will be the
> target, this is object class confusion) flowing out an 
> association so it
> should be allow network_t unlabeled_t (or 
> avahi_server_packet_t if I had
> secmark on : packet { flow_out }
> 
> If this is intentionally referring to the association as the 
> target then
> the permissions need to be moved to the association object class

I would have to refer you to the following discussion we had on how
secpoint err secmark is intended to be used thru to deciding not to
mess with the naming.
http://marc.theaimsgroup.com/?l=selinux&m=115928609916717&w=2

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 15:11 Venkat Yekkirala
  2006-10-06 15:17 ` Joshua Brindle
  2006-10-06 15:21 ` Stephen Smalley
  0 siblings, 2 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 15:11 UTC (permalink / raw)
  To: Joshua Brindle, Venkat Yekkirala; +Cc: selinux

Joshua Brindle wrote:
> On Fri, 2006-10-06 at 10:23 -0400, Venkat Yekkirala wrote:
> > > -----Original Message-----
> > > From: Joshua Brindle [mailto:jbrindle@tresys.com]
> > > Sent: Friday, October 06, 2006 8:56 AM
> > I would have to refer you to the following discussion we had on how
> > secpoint err secmark is intended to be used thru to deciding not to
> > mess with the naming.
> > http://marc.theaimsgroup.com/?l=selinux&m=115928609916717&w=2
> 
> That peer conversation was bin/null'd though,

Stephen and others can correct me if I am wrong, but while
the naming was bin/null'd AFTER the con call, the policy was
going to be done substantially as related in the peer conversation.

> the conference 
> call we had
> indicated that the new model was going to be 
> 
> 1) domains send/recv packets

1(a). packets "carry" originating socket domains
1(b). domains "recv" from other domains the packets are "carrying".

> 2) packets flow_in and flow_out associations

2(a) Associations again merely "carry" the domain of the originating socket
     and as such are not of much relevance.
2(b) domains as carried by packets can either flow_in or flow_out of
     the security points as defined using the secmark rules.

> 3) domains polmatch spd's (which are classified as associations)

I wish the association class were renamed more like "ipsec" considering
the only 2 perms used in there are polmatch and setcontext.

> 4) domains sendto/recvfrom associations

In the compat_net case, yes. But not in the secmark world.

> 
> IMO we need to get the permissions and object classes cleared 
> up before
> merging this stuff, its very confusing and inappropriate right 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.

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 19:43 Venkat Yekkirala
  0 siblings, 0 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 19:43 UTC (permalink / raw)
  To: Paul Moore, Joshua Brindle, Venkat Yekkirala; +Cc: selinux

Paul Moore wrote:
> Joshua Brindle wrote:
> > I grabbed Erics new kernel builds and installed them and got some
> > interesting denials. I started with no secmark rules 
> whatsoever on the
> > machine.
> 
> Okay, some more data for everybody to chew on.  For my tests 
> I used the lspp.51
> kernel as well as the kernel and MLS policy generated from 
> the source RPMs
> posted here:
> 
>  * http://free.linux.hp.com/~pmoore/files
> 
> The only differences between these source RPMs are the 
> original is the removal
> of the NetLabel/secid patch in the kernel and the addition of
> "network_t:s0-s15:c0.c255" to the netmsg initial SID.
> 
> The summary is that I see no difference between the kernel with the
> NetLabel/secid patch and the one without.
> 
>  * flow_out permission
> 
> Joshua reported:
> 
> > avc:  denied  { flow_out } for  pid=1815 comm="avahi-daemon"
> > saddr=10.1.13.105 daddr=224.0.0.22 netif=eth0
> > scontext=system_u:object_r:unlabeled_t:s0
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
> 
> With the lspp.51 kernel I see:
> 
> type=AVC msg=audit(1160160485.587:61): avc:  denied  { 
> flow_out } for  pid=2297
> comm="avahi-daemon" saddr=10.0.0.255 src=5353 
> daddr=224.0.0.251 dest=5353
> netif=eth0 scontext=root:staff_r:staff_t:s0-s15:c0.c255
> tcontext=system_u:object_r:network_t:s0-s15:c0.c255 tclass=packet
> 
> With the lspp.51 kernel w/o NetLabel/secid I see:
> 
> type=AVC msg=audit(1160160670.049:61): avc:  denied  { 
> flow_out } for  pid=2289
> comm="avahi-daemon" saddr=10.0.0.255 src=5353 
> daddr=224.0.0.251 dest=5353
> netif=eth0 scontext=root:staff_r:staff_t:s0-s15:c0.c255
> tcontext=system_u:object_r:network_t:s0-s15:c0.c255 tclass=packet
> 
> * flow_in permission
> 
> Joshua reported:
> 
> > avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon" 
> > scontext=system_u:object_r:unlabeled_t:s0
> > tcontext=system_u:system_r:avahi_t:s0 tclass=packet

I see you aren't seeing what Joshua reported.

Joshua, what policy version are you using and what patches
have been applied to it? Are you still seeing the above flow_in
with the target saying "avahi_t"?

> 
> With the lspp.51 kernel I see:
> 
> type=AVC msg=audit(1160160485.587:61): avc:  denied  { 
> flow_in } for  pid=2297
> comm="avahi-daemon" scontext=system_u:object_r:unlabeled_t:s15:c0.c255
> tcontext=system_u:object_r:network_t:s0-s15:c0.c255 tclass=packet
> 
> With the lspp.51 kernel w/o NetLabel/secid I see:
> 
> type=AVC msg=audit(1160160670.049:61): avc:  denied  { 
> flow_in } for  pid=2289
> comm="avahi-daemon" scontext=system_u:object_r:unlabeled_t:s15:c0.c255
> tcontext=system_u:object_r:network_t:s0-s15:c0.c255 tclass=packet
> 
>  * recv permission
> 
> Joshua reported:
> 
> > avc:  denied  { recv } for  pid=1815 comm="avahi-daemon"
> > src=5353 dest=5353 netif=eth0
> > scontext=system_u:system_r:avahi_t:s0
> > tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> 
> I still get nothing as reported before.
> 
> -- 
> 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.

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 20:05 Venkat Yekkirala
  0 siblings, 0 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 20:05 UTC (permalink / raw)
  To: Joshua Brindle, selinux, Venkat Yekkirala

Joshua Brindle wrote:
> I grabbed Erics new kernel builds and installed them and got some
> interesting denials. I started with no secmark rules whatsoever on the
> machine.
> 

Taking a fresh look again...

1. What policy (with what patches) were you using when you saw these errors?

2. What is the avahi daemon doing in the below? The reason I ask is that
   if the packet originated on the local machine itself and some how flowed
back in,
   we would obviously see the avahi_t context as the target since that's
what the
   packet was carrying.

> avc:  denied  { flow_out } for  pid=1815 comm="avahi-daemon" 
> saddr=10.1.13.105 daddr=224.0.0.22 netif=eth0 
> scontext=system_u:object_r:unlabeled_t:s0 
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
> 
> the target seems reasonable (unlabeled_t since there are no secmark
> rules) but the target should have been network_t (the unlabeled
> association) right?
> 
> avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon" 
> scontext=system_u:object_r:unlabeled_t:s0 
> tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> 
> don't understand this one at all, source should be network_t 
> (i thought)
> and target should be a packet object (and there aren't any). Why is it
> getting the domain context?
> 
> avc:  denied  { recv } for  pid=1815 comm="avahi-daemon" 
> src=5353 dest=5353 netif=eth0 
> scontext=system_u:system_r:avahi_t:s0 
> tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> 
> So the source here seems correct but the target is avahi_t again..
> 
> 
> I'm going to load up some secmark rules as soon as I get an iptables
> build that lets me (wonder why rawhides doesn't come with SECMARK :\ )
> and try this again.
> 

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 21:15 Venkat Yekkirala
  2006-10-06 21:31 ` Paul Moore
  0 siblings, 1 reply; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 21:15 UTC (permalink / raw)
  To: Venkat Yekkirala, 'Joshua Brindle',
	'selinux@tycho.nsa.gov'

Venkat Yekkirala wrote:
> Joshua Brindle wrote:
> > I grabbed Erics new kernel builds and installed them and got some
> > interesting denials. I started with no secmark rules 
> whatsoever on the
> > machine.
> > 
> 
> Taking a fresh look again...
> 
> 1. What policy (with what patches) were you using when you 
> saw these errors?
> 
> 2. What is the avahi daemon doing in the below? The reason I 
> ask is that
>    if the packet originated on the local machine itself and 
> some how flowed back in,
>    we would obviously see the avahi_t context as the target 
> since that's what the
>    packet was carrying.
> 

Seeing that avahi is sending to a multicast address, it seems like
it's receiving a copy of the message, THAT HAS THE avahi_t originating
domain still tied to it. I am going to send a patch out shortly that
will nullout this tie-up to the originating domain in postroute_last.
This *should* take care of denials 2 &3 below. They will still appear,
but with network_t (or unlabeled_t in Joshua's case since he seems to
have his netmsg initsid context set to unlabeled_t:s0 as also the unlabeled
initsid) in the target.

I am still unable to explain the 1st denial below though. The source should
have been "avahi_t", but it shows up as unlabeled_t.

> > avc:  denied  { flow_out } for  pid=1815 comm="avahi-daemon" 
> > saddr=10.1.13.105 daddr=224.0.0.22 netif=eth0 
> > scontext=system_u:object_r:unlabeled_t:s0 
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
> > 
> > the target seems reasonable (unlabeled_t since there are no secmark
> > rules) but the target should have been network_t (the unlabeled
> > association) right?
> > 
> > avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon" 
> > scontext=system_u:object_r:unlabeled_t:s0 
> > tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> > 
> > don't understand this one at all, source should be network_t 
> > (i thought)
> > and target should be a packet object (and there aren't 
> any). Why is it
> > getting the domain context?
> > 
> > avc:  denied  { recv } for  pid=1815 comm="avahi-daemon" 
> > src=5353 dest=5353 netif=eth0 
> > scontext=system_u:system_r:avahi_t:s0 
> > tcontext=system_u:system_r:avahi_t:s0 tclass=packet
> > 
> > So the source here seems correct but the target is avahi_t again..
> > 
> > 
> > I'm going to load up some secmark rules as soon as I get an iptables
> > build that lets me (wonder why rawhides doesn't come with 
> SECMARK :\ )
> > and try this again.
> > 
> 

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 21:17 Venkat Yekkirala
  2006-10-09 14:03 ` Joshua Brindle
  0 siblings, 1 reply; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 21:17 UTC (permalink / raw)
  To: Venkat Yekkirala, 'Joshua Brindle',
	'selinux@tycho.nsa.gov'

Venkat Yekkirala wrote:
> Venkat Yekkirala wrote:
> > Joshua Brindle wrote:
> > > I grabbed Erics new kernel builds and installed them and got some
> > > interesting denials. I started with no secmark rules 
> > whatsoever on the
> > > machine.
> > > 
> > 
> > Taking a fresh look again...
> > 
> > 1. What policy (with what patches) were you using when you 
> > saw these errors?
> > 
> > 2. What is the avahi daemon doing in the below? The reason I 
> > ask is that
> >    if the packet originated on the local machine itself and 
> > some how flowed back in,
> >    we would obviously see the avahi_t context as the target 
> > since that's what the
> >    packet was carrying.
> > 
> 
> Seeing that avahi is sending to a multicast address, it seems like
> it's receiving a copy of the message, THAT HAS THE avahi_t originating
> domain still tied to it. I am going to send a patch out shortly that
> will nullout this tie-up to the originating domain in postroute_last.
> This *should* take care of denials 2 &3 below. They will still appear,
> but with network_t (or unlabeled_t in Joshua's case since he seems to
> have his netmsg initsid context set to unlabeled_t:s0 as also 
> the unlabeled
> initsid) in the target.
BTW, Joshua probably knows that the machine needs to be rebooted for
any initsid changes to take effect.

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-06 21:34 Venkat Yekkirala
  0 siblings, 0 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-06 21:34 UTC (permalink / raw)
  To: Paul Moore, Venkat Yekkirala
  Cc: 'Joshua Brindle', 'selinux@tycho.nsa.gov'

Paul Moore wrote:
> Venkat Yekkirala wrote:
> > Venkat Yekkirala wrote:
> > 
> >>Joshua Brindle wrote:
<snip>
> Just so it's clear in my mind, you're planning to set skb->secmark to
> SECSID_NULL/0 *after* the last access check in 
> selinux_ip_postroute_last()?

Yes, sir. Patch forthcoming in a few minutes.

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-09 23:40 Venkat Yekkirala
  2006-10-10  0:10 ` Joshua Brindle
  2006-10-10 14:07 ` Christopher J. PeBenito
  0 siblings, 2 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-09 23:40 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: 'selinux@tycho.nsa.gov'

> Anyway, after installing the labeled-networking branch from 
> svn co
> http://oss.tresys.com/repos/refpolicy/branches/labeled-networking-2029
> 
> and rebooting onto erics kernel:
> http://people.redhat.com/eparis/RHEL5_labeled_networking/kerne
> l-PAE-2.6.18-1.2717.2.1.el5.lspp.51.i686.rpm
> 
> I'm still getting some strange denials. I know some of these are
> probably from the patches you've put that that eric hasn't picked up,
> I'll try to filter those out. 
> 
> audit(1160324043.201:242): avc:  denied  { flow_out } for  
> pid=1822 comm="yum-updatesd" 
> scontext=system_u:object_r:client_packet_t:s0 
> tcontext=system_u:object_r:http_client_packet_t:s0 tclass=packet
> 
> I don't even know what these mean at all. What is the source? What is
> the target? The secmark rules that will give these types are: 
> -A selinux_new_output -p tcp --dport 80 -j SECMARK --selctx 
> system_u:object_r:http_client_packet_t:s0
> -A selinux_new_output -p tcp --dport 443 -j SECMARK --selctx 
> system_u:object_r:http_client_packet_t:s0
> -A selinux_new_output -p tcp --dport 488 -j SECMARK --selctx 
> system_u:object_r:http_client_packet_t:s0
> -A selinux_new_output -p tcp --dport 8008 -j SECMARK --selctx 
> system_u:object_r:http_client_packet_t:s0
> -A selinux_new_output -p tcp --dport 8009 -j SECMARK --selctx 
> system_u:object_r:http_client_packet_t:s0
> -A selinux_new_output -p tcp --dport 8443 -j SECMARK --selctx 
> system_u:object_r:http_client_packet_t:s0
> and
> -A selinux_new_output -j SECMARK --selctx 
> system_u:object_r:client_packet_t:s0
> (which is the first rule incase no others match)

It seems like the SECMARK target on the last rule (client_packet_t)
got executed BEFORE the port 80 one, causing the packet (yum-updatesd_t?)
to

1. be flow-controlled first against client_packet_t
2. assume the client_packet_t label overriding yum-updatesd_t
3. be flow-controlled against http_client_packet_t
4. assume http_client_packet_t
5. be flow-controlled against network_t

It seems like you saw 1,2 and 3 here and 4 & 5 later when you
mention you were finally seeing the expected denials.

> 
> So I guess maybe this is getting the target from the outgoing port
> (which is probably 80) and then the source from the local port (which

No, the "source" here is whatever domain the packet is carrying at the point
it hits the secmark rule that specifies the target.

> hit the fallback). This doesn't sound like the access checks we wanted
> at all. 
> 
> on the bright side I did manage to see some that looked 
> semi-valid (only
> with ping between 2 selinux machines though) 
> audit(1160317777.866:171): avc:  denied  { flow_out } for  
> saddr=10.1.13.105 daddr=10.1.13.30 netif=eth0 
> scontext=system_u:object_r:server_packet_t:s0 
> tcontext=system_u:object_r:no_extlabel_t:s0 tclass=packet
>

I will have to look at the policy (BTW what file has these secmark
rules?), but the thing to look to see is if the documented behavior
matches up with the actual as driven by policy. IOW, should the
packet have been carrying "server_packet_t" when it hit this check?
(The document I posted this morning for policy writers is hopefully
explanatory enough).

> (PeBenito changed the netmsg initial sid to no_extlabel_t, he 
> didn't like network_t I guess).

This is scary to my eyes at least. I had already laid out the
intended usage of these controls in terms of peer "domains" as
opposed to "packet types".

> 
> I added these rules 
> auditallow { packet_type domain } { unlabeled_t no_extlabel_t 
> domain packet_type } : association *;
> auditallow { packet_type domain } { unlabeled_t no_extlabel_t 
> domain packet_type } : packet *;
> 
> but am not seeing polmatches and other permissions that I expect. For
> example, the first denials in this email had no accompanying polmatch
> denials (even after switching to enforcing and allowing the packet
> flow_out)

No polmatch denials show up unless you have spd rules that specify
explicit contexts.

> 
> ah! after a few reloads I just got 
> audit(1160329607.081:254): avc:  denied  { flow_out } for  
> pid=2517 comm="yum" saddr=10.1.13.105 src=51656 
> daddr=152.3.220.166 dest=80 netif=eth0 
> scontext=system_u:object_r:http_client_packet_t:s0 
> tcontext=system_u:object_r:no_extlabel_t:s0 tclass=packet
> audit(1160329610.061:255): avc:  denied  { flow_out } for  
> saddr=10.1.13.105 src=51656 daddr=152.3.220.166 dest=80 
> netif=eth0 scontext=system_u:object_r:http_client_packet_t:s0 
> tcontext=system_u:object_r:no_extlabel_t:s0 tclass=packet
> 
> audit(1160330449.365:370): avc:  granted  { flow_out } for  
> pid=2453 comm="sshd" saddr=10.1.13.105 src=22 
> daddr=10.1.13.126 dest=58972 netif=eth0 
> scontext=system_u:object_r:ssh_server_packet_t:s0 
> tcontext=system_u:object_r:no_extlabel_t:s0 tclass=packet
> 
> which looks alot closer to what I expected (not sure why it 
> didn't show

See items 4&5 toward the top.

> up the first several times I tried it). Still no polmatch 
> rules though.

No spd rules with explicit contexts, no polmatch denials.

> 
> I also got this one
> audit(1160330449.365:369): avc:  granted  { flow_out } for  
> pid=2453 comm="sshd" 
> scontext=system_u:system_r:unconfined_t:s0 
> tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet
> 
> So that is the same weirdness, how can the exact same object 
> class/perm
> be used for a domain -> secmark check _and_ for a secmark -> 
> association

No "association" exists in the sense of IPSec SAs. Did you mean
network_t here?

> check.. this is very confusing

Indeed. The way to avoid the confusion is to define peer domains
using secmark, with network_t or such representing the network domain.

> 
> 
> (that was all with no ipsec)
> 
> After loading up some spd rules (all spd's labeled ipsec_spd_t)
> 
> audit(1160329985.116:279): avc:  denied  { polmatch } for  
> pid=2607 scontext=root:system_r:semanage_t:s0-s0:c0.c1023 
> tcontext=system_u:object_r:ipsec_spd_t:s0 tclass=association
> 
> there is our expected polmatch denial
> 
> audit(1160329985.124:281): avc:  denied  { flow_out } for  
> pid=2607 scontext=system_u:object_r:client_packet_t:s0 
> tcontext=system_u:object_r:client_packet_t:s0 tclass=packet
> 
> not sure here, was this an attempt to go out the unlabeled 
> association once the other was denied?

Seems like the secmark rule(s) with client_packet_t defined
as the context are being hit in succession. Most likely a
policy issue.

> 
> and here are some more when racoon tries to run (after I 
> allow the above polmatch)
> audit(1160330873.428:1629): avc:  granted  { flow_out } for  
> pid=2785 comm="racoon" 
> scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 
> tcontext=system_u:object_r:client_packet_t:s0 tclass=packet
> audit(1160330873.428:1631): avc:  granted  { flow_out } for  
> pid=2785 comm="racoon" saddr=10.1.13.105 src=500 
> daddr=10.1.13.30 dest=500 netif=eth0 
> scontext=system_u:object_r:isakmp_client_packet_t:s0 
> tcontext=system_u:object_r:no_extlabel_t:s0 tclass=packet

The latter seems like what one would expect to see per the policy
you are using.

Please see if the doc I posted today helps explain things.

I will try to use test using your policy and such tomorrow.

Thanks.

<snip>
> 

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-10 14:18 Venkat Yekkirala
  2006-10-10 14:42 ` Christopher J. PeBenito
  0 siblings, 1 reply; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-10 14:18 UTC (permalink / raw)
  To: Joshua Brindle; +Cc: selinux

> > It seems like the SECMARK target on the last rule 
> > (client_packet_t) got executed BEFORE the port 80 one, 
> > causing the packet (yum-updatesd_t?) to
> > 
> > 1. be flow-controlled first against client_packet_t 2. assume 
> > the client_packet_t label overriding yum-updatesd_t 3. be 
> > flow-controlled against http_client_packet_t 4. assume 
> > http_client_packet_t 5. be flow-controlled against network_t
> > 
> > It seems like you saw 1,2 and 3 here and 4 & 5 later when you 
> > mention you were finally seeing the expected denials.
> > 
> 
> Yep, the client_packet_t one is first, Chris was under the impression
> the last one would win and the others wouldn't matter so the fallback
> was specified as the first rule in the chain. Look at the

I will have to just refer you to the following to get an idea
as to what the developers had in mind :)
http://marc.theaimsgroup.com/?l=selinux&m=115876013220221&w=2
http://marc.theaimsgroup.com/?l=selinux&m=115876375201000&w=2

> netfilter_contexts file created when you build refpolicy and 
> insert all
> the modules (make load) 
> 
> That seems like a very strange way of doing access checks, I 
> guess I was
> also under the impression that the check would be done after 
> the mangle
> table was exited so that only the net result was tested.

We are currently unable to do that due to implementation
constraints. But you can to the most part avoid this situation
by heeding James' suggestions in the above, by jumping to
unique labeling chains that quickly end with a verdict.

Otherwise, you would have to have the more fine-grained security points
defined ahead of the less fine-grained. A very useful way to visualize
this is to think of smaller pipes protruding from bigger ones, with
network_t being the all-encompassing one.

> I'll 
> fix up my
> netfilter_contexts file and see how that affects the tests. Thanks.

I would really start looking at things in the realm of the peer domains
to make the best sense of the new 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.

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-10 14:42 Venkat Yekkirala
  2006-10-10 18:33 ` Christopher J. PeBenito
  0 siblings, 1 reply; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-10 14:42 UTC (permalink / raw)
  To: Christopher J. PeBenito, Venkat Yekkirala
  Cc: Joshua Brindle, 'selinux@tycho.nsa.gov'

> I don't think this is a desired behavior for a couple reasons.  First,
> this means that every domain that has access to a specific packet, for
> example, http_client_packet_t, but not to client_packet_t, 
> will have to
> dontaudit the client_packet_t access.  Thats a lot of 

But this is a problem of our own making in the policy. If we
jump into a unique chain for a label (or a set of labels all
fine-grained to the same "grade", and hence are non-conflicting)
then we shouldn't see this. Please refer to the links I mentioned in
my response to Joshua.

> dontauditing, and
> also it will cover up legitimate denials on client_packet_t.  Second,

It won't if you defined the catch-all security point only for the
real catch-all cases.

> this will cause permissive to have a different behavior than 
> enforcing.
> This makes development in permissive more difficult, since you'll get
> spurious denials that you wouldn't get in enforcing.
> 
> > > (PeBenito changed the netmsg initial sid to no_extlabel_t, he 
> > > didn't like network_t I guess).
> > 
> > This is scary to my eyes at least. I had already laid out the
> > intended usage of these controls in terms of peer "domains" as
> > opposed to "packet types".
> 
> The refpolicy interfaces should be able to make this abstraction.
> Network_t wasn't clear in my opinion, since you only needed 
> that access
> for non labeled networking.

Nope, all of the following need to be able to flow_out of this pipe
that represents the network.

1. All the local domains that need to access the network directly
   without flowing thru any "fine-grained" security points.

2. All fine-grained security point domains assumed by packets that
   are flowing out of these security points. This check should have
   been avoidable, but is not due to implementation constraints.

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

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-10 15:45 Venkat Yekkirala
  0 siblings, 0 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-10 15:45 UTC (permalink / raw)
  To: Christopher J. PeBenito, Venkat Yekkirala; +Cc: Joshua Brindle, selinux

> Thats what was intended, but that doesn't mean its the only solution.
> Netfilter is supposed to be flexible and works in many different ways,
> otherwise everyone would have similar firewalls.  The netfilter
> configuration currently provided by refpolicy provides the anticipated
> behavior on mainline kernels, the same as if it were done the 
> way James
> suggested.  What you're describing breaks the current behavior.

First of all, we are dealing with a different paradigm here (of security
points)
and any policy written to operate within that paradigm is naturally (perhaps
unfortunately) subject to the constraints as well.

Secondly, as to your contention that this breaks the current behavior,
it just happened that the policy was written to the paradigm current
as of the time it was written. For example, if that paradigm said "the
first label prevails", then the policy would have been done that way
(more restrictive followed by the catch-all).

In fact I view the constraints with the new paradigm  a blessing since
it has the effect of resulting in a very succinct policy since it
enforces a strict sequence of flow controls among the security point
domains when more than one apply to 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.

^ permalink raw reply	[flat|nested] 76+ messages in thread
* RE: Denials from newest kernel
@ 2006-10-10 16:28 Venkat Yekkirala
  0 siblings, 0 replies; 76+ messages in thread
From: Venkat Yekkirala @ 2006-10-10 16:28 UTC (permalink / raw)
  To: Joshua Brindle, Christopher J. PeBenito, Venkat Yekkirala; +Cc: selinux

> I (think) understand what is happening technically, everytime 
> you hit a
> secmark rule the label gets set on the skbuff which triggers an access
> check. Subsequent secmark rules trigger an access check 
> between the old
> label and the new one (I still suspect this should be a different
> permission), but it is still very unintuitive to me, and I'd imagine
> pretty much everyone else.

I wonder what's so unintuitive about the following description:

1. One could define several levels of security check points (one in
   the OUTPUT chain and another in POSTROUTING for example, or
   multiple points in the OUTPUT chain itself for another example).

2. As a packet passes a security point, it assumes the label of the
   security point for further flow control checks at subsequent security
   points.

> 
> (reading your email that just arrived..) 
> You really think that you can tell millions of users that they have to
> use iptables in James' way, with hundreds or thousands of chains and
> they'll buy it?

They will or they will not, to the same that they won't buy the "constraint"
that the last label prevails.

> That is not how iptables is normally used, noone who
> currently uses iptables is going to like it.. 

It's a matter of just looking at all existing and new verdict points and
just sticking in a SECMARK label before issuing the verdict, possibly in
the same rule.

> 
> 
> Anyway, the real issue I have is that I was under the impression

I hope would have been disspelled by the long discussions we have been
having on this stuff. Hopefully, the documentation I posted yesterday
for policy writers is clear enough.

> that
> flow_out was a permission between a packet type and an association, to

between a domain the packet is carrying and a security point domain

> indicate that the packet type can flow out the association type.

to indicate that the packet from the domain can flow out to the security
point domain.

> This
> makes sense and is very useful, so that we can bind very specific
> properties of packets to ipsec associations. 

This is not possible at the iptables level. Your ability to define
the "very specific properties of packets" is limited to what the
spd offers, in conjunction with the polmatch check ofcourse.

ipsec labeling (which is the exact same as the originating domain)
happens long before and has nothing to do with the new flow controls.

> 
> I just don't get why there are denials on flow_in and 
> flow_out that have
> no association in either the source or target, how does flow_out make
> sense for a secmark changing because it hit more than 1 
> iptables rule? 
> 

Hopefully the above addressed 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.

^ permalink raw reply	[flat|nested] 76+ messages in thread
end of thread, other threads:[~2006-10-24  0:44 UTC | newest]

Thread overview: 76+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-06 13:31 Denials from newest kernel Joshua Brindle
2006-10-06 17:32 ` James Morris
2006-10-06 18:41   ` Steve G
2006-10-06 19:50     ` James Morris
2006-10-06 19:56       ` Joshua Brindle
2006-10-06 20:13         ` Christopher J. PeBenito
2006-10-06 19:02 ` Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
2006-10-06 13:45 Venkat Yekkirala
2006-10-06 13:55 ` Joshua Brindle
2006-10-06 14:39 ` Paul Moore
2006-10-06 14:23 Venkat Yekkirala
2006-10-06 14:50 ` Joshua Brindle
2006-10-06 15:11 Venkat Yekkirala
2006-10-06 15:17 ` Joshua Brindle
2006-10-06 16:25   ` Stephen Smalley
2006-10-06 15:21 ` Stephen Smalley
2006-10-06 15:44   ` Joshua Brindle
2006-10-06 15:56     ` Stephen Smalley
2006-10-06 16:59       ` Karl MacMillan
2006-10-06 18:31   ` Joshua Brindle
2006-10-06 19:04     ` Joshua Brindle
2006-10-06 19:43 Venkat Yekkirala
2006-10-06 20:05 Venkat Yekkirala
2006-10-06 21:15 Venkat Yekkirala
2006-10-06 21:31 ` Paul Moore
2006-10-06 21:17 Venkat Yekkirala
2006-10-09 14:03 ` Joshua Brindle
2006-10-06 21:34 Venkat Yekkirala
2006-10-09 23:40 Venkat Yekkirala
2006-10-10  0:10 ` Joshua Brindle
2006-10-10 14:07 ` Christopher J. PeBenito
2006-10-10 15:55   ` Joshua Brindle
2006-10-10 14:18 Venkat Yekkirala
2006-10-10 14:42 ` Christopher J. PeBenito
2006-10-10 14:42 Venkat Yekkirala
2006-10-10 18:33 ` Christopher J. PeBenito
2006-10-10 19:15   ` Venkat Yekkirala
2006-10-10 19:35     ` Karl MacMillan
2006-10-10 19:56       ` Venkat Yekkirala
2006-10-12 18:51         ` Christopher J. PeBenito
2006-10-12 20:06           ` Venkat Yekkirala
2006-10-13 15:06             ` Christopher J. PeBenito
2006-10-13 21:52               ` Venkat Yekkirala
2006-10-16 12:31                 ` Christopher J. PeBenito
2006-10-16 13:45                   ` Venkat Yekkirala
2006-10-16 13:53                     ` Christopher J. PeBenito
2006-10-16 14:16                       ` Venkat Yekkirala
2006-10-16 17:26                         ` Christopher J. PeBenito
2006-10-16 18:29                           ` Venkat Yekkirala
2006-10-16 18:53                             ` Paul Moore
2006-10-17 13:56                             ` Christopher J. PeBenito
2006-10-17 17:58                               ` Darrel Goeddel
2006-10-17 18:22                                 ` Christopher J. PeBenito
2006-10-17 19:23                                   ` Darrel Goeddel
2006-10-18 13:45                                     ` Christopher J. PeBenito
2006-10-19 15:57                                       ` Venkat Yekkirala
2006-10-20 12:41                                         ` Christopher J. PeBenito
2006-10-23 17:42                                           ` Venkat Yekkirala
2006-10-24  0:44                                             ` Christopher J. PeBenito
2006-10-13 22:42             ` Paul Moore
2006-10-14  1:00               ` Venkat Yekkirala
2006-10-14 12:13                 ` Paul Moore
2006-10-14 19:50                   ` Venkat Yekkirala
2006-10-14 20:41                     ` Paul Moore
2006-10-14 20:58                     ` James Morris
2006-10-14 23:01                       ` Venkat Yekkirala
2006-10-16 13:16                         ` Christopher J. PeBenito
2006-10-16 14:11                           ` Venkat Yekkirala
2006-10-14  7:36               ` James Morris
2006-10-14 12:18                 ` Paul Moore
2006-10-14 20:10                 ` Venkat Yekkirala
2006-10-10 20:05     ` Christopher J. PeBenito
2006-10-11 14:04       ` Venkat Yekkirala
2006-10-12  7:19         ` James Morris
2006-10-10 15:45 Venkat Yekkirala
2006-10-10 16:28 Venkat Yekkirala

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.