From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 10 Jul 2012 08:27:42 -0400
Subject: [refpolicy] [PATCH v2 2/6] Allow init scripts to handle sysctls
In-Reply-To: <20120703174930.GA31482@siphos.be>
References: <1340911046-30441-1-git-send-email-sven.vermeulen@siphos.be>
	<1340911046-30441-3-git-send-email-sven.vermeulen@siphos.be>
	<4FF1B48F.4060909@tresys.com> <20120702201951.GA19551@siphos.be>
	<4FF2FAD8.8010202@tresys.com> <20120703174930.GA31482@siphos.be>
Message-ID: <4FFC1FBE.3070506@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 07/03/12 13:49, Sven Vermeulen wrote:
> On Tue, Jul 03, 2012 at 09:59:52AM -0400, Christopher J. PeBenito wrote:
>>> 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.
> 
> Yes, there are apparently a few cases in sysctls where this is hit. In my
> particular case, it is on grSecurity sysctl's. There's something in the
> kernel about "tainted" sysctls as well which also require the CAP_SYS_ADMIN
> capability before writing to them.
> 
> That said, I removed that particular part from the patchset as I've still
> got a few questions on this case. I was first going to create a sysctl_t
> domain... but that one already exists, although it isn't a domain (yet) but
> rather the label given to sysctl's in /proc/sys. 
> 
> I don't think it is wise to make sysctl_t a domain as well, do you? If not,
> is it still a good idea to move sysctl in its own domain and would I then
> need to rename sysctl_t (the current one) to something else, or look for a
> other name for the domain?

It would be better to find another name for the domain, otherwise we'd have compatibility problems.  e.g. someone has a custom policy module installed that has a domain that sets sysctls.
 
> Another way to handle this is to make a sysctl_initrc_t domain (like
> Dominick suggested) but that'll be more different for Gentoo to take as we
> currently don't use such named init scripts yet (but I have to start
> supporting that anyhow sometime, so this is as good a time as any I guess).

I don't have a strong feeling either way.

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