[refpolicy] [PATCH/RFC 2/2] Add minidlna policy

[dominick.grift@gmail.com (Dominick Grift)]

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.

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.

I just remember that "client_packets" correspond to connecting to a
port, and "server_packets" correspond to binding sockets to a port.

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

> 
> 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?
> 
> # ps -efZ | grep minidlna
> system_u:system_r:minidlna_t    minidlna 10236     1  0 21:08 ?  00:00:00 /usr/sbin/minidlna -P /var/run/minidlna/minidlna.pid -R -f /etc/minidlna.conf
> 
> # semanage port -l | grep 8200
> trivnet1_port_t                tcp      8200
> trivnet1_port_t                udp      8200
> 
> # sesearch -s minidlna_t -t trivnet1_port_t -c tcp_socket -Ad
> Found 1 semantic av rules:
>   allow minidlna_t trivnet1_port_t : tcp_socket name_bind ; 
> 
> # sesearch -s minidlna_t -c tcp_socket -p send_msg -A
> #
>    (no hits, just in case it was through an attribute)
> 
> # sestatus | grep mode
> Current mode:			enforcing
> 
> # semanage permissive -l
> # 
>   (no permissive domains)
> 
> I'll add in the corenet_tcp_sendrecv_trivnet1_port(minidlna_t) and the
> udp/ssdp one as, from online documentation, I think I understand that they
> are needed. But I am wondering why my system doesn't mind working onwards
> even without these rules :-(

Fedora shows the same behavior. I think it is related to "compat_net"
but i am not sure. I just know how it use to work, and i would like to
maintain backwards compatibility.

> Wkr,
>   Sven Vermeulen