From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Thu, 2 May 2013 21:23:47 +0200
Subject: [refpolicy] [PATCH/RFC 2/2] Add minidlna policy
In-Reply-To: <1367509285.27309.34.camel@d30>
References: <20130501183657.GA25116@siphos.be>
	<20130501183845.GC25116@siphos.be> <1367509285.27309.34.camel@d30>
Message-ID: <20130502192347.GA25444@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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?

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?

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

Wkr,
  Sven Vermeulen