From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Fri, 3 May 2013 09:47:26 -0400 Subject: [refpolicy] [PATCH/RFC 2/2] Add minidlna policy In-Reply-To: <1367524372.27309.45.camel@d30> References: <20130501183657.GA25116@siphos.be> <20130501183845.GC25116@siphos.be> <1367509285.27309.34.camel@d30> <20130502192347.GA25444@siphos.be> <1367524372.27309.45.camel@d30> Message-ID: <5183BFEE.1030309@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 05/02/13 15:52, Dominick Grift wrote: > On Thu, 2013-05-02 at 21:23 +0200, Sven Vermeulen wrote: >> On Thu, May 02, 2013 at 05:41:25PM +0200, Dominick Grift wrote: >>>> +corenet_sendrecv_trivnet1_client_packets(minidlna_t) >>>> +corenet_sendrecv_trivnet1_server_packets(minidlna_t) >>>> +corenet_tcp_bind_trivnet1_port(minidlna_t) >>>> + >>> >>> Another oversight >>> >>> You do not need the "client_packets" interface calls if the domain does >>> not connect to the port >>> >>> In this case minidlna domain only binds tcp sockets to trivnet1 ports, >>> and udp sockets to ssdp ports >> >> I must admit, I never understood (and still don't understand) the networking >> aspects in more detail. The corenet_sendrecv_*_packets() interfaces are for >> the SECMARK labeled usage, right? > > Good question, and i am not sure. Yes, they are used for SECMARK. > I just know/remember the behavior as i've experienced it. I just do not > remember if it was due to secmark or compat_net or something else. > > Could be just how selinux network controls were previously configured by > default on fedora in the past (compat_net?). In that case it is still > good to support backwards compatibility. As you mentioned in a latter email, compat_net has been removed. The SELinux network access controls are only SECMARK now. > I just remember that "client_packets" correspond to connecting to a > port, and "server_packets" correspond to binding sockets to a port. Yes, the premise was to differentiate incoming and outgoing packets. For example if you ssh out of a system that has a sshd, you want to separate the packets going to sshd from those going to the ssh client. >> The interfaces assume that iptables (or whatever you use) labels the packets >> as trivnet1_client_packet_t or trivnet1_server_packet_t. Does that mean >> that, in case of a daemon (which does not connect to remote ports, i.e. act >> as a client) we assume that iptables marks it as trivnet1_server_packet_t? >> >> And that, if we would connect to a remote site somehow, these packets would >> be assumed to be marked trivnet1_client_packet_t? > > I am just not sure, sorry. Maybe Chris or Paul Moore can shed some more > light on this. Yes. I think what you're confused on is that SECMARK labels are local only. They are not transferred over the network like labeled IPSEC or NetLabel/CIPSO. The object class for those labels is peer. The only remaining permissions on port types is name_bind and name_connect. >> Also, if a system would use SECMARK, are the following interfaces then no >> longer needed (as these are the "old" ones)? >> - corenet_all_recvfrom_unlabeled >> - corenet_tcp_sendrecv_generic_if >> - corenet_tcp_sendrecv_generic_node >> - corenet_tcp_bind_generic_node >> - corenet_tcp_bind_*_port >> - corenet_tcp_sendrecv_*_port >> >>> i think we also need these: >>> >>> corenet_tcp_sendrecv_trivnet1_port(minidlna_t) >>> corenet_udp_sendrecv_ssdp_port(minidlna_t) >> >> From the looks of it, you're right, as minidlna_t currently doesn't have { >> send_msg recv_msg } rights on the trivnet1_port_t's tcp_socket. The weird >> thing is, my minidlna server is running just fine and my TV can connect and >> play stuff from the server. I'm not running a firewall that labels the >> packets either, so what gives? These permissions are no longer checked, as they are replaced by the SECMARK/packet permissions. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com