[refpolicy] [RFC] Add the security class and AV's needed for systemd

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

On 7/8/2014 9:16 AM, Laurent Bigonville wrote:
> Le Tue, 8 Jul 2014 08:30:32 -0400,
> "Christopher J. PeBenito" <cpebenito@tresys.com> a ?crit :
> 
>> On 7/5/2014 9:59 AM, Laurent Bigonville wrote:
>>> From: Laurent Bigonville <bigon@bigon.be>
>>>
>>> The list of AV's has been built by grepping the systemd code for the
>>> calls to selinux_unit_access_check() and selinux_access_check()
>>> macro. ---
>>>  policy/flask/access_vectors      | 18 ++++++++++++++++++
>>>  policy/flask/security_classes    |  3 +++
>>>  policy/support/obj_perm_sets.spt |  5 +++++
>>>  3 files changed, 26 insertions(+)
>>>
>>> diff --git a/policy/flask/access_vectors
>>> b/policy/flask/access_vectors index a94b169..e0d3768 100644
>>> --- a/policy/flask/access_vectors
>>> +++ b/policy/flask/access_vectors
>>> @@ -393,6 +393,14 @@ class system
>>>  	syslog_mod
>>>  	syslog_console
>>>  	module_request
>>> +	halt
>>> +	reboot
>>> +	status
>>> +	start
>>> +	stop
>>> +	enable
>>> +	disable
>>> +	reload
>>
>> This doesn't look right.  There shouldn't be userspace permissions
>> mixed in with a kernel object class.  Are these really used or are
>> they compatibility for old versions of systemd?
> 
> I searched the code that is currently in the HEAD of the master branch
> in the systemd git repository and the code path still seems to be used
> ATM.
> 
> Dominick even had issue with the "start" AV not being associated to the
> system class when developing his own policy

I just looked at the bug you're referring to.  From Dominick's
description, it sounds like it's buggy code being covered up by the
unknown permissions=allow functionality.

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