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

Sven Vermeulen sven.vermeulen at siphos.be
Tue Jul 3 12:49:30 CDT 2012


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?

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).

Wkr,
	Sven Vermeulen



More information about the refpolicy mailing list