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

[cpebenito@tresys.com (Christopher J. PeBenito)]

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