From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 27 Aug 2014 13:41:00 -0400
Subject: [refpolicy] [PATCH 5/7] Add socket and dccp_socket to
	socket_class_set
In-Reply-To: <53FCC247.1020500@m4x.org>
References: <1408793751-11289-1-git-send-email-nicolas.iooss@m4x.org>
	<1408793751-11289-6-git-send-email-nicolas.iooss@m4x.org>
	<53FB514C.6090405@tresys.com> <53FCC247.1020500@m4x.org>
Message-ID: <53FE182C.5090800@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 8/26/2014 1:22 PM, Nicolas Iooss wrote:
> 2014-08-25 17:07 GMT+02:00 Christopher J. PeBenito:
>> On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
>>> @@ -28,8 +28,7 @@ define(`devfile_class_set', `{ chr_file blk_file }')
>>>  #
>>>  # All socket classes.
>>>  #
>>> -define(`socket_class_set', `{ tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket }')
>>> -
>>> +define(`socket_class_set', `{ socket dccp_socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket }')
>>
>> I don't think we want to add socket to this set.  We need to be able to
>> detect when there is generic socket class usage, as that means we need a
>> kernel change and a corresponding new object class.
> 
> I agree with this point of view, if "socket" class means "generic socket
> which is never used in practice" (and which defines access vectors
> common to all socket classes, as stated on the SELinux wiki [1]).

To be more specific, it refers to sockets that have no defined SELinux
object class.  It is a fallback object class.


> Now that you said that "socket" should be used to detect new socket
> class (if I understood correctly), there is something I no longer
> understand in the current policy.  Why does contrib/mozilla.te contains
> this? [5]
> 
>     allow mozilla_t self:socket create_socket_perms;

I did some digging and found that rule was pulled in from the NSA
example policy.  I don't know why it's there or if it is still needed.


> A quick "grep :socket -r policy" shows other domains allowed to use this
> kind of socket.  Do you know where I could find a good documentation
> about the socket class to understand why these allow rules are needed?

It would depend on the application; you would have to identify what type
of sockets that are being used, and then we'd have to add new object
classes.  I'd be happy to remove them if it can be demonstrated that
they are no longer needed.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com