Re: Denials from newest kernel

[Joshua Brindle <jbrindle@tresys.com>]

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.