[refpolicy] [PATCH 2/5] Fix avc_context_to_raw assertion (avc_running) failure upon running groupadd or useradd

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

On 04/09/2014 12:52 PM, Sven Vermeulen wrote:
> On Fri, Apr 04, 2014 at 04:07:25PM -0400, Christopher J. PeBenito wrote:
>> On 03/25/2014 04:30 PM, Sven Vermeulen wrote:
>>> When trying to create a group, the following error occurs:
>>>
>>> ~# groupadd test
>>> groupadd: avc.c:74: avc_context_to_sid_raw: Assertion `avc_running'
>>> failed.
>>> zsh: abort      groupadd test
>>>
>>> In the denial logs, the following AVC denial is shown:
>>>
>>> Jan 23 13:57:17 maelstrom kernel: [11395.396588] type=1400
>>> audit(1390481837.876:989): avc:  denied  { create } for  pid=14296
>>> comm="groupadd" scontext=staff_u:sysadm_r:groupadd_t
>>> tcontext=staff_u:sysadm_r:groupadd_t tclass=netlink_selinux_socket
>>>
>>> In permissive mode, we notice that it both creates and binds to the
>>> netlink_selinux_socket.
>>>
>>> Same with useradd.
>>>
>>> Allowing the create/bind fixes the problem.
>>
>> I think we should start a new seutil interface which provides the necessary access for domains that have a userspace AVC.  However, since this seems to only initialize a userspace AVC to do context_to_sid_raw, I wonder if it makes sense to keep this explicit netlink_selinux_socket access.
> [...]
>>> +allow groupadd_t self:netlink_selinux_socket { bind create };
> 
> Hi Chris & refpolicy folks
> 
> I'm afraid I don't follow.
> 
> I understand that netlink_selinux_socket class is related to userspace
> SELinux support (netlink interface for interaction between userspace and
> kernel towards the SELinux subsystem) but you lost me at "to only initialize
> a userspace AVC to do context_to_sid_raw".

Well as far as I know, there aren't any reasons for groupadd to run a userspace AVC (it's not an object manager).  However, to do context_to_sid_raw, it needs to have one running (hence the assertion that failed above).  I'd like to start putting together an interface that domains that have a userspace AVC can use, which provides all the necessary access for the AVC to work.
 
> Do you mean that the permissions (bind + create) do not really mean that
> there is any communication otherwise (as there is no send_msg/recv_msg)? If

Yes, but due to no read/write perms.

> so, does this then mean that the application shouldn't be calling
> avc_context_to_sid_raw at all?

I'm not suggesting that, as I haven't looked at the code.

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