Denials from newest kernel

Denials from newest kernel

[Joshua Brindle]

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.

RE: Denials from newest kernel

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

RE: Denials from newest kernel

[Joshua Brindle]

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

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

seems like there is confusion again, if the target is network_t (which
is the default association label) then the target class should be
association. This should have been (to my understanding) allow network_t
unlabeled_t : packet { flow_in }

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

where are these contexts coming from?


--
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: Denials from newest kernel

[Venkat Yekkirala]

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

Re: Denials from newest kernel

[Paul Moore]

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.
> 
> I would like Paul to first clear the netlabel changes as the culprit.

I'm rebuilding the source RPM without the NetLabel/secid patch as I type this.
I'll startup the "avahi-daemon" and post the audit messages I see as a result.

-- 
paul moore
linux security @ hp

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

RE: Denials from newest kernel

[Joshua Brindle]

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

That peer conversation was bin/null'd though, the conference call we had
indicated that the new model was going to be 

1) domains send/recv packets
2) packets flow_in and flow_out associations
3) domains polmatch spd's (which are classified as associations)
4) domains sendto/recvfrom associations

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.

RE: Denials from newest kernel

[Venkat Yekkirala]

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.

RE: Denials from newest kernel

[Joshua Brindle]

On Fri, 2006-10-06 at 11:11 -0400, Venkat Yekkirala wrote:
> 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.
> 

maybe so but that doesn't mean they need to be fixed now :)

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

fine.

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

regardless of the semantics the target type *must* be the kind of object
referred to by the target object class, anything else is very confusing.

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

why not do it? none of this is merged yet.

> 
> > 4) domains sendto/recvfrom associations
> 
> In the compat_net case, yes. But not in the secmark world.
> 

I think we need this, in my proxy example we depend on being able to
differentiate the socket label from the domain label. The socket label
(which is the proxy client label) needs to be able to flow over the
association but the proxy client itself should not be able to, only the
proxy server should.

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

RE: Denials from newest kernel

[Stephen Smalley]

On Fri, 2006-10-06 at 11:11 -0400, Venkat Yekkirala wrote:
> 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.

Correct.  BTW, that's /dev/null to most people ;)

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

More importantly:
- We need to fix real bug (e.g. incorrect source or target context for a
given check, incorrect set of checks applied on some operation/code
path).
- We need to document what the checks mean and how they are applied so
that policy writers can understand them.

Renaming them doesn't really help.  Classes have always been a fairly
artificial construct, and you can see that already in the existing
checks prior to this work.

-- 
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: Denials from newest kernel

[Joshua Brindle]

On Fri, 2006-10-06 at 11:21 -0400, Stephen Smalley wrote:
> On Fri, 2006-10-06 at 11:11 -0400, Venkat Yekkirala wrote:
> > 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.
> 
> Correct.  BTW, that's /dev/null to most people ;)
> 

err, yea, I'm a rebel, take that FHS

> > > 
> > > IMO we need to get the permissions and object classes cleared 
> > > up before
> > > merging this stuff, its very confusing and inappropriate right now.
> 
> More importantly:
> - We need to fix real bug (e.g. incorrect source or target context for a
> given check, incorrect set of checks applied on some operation/code
> path).

Correct.

> - We need to document what the checks mean and how they are applied so
> that policy writers can understand them.
> 

Yes, I'm trying to document it (thus my previous emails about the
complex case, once that is solved the steps preceding it are the ones
interesting to most people)

> Renaming them doesn't really help.  Classes have always been a fairly
> artificial construct, and you can see that already in the existing
> checks prior to this work.
> 

Renaming does help, classes may be artificial but the target context
*should* be an object that is represented by the target object class. It
was very confusing writing rules (and seeing denials) where there is no
such object of the tclass type that was labeled with tcon.


--
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: Denials from newest kernel

[Stephen Smalley]

On Fri, 2006-10-06 at 11:44 -0400, Joshua Brindle wrote:
> > Renaming them doesn't really help.  Classes have always been a fairly
> > artificial construct, and you can see that already in the existing
> > checks prior to this work.
> > 
> 
> Renaming does help, classes may be artificial but the target context
> *should* be an object that is represented by the target object class. It
> was very confusing writing rules (and seeing denials) where there is no
> such object of the tclass type that was labeled with tcon.

But in the case where an object inherits the label of another object,
that is to be expected - we will end up seeing "packets" with the labels
of associations, which in turn are labels of sockets, which in turn are
(usually) labels of processes.  No need to turn every check on a
"packet" into a check on some original class from which its label was
derived.

Also, the above isn't true of all checks, e.g.
	allow ftpd_t ftp_port_t:tcp_socket name_bind;

-- 
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: Denials from newest kernel

[Stephen Smalley]

On Fri, 2006-10-06 at 11:17 -0400, Joshua Brindle wrote:
> > > 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.
> 
> why not do it? none of this is merged yet.

Um, association class has been present since 2.6.16, and polmatch is
already in 2.6.19-rc1.  

-- 
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: Denials from newest kernel

[Karl MacMillan]

Stephen Smalley wrote:
> On Fri, 2006-10-06 at 11:44 -0400, Joshua Brindle wrote:
>   
>
> But in the case where an object inherits the label of another object,
> that is to be expected - we will end up seeing "packets" with the labels
> of associations, which in turn are labels of sockets, which in turn are
> (usually) labels of processes.  No need to turn every check on a
> "packet" into a check on some original class from which its label was
> derived.
>
>   

Agreed.
> Also, the above isn't true of all checks, e.g.
> 	allow ftpd_t ftp_port_t:tcp_socket name_bind;
>
>   

For what its worth I always found that the overloading of the socket 
objects for port checks to be very confusing and difficult to explain.

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: Denials from newest kernel

[James Morris]

On Fri, 6 Oct 2006, Joshua Brindle wrote:

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

You need compat_net=1 to test what FC6 and RHEL5 will be shipping.



-- 
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: Denials from newest kernel

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2006-10-06 at 11:11 -0400, Venkat Yekkirala wrote:
>   
> <snip>
> More importantly:
> - We need to fix real bug (e.g. incorrect source or target context for a
> given check, incorrect set of checks applied on some operation/code
> path).
> - We need to document what the checks mean and how they are applied so
> that policy writers can understand them.
>
> Renaming them doesn't really help.  Classes have always been a fairly
> artificial construct, and you can see that already in the existing
> checks prior to this work

Ok, after loading up some secmark rules (the ones from targeted in 
rawhide) the packets are labeled things like httpd_client_packet_t and 
httpd_server_packet_t and so on. Here are the denials I get: (this is 
with no associations)

allow avahi_t self:packet recv;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : recv
 - so the packet somehow got the domain label, this was the same as the 
pre-secmark case so its an expected error I think.

allow avahi_t client_packet_t:packet flow_out;
 - based on the conversation this seems correct (whatever port it used 
for an outgoing connection was not a port specified in refpolicy, thus 
the generic client_packet_t)

allow avahi_t unlabeled_t:packet flow_out;
- So this is why I don't like the object class mixing. This could either 
be the mislabeled association (expected) or an unlabled packet (which 
should not happen, with the refpolicy netfilter_context all packets have 
some label, the fallbacks are client_packet_t and server_packet_t)

allow client_packet_t dns_client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="rpc.statd"   : flow_out
        #TYPE=AVC  MSG=  COMM="sshd"   : flow_out
allow client_packet_t howl_client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_out
allow client_packet_t portmap_client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="rpc.statd"   : flow_out
allow client_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_out
 - I don't even know what these mean. client_packet_t flowing out 
dns_client_packet_t?

And some others at the bottom that have unlabeled (i assume association)

I'd like to document somewhere the set of rules (selinux policy and 
other) necessary for simple things:
1) secmark rules w/ no ipsec
2) ipsec label propagation w/ no secmark  (this will be useful on rhel5 
since secmark will be disabled)
3) secmark and ipsec
4) the complex example with different labels on the sockets than the 
domain (I don't think this is possible right now)

The security properties that this should give us: (with all options in use)
1) Bind a domain (or socket) to a packet label to specify very precisely 
how a domain can communicate on the network
2) Bind a domain to a specific spd rule to specify the encryption 
properties needed for said domain
3) Bind a packet type to an association (labeled via the remote socket) 
to specify how packets can flow on the network (and to whom)
4) Bind a domain to an association (labeled via the remote socket) to 
specify how domains on remote machines can interact

All together this allows a very precise definition of both local network 
access and domain interaction between machines, which is very good :). 
Now if we can tell people how to accomplish this we all win, I'm still 
trying to fight through how to accomplish this. I'm posting this to 
ensure that my impression of the capabilities that should be present is 
accurate before I start lying to people :)

----

allow cupsd_t dns_client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="cupsd"   : flow_out
allow dns_client_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="rpc.statd"   : flow_out
        #TYPE=AVC  MSG=  COMM="cupsd"   : flow_out
allow howl_client_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_out
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_out
allow portmap_client_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="rpc.statd"   : flow_out
allow portmap_t portmap_client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="portmap"   : flow_out
allow rpcd_t client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="rpc.statd"   : flow_out
allow rpcd_t dns_client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="rpc.statd"   : flow_out
allow ssh_server_packet_t self:packet flow_out;
        #TYPE=AVC  MSG=   : flow_out
allow ssh_server_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=   : flow_out
allow unlabeled_t avahi_t:packet flow_in;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_in
allow unlabeled_t client_packet_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_out
allow unlabeled_t dhcpc_server_packet_t:packet flow_in;
        #TYPE=AVC  MSG=   : flow_in
        #TYPE=AVC  MSG=   : flow_in
allow unlabeled_t dns_client_packet_t:packet flow_in;
        #TYPE=AVC  MSG=   : flow_in
        #TYPE=AVC  MSG=   : flow_in
        #TYPE=AVC  MSG=  COMM="sshd"   : flow_in
allow unlabeled_t howl_server_packet_t:packet flow_in;
        #TYPE=AVC  MSG=  COMM="avahi-daemon"   : flow_in
allow unlabeled_t ssh_server_packet_t:packet flow_in;
        #TYPE=AVC  MSG=   : flow_in

--
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: Denials from newest kernel

[Steve G]

>You need compat_net=1 to test what FC6 and RHEL5 will be shipping.

FC6 turned off secmark support, but RHEL5 has it on.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Denials from newest kernel

[Paul Moore]

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

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.

Re: Denials from newest kernel

[Joshua Brindle]

On Fri, 2006-10-06 at 14:31 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2006-10-06 at 11:11 -0400, Venkat Yekkirala wrote:
> >   
> > <snip>
> > More importantly:
> > - We need to fix real bug (e.g. incorrect source or target context for a
> > given check, incorrect set of checks applied on some operation/code
> > path).
> > - We need to document what the checks mean and how they are applied so
> > that policy writers can understand them.
> >
> > Renaming them doesn't really help.  Classes have always been a fairly
> > artificial construct, and you can see that already in the existing
> > checks prior to this work
> 
> Ok, after loading up some secmark rules (the ones from targeted in 
> rawhide) the packets are labeled things like httpd_client_packet_t and 
> httpd_server_packet_t and so on. Here are the denials I get: (this is 
> with no associations)

Ok, with secmark rules and an association:

client side (domain is semanage_t)

allow client_packet_t self:packet flow_out;
        #TYPE=AVC  MSG=  COMM="client"   : flow_out
allow client_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="client"   : flow_out
allow isakmp_client_packet_t unlabeled_t:packet flow_out;
        #TYPE=AVC  MSG=  COMM="racoon"   : flow_out

I think these are expected from the initial request to use no
association (which then fails), right?

allow semanage_t client_packet_t:packet { flow_in flow_out };
        #TYPE=AVC  MSG=   : flow_in
        #TYPE=AVC  MSG=  COMM="client"   : flow_out

This looks good

allow semanage_t ipsec_spd_t:association polmatch;
        #TYPE=AVC  MSG=  COMM="client"   : polmatch

Also looks good

allow semanage_t self:association sendto;
        #TYPE=AVC  MSG=  COMM="client"   : sendto

Not so good, the client side SA should have the context of the server
side socket, right? (which would have been unconfined_t)

allow semanage_t self:packet recv;
        #TYPE=AVC  MSG=   : recv

This is probably the association (though you can't tell, another symptom
of object class confusion..)


Server side:

allow semanage_t ipsec_spd_t:association polmatch;
        #TYPE=AVC  MSG=   : polmatch

This is interesting, the client is running as semanage_t but the server
is running as unconfined_t. Is it expected that the client socket
context would be used in the polmatch check?

allow semanage_t server_packet_t:packet { flow_in flow_out };
        #TYPE=AVC  MSG=   : flow_in
        #TYPE=AVC  MSG=  COMM="server"   : flow_out
allow unconfined_t semanage_t:packet recv;

allow unconfined_t semanage_t:association { sendto };

All these look correct..

allow server_packet_t self:packet flow_out;

not sure...

so the server side is fairly reasonable except for the first and last
rules, not sure if those are intentional or not. So it looks like the
main outstanding issue now is the fact that the server context is not
correctly propagated to the client side.



--
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: Denials from newest kernel

[Venkat Yekkirala]

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.

Re: Denials from newest kernel

[James Morris]

On Fri, 6 Oct 2006, Steve G wrote:

> 
> >You need compat_net=1 to test what FC6 and RHEL5 will be shipping.
> 
> FC6 turned off secmark support, but RHEL5 has it on.

Is there policy to support secmark properly in RHEL5?  If not, it needs 
to be disabled.


-- 
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: Denials from newest kernel

[Joshua Brindle]

On Fri, 2006-10-06 at 15:50 -0400, James Morris wrote:
> 
> Is there policy to support secmark properly in RHEL5?  If not, it
> needs 
> to be disabled. 

refpolicy defines the secmark rules and the selinux rules so that is
fine, however there is no infrastructure to get the netfilter_contexts
into the running iptables so things explode quickly.


