From mboxrd@z Thu Jan  1 00:00:00 1970
From: dominick.grift@gmail.com (Dominick Grift)
Date: Mon, 02 Jul 2012 22:25:06 +0200
Subject: [refpolicy] [PATCH v2 2/6] Allow init scripts to handle sysctls
In-Reply-To: <20120702201951.GA19551@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>
Message-ID: <1341260706.12606.1.camel@x220.mydomain.internal>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2012-07-02 at 22:19 +0200, 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?

or create a init_script_domain() for this particular script maybe?

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy