[refpolicy] [PATCH v2 2/6] Allow init scripts to handle sysctls

Christopher J. PeBenito cpebenito at tresys.com
Tue Jul 3 08:59:52 CDT 2012


On 7/2/2012 4:19 PM, Sven Vermeulen wrote:
> On Mon, Jul 02, 2012 at 10:47:43AM -0400, Christopher J. PeBenito wrote:
>>>   allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
>>> -allow initrc_t self:capability ~{ sys_admin sys_module };
>>> +allow initrc_t self:capability ~{ sys_module };
>>>   dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
>>>   allow initrc_t self:passwd rootok;
>>>   allow initrc_t self:key manage_key_perms;
>>
>> We typically try to separate out the sys_admin privileges since its so broad.  Can a new domain be created?
>
> Its the init script calling the sysctl binary. We currently don't hold a
> separate domain for sysctl, but that's certainly doable. I guess it would
> start with allowing both initrc_t and sysadm_t to transition to sysctl_t.
>
> But for some reason I think this has been thought of before - sysctl's are
> well known throughout the policy (with specific labels for kernel sysctl's
> and such). Was a new domain for sysctl's not done because there was little
> need for, or am I missing something?

My guess is that its a new capability check, or its a capability check for a sysctl that isn't often set.

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




More information about the refpolicy mailing list