--
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: Denials from newest kernel

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

Re: Denials from newest kernel

[Christopher J. PeBenito]

On Fri, 2006-10-06 at 15:56 -0400, Joshua Brindle wrote:
> On Fri, 2006-10-06 at 15:50 -0400, James Morris wrote:
> > 
> > Is there policy to support secmark properly in RHEL5?  If not, it
> > needs 
> > to be disabled. 
> 
> refpolicy defines the secmark rules and the selinux rules so that is
> fine, however there is no infrastructure to get the netfilter_contexts
> into the running iptables so things explode quickly.

Not entirely accurate; anyone that has networking can send and receive
unlabeled_t packets currently.  It originally was a temporary
compatibility thing until we could figure out how to manage the labels.
But since that part hasn't been figured out, the decision was made to
turn on secmark with no labeling rules and put the unlabeled packet
perms in, but make them conditional (a boolean).  So if someone wanted
to constrain networking, they could load up the iptables labeling rules,
and disable the boolean.  The boolean has not been implemented yet, but
it should be straightforward.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

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.

RE: Denials from newest kernel

[Venkat Yekkirala]

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.

Re: Denials from newest kernel

[Paul Moore]

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.

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()?

-- 
paul moore
linux security @ hp

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

RE: Denials from newest kernel

[Venkat Yekkirala]

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.

RE: Denials from newest kernel

[Joshua Brindle]

On Fri, 2006-10-06 at 17:17 -0400, Venkat Yekkirala wrote: 
> 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.

I knew it, whether I did it or not is a whole nother story :)

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/kernel-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)

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

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

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)

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
up the first several times I tried it). Still no polmatch rules though.

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
check.. this is very confusing


(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?

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

these are basically the same as the others where the objclass/perm were
the same for different checks except there is another that I'm not sure
about: 
audit(1160330873.428:1630): avc:  granted  { flow_out } for  pid=2785 comm="racoon" scontext=system_u:object_r:client_packet_t:s0 tcontext=system_u:object_r:isakmp_client_packet_t:s0 tclass=packet

so we finally have the client trying to talk to the server racoon, on the server side I get something interesting:

audit(1160331421.382:49): avc:  denied  { flow_in } for  scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:isakmp_server_packet_t:s0 tclass=packet

And I'm not sure why, I have reboot for sure this time, and the policy
says the initial sid is no_extlabel_t: 
sid 11 -> scontext system_u:object_r:no_extlabel_t:s0

So I don't know where the unlabeled there is coming from. Once I allow
it I get a similar one on the client side: 
audit(1160332410.064:1700): avc:  denied  { flow_in } for  scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:isakmp_client_packet_t:s0 tclass=packet


switching to semanage_t on the client side

Now I get this from racoon on the server:
racoon:  denied  { 0x8 } for  scontext=root:system_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ipsec_spd_t:s0:c0.c1023 tclass=association

not sure what it is so i'll add semanage_t ipsec_spd_t:association * ;)

Ok, so after all this I get:
Received: Hello, root:system_r:semanage_t:s0-s0:c0.c1023 from root:system_r:semanage_t:s0-s0:c0.c1023

So getpeercon() on both sides is returning
root:system_r:semanage_t:s0-s0:c0.c1023 even though the server is
running as root:system_r:unconfined_t:s0-s0:c0.c1023 which still isn't
correct I don't think.


In addition to the kernel and policy above here are the modules, and the
client/server source:

http://securityblog.org/~method/labeled_networking/server.c
http://securityblog.org/~method/labeled_networking/client.c
http://securityblog.org/~method/labeled_networking/client_packet.te
http://securityblog.org/~method/labeled_networking/server_packet.te




--
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: Denials from newest kernel

[Venkat Yekkirala]

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

RE: Denials from newest kernel

[Joshua Brindle]

> From: Venkat Yekkirala [mailto:vyekkirala@TrustedCS.com] 
> 
> > 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.
> 

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
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. I'll fix up my
netfilter_contexts file and see how that affects the tests. Thanks.


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

RE: Denials from newest kernel

[Christopher J. PeBenito]

On Mon, 2006-10-09 at 19:40 -0400, Venkat Yekkirala wrote:
> > 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.

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 dontauditing, and
also it will cover up legitimate denials on client_packet_t.  Second,
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.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

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

RE: Denials from newest kernel

[Venkat Yekkirala]

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

RE: Denials from newest kernel

[Christopher J. PeBenito]

On Tue, 2006-10-10 at 10:18 -0400, Venkat Yekkirala wrote:
> > > 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

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.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

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

RE: Denials from newest kernel

[Joshua Brindle]

> From: Christopher J. PeBenito 
> 
> On Mon, 2006-10-09 at 19:40 -0400, Venkat Yekkirala wrote:
> > 
> > > 
> > > 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.
> 
> 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 dontauditing, and 
> also it will cover up legitimate denials on client_packet_t.  
> Second, 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.
> 

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.

(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? That is not how iptables is normally used, noone who
currently uses iptables is going to like it.. 


Anyway, the real issue I have is that I was under the impression that
flow_out was a permission between a packet type and an association, to
indicate that the packet type can flow out the association type. This
makes sense and is very useful, so that we can bind very specific
properties of packets to ipsec associations. 

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? 


--
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: Denials from newest kernel

[Venkat Yekkirala]

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

RE: Denials from newest kernel

[Christopher J. PeBenito]

On Tue, 2006-10-10 at 10:42 -0400, Venkat Yekkirala wrote:
> > 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.

On both of the above two points, you're making my point.  You're
applying to constraints to the chaining of iptables rules, making
secmark work differently than the remainder of netfilter.

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

You didn't respond to this, and it is an important point.

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

I don't understand, it seems as though you're saying that all network
traffic will hit a network_t flow out check, regardless of whether it is
labeled networking or non-labeled networking.  Can you illustrate with a
couple allow rule examples?

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> On Tue, 2006-10-10 at 10:42 -0400, Venkat Yekkirala wrote:
> > > 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.
>
> On both of the above two points, you're making my point.  You're
> applying to constraints to the chaining of iptables rules,

My point is that you already were applying constraints to the chaining
of iptabels rules in the current secmark paradigm, which is that the
secmark label on the last rule will prevail. Were you not?

> making
> secmark work differently than the remainder of netfilter.

I don't understand this point; can't really compare an accessory (semark)
to the mechanism it's piggybacking on (netfilter).

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

Can you give an example of a spurious denial here?

>
> You didn't respond to this, and it is an important point.
>
> > > > > (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.
>
> I don't understand, it seems as though you're saying that all network
> traffic will hit a network_t flow out check, regardless of
> whether it is
> labeled networking or non-labeled networking.

It doesn't matter whether it's labeled or non-labeled. What matters is that
anything that hasn't been subject to a security point will be subject to the
network_t check to see if it can flow out to the network.

Additionally, due to implementation constraints, the security point domains
themselves are subject to the network_t check as well, as noted above.

>  Can you
> illustrate with a
> couple allow rule examples?

The following describes the checks.

http://marc.theaimsgroup.com/?l=selinux&m=116042211115508&w=2

Example 1:

firefox_t can't directly access the network.

allow firefox_t  p_httpd_t:packet { flow_out };

allow p_httpd_t  network_t:packet { flow_out };

Example 2:

firefox_t can directly access the network.

allow firefox_t network_t:packet { flow_out };

NOTE: I deliberately used the "p" prefix in p_httpd_t
      to signify that it's a peer domain (not necessarily
      in the tcp sense, but just that firefox_t is communicating
      to a peer domain labeled p_httpd_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: Denials from newest kernel

[Karl MacMillan]

On Tue, 2006-10-10 at 14:15 -0500, Venkat Yekkirala wrote:
> > On Tue, 2006-10-10 at 10:42 -0400, Venkat Yekkirala wrote:
> > > > 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.
> >
> > On both of the above two points, you're making my point.  You're
> > applying to constraints to the chaining of iptables rules,
> 
> My point is that you already were applying constraints to the chaining
> of iptabels rules in the current secmark paradigm, which is that the
> secmark label on the last rule will prevail. Were you not?
> 

I wouldn't call making the last rule prevail a constraint in the
previous model, but yes that is how it worked.

To me - and I guess Josh and Chris - it seems natural to allow netfilter
to refine the label of a packet as it passes through the process of
evaluating the rules without imposing access checks. This is, as you
point out, because of the previous idea of secmark as a labeling only.

However, in the new paradigm it seems that there is some value to only
enforcing access checks after the processing of the mangle rules. Namely
it reduces the number of checks performed and allows the secmark rules
to be more similar - I think - to other iptables rules.

I may be misunderstanding, but essentially I am suggesting that secmark
labels the flow point through processing the mangle rules. After that
label is determined the flow checks are made against the final label for
the flow point.

What advantage do you see to make the check more often?

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: Denials from newest kernel

[Venkat Yekkirala]

> > My point is that you already were applying constraints to
> the chaining
> > of iptabels rules in the current secmark paradigm, which is that the
> > secmark label on the last rule will prevail. Were you not?
> >
>
> I wouldn't call making the last rule prevail a constraint in the
> previous model, but yes that is how it worked.
>
> To me - and I guess Josh and Chris - it seems natural to
> allow netfilter
> to refine the label of a packet as it passes through the process of
> evaluating the rules without imposing access checks. This is, as you
> point out, because of the previous idea of secmark as a labeling only.
>
> However, in the new paradigm it seems that there is some value to only
> enforcing access checks after the processing of the mangle
> rules. Namely
> it reduces the number of checks performed and allows the secmark rules
> to be more similar - I think - to other iptables rules.
>
> I may be misunderstanding, but essentially I am suggesting
> that secmark
> labels the flow point through processing the mangle rules. After that
> label is determined the flow checks are made against the
> final label for
> the flow point.

This is exactly what I had intended to do but couldn't due to
implementation constraints. James got us the one secmark field
on the skb with great difficulty, and this secmark initially
carries the label of the socket (or the security point it entered
into the system in the forwarding case) it originates from. Now
when we hit a secmark rule, there's no place to save the secmark
context for a check later AFTER all the mangle rules have been
processed for the packet. So, I have had to essentially perform the
check at the time I hit the secmark rule and again each time
I hit another applicable rule. If the check succeeds, I replace the
secmark on the packet with the secmark from the secmark (aks security point)
rule. I have to do this replacing of the secmark on the packet so that
a following connsecmark/save would use the context from the secmark
rule that it follows.

>
> What advantage do you see to make the check more often?

As described above, we are forced to make the check due to the
current implementation constraints, but I do see the advantage
of a policy that isn't arbitrary, but forces the policy writer
to aknowledge the multiple security points a packet hits by additionally
having to write allow rules allowing one security point domain
to flow out a succeeding one. A very useful and perhaps crude way
to visualize this is to think of smaller pipes entering bigger
ones, with network_t being the all-encompassing-one/the-network.

Another way to describe this is:

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.


--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Tue, 2006-10-10 at 14:15 -0500, Venkat Yekkirala wrote:
> > On Tue, 2006-10-10 at 10:42 -0400, Venkat Yekkirala wrote:
> > > > 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.
> >
> > On both of the above two points, you're making my point.  You're
> > applying to constraints to the chaining of iptables rules,
> 
> My point is that you already were applying constraints to the chaining
> of iptabels rules in the current secmark paradigm, which is that the
> secmark label on the last rule will prevail. Were you not?

Yes, but this isn't an extra constraint, its how netfilter works.  If
you have a MARK mangle rule that does --set-mark, and then later in the
chain you have a MARK mangle rule that does a --set-mark, the result is
always whatever is done by the last MARK.  Thats how the refpolicy
SECMARK labeling works right now.

What I'm describing also seems to be consistent with your docs:

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

On point b, you say the last context will be used in the check.

> > making
> > secmark work differently than the remainder of netfilter.
> 
> I don't understand this point; can't really compare an accessory (semark)
> to the mechanism it's piggybacking on (netfilter).

I'm comparing SECMARK to IPMARK or MARK, etc.

> > > > 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.
> 
> Can you give an example of a spurious denial here?

I'm going to retract this, based on the fact that it isn't spurious
based on the current implementation.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> > My point is that you already were applying constraints to 
> the chaining
> > of iptabels rules in the current secmark paradigm, which is that the
> > secmark label on the last rule will prevail. Were you not?
> 
> Yes, but this isn't an extra constraint, its how netfilter works.

More specifically, I see you were referring to the MARK module here.

>  If
> you have a MARK mangle rule that does --set-mark, and then 
> later in the
> chain you have a MARK mangle rule that does a --set-mark, the 
> result is
> always whatever is done by the last MARK.

That's the semantics of the MARK module.

>  Thats how the refpolicy
> SECMARK labeling works right now.

That's correct. This is where I have often wondered if we should
change the name to SECPOINT to signify the change in semantics.

> 
> What I'm describing also seems to be consistent with your docs:
> 
> > 1. PACKETS ENTERING SYSTEM FROM A NON-LOOPBACK DEVICE:
> > 
> >    Can a packet "carrying" external domain label x_t 
> "flow_in" thru the
> >    security point with the peer domain label p_d_t?
> > 
> > 	NOTE:
> > 	a. x_t defaults to unlabeled_t, if no external label.
> > 	b. p_d_t defaults to network_t in the absence of any applicable
> > 	   [conn]secmark rules for the packet. If there are multiple
> > 	   secmark rules applicable to a packet, the context on the LAST
> > 	   rule will apply.
> > 
> >    NO: Drop packet.
> >    YES: If no external label, let packet "carry" p_d_t.
> 
> On point b, you say the last context will be used in the check.

Only in relation to the flow_in controls. Not the flow_out.

> 
> > > making
> > > secmark work differently than the remainder of netfilter.
> > 
> > I don't understand this point; can't really compare an 
> accessory (semark)
> > to the mechanism it's piggybacking on (netfilter).
> 
> I'm comparing SECMARK to IPMARK or MARK, etc.

Again, I wonder if we should change the name to SECPOINT, especially
since we aren't in a huge rush currently.

--
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: Denials from newest kernel

[James Morris]

On Wed, 11 Oct 2006, Venkat Yekkirala wrote:

> Again, I wonder if we should change the name to SECPOINT, especially
> since we aren't in a huge rush currently.

The name won't be changed.


- 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: Denials from newest kernel

[Christopher J. PeBenito]

On Tue, 2006-10-10 at 14:56 -0500, Venkat Yekkirala wrote:
> > > My point is that you already were applying constraints to
> > the chaining
> > > of iptabels rules in the current secmark paradigm, which is that the
> > > secmark label on the last rule will prevail. Were you not?
> > >
> >
> > I wouldn't call making the last rule prevail a constraint in the
> > previous model, but yes that is how it worked.
> >
> > To me - and I guess Josh and Chris - it seems natural to
> > allow netfilter
> > to refine the label of a packet as it passes through the process of
> > evaluating the rules without imposing access checks. This is, as you
> > point out, because of the previous idea of secmark as a labeling only.
> >
> > However, in the new paradigm it seems that there is some value to only
> > enforcing access checks after the processing of the mangle
> > rules. Namely
> > it reduces the number of checks performed and allows the secmark rules
> > to be more similar - I think - to other iptables rules.
> >
> > I may be misunderstanding, but essentially I am suggesting
> > that secmark
> > labels the flow point through processing the mangle rules. After that
> > label is determined the flow checks are made against the
> > final label for
> > the flow point.
> 
> This is exactly what I had intended to do but couldn't due to
> implementation constraints. James got us the one secmark field
> on the skb with great difficulty, and this secmark initially
> carries the label of the socket (or the security point it entered
> into the system in the forwarding case) it originates from. Now
> when we hit a secmark rule, there's no place to save the secmark
> context for a check later AFTER all the mangle rules have been
> processed for the packet. So, I have had to essentially perform the
> check at the time I hit the secmark rule and again each time
> I hit another applicable rule. If the check succeeds, I replace the
> secmark on the packet with the secmark from the secmark (aks security point)
> rule. I have to do this replacing of the secmark on the packet so that
> a following connsecmark/save would use the context from the secmark
> rule that it follows.
> 
> >
> > What advantage do you see to make the check more often?
> 
> As described above, we are forced to make the check due to the
> current implementation constraints, but I do see the advantage
> of a policy that isn't arbitrary, but forces the policy writer
> to aknowledge the multiple security points a packet hits by additionally
> having to write allow rules allowing one security point domain
> to flow out a succeeding one. A very useful and perhaps crude way
> to visualize this is to think of smaller pipes entering bigger
> ones, with network_t being the all-encompassing-one/the-network.
> 
> Another way to describe this is:
> 
> 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.

I read this email several times, and as a policy writer I repeatedly
came up with this question: what security goals can I express with the
multiple "security points" going though the mangle table?  I thought
about this for a couple hours and could not come up with an answer.

I believe that for each direction, the mangle table represents _one
labeling decision_.  Its just like the file_contexts: multiple lines may
match and the last one wins.  Do we have access checks for each line
matched in the file_contexts?  No.  The access check is performed after
all of the file context entries have been tested when the file is
relabeled.  The intermediate labels are irrelevant; if they were
relevant, setfiles would relabel the file for each matching line in
file_contexts.  In the same line of logic, the intermediate labels in
the mangle table are irrelevant.

The arguments for the current implementation (which is not an
implementation of the agreed design) is implementation constraints.
This tells me that if we can't implement our design then we need to make
a new design.  I realize thats an inflammatory remark, but I don't think
we're far off.  I don't have any problem with label reconciliations or
any of the previously contentious parts, only the access control checks.

So what do I think are the pieces needed to express labeled networking
security goals?

Using a send as an example, and having the assumption that the
association has the label of the domain on the other end:

1. can the domain write to the socket?

2. can the socket send this packet in the basic networking sense
(ip address, port, protocol, etc)?

3. can the domain(socket?) match a particular spd entry?

4. can the domain send to the ipsec association?

5. can the packet flow into the ipsec association?

I don't see how the multiple checks nor all traffic eventually flowing
into network_t addresses anything in the above.  My understanding of the
agreed design succeeded in meeting these goals.  Coincidentally, the
mainline kernel already does #1-4 for the non labeled networking case.
The last one seems like a nice check, since you can say "only
httpd_client_packet_t and httpd_server_packet_t" can go into a apache_t
association; however, its debatable as to whether or not its strictly
required, if it came down it.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> I read this email several times, and as a policy writer I repeatedly
> came up with this question: what security goals can I express with the
> multiple "security points" going though the mangle table?

First of all, any time you have an indirection such as this available,
that could serve to simplify policy and/or make it flexible. You could
for example have the "initial" netfilter contexts specified based on a
generic set of attributes (without taking the interface into account for
example), and then have a later rule specify a secpoint on the interface.
This can currently only be leveraged for the outbound however, since no
such indirection is currently available for the inbound.

As for what security goals can be expressed: the questions I would ask are
the following:

What security goals can I NOT express in the new paradigm that I can
in the existing paradigm?

Answer: 0

What security goals can I express in the new paradigm that I can NOT
in the existing paradigm?

Answer: Flow controlling on forwarded traffic, localhost traffic labeling.

>  I thought
> about this for a couple hours and could not come up with an answer.
> 
> I believe that for each direction, the mangle table represents _one
> labeling decision_.  Its just like the file_contexts: 
> multiple lines may
> match and the last one wins.  Do we have access checks for each line
> matched in the file_contexts?  No.  The access check is 
> performed after
> all of the file context entries have been tested when the file is
> relabeled.  The intermediate labels are irrelevant; if they were
> relevant, setfiles would relabel the file for each matching line in
> file_contexts.  In the same line of logic, the intermediate labels in
> the mangle table are irrelevant.

There is no denying they *should* have been irrelevant, but here we do
NOT have a choice (at least that I can think of).

> 
> The arguments for the current implementation (which is not an
> implementation of the agreed design)

but very close to the agreed design, with the "fallout" from the
implementation constraints to be "manageable" in the policy.

> is implementation constraints.
> This tells me that if we can't implement our design then we 
> need to make
> a new design.

Before talking about a new design the question to be answered is
whether the fallout from the digression can be managed in the
policy or not.

>  I realize thats an inflammatory remark, but I 
> don't think
> we're far off.  I don't have any problem with label reconciliations or
> any of the previously contentious parts, only the access 
> control checks.

which should be manageable in the policy.

> 
> So what do I think are the pieces needed to express labeled networking
> security goals?
> 
> Using a send as an example, and having the assumption that the
> association has the label of the domain on the other end:
> 
> 1. can the domain write to the socket?
> 
> 2. can the socket send this packet in the basic networking sense
> (ip address, port, protocol, etc)?
> 
> 3. can the domain(socket?) match a particular spd entry?
> 
> 4. can the domain send to the ipsec association?

This is now implicit by making sure the domain context matches
exactly with the SA context.

> 
> 5. can the packet flow into the ipsec association?

This is actually the same question as "4" above. What's the difference?

> 
> I don't see how the multiple checks nor all traffic eventually flowing
> into network_t addresses anything in the above.

The thing to really see is how these come in the way of accomplishing
any of the above goals.

>  My 
> understanding of the
> agreed design succeeded in meeting these goals.

As does, I would contend, the implementation. It's just that policy
needs to be laid out taking the constraints into account.

>  Coincidentally, the
> mainline kernel already does #1-4 for the non labeled networking case.

But lacking in the features provided by the new controls.

> The last one seems like a nice check, since you can say "only
> httpd_client_packet_t and httpd_server_packet_t" can go into 
> a apache_t
> association; however, its debatable as to whether or not its strictly
> required, if it came down it.

Like I mentioned yesterday, there's no IPSec stuff involved at the
netfilter level. A packet can only use a labeled IPSec association (SA)
iff the domain on the packet EXACTLY matches the domain on the SA
as signified by the constraint in the policy patch I posted a week or so
back.

--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Thu, 2006-10-12 at 15:06 -0500, Venkat Yekkirala wrote:
> What security goals can I express in the new paradigm that I can NOT
> in the existing paradigm?
> 
> Answer: Flow controlling on forwarded traffic, localhost traffic labeling.

Now that you mention the forwarded traffic, I can see this being useful
in the context of making decision in a network router, so I'll concede
the point on multiple checks.  Though I'm curious why localhost traffic
labeling would be tied to the multiple checks.

> > 4. can the domain send to the ipsec association?
> > 
> > 5. can the packet flow into the ipsec association?
> 
> This is actually the same question as "4" above. What's the difference?

This is like a filesystem associate check.  As an example, we have
mozilla_t communicating with httpd_t.  Mozilla_t needs to send
dns_client_packet_t for doing DNS lookups, and httpd_client_packet_t is
obvious.  Mozilla_t needs to send/recv to the httpd_t association.
Without 5, we can't restrict the association traffic to just
http_client_packet_t, so mozilla_t can't be denied sending/receiving
dns_client_packets_t over the httpd_t association.

> Like I mentioned yesterday, there's no IPSec stuff involved at the
> netfilter level. A packet can only use a labeled IPSec association (SA)
> iff the domain on the packet EXACTLY matches the domain on the SA
> as signified by the constraint in the policy patch I posted a week or so
> back.

I'm glad you mentioned this constraint, because I forgot about it.  I
hadn't planned on adding it to the policy.  In light of setsockcreate
and a SELinux aware inetd in the future (having the sockets be the type
of their child processes), this constraint makes less sense.  I also
find it objectionable to have the code depend on a policy when there is
no guarantee that the constraint will be there.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> > > 4. can the domain send to the ipsec association?
> > >
> > > 5. can the packet flow into the ipsec association?
> >
> > This is actually the same question as "4" above. What's the
> difference?
>
> This is like a filesystem associate check.  As an example, we have
> mozilla_t communicating with httpd_t.

Yes. This we represent by something similar to:

-A selinux_new_output -p tcp --dport 80 -j SECMARK --selctx p_httpd_t

allow mozilla_t p_httpd_t:packet { flow_out };

>  Mozilla_t needs to send
> dns_client_packet_t for doing DNS lookups, and

First of all, all packets from mozilla are mozilla_t packets.

In the new paradigm, mozilla_t needing to send "through to" DNS is
represented as:

-A selinux_new_output --dport 53 -j SECMARK --selctx p_dnsd_t

allow mozilla_t p_dnsd_t:packet { flow_out };

So in the new paradigm, we look at the security points as representing
corresponding "peers" (not in the tcp sense, just in the general
communication
sense) running on remote machines.

> httpd_client_packet_t is
> obvious.  Mozilla_t needs to send/recv to the httpd_t association.

No. mozilla_t "sends using/to" an association with the context mozilla_t.
mozilla_t "receives from" an association with the context httpd_t.

> Without 5, we can't restrict the association traffic to just
> http_client_packet_t, so mozilla_t can't be denied sending/receiving
> dns_client_packets_t over the httpd_t association.

You can restrict it, but by way of the policy in the SPD, where you
can use selectors such as ipaddr, port, protocol, etc. (see setkey(8)).

The "security points" have nothing to do with ipsec associations.

>
> > Like I mentioned yesterday, there's no IPSec stuff involved at the
> > netfilter level. A packet can only use a labeled IPSec association
> (SA)
> > iff the domain on the packet EXACTLY matches the domain on the SA
> > as signified by the constraint in the policy patch I posted
> a week or
> so
> > back.
>
> I'm glad you mentioned this constraint, because I forgot about it.  I
> hadn't planned on adding it to the policy.  In light of setsockcreate
> and a SELinux aware inetd in the future (having the sockets
> be the type
> of their child processes), this constraint makes less sense.

Can you please elaborate on this?

In the case where you have a socket created at a different context
than the process, you would still want the SA used to be
the one that corresponds to the socket context. Wouldn't you?

>  I also
> find it objectionable to have the code
> depend on a policy
> when there is
> no guarantee that the constraint will be there.

With a couple of minor adjustments to the code I should be able to
delink it from the dependence on the policy, but the semantics would
obviously change as follows:

1. The peercon seen on the remote machine would be the SA context
   which may not necessarily be the same as the true peer context as
   represented by the socket.
2. Multiple socket contexts could potentially be sharing the same SA
   as allowed by policy.

Now one might in fact find some use cases for the above.

Alternatively, we could hardcode the check in the kernel, but with
some potential performance implications.

Stephen, am I able to mitigate the performance implications by doing
something like the below:

if (sock_sid == SA_sid)
	use_SA;
else if (sock_sid < SECINITSID_NUM || SA_sid < SECINITSID_NUM)
	retrieve_contexts_and_compare_with_some_performance_penalty;


--
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: Denials from newest kernel

[Paul Moore]

> What security goals can I express in the new paradigm that I can NOT
> in the existing paradigm?
> 
> Answer: Flow controlling on forwarded traffic, localhost traffic labeling.

This is something I have been thinking about a lot lately, even before Venkat
reponded with the above answer.  More specifically I've been thinking about how
we can accomplish those two security goals without causing as much disruption as
the secid patches have seem to have caused.  The goal of combining all the
different packet labeling mechanisms into the secmark field is a noble one, but
I think we just loose too much in the process and I don't think we gain enough
to make it worthwhile.

At the risk of being dragged out into the street and shot for suggesting
something new at this stage I would like to offer up this rough idea for
comments, it's not really a big change from the current secid patches but I
think it should help address a lot of the problems that I have seen on the list:

1. The skb->secmark field should only be used for local/netfilter packet
labeling, neither labeled IPsec or NetLabel should ever change it's value.

2. Add a selinux_skb_flow_in() similar to what is done with the current secid
patches but do not change the skb->secmark value (see #1 above) and for each
external packet label do a permission check similar to the following:

 avc_has_perm(extlbl_sid, skb->secmark, "packet", "flow_in");

We could always swap SECINITSID_NETMSG in for the secmark is it was not set
similar to what the secid patches do now.  If there are no external packet
labels then there would be a simple "unlabeled" check similar to the following:

 avc_has_perm(SECINITSID_UNLABELED, skb->secmark, "packet", "flow_in");

3. In selinuc_socket_sock_rcv_skb() we would have the usual secmark check and if
external labeling is in use a check similar to the following:

 avc_has_perm(extlbl_sid, sock_sid, sock_class, "recvfrom");

4. Add a selinux_skb_flow_out() similar to what is done with the current secid
patches but do not change the skb->secmark value (see #1 above) and if the
packet is associated with a socket, i.e. skb->sk != NULL, do a permission check
similar to the following:

 avc_has_perm(skb->sk->sk_security->sid, nf_secid, "packet", "flow_out");

In addition, if there is an external label we would do a permission similar to
the following:

 avc_has_perm(extlbl_sid, nf_secid, "packet", "flow_out");

The suggestions should address all of the packet flow control issues in what I
think is a reasonable manner.  However, they don't address the localhost
labeling issue, but honestly I think this is a completely separate issue which
we shouldn't let clutter up the packet flow issues.  NetLabel works just fine
over localhost and according to Venkat's email earlier this week it looks like
labeled IPsec could work over localhost as well, we just need to do some testing.

-- 
paul moore
linux security @ hp

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

RE: Denials from newest kernel

[Venkat Yekkirala]

> > What security goals can I express in the new paradigm that I can NOT
> > in the existing paradigm?
> > 
> > Answer: Flow controlling on forwarded traffic, localhost 
> traffic labeling.
> 
> This is something I have been thinking about a lot lately, 
> even before Venkat
> reponded with the above answer.  More specifically I've been 
> thinking about how
> we can accomplish those two security goals without causing as 
> much disruption as
> the secid patches have seem to have caused.  The goal of 
> combining all the
> different packet labeling mechanisms into the secmark field 
> is a noble one, but
> I think we just loose too much in the process

Can you specify what we are exactly loosing, if any, in the process?

> and I don't 
> think we gain enough
> to make it worthwhile.
> 
> At the risk of being dragged out into the street and shot for 
> suggesting
> something new at this stage

Don't bother about the stage we are at. This is open development, so one
should always feel free to come up with new ideas.

BTW, do I have your address correctly as: Carly Ave, Fiorina, CA 12345? :)
(Disclaimer: the above purely a joke)

> I would like to offer up this 
> rough idea for
> comments, it's not really a big change from the current secid 
> patches but I
> think it should help address a lot of the problems

Again I would very much like to see the particular problems
on the list that you are addressing here.

> that I 
> have seen on the list:
> 
> 1. The skb->secmark field should only be used for 
> local/netfilter packet
> labeling, neither labeled IPsec or NetLabel should ever 
> change it's value.

What specifically would we gain with NOT replacing the secmark?

Alternatively, what problems are we warding off here by NOT
replacing the secmark?

> 
> 2. Add a selinux_skb_flow_in() similar to what is done with 
> the current secid
> patches but do not change the skb->secmark value (see #1 
> above) and for each
> external packet label do a permission check similar to the following:
> 
>  avc_has_perm(extlbl_sid, skb->secmark, "packet", "flow_in");

Why repeat the check for "each" external label? The current proposal
(courtesy Paul Moore :)) determines ONE external label with NetLabel
overriding ipsec and performs the check once. We have already determined
that multiple external labels are redundant.

> 
> We could always swap SECINITSID_NETMSG in for the secmark is 
> it was not set
> similar to what the secid patches do now.  If there are no 
> external packet
> labels then there would be a simple "unlabeled" check similar 
> to the following:
> 
>  avc_has_perm(SECINITSID_UNLABELED, skb->secmark, "packet", 
> "flow_in");
> 
> 3. In selinuc_socket_sock_rcv_skb() we would have the usual 
> secmark check and if
> external labeling is in use a check similar to the following:
> 
>  avc_has_perm(extlbl_sid, sock_sid, sock_class, "recvfrom");

Again, more access checks (because you don't replace the secmark)
and so more policy.

> 
> 4. Add a selinux_skb_flow_out() similar to what is done with 
> the current secid
> patches but do not change the skb->secmark value (see #1 
> above) and if the
> packet is associated with a socket, i.e. skb->sk != NULL, do 
> a permission check
> similar to the following:
> 
>  avc_has_perm(skb->sk->sk_security->sid, nf_secid, "packet", 
> "flow_out");

This won't work in the corner cases such as icmp, timewait acks
and such where the sock coming with the skb is a proxy sock (not
a real one).

Also, I don't see the check for forwarded packets (on the way out)
here; did you mean to include it here like it happens in the secid
patches?

> 
> In addition, if there is an external label we would do a 
> permission similar to
> the following:
> 
>  avc_has_perm(extlbl_sid, nf_secid, "packet", "flow_out");

Why the additional check? If you leverage secmark like the secid
patches do, you would end up with one check instead of two.

> 
> The suggestions should address all of the packet flow control 
> issues in what I
> think is a reasonable manner.  However, they don't address 
> the localhost
> labeling issue,

They would, effortlessly, if you just let things go with the flow
with secmark. i.e., leverage secmark by letting it carry the
appropriate/socket label on the outbound.

> but honestly I think this is a completely 
> separate issue which
> we shouldn't let clutter up the packet flow issues.  NetLabel 
> works just fine
> over localhost and according to Venkat's email earlier this 
> week it looks like
> labeled IPsec could work over localhost as well, we just need 
> to do some testing.

All in all, the only significant thing I notice is that you don't
replace secmark. And I wonder why? What problems/issues does it ward off?

--
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: Denials from newest kernel

[James Morris]

On Fri, 13 Oct 2006, Paul Moore wrote:

> 1. The skb->secmark field should only be used for local/netfilter packet
> labeling, neither labeled IPsec or NetLabel should ever change it's value.

Yep, this may be the best way forward.  They really are different types of 
labeling.  I previously mentioned a way to _internally_ have the secmark 
field carry multiple distinct labels (assign half to external labeling 
and half to internal, and transparently perform mapping so that userland 
tools always deal with the internal label only).  Perhaps this needs to be 
part of the solution.


-- 
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: Denials from newest kernel

[Paul Moore]

On Friday 13 October 2006 9:00 pm, Venkat Yekkirala wrote:
> > > What security goals can I express in the new paradigm that I can NOT
> > > in the existing paradigm?
> > >
> > > Answer: Flow controlling on forwarded traffic, localhost
> >
> > traffic labeling.
> >
> > This is something I have been thinking about a lot lately,
> > even before Venkat
> > reponded with the above answer.  More specifically I've been
> > thinking about how
> > we can accomplish those two security goals without causing as
> > much disruption as
> > the secid patches have seem to have caused.  The goal of
> > combining all the
> > different packet labeling mechanisms into the secmark field
> > is a noble one, but
> > I think we just loose too much in the process
>
> Can you specify what we are exactly loosing, if any, in the process?

In one work, "understandability" (yeah, I just made that word up but I think 
you get the idea).  From my point of view the number one problem with the 
current secid work is that is is very difficult for people to understand and 
use.  You've documented it, discussed it on the mailing lists for weeks now 
and still people can't quite come to grips with how it is all supposed to 
work.  Sadly I know some people have just given up on the whole discussion.

I think if we ever want to make labeled networking usable for real people it 
needs to be much easier to understand and use than it is with the current 
secid patches.

> > I would like to offer up this
> > rough idea for
> > comments, it's not really a big change from the current secid
> > patches but I
> > think it should help address a lot of the problems
>
> Again I would very much like to see the particular problems
> on the list that you are addressing here.

See my comments above, and the mailing lists for the past several weeks.

> > that I
> > have seen on the list:
> >
> > 1. The skb->secmark field should only be used for
> > local/netfilter packet
> > labeling, neither labeled IPsec or NetLabel should ever
> > change it's value.
>
> What specifically would we gain with NOT replacing the secmark?

Consistency: secmark would always be the local label no matter what.

> Alternatively, what problems are we warding off here by NOT
> replacing the secmark?

Confusion by overloading the secmark value.

> > 2. Add a selinux_skb_flow_in() similar to what is done with
> > the current secid
> > patches but do not change the skb->secmark value (see #1
> > above) and for each
> > external packet label do a permission check similar to the following:
> >
> >  avc_has_perm(extlbl_sid, skb->secmark, "packet", "flow_in");
>
> Why repeat the check for "each" external label? The current proposal
> (courtesy Paul Moore :)) determines ONE external label with NetLabel
> overriding ipsec and performs the check once. We have already determined
> that multiple external labels are redundant.

Okay so we consolidate/reconcile the external label like we do now.

> > 3. In selinuc_socket_sock_rcv_skb() we would have the usual
> > secmark check and if
> > external labeling is in use a check similar to the following:
> >
> >  avc_has_perm(extlbl_sid, sock_sid, sock_class, "recvfrom");
>
> Again, more access checks (because you don't replace the secmark)
> and so more policy.

Perhaps, but I think it's policy that is easier to understand, write, and live 
with.

> > 4. Add a selinux_skb_flow_out() similar to what is done with
> > the current secid
> > patches but do not change the skb->secmark value (see #1
> > above) and if the
> > packet is associated with a socket, i.e. skb->sk != NULL, do
> > a permission check
> > similar to the following:
> >
> >  avc_has_perm(skb->sk->sk_security->sid, nf_secid, "packet",
> > "flow_out");
>
> This won't work in the corner cases such as icmp, timewait acks
> and such where the sock coming with the skb is a proxy sock (not
> a real one).

In the case where there is not a valid socket SID we just use the unlabeled 
SID.  If the socket has the kernel's SID we can use that or substitute the 
unlabeled SID.  I guess I don't consider this too much of a problem as those 
particular packets don't really carry any user generated data so data flow 
issue aren't really applicable here.  Regardless, using the unlabeled SID or 
the kernel SID better reflects the true nature of the packet's contents.

> Also, I don't see the check for forwarded packets (on the way out)
> here; did you mean to include it here like it happens in the secid
> patches?

Yes, my mistake; the existing secid code for the flow_out() and 
postroute_last() functions are so similar I often only speak about one of 
them.

> > In addition, if there is an external label we would do a
> > permission similar to
> > the following:
> >
> >  avc_has_perm(extlbl_sid, nf_secid, "packet", "flow_out");
>
> Why the additional check? If you leverage secmark like the secid
> patches do, you would end up with one check instead of two.

See all the comments above about the policy being hard to understand when the 
secmark value is overridden.

> > The suggestions should address all of the packet flow control
> > issues in what I
> > think is a reasonable manner.  However, they don't address
> > the localhost
> > labeling issue,
>
> They would, effortlessly, if you just let things go with the flow
> with secmark. i.e., leverage secmark by letting it carry the
> appropriate/socket label on the outbound.

While I agree it is tempting it would mean we would be overloading the secmark 
value which I don't think we should do (see point #1 in my original mail).  
It also has the nasty tendency of using localhost as a special case for 
labeled networking which could cause some unintended behavior.

> > but honestly I think this is a completely
> > separate issue which
> > we shouldn't let clutter up the packet flow issues.  NetLabel
> > works just fine
> > over localhost and according to Venkat's email earlier this
> > week it looks like
> > labeled IPsec could work over localhost as well, we just need
> > to do some testing.
>
> All in all, the only significant thing I notice is that you don't
> replace secmark.

That was the point I was trying to make; I think we can still achieve our 
packet flow control goals without reconciling all of the secids.  In fact I 
think we can do it in a way that is easier to understand if we *don't* 
reconcile the secids.

-- 
paul moore
linux security @ hp

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

Re: Denials from newest kernel

[Paul Moore]

On Saturday 14 October 2006 3:36 am, James Morris wrote:
> On Fri, 13 Oct 2006, Paul Moore wrote:
> > 1. The skb->secmark field should only be used for local/netfilter packet
> > labeling, neither labeled IPsec or NetLabel should ever change it's
> > value.
>
> Yep, this may be the best way forward.  They really are different types of
> labeling.  I previously mentioned a way to _internally_ have the secmark
> field carry multiple distinct labels (assign half to external labeling
> and half to internal, and transparently perform mapping so that userland
> tools always deal with the internal label only).  Perhaps this needs to be
> part of the solution.

If we had more bits in the secmark field I would agree with you (and maybe 
this is the way the community wants to go, time will tell) but I tend to 
think that 32 bits may already be a constraint at some point in the future so 
I'm hesitant to further restrict ourselves.

I think one thing to remember is that all of the external labeling mechanisms 
in use right now already have a way to carry a SID for the life of the 
sk_buff, it may just not be stored in the sk_buff struct itself.

-- 
paul moore
linux security @ hp

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

RE: Denials from newest kernel

[Venkat Yekkirala]

> > Can you specify what we are exactly loosing, if any, in the process?
>
> In one work, "understandability"

First of all, the "understandability" problem we have been having has
to do with the following:

1. Naming: we just refuse to change the naming for some inexplicable reason.

2. People not reading/studying examples and documentation posted.
Specifically
   the following.
	http://marc.theaimsgroup.com/?l=selinux&m=116039675620555&w=2
	http://marc.theaimsgroup.com/?l=selinux&m=115928609916717&w=2

So, no point in messing with the design when the problem is with the
naming and people's inertia/confusion with latching onto new paradigms
particularly
when a paradigm replaces an existing one (secmark as a way to mark packets
Vs.
secpoint as a way to specify fine grained security check points) while the
naming has stayed the same (secmark).

> (yeah, I just made that word
> up but I think
> you get the idea).  From my point of view the number one
> problem with the
> current secid work is that is is very difficult for people to
> understand and
> use.  You've documented it, discussed it on the mailing lists
> for weeks now
> and still people can't quite come to grips with how it is all
> supposed to
> work.

See above.

>  Sadly I know some people have just given up on the
> whole discussion.

Not that I am aware of. All the primary stake holders are either already
on board or close to being so.

>
> I think if we ever want to make labeled networking usable for
> real people it
> needs to be much easier to understand and use than it is with
> the current
> secid patches.

And the key to it is to make the naming more intuitive and getting
people to pay attention to documentation.

>
> > > I would like to offer up this
> > > rough idea for
> > > comments, it's not really a big change from the current secid
> > > patches but I
> > > think it should help address a lot of the problems
> >
> > Again I would very much like to see the particular problems
> > on the list that you are addressing here.
>
> See my comments above, and the mailing lists for the past
> several weeks.
>
> > > that I
> > > have seen on the list:
> > >
> > > 1. The skb->secmark field should only be used for
> > > local/netfilter packet
> > > labeling, neither labeled IPsec or NetLabel should ever
> > > change it's value.
> >
> > What specifically would we gain with NOT replacing the secmark?
>
> Consistency: secmark would always be the local label no matter what.
>
> > Alternatively, what problems are we warding off here by NOT
> > replacing the secmark?
>
> Confusion by overloading the secmark value.

This is the least of the confusions we have ever faced with this.
People now understand that there's only one label a packet carries
and that's the external domain if there's one or in it's absence,
the default domain it acquires at the entry point. Very intuitive
and straightforward. No policy having to account for multiple access
checks on the same packet.

>
> > > 2. Add a selinux_skb_flow_in() similar to what is done with
> > > the current secid
> > > patches but do not change the skb->secmark value (see #1
> > > above) and for each
> > > external packet label do a permission check similar to
> the following:
> > >
> > >  avc_has_perm(extlbl_sid, skb->secmark, "packet", "flow_in");
> >
> > Why repeat the check for "each" external label? The current proposal
> > (courtesy Paul Moore :)) determines ONE external label with NetLabel
> > overriding ipsec and performs the check once. We have
> already determined
> > that multiple external labels are redundant.
>
> Okay so we consolidate/reconcile the external label like we do now.
>
> > > 3. In selinuc_socket_sock_rcv_skb() we would have the usual
> > > secmark check and if
> > > external labeling is in use a check similar to the following:
> > >
> > >  avc_has_perm(extlbl_sid, sock_sid, sock_class, "recvfrom");
> >
> > Again, more access checks (because you don't replace the secmark)
> > and so more policy.
>
> Perhaps, but I think it's policy that is easier to
> understand, write, and live
> with.

But totally unnecessary considering the intuitive and straightforward way
a packet comes to carry one domain.

>
> > > 4. Add a selinux_skb_flow_out() similar to what is done with
> > > the current secid
> > > patches but do not change the skb->secmark value (see #1
> > > above) and if the
> > > packet is associated with a socket, i.e. skb->sk != NULL, do
> > > a permission check
> > > similar to the following:
> > >
> > >  avc_has_perm(skb->sk->sk_security->sid, nf_secid, "packet",
> > > "flow_out");
> >
> > This won't work in the corner cases such as icmp, timewait acks
> > and such where the sock coming with the skb is a proxy sock (not
> > a real one).
>
> In the case where there is not a valid socket SID we just use
> the unlabeled
> SID.

Won't work for MLS in the least and would be objectionable/dangerous for
even
a strict policy to be needing to let unlabeled stuff out.

>  If the socket has the kernel's SID we can use that or
> substitute the
> unlabeled SID.  I guess I don't consider this too much of a
> problem as those
> particular packets don't really carry any user generated data

Not necessarily. Look at IGMP.

> so data flow
> issue aren't really applicable here.  Regardless, using the
> unlabeled SID or
> the kernel SID better reflects the true nature of the
> packet's contents.

Not at all. icmp, timewaitack and such technically carry/indicate
data at a particular lavel.

Besides, this whole socket thing is a mute discussion since secmark on
the outbound is anyway available for us to use before we hit netfilter.

>
> > Also, I don't see the check for forwarded packets (on the way out)
> > here; did you mean to include it here like it happens in the secid
> > patches?
>
> Yes, my mistake; the existing secid code for the flow_out() and
> postroute_last() functions are so similar I often only speak
> about one of
> them.
>
> > > In addition, if there is an external label we would do a
> > > permission similar to
> > > the following:
> > >
> > >  avc_has_perm(extlbl_sid, nf_secid, "packet", "flow_out");
> >
> > Why the additional check? If you leverage secmark like the secid
> > patches do, you would end up with one check instead of two.
>
> See all the comments above about the policy being hard to
> understand when the
> secmark value is overridden.

See all the comments above about how intuitive and straightforward is
the way we get to havce a single domain on a packet.

>
> > > The suggestions should address all of the packet flow control
> > > issues in what I
> > > think is a reasonable manner.  However, they don't address
> > > the localhost
> > > labeling issue,
> >
> > They would, effortlessly, if you just let things go with the flow
> > with secmark. i.e., leverage secmark by letting it carry the
> > appropriate/socket label on the outbound.
>
> While I agree it is tempting it would mean we would be
> overloading the secmark
> value which I don't think we should do

It's not overloading since there isn't any undue change in semantics
at the user level. Hence we call it "leveraging".

> (see point #1 in my
> original mail).
> It also has the nasty tendency of using localhost as a
> special case for
> labeled networking which could cause some unintended behavior.
>
> > > but honestly I think this is a completely
> > > separate issue which
> > > we shouldn't let clutter up the packet flow issues.  NetLabel
> > > works just fine
> > > over localhost and according to Venkat's email earlier this
> > > week it looks like
> > > labeled IPsec could work over localhost as well, we just need
> > > to do some testing.
> >
> > All in all, the only significant thing I notice is that you don't
> > replace secmark.
>
> That was the point I was trying to make; I think we can still
> achieve our
> packet flow control goals without reconciling all of the
> secids.

The reconciliation specific issue had long past been beaten on, with
resulting
refinements already incorporated into the design (such as a. no
reconciliation
between xfrm and NetLabel since they are redundant, b. no transitions,
etc.).
No need to resurrect a dead issue and create further confusion in people's
minds.

>  In fact I
> think we can do it in a way that is easier to understand if
> we *don't*
> reconcile the secids.

The way I see it: loss of significant functionality, and need for additional
policy for no real gain in understandability.

My goal here has been to provide a "comprehensive" yet easy to undestand
set of controls that will satisfy our network security goals for the
forseeable
future.
(Yes, I seem to have acquired a little bit of the marketing buzz from you:)


--
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: Denials from newest kernel

[Venkat Yekkirala]

> Yep, this may be the best way forward.

Not really so. Please see my response to Paul.

The best step forward really would be to let naming catchup
with the semantics.

I have the following specific proposals in this regard:

1. Use "secpoint" or a close relative for the module name.
   I know you won't have none of it. Is it because there's
   another LSM that might use it with the original semantics?
   If so, should we then have a new "secpoint" module? I ask
   because Chris PeBenito was the latest victim of the confusion
   arising from here.

2. Leave the "packet" class with the recv perm, but place the
   "relabelto", "flow_in" and "flow_out" perms in a new secpoint class.

--
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: Denials from newest kernel

[Paul Moore]

On Saturday 14 October 2006 3:50 pm, Venkat Yekkirala wrote:
> > > Can you specify what we are exactly loosing, if any, in the process?
> >
> > In one work, "understandability"
>
> First of all, the "understandability" problem we have been having has
> to do with the following:
>
> 1. Naming: we just refuse to change the naming for some inexplicable
> reason.

I'm sure James has his own opinions on this, but from my point of view there 
is just no point to it - it's a cosmetic issue.  If the name of a mechanism 
was truly the only problem it could be dealt with through documentation and 
education.

However, I think the real problem is that the secid reconciliation patches are 
a fundamental change in how the secmark field is used.  Other developers, 
policy writers, and users are going to expect it to behave a certain way - 
the way it was originally introduced - and any changes should be compatible 
with that original usage.

> 2. People not reading/studying examples and documentation posted.
> Specifically
>    the following.
> 	http://marc.theaimsgroup.com/?l=selinux&m=116039675620555&w=2
> 	http://marc.theaimsgroup.com/?l=selinux&m=115928609916717&w=2
>
> So, no point in messing with the design when the problem is with the
> naming and people's inertia/confusion with latching onto new paradigms
> particularly
> when a paradigm replaces an existing one (secmark as a way to mark packets
> Vs.
> secpoint as a way to specify fine grained security check points) while the
> naming has stayed the same (secmark).

Yes, yes, yes, that's all well and good - documentation is good, very good in 
fact, but the problem is the policy writers still seem to be having a 
difficult time doing anything useful with the secid changes and I just not 
certain there is going to be any real resolution at this point with the 
current approach.

> >  Sadly I know some people have just given up on the
> > whole discussion.
>
> Not that I am aware of. All the primary stake holders are either already
> on board or close to being so.

Okay - ask yourself this question: have any of the people working on the 
reference policy actually give an explicit "Yes, I like this approach" or did 
they simply stop responding?

> > > > 3. In selinuc_socket_sock_rcv_skb() we would have the usual
> > > > secmark check and if
> > > > external labeling is in use a check similar to the following:
> > > >
> > > >  avc_has_perm(extlbl_sid, sock_sid, sock_class, "recvfrom");
> > >
> > > Again, more access checks (because you don't replace the secmark)
> > > and so more policy.
> >
> > Perhaps, but I think it's policy that is easier to
> > understand, write, and live
> > with.
>
> But totally unnecessary considering the intuitive and straightforward way
> a packet comes to carry one domain.

If it really was as intuitive as you say why would Chris, Josh, and the other 
being have such a hard time with this?  Don't say it's because it's 
called "secmark" ...

> > > > 4. Add a selinux_skb_flow_out() similar to what is done with
> > > > the current secid
> > > > patches but do not change the skb->secmark value (see #1
> > > > above) and if the
> > > > packet is associated with a socket, i.e. skb->sk != NULL, do
> > > > a permission check
> > > > similar to the following:
> > > >
> > > >  avc_has_perm(skb->sk->sk_security->sid, nf_secid, "packet",
> > > > "flow_out");
> > >
> > > This won't work in the corner cases such as icmp, timewait acks
> > > and such where the sock coming with the skb is a proxy sock (not
> > > a real one).
> >
> > In the case where there is not a valid socket SID we just use
> > the unlabeled
> > SID.
>
> Won't work for MLS in the least and would be objectionable/dangerous for
> even
> a strict policy to be needing to let unlabeled stuff out.
>
> >  If the socket has the kernel's SID we can use that or
> > substitute the
> > unlabeled SID.  I guess I don't consider this too much of a
> > problem as those
> > particular packets don't really carry any user generated data
>
> Not necessarily. Look at IGMP.
>
> > so data flow
> > issue aren't really applicable here.  Regardless, using the
> > unlabeled SID or
> > the kernel SID better reflects the true nature of the
> > packet's contents.
>
> Not at all. icmp, timewaitack and such technically carry/indicate
> data at a particular lavel.

I guess I don't understand how an ICMP response is carrying user generated 
data?  Can you give an example?

> > > > The suggestions should address all of the packet flow control
> > > > issues in what I
> > > > think is a reasonable manner.  However, they don't address
> > > > the localhost
> > > > labeling issue,
> > >
> > > They would, effortlessly, if you just let things go with the flow
> > > with secmark. i.e., leverage secmark by letting it carry the
> > > appropriate/socket label on the outbound.
> >
> > While I agree it is tempting it would mean we would be
> > overloading the secmark
> > value which I don't think we should do
>
> It's not overloading since there isn't any undue change in semantics
> at the user level. Hence we call it "leveraging".

The secid patches change how the policy is written, therefore I still consider 
it overloading.  You can call it leveraging.

-- 
paul moore
linux security @ hp

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

RE: Denials from newest kernel

[James Morris]

On Sat, 14 Oct 2006, Venkat Yekkirala wrote:

> > > Can you specify what we are exactly loosing, if any, in the process?
> >
> > In one work, "understandability"
> 
> First of all, the "understandability" problem we have been having has
> to do with the following:
> 
> 1. Naming: we just refuse to change the naming for some inexplicable reason.

We are not renaming the SECMARK and CONNSECMARK kernel modules, which are 
already upstream, as well as the userland iptables code, and the existing 
packet labeling policy constructs.  Secmark works fine for normal users 
who are using internal labeling.

Also, ss I've said before, 'secpoint' is an abstraction which IMHO does 
not increase understandability in the common case.  'secmark' is the 
security analog of 'mark' (i.e. the MARK and CONNMARK modules), and it is 
very simply understandable as "adding security marks to packets".  Thus, 
the packet class is also appropriate, as packets are real kernel objects 
which you can literally set a security marking on.

I think this idea of modifying secmarks when external labeling enabled is 
not the right solution.

1. If you want to use the skb to carry external labeling information, then 
you can do this internally by splitting the secmark field and assigning 
limits to the number of network labels to be used.

2. If you want to introduce policy to mediate flow between external and 
internal labeling, do so, but don't change the internal label.

It's not clear to me that you actually need (1) or (2).

It's much simpler to just have two orthogonal labeling schemes.



-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> > First of all, the "understandability" problem we have been
> having has
> > to do with the following:
> >
> > 1. Naming: we just refuse to change the naming for some
> inexplicable reason.
>
> We are not renaming the SECMARK and CONNSECMARK kernel
> modules, which are
> already upstream, as well as the userland iptables code, and
> the existing
> packet labeling policy constructs.  Secmark works fine for
> normal users
> who are using internal labeling.

Ok. This is where we have a disconnect (I thought we understood this
implicitly a long time back, but since we haven't I will say this):

Secmark DOES NOT work fine for normal users who are using internal
labeling for the reason that it's scope is very narrow (socket Vs. packet)
with no controls for forwarded traffic. Now you may argue that that's what
it was designed for, but the fact still remains: it's NOT a comprehensive
(still talking internal labeling only) solution to the problem of packet
flow control on a modern "security-enhanced" OS. This everyone needs to
first
understand.

>
> Also, ss I've said before, 'secpoint' is an abstraction

It's NOT an abstraction. It is a replacement. Whereas in the secmark case
you were marking security contexts on packets, in the secpoint case, you
are specifying security contexts on "fine-grained flow-control points".
You see the difference?

> which
> IMHO does
> not increase understandability in the common case.  'secmark' is the
> security analog of 'mark' (i.e. the MARK and CONNMARK
> modules), and it is
> very simply understandable as "adding security marks to
> packets".

Which is the reason why I have been angling to get rid of "mark" from the
module name.

>  Thus,
> the packet class is also appropriate, as packets are real
> kernel objects
> which you can literally set a security marking on.

You can, but that's not the primary thing in the secpoint case where you
are instead labeling "fine-grained security/flow-control points".

>
> I think this idea of modifying secmarks when external
> labeling enabled is
> not the right solution.

I can understand why you would think so if you didn't see the
difference between secmark and secpoint.

>
> 1. If you want to use the skb to carry external labeling
> information, then
> you can do this internally by splitting the secmark field and
> assigning
> limits to the number of network labels to be used.

But in the secpoint case, there's no need to do this.

>
> 2. If you want to introduce policy to mediate flow between
> external and
> internal labeling, do so, but don't change the internal label.

There's no such thing as internal Vs. external in secpoint as
far as socket access to the packet is concerned. We use the most
appropriate label (the actual label the packet came in with or
in it's absence the label from the security point; how much more
intuitive can it get?)

IOW, in the terms you use above: the internal label (the security point
label in the new paradigm) is no longer significant once we "mediate flow"
between the external and internal (security point) labeling. IOW, the
internal
(aka secpoint) label has already served it's purpose once the mediation is
done.
The external label prevails like it should, since that's what the label of
the data is.

>
> It's not clear to me that you actually need (1) or (2).
>
> It's much simpler to just have two orthogonal labeling schemes.

As mentioned above, secmark is a good, narrowly focused mechanism that
perhaps has application in some niche areas, but it's not
a comprehensive mechanism. But it has certainly caused us to use it as a
stepping stone for secpoint.


--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Fri, 2006-10-13 at 16:52 -0500, Venkat Yekkirala wrote:
> > > > 5. can the packet flow into the ipsec association?

> > Without 5, we can't restrict the association traffic to just
> > http_client_packet_t, so mozilla_t can't be denied sending/receiving
> > dns_client_packets_t over the httpd_t association.
> 
> You can restrict it, but by way of the policy in the SPD, where you
> can use selectors such as ipaddr, port, protocol, etc. (see setkey(8)).
> 
> The "security points" have nothing to do with ipsec associations.

This is not sufficient because it encodes the access control policy into
the SPD, instead of putting the policy in the SELinux policy.  Putting
it in the SPD can't be analyzed when you do a policy analysis.

-- 
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: Denials from newest kernel

[Christopher J. PeBenito]

On Sat, 2006-10-14 at 18:01 -0500, Venkat Yekkirala wrote:
> > > First of all, the "understandability" problem we have been
> > having has
> > > to do with the following:
> > >
> > > 1. Naming: we just refuse to change the naming for some
> > inexplicable reason.
> >
> > We are not renaming the SECMARK and CONNSECMARK kernel
> > modules, which are
> > already upstream, as well as the userland iptables code, and
> > the existing
> > packet labeling policy constructs.  Secmark works fine for
> > normal users
> > who are using internal labeling.
> 
> Ok. This is where we have a disconnect (I thought we understood this
> implicitly a long time back, but since we haven't I will say this):
> 
> Secmark DOES NOT work fine for normal users who are using internal
> labeling for the reason that it's scope is very narrow (socket Vs. packet)
> with no controls for forwarded traffic. Now you may argue that that's what
> it was designed for, but the fact still remains: it's NOT a comprehensive
> (still talking internal labeling only) solution to the problem of packet
> flow control on a modern "security-enhanced" OS. This everyone needs to
> first
> understand.

I strongly disagree with this.  It is a replacement for the
port/node/netif basic networking controls.  Its vastly superior because
it provides the expressiveness of netfilter so you can have combinations
of ports, nodes, and netifs (and other netfilter things if you want).

I can see how the flow controls can do something for the forwarding
case, but in my opinion doesn't do anything for the regular input and
output cases.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> > > > > 5. can the packet flow into the ipsec association?
> 
> > > Without 5, we can't restrict the association traffic to just
> > > http_client_packet_t, so mozilla_t can't be denied 
> sending/receiving
> > > dns_client_packets_t over the httpd_t association.
> > 
> > You can restrict it, but by way of the policy in the SPD, where you
> > can use selectors such as ipaddr, port, protocol, etc. (see 
> setkey(8)).
> > 
> > The "security points" have nothing to do with ipsec associations.
> 
> This is not sufficient because it encodes the access control 
> policy into
> the SPD,

No it doesn't. You are ONLY labeling the rules in the SPD. Enforcement
is still via SELinux policy where you would have rules like:

allow apache_t  httpd_ipsec_t:association { polmatch };

> instead of putting the policy in the SELinux policy.  Putting
> it in the SPD can't be analyzed when you do a policy analysis.

Agreed and that's not what's happening. IOW, you are only labeling
the rules in the SPD leveraging the SPD syntax, but enforcement is
still via SELinux policy. Hope that clarifies. I think looking at
www.ipsec-howto.org would give you a good idea.

--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Mon, 2006-10-16 at 08:45 -0500, Venkat Yekkirala wrote:
> > > > > > 5. can the packet flow into the ipsec association?
> > 
> > > > Without 5, we can't restrict the association traffic to just
> > > > http_client_packet_t, so mozilla_t can't be denied 
> > sending/receiving
> > > > dns_client_packets_t over the httpd_t association.
> > > 
> > > You can restrict it, but by way of the policy in the SPD, where you
> > > can use selectors such as ipaddr, port, protocol, etc. (see 
> > setkey(8)).
> > > 
> > > The "security points" have nothing to do with ipsec associations.
> > 
> > This is not sufficient because it encodes the access control 
> > policy into
> > the SPD,
> 
> No it doesn't. You are ONLY labeling the rules in the SPD. Enforcement
> is still via SELinux policy where you would have rules like:
> 
> allow apache_t  httpd_ipsec_t:association { polmatch };
> 
> > instead of putting the policy in the SELinux policy.  Putting
> > it in the SPD can't be analyzed when you do a policy analysis.
> 
> Agreed and that's not what's happening. IOW, you are only labeling
> the rules in the SPD leveraging the SPD syntax, but enforcement is
> still via SELinux policy.

No, that is what is happening.  You can't tell from looking at the
SELinux policy that only http_server_packet_t can go on the
httpd_ipsec_t association, you would have to look at the SPD.  That's
the problem.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> I strongly disagree with this.  It is a replacement for the
> port/node/netif basic networking controls.

Which is what I mentioned as well. It's "narrow" however, in that,
it doesn't address the problem of general flow-control, of which,
controls on forwarded traffic are an important part.

>  Its vastly 
> superior because
> it provides the expressiveness of netfilter so you can have 
> combinations
> of ports, nodes, and netifs (and other netfilter things if you want).

Fully agreed with you here.

> 
> I can see how the flow controls can do something for the forwarding
> case, but in my opinion doesn't do anything for the regular input and
> output cases.

It does do EVERYTHING that secmark does in terms of expressing the
security goals applicable to regular input and ouput cases. Can you
show me an example where this isn't the case?

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

RE: Denials from newest kernel

[Venkat Yekkirala]

> > > > > > > 5. can the packet flow into the ipsec association?
> > > 
> > > > > Without 5, we can't restrict the association traffic to just
> > > > > http_client_packet_t, so mozilla_t can't be denied 
> > > sending/receiving
> > > > > dns_client_packets_t over the httpd_t association.
> > > > 
> > > > You can restrict it, but by way of the policy in the 
> SPD, where you
> > > > can use selectors such as ipaddr, port, protocol, etc. (see 
> > > setkey(8)).
> > > > 
> > > > The "security points" have nothing to do with ipsec 
> associations.
> > > 
> > > This is not sufficient because it encodes the access control 
> > > policy into
> > > the SPD,
> > 
> > No it doesn't. You are ONLY labeling the rules in the SPD. 
> Enforcement
> > is still via SELinux policy where you would have rules like:
> > 
> > allow apache_t  httpd_ipsec_t:association { polmatch };
> > 
> > > instead of putting the policy in the SELinux policy.  Putting
> > > it in the SPD can't be analyzed when you do a policy analysis.
> > 
> > Agreed and that's not what's happening. IOW, you are only labeling
> > the rules in the SPD leveraging the SPD syntax, but enforcement is
> > still via SELinux policy.
> 
> No, that is what is happening.  You can't tell from looking at the
> SELinux policy that only http_server_packet_t can go on the
> httpd_ipsec_t association, you would have to look at the SPD.

You CAN, if you labeled your SPD rules properly, just like how you
have to ensure you labeled your files and secmark rules correctly.
What's the difference?

>  That's
> the problem.

--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Mon, 2006-10-16 at 09:16 -0500, Venkat Yekkirala wrote:
> > > > > > > > 5. can the packet flow into the ipsec association?
> > > > 
> > > > > > Without 5, we can't restrict the association traffic to just
> > > > > > http_client_packet_t, so mozilla_t can't be denied 
> > > > sending/receiving
> > > > > > dns_client_packets_t over the httpd_t association.
> > > > > 
> > > > > You can restrict it, but by way of the policy in the 
> > SPD, where you
> > > > > can use selectors such as ipaddr, port, protocol, etc. (see 
> > > > setkey(8)).
> > > > > 
> > > > > The "security points" have nothing to do with ipsec 
> > associations.
> > > > 
> > > > This is not sufficient because it encodes the access control 
> > > > policy into
> > > > the SPD,
> > > 
> > > No it doesn't. You are ONLY labeling the rules in the SPD. 
> > Enforcement
> > > is still via SELinux policy where you would have rules like:
> > > 
> > > allow apache_t  httpd_ipsec_t:association { polmatch };
> > > 
> > > > instead of putting the policy in the SELinux policy.  Putting
> > > > it in the SPD can't be analyzed when you do a policy analysis.
> > > 
> > > Agreed and that's not what's happening. IOW, you are only labeling
> > > the rules in the SPD leveraging the SPD syntax, but enforcement is
> > > still via SELinux policy.
> > 
> > No, that is what is happening.  You can't tell from looking at the
> > SELinux policy that only http_server_packet_t can go on the
> > httpd_ipsec_t association, you would have to look at the SPD.
> 
> You CAN, if you labeled your SPD rules properly, just like how you
> have to ensure you labeled your files and secmark rules correctly.
> What's the difference?

The above rule clearly shows a relationship between a domain(socket?)
and a SPD entry.  It does not show a relationship between a packet and
an association.

When analyzing policy, the labeling is ignored until the very end where
you verify that the labeling fits the policy.   If you don't know what
is in the SPD, you can not know which packets can go over the
association by looking at the above rule.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> > > >
> > > > allow apache_t  httpd_ipsec_t:association { polmatch };
> > > >
<snip>
>
> The above rule clearly shows a relationship between a domain(socket?)
> and a SPD entry.  It does not show a relationship between a packet and
> an association.

This relationship is implicit in that a packet from apache_t can only
use an association labeled apache_t. This would be currently shown in the
SELinux policy itself as:

allow apache_t apache_t:association { sendto };

We did talk about moving this "implicit" relationship into the kernel itself
essentially eliminating the association indirection for SAs.

>
> When analyzing policy, the labeling is ignored until the very
> end where
> you verify that the labeling fits the policy.   If you don't know what
> is in the SPD, you can not know which packets can go over the
> association by looking at the above rule.

Can you please explain this in terms of file_contexts in case I am missing
something here (you seem to be saying in the above para that: If you don't
know what's in the file_contexts db, you can not know which procs can write
to which files).


--
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: Denials from newest kernel

[Paul Moore]

Venkat Yekkirala wrote:
>>>>>allow apache_t  httpd_ipsec_t:association { polmatch };
>>>>>
> 
> <snip>
> 
>>The above rule clearly shows a relationship between a domain(socket?)
>>and a SPD entry.  It does not show a relationship between a packet and
>>an association.
> 
> 
> This relationship is implicit in that a packet from apache_t can only
> use an association labeled apache_t. This would be currently shown in the
> SELinux policy itself as:
> 
> allow apache_t apache_t:association { sendto };
> 
> We did talk about moving this "implicit" relationship into the kernel itself
> essentially eliminating the association indirection for SAs.

That might be a good thing to do regardless of the secid work.

-- 
paul moore
linux security @ hp

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

RE: Denials from newest kernel

[Christopher J. PeBenito]

On Mon, 2006-10-16 at 13:29 -0500, Venkat Yekkirala wrote:
> > > > >
> > > > > allow apache_t  httpd_ipsec_t:association { polmatch };
> > > > >
> <snip>
> >
> > The above rule clearly shows a relationship between a domain(socket?)
> > and a SPD entry.  It does not show a relationship between a packet and
> > an association.
> 
> This relationship is implicit in that a packet from apache_t can only
> use an association labeled apache_t. This would be currently shown in the
> SELinux policy itself as:
> 
> allow apache_t apache_t:association { sendto };
> 
> We did talk about moving this "implicit" relationship into the kernel itself
> essentially eliminating the association indirection for SAs.

Exactly, implicit isn't sufficient, because we won't be able to specify
that http packets can go over the apache association but not dns
packets.

> > When analyzing policy, the labeling is ignored until the very
> > end where
> > you verify that the labeling fits the policy.   If you don't know what
> > is in the SPD, you can not know which packets can go over the
> > association by looking at the above rule.
> 
> Can you please explain this in terms of file_contexts in case I am missing
> something here (you seem to be saying in the above para that: If you don't
> know what's in the file_contexts db, you can not know which procs can write
> to which files).

No, that's not what I'm saying.  Its already understood that, for
example, shadow_t is for the shadow passwords.  There are explicit rules
for allowing a domain access to shadow passwords in the TE policy.  For
the purposes of analysis, we don't need to know which files have this
label until after we have determined that the policy rules match our
security goals.  Then after that, we can look at the labeling to make
sure that it lines up with the policy.

Its tough to put this in terms of file contexts, because it doesn't work
like ipsec, but I'll try.  Currently we have something like this:

TE:
allow passwd_t shadow_t:file rw_file_perms;
allow passwd_t etc_t:file r_file_perms;
allow checkpasswd_t shadow_t:file r_file_perms;
allow checkpasswd_t etc_t:file r_file_perms;

FC:
/etc(/.*)? system_u:object_r:etc_t
/etc/shadow -- system_u:object_r:shadow_t

where by looking at only the TE rules, you can see a relationship
between the password and checkpasswd domains and the shadow_t and etc_t
files.  By the policy design, we know that etc_t are general system
config files, and shadow_t are the shadow passwords.  Then after we're
done verifying our security goals in the TE rules, we can check the FC
to see that the labeling is indeed valid, and then label the
filesystems.

Now pretend that file contexts are instead loaded into the kernel and
each fc entry is labeled and has rules for access.

TE:
allow passwd_t passwd_fc_entries_t:fc fcmatch;

FC:
system_u:object_r:passwd_fc_entries_t r /etc(/.*)?
system_u:object_r:passwd_fc_entries_t rw /etc/shadow
system_u:object_r:checkpasswd_fc_entries_t r /etc(/.*)?
system_u:object_r:checkpasswd_fc_entries_t r /etc/shadow

See the difference?  Now we can't tell whats going on by looking at the
TE rules because we're putting policy somewhere else.  It doesn't matter
that these other rules also happen to be in the kernel; the point is
that they aren't in the TE policy.

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


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

Re: Denials from newest kernel

[Darrel Goeddel]

Christopher J. PeBenito wrote:
> On Mon, 2006-10-16 at 13:29 -0500, Venkat Yekkirala wrote:
> 
>>>>>>allow apache_t  httpd_ipsec_t:association { polmatch };
>>>>>>
>>
>><snip>
>>
>>>The above rule clearly shows a relationship between a domain(socket?)
>>>and a SPD entry.  It does not show a relationship between a packet and
>>>an association.
>>
>>This relationship is implicit in that a packet from apache_t can only
>>use an association labeled apache_t. This would be currently shown in the
>>SELinux policy itself as:
>>
>>allow apache_t apache_t:association { sendto };
>>
>>We did talk about moving this "implicit" relationship into the kernel itself
>>essentially eliminating the association indirection for SAs.
> 
> 
> Exactly, implicit isn't sufficient, because we won't be able to specify
> that http packets can go over the apache association but not dns
> packets.

Wouldn't the absence of "allow dns_t apache_t:association { sendto };" prevent
dns packets using an apache_t association?

This is probably my fault for suggesting using a policy constraint for choosing
the SA.  When the SA is being chosen, a check will be done for the socket sendto
the SA going down the line of SAs until we have a success.  We had used
constraints of u1==u2, r1==r2, t1==t2, l1==l2, and h1==h2 to ensure that the
socket context matched the SA context.  Having the entire context match means
that getpeercon would return the entire context from the peer socket.  The
alternative to ensuring the exact match, and therefore propagation of the context,
would be to enforce the context equality check in the kernel rather than leave
it configurable via policy.  The matching criteria is never really implicit.  It
requires that the policy allow the socket to send to the SA, this require type
access and meeting the conditions of the constraints.  This seems to be both
expressive and analyzable.

>>>When analyzing policy, the labeling is ignored until the very
>>>end where
>>>you verify that the labeling fits the policy.   If you don't know what
>>>is in the SPD, you can not know which packets can go over the
>>>association by looking at the above rule.
>>
>>Can you please explain this in terms of file_contexts in case I am missing
>>something here (you seem to be saying in the above para that: If you don't
>>know what's in the file_contexts db, you can not know which procs can write
>>to which files).
> 
> 
> No, that's not what I'm saying.  Its already understood that, for
> example, shadow_t is for the shadow passwords.  There are explicit rules
> for allowing a domain access to shadow passwords in the TE policy.  For
> the purposes of analysis, we don't need to know which files have this
> label until after we have determined that the policy rules match our
> security goals.  Then after that, we can look at the labeling to make
> sure that it lines up with the policy.
> 
> Its tough to put this in terms of file contexts, because it doesn't work
> like ipsec, but I'll try.  Currently we have something like this:
> 
> TE:
> allow passwd_t shadow_t:file rw_file_perms;
> allow passwd_t etc_t:file r_file_perms;
> allow checkpasswd_t shadow_t:file r_file_perms;
> allow checkpasswd_t etc_t:file r_file_perms;
> 
> FC:
> /etc(/.*)? system_u:object_r:etc_t
> /etc/shadow -- system_u:object_r:shadow_t
> 
> where by looking at only the TE rules, you can see a relationship
> between the password and checkpasswd domains and the shadow_t and etc_t
> files.  By the policy design, we know that etc_t are general system
> config files, and shadow_t are the shadow passwords.  Then after we're
> done verifying our security goals in the TE rules, we can check the FC
> to see that the labeling is indeed valid, and then label the
> filesystems.
> 
> Now pretend that file contexts are instead loaded into the kernel and
> each fc entry is labeled and has rules for access.
> 
> TE:
> allow passwd_t passwd_fc_entries_t:fc fcmatch;
> 
> FC:
> system_u:object_r:passwd_fc_entries_t r /etc(/.*)?
> system_u:object_r:passwd_fc_entries_t rw /etc/shadow
> system_u:object_r:checkpasswd_fc_entries_t r /etc(/.*)?
> system_u:object_r:checkpasswd_fc_entries_t r /etc/shadow
> 
> See the difference?  Now we can't tell whats going on by looking at the
> TE rules because we're putting policy somewhere else.  It doesn't matter
> that these other rules also happen to be in the kernel; the point is
> that they aren't in the TE policy.

I think the analogy between ipsec and files isn't working all that well :)
The policy (SELinux policy) must specifically allow for the sock vs SA
polmatch to choose the correct SPD and it must specifically allow for
the sock vs SA sendto to choose the correct SA.  If a domain such as
apache_t is allow to sendto SAs of many types (say http1_t, http2_t, etc.)
and SAs already exist for all of those types, it will use the first SA
that it can successfully sendto.  This would be analogous to passwd trying
/etc/shadow, /etc/shadow1, ... until it could write a shadow file.  In
any case, the policy still governs what can happen.  At least this is my
current understanding and that is always subject to change ;)

-- 

Darrel

--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Tue, 2006-10-17 at 12:58 -0500, Darrel Goeddel wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2006-10-16 at 13:29 -0500, Venkat Yekkirala wrote:
> > 
> >>>>>>allow apache_t  httpd_ipsec_t:association { polmatch };
> >>>>>>
> >>
> >><snip>
> >>
> >>>The above rule clearly shows a relationship between a domain(socket?)
> >>>and a SPD entry.  It does not show a relationship between a packet and
> >>>an association.
> >>
> >>This relationship is implicit in that a packet from apache_t can only
> >>use an association labeled apache_t. This would be currently shown in the
> >>SELinux policy itself as:
> >>
> >>allow apache_t apache_t:association { sendto };
> >>
> >>We did talk about moving this "implicit" relationship into the kernel itself
> >>essentially eliminating the association indirection for SAs.
> > 
> > 
> > Exactly, implicit isn't sufficient, because we won't be able to specify
> > that http packets can go over the apache association but not dns
> > packets.
> 
> Wouldn't the absence of "allow dns_t apache_t:association { sendto };" prevent
> dns packets using an apache_t association?

What I'm referring in this case is dns client packets; the ones used
when a process does a DNS name resolution.  I believe you're confusing
that with dns server packets which named_t would be sending to answer
DNS queries.  Apache can do name resolution, so it sends both httpd
server packets and dns client packets.

> >>>When analyzing policy, the labeling is ignored until the very
> >>>end where
> >>>you verify that the labeling fits the policy.   If you don't know what
> >>>is in the SPD, you can not know which packets can go over the
> >>>association by looking at the above rule.
> >>
> >>Can you please explain this in terms of file_contexts in case I am missing
> >>something here (you seem to be saying in the above para that: If you don't
> >>know what's in the file_contexts db, you can not know which procs can write
> >>to which files).
> > 
> > 
> > No, that's not what I'm saying.  Its already understood that, for
> > example, shadow_t is for the shadow passwords.  There are explicit rules
> > for allowing a domain access to shadow passwords in the TE policy.  For
> > the purposes of analysis, we don't need to know which files have this
> > label until after we have determined that the policy rules match our
> > security goals.  Then after that, we can look at the labeling to make
> > sure that it lines up with the policy.
> > 
> > Its tough to put this in terms of file contexts, because it doesn't work
> > like ipsec, but I'll try.  Currently we have something like this:
> > 
> > TE:
> > allow passwd_t shadow_t:file rw_file_perms;
> > allow passwd_t etc_t:file r_file_perms;
> > allow checkpasswd_t shadow_t:file r_file_perms;
> > allow checkpasswd_t etc_t:file r_file_perms;
> > 
> > FC:
> > /etc(/.*)? system_u:object_r:etc_t
> > /etc/shadow -- system_u:object_r:shadow_t
> > 
> > where by looking at only the TE rules, you can see a relationship
> > between the password and checkpasswd domains and the shadow_t and etc_t
> > files.  By the policy design, we know that etc_t are general system
> > config files, and shadow_t are the shadow passwords.  Then after we're
> > done verifying our security goals in the TE rules, we can check the FC
> > to see that the labeling is indeed valid, and then label the
> > filesystems.
> > 
> > Now pretend that file contexts are instead loaded into the kernel and
> > each fc entry is labeled and has rules for access.
> > 
> > TE:
> > allow passwd_t passwd_fc_entries_t:fc fcmatch;
> > 
> > FC:
> > system_u:object_r:passwd_fc_entries_t r /etc(/.*)?
> > system_u:object_r:passwd_fc_entries_t rw /etc/shadow
> > system_u:object_r:checkpasswd_fc_entries_t r /etc(/.*)?
> > system_u:object_r:checkpasswd_fc_entries_t r /etc/shadow
> > 
> > See the difference?  Now we can't tell whats going on by looking at the
> > TE rules because we're putting policy somewhere else.  It doesn't matter
> > that these other rules also happen to be in the kernel; the point is
> > that they aren't in the TE policy.
> 
> I think the analogy between ipsec and files isn't working all that well :)
> The policy (SELinux policy) must specifically allow for the sock vs SA
> polmatch to choose the correct SPD and it must specifically allow for
> the sock vs SA sendto to choose the correct SA.  If a domain such as
> apache_t is allow to sendto SAs of many types (say http1_t, http2_t, etc.)
> and SAs already exist for all of those types, it will use the first SA
> that it can successfully sendto.  This would be analogous to passwd trying
> /etc/shadow, /etc/shadow1, ... until it could write a shadow file.  In
> any case, the policy still governs what can happen.  At least this is my
> current understanding and that is always subject to change ;)

I'm not trying to argue that polmatch is a bad check; I understand its
reasons for existing.  I'm just saying its insufficient for checking if
a packet can go over an association.  The above contrived example shows
this, since you can't truly tell what you can access without looking at
the FC.

-- 
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: Denials from newest kernel

[Darrel Goeddel]

Christopher J. PeBenito wrote:
>>>>This relationship is implicit in that a packet from apache_t can only
>>>>use an association labeled apache_t. This would be currently shown in the
>>>>SELinux policy itself as:
>>>>
>>>>allow apache_t apache_t:association { sendto };
>>>>
>>>>We did talk about moving this "implicit" relationship into the kernel itself
>>>>essentially eliminating the association indirection for SAs.
>>>
>>>
>>>Exactly, implicit isn't sufficient, because we won't be able to specify
>>>that http packets can go over the apache association but not dns
>>>packets.
>>
>>Wouldn't the absence of "allow dns_t apache_t:association { sendto };" prevent
>>dns packets using an apache_t association?
> 
> 
> What I'm referring in this case is dns client packets; the ones used
> when a process does a DNS name resolution.  I believe you're confusing
> that with dns server packets which named_t would be sending to answer
> DNS queries.  Apache can do name resolution, so it sends both httpd
> server packets and dns client packets.

Ahh, gotcha...  I think I'll need a little more info on what you're going after
though.  I'll take a stab anyway...

One option is to modify apache to use setsockcreate to indicate different
network usages.  However, I think what you are really wanting lies in the
scope of IPSec SPD definitions, not SELinux policy.  I'm assuming that you
are wanting http traffic to use one SA, and dns requests to use another SA
(If that is not correct, I'll try again).  All traffic generated by apache
will fall within the same equivalence class (apache_t) in the eyes of
SELinun, so further action there is not feasible.  The IPSec
configuration is able to make a distinction based on other properties
such as addresses/ports.  What I think you want to do in this case is to
set up SPD as such (very informal pseudo syntax...):

SPD1 localhost dnsserver:53 ipsec out context=...dns_t...
SPD2 * localhost:80 ipsec in context=...http_t...

you would then allow apache to use both of the SPDs:

allow apache_t { dns_t http_t } association:polmatch;

When apache tries to send dns requests, the polmatch on the SPD1 will
be chosen based on the IPSec selectors and the SELinux policy (polmatch)
The second would have failed due to port specification.  An SA will
be established with the type apache_t (from the socket).

Then when a http request is serviced, SPD2 will be chosen.  A new SA
would be used, also having the type apache_t (from the socket), but
with a different spi because of the differing SPDs.  The SA created
above with apache_t will not be looked at because they will come from
different SPDs.

I think that all seems right.  Does that help at all?  Anyone see where I
may be sniffing glues here (I haven't actually done this lately)?

<snip, hopefully nothing important>

>>I think the analogy between ipsec and files isn't working all that well :)
>>The policy (SELinux policy) must specifically allow for the sock vs SA
>>polmatch to choose the correct SPD and it must specifically allow for
>>the sock vs SA sendto to choose the correct SA.  If a domain such as
>>apache_t is allow to sendto SAs of many types (say http1_t, http2_t, etc.)
>>and SAs already exist for all of those types, it will use the first SA
>>that it can successfully sendto.  This would be analogous to passwd trying
>>/etc/shadow, /etc/shadow1, ... until it could write a shadow file.  In
>>any case, the policy still governs what can happen.  At least this is my
>>current understanding and that is always subject to change ;)
> 
> 
> I'm not trying to argue that polmatch is a bad check; I understand its
> reasons for existing.  I'm just saying its insufficient for checking if
> a packet can go over an association.  The above contrived example shows
> this, since you can't truly tell what you can access without looking at
> the FC.

IIRC, the polmatch check is used only for choosing the SPD, the sendto check
is used in determining the specific SA to use.

I think you can tell with certainty what you *can* access, but not what you
*will* access.  What you can access is based on policy.  What you will access
is based on the order in which the SA are looked at - first "match" wins, but
it still must be allowed via policy.

I should have pointed talked a bit more more about the idea of replacing the
association:sendto check with a straight up context comparison in the kernel
for choosing the SA.  This removes flexibility, but it also removes some
complexity.  In this scenario, the check for choosing the SA would be replaced
with something that actually looks for context equality (this is the exact
behavior that we demonstrated with the constraints u1==u2, r1==r2, etc.).
Explicitly requiring this equality would essentially make the SA a proxy for
the socket, along the lines that the socket was always a proxy for the process
before the likes of setsockcreate.  The association:sendto check could then
be thrown out because the SA context would always equal that of the socket.
The results are the same, but the path is different.  In the current case,
the policy helps determine the match, and analysis can take that into
consideration since it should know about the policy ;).  With the kernel mod,
the kernel will always enforce and exact match and the analysis can work from
that fact.  Would the hardcoded proxy behavior be preferable in your eyes?

-- 

Darrel

--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Tue, 2006-10-17 at 14:23 -0500, Darrel Goeddel wrote:
> Christopher J. PeBenito wrote:
> >>>>This relationship is implicit in that a packet from apache_t can only
> >>>>use an association labeled apache_t. This would be currently shown in the
> >>>>SELinux policy itself as:
> >>>>
> >>>>allow apache_t apache_t:association { sendto };
> >>>>
> >>>>We did talk about moving this "implicit" relationship into the kernel itself
> >>>>essentially eliminating the association indirection for SAs.
> >>>
> >>>
> >>>Exactly, implicit isn't sufficient, because we won't be able to specify
> >>>that http packets can go over the apache association but not dns
> >>>packets.
> >>
> >>Wouldn't the absence of "allow dns_t apache_t:association { sendto };" prevent
> >>dns packets using an apache_t association?
> > 
> > 
> > What I'm referring in this case is dns client packets; the ones used
> > when a process does a DNS name resolution.  I believe you're confusing
> > that with dns server packets which named_t would be sending to answer
> > DNS queries.  Apache can do name resolution, so it sends both httpd
> > server packets and dns client packets.
> 
> Ahh, gotcha...  I think I'll need a little more info on what you're going after
> though.  I'll take a stab anyway...

I want to be able to restrict which associations a packet can go over,
specified by TE policy _alone_.

> One option is to modify apache to use setsockcreate to indicate different
> network usages.  However, I think what you are really wanting lies in the
> scope of IPSec SPD definitions, not SELinux policy.  I'm assuming that you
> are wanting http traffic to use one SA, and dns requests to use another SA
> (If that is not correct, I'll try again).  All traffic generated by apache
> will fall within the same equivalence class (apache_t) in the eyes of
> SELinun, so further action there is not feasible.  The IPSec
> configuration is able to make a distinction based on other properties
> such as addresses/ports.  What I think you want to do in this case is to
> set up SPD as such (very informal pseudo syntax...):
> 
> SPD1 localhost dnsserver:53 ipsec out context=...dns_t...
> SPD2 * localhost:80 ipsec in context=...http_t...
> 
> you would then allow apache to use both of the SPDs:
> 
> allow apache_t { dns_t http_t } association:polmatch;

This is exactly what I'm saying, the above encodes policy into the SPD!
When the question is "how to specify which packets can go over the
association?", the answer should not be "write a SPD rule", it should be
"write a SELinux rule".  These SPD entries only configure association
behaviors, but the current implementation makes an implicit relationship
between the packet and the association configuration.  Say we change the
first SPD entry to:

SPD1 localhost dnsserver:* ipsec out context=::dns_t

Now http packets can go over the same association as dns packets.  Your
first reaction would be "user error: misconfiguration", which would mean
you're encoding the packet->association policy into the SPD.  If SELinux
was mediating this correctly, it could still deny http packets from
going over this association.

> >>I think the analogy between ipsec and files isn't working all that well :)
> >>The policy (SELinux policy) must specifically allow for the sock vs SA
> >>polmatch to choose the correct SPD and it must specifically allow for
> >>the sock vs SA sendto to choose the correct SA.  If a domain such as
> >>apache_t is allow to sendto SAs of many types (say http1_t, http2_t, etc.)
> >>and SAs already exist for all of those types, it will use the first SA
> >>that it can successfully sendto.  This would be analogous to passwd trying
> >>/etc/shadow, /etc/shadow1, ... until it could write a shadow file.  In
> >>any case, the policy still governs what can happen.  At least this is my
> >>current understanding and that is always subject to change ;)
> > 
> > 
> > I'm not trying to argue that polmatch is a bad check; I understand its
> > reasons for existing.  I'm just saying its insufficient for checking if
> > a packet can go over an association.  The above contrived example shows
> > this, since you can't truly tell what you can access without looking at
> > the FC.
> 
> IIRC, the polmatch check is used only for choosing the SPD, the sendto check
> is used in determining the specific SA to use.
> 
> I think you can tell with certainty what you *can* access, but not what you
> *will* access.  What you can access is based on policy.  What you will access
> is based on the order in which the SA are looked at - first "match" wins, but
> it still must be allowed via policy.
> 
> I should have pointed talked a bit more more about the idea of replacing the
> association:sendto check with a straight up context comparison in the kernel
> for choosing the SA.  This removes flexibility, but it also removes some
> complexity.
[cut]
> Would the hardcoded proxy behavior be preferable in your eyes?

No.  In fact, Joshua and I were testing and the current SA labeling
behavior is not what I thought it was.  The association on both sides of
the connection is currently labeled with the type of the client, e.g.,
for mozilla_t making a new SA while connecting to httpd_t, the
association is labeled mozilla_t on both machines.  The current
implementation breaks the idea that the label of the association
represents the domain on the other side of the connection, which is why
the sendto check seems redundant.  Mozilla_t should sendto/recvfrom the
httpd_t association, and httpd_t should sendto/recvfrom the mozilla_t
association in this example.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

> I want to be able to restrict which associations a packet can go over,
> specified by TE policy _alone_.

Yes. The current design (including the constraints for context equality)
is in fact assuring that all packets from apache use the apache_t
association, since it's all coming from apache. This also preserves
the getpeercon semantics in that the remote BIND as well as firefox_t
will see the traffic as coming from apache_t. Choice of association
by "packet type" (specified entirely in the SELinux policy) isn't
possible for the following reasons:

1. secmarking comes into play AFTER the association is chosen. This is just
   how Linux networking operates.
2. In the new secpoint design (if we ever get to do it) there's no "packet
   type" per se. It's a flow-control point (dp_bind_t and dp_firefox_t) that
   apache_t will have to be configured to talk to in the SELinux policy.

So SELinux policy would have to assume that all packets from apache
use a "single" apache_t association, but in reality they may get to
be different associations based on how you have your SPD and SAD and IKE
setup. Also, if we think about it it's not an unreasonable assumption to
make either since this means different socket domains will use different
associations, thus assuring the needed separation. For what IPSec does
(encryption, auth, compress) this seems to be a good-enough isolation.


--
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: Denials from newest kernel

[Christopher J. PeBenito]

On Thu, 2006-10-19 at 10:57 -0500, Venkat Yekkirala wrote:
> > I want to be able to restrict which associations a packet can go over,
> > specified by TE policy _alone_.
>
> Yes. The current design (including the constraints for context equality)
> is in fact assuring that all packets from apache use the apache_t
> association, since it's all coming from apache. This also preserves
> the getpeercon semantics in that the remote BIND as well as firefox_t
> will see the traffic as coming from apache_t.

There is a severe problem with this.  The label of the association on
the apache machine should not be apache_t, it should be named_t for the
BIND association and firefox_t for the firefox association.  I described
this in a previous email.  The wrong labeling will cause unexpected
getpeercon results on the initiator side because apache would get
apache_t instead of firefox_t for example.  There should not be a
context equality between the socket and the association.

>  Choice of association
> by "packet type" (specified entirely in the SELinux policy) isn't
> possible for the following reasons:
>
> 1. secmarking comes into play AFTER the association is chosen. This is just
>    how Linux networking operates.

The question for this check is, "is this packet allowed to go over the
association?", and has the assumption that the association has been
chosen.  The negative answer means the packet is dropped, not "try next
association".  Your description above sounds like the appropriate
information is probably available for this check.

> 2. In the new secpoint design (if we ever get to do it) there's no "packet
>    type" per se. It's a flow-control point (dp_bind_t and dp_firefox_t) that
>    apache_t will have to be configured to talk to in the SELinux policy.

Its been stated clearly that the internal labeling shouldn't be
overwritten, see James's comments (which I agree with).

> So SELinux policy would have to assume that all packets from apache
> use a "single" apache_t association, but in reality they may get to
> be different associations based on how you have your SPD and SAD and IKE
> setup.

More than one file can have the same type, for example, so more than one
association having the same label isn't anything new.  See above for the
problem with the context equality.

-- 
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: Denials from newest kernel

[Venkat Yekkirala]

Just FYI- I spoke to Chris Friday morning and after we discussed that
the incoming traffic uses a differently labeled SA than the outgoing
traffic,
getpeercon semantics, etc., he is agreeable to eliminating the sendto check
for the outbound traffic. I am going to put a patch out that does this as
also
a. get the SA context from the sock (part of the failed secid patch)
b. fix getpeercon

Stay tuned.


> -----Original Message-----
> From: Christopher J. PeBenito [mailto:cpebenito@tresys.com]
> Sent: Friday, October 20, 2006 7:41 AM
> To: vyekkirala@trustedcs.com
> Cc: Darrel Goeddel; 'Karl MacMillan'; 'Joshua Brindle';
> selinux@tycho.nsa.gov; sds@tycho.nsa.gov
> Subject: RE: Denials from newest kernel
>
>
> On Thu, 2006-10-19 at 10:57 -0500, Venkat Yekkirala wrote:
> > > I want to be able to restrict which associations a packet
> can go over,
> > > specified by TE policy _alone_.
> >
> > Yes. The current design (including the constraints for
> context equality)
> > is in fact assuring that all packets from apache use the apache_t
> > association, since it's all coming from apache. This also preserves
> > the getpeercon semantics in that the remote BIND as well as
> firefox_t
> > will see the traffic as coming from apache_t.
>
> There is a severe problem with this.  The label of the association on
> the apache machine should not be apache_t, it should be
> named_t for the
> BIND association and firefox_t for the firefox association.
> I described
> this in a previous email.  The wrong labeling will cause unexpected
> getpeercon results on the initiator side because apache would get
> apache_t instead of firefox_t for example.  There should not be a
> context equality between the socket and the association.
>
> >  Choice of association
> > by "packet type" (specified entirely in the SELinux policy) isn't
> > possible for the following reasons:
> >
> > 1. secmarking comes into play AFTER the association is
> chosen. This is just
> >    how Linux networking operates.
>
> The question for this check is, "is this packet allowed to go over the
> association?", and has the assumption that the association has been
> chosen.  The negative answer means the packet is dropped, not
> "try next
> association".  Your description above sounds like the appropriate
> information is probably available for this check.
>
> > 2. In the new secpoint design (if we ever get to do it)
> there's no "packet
> >    type" per se. It's a flow-control point (dp_bind_t and
> dp_firefox_t) that
> >    apache_t will have to be configured to talk to in the
> SELinux policy.
>
> Its been stated clearly that the internal labeling shouldn't be
> overwritten, see James's comments (which I agree with).
>
> > So SELinux policy would have to assume that all packets from apache
> > use a "single" apache_t association, but in reality they may get to
> > be different associations based on how you have your SPD
> and SAD and IKE
> > setup.
>
> More than one file can have the same type, for example, so
> more than one
> association having the same label isn't anything new.  See
> above for the
> problem with the context equality.
>
> --
> 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: Denials from newest kernel

[Christopher J. PeBenito]

On Mon, 2006-10-23 at 12:42 -0500, Venkat Yekkirala wrote:
> Just FYI- I spoke to Chris Friday morning and after we discussed that
> the incoming traffic uses a differently labeled SA than the outgoing
> traffic,
> getpeercon semantics, etc., he is agreeable to eliminating the sendto check
> for the outbound traffic.

Just for clarification, I think we need a sendto check; however, I
understand why the sendto check is not useful in the current
implementation.

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