From: sds@tycho.nsa.gov (Stephen Smalley)
Date: Wed, 14 Jul 2010 09:40:39 -0400
Subject: [refpolicy] Defining per-service initrc domains
In-Reply-To: <201007142148.01963.russell@coker.com.au>
References: <1279054665.28691.227.camel@moss-pluto.epoch.ncsc.mil>
	<201007142148.01963.russell@coker.com.au>
Message-ID: <1279114839.15485.49.camel@moss-pluto.epoch.ncsc.mil>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 2010-07-14 at 21:48 +1000, Russell Coker wrote:
> On Wed, 14 Jul 2010, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > We would like to be able to define a set of per-service initrc domains
> > for particular rc scripts.
> 
> What is the aim of this?
> 
> Do you want to allow different source domains (other than init_t) to run some 
> of these init scripts, do you want to prevent a bug in init script A from 
> messing with daemon B (through accident or malice), or both?
> 
> I guess it's worth noting here that currently initrc_t is not confined in any 
> way that really matters.  The privileges associated with mounting filesystems 
> and starting udev mean that you can't stop a script running as initrc_t from 
> taking over your system.
> 
> To what degree are you thinking of breaking down initrc_t?  Just domains for 
> starting a few daemons or do you want to have separate domains for all the 
> major areas of functionality in booting the system?
> 
> Have you considered the possibility of just using labels such as ftpd_exec_t 
> for init scripts?  I've done that before...

We're just looking at moving a specific set of rc scripts into their own
domains.  The initial motivation has less to do with confining the rc
scripts (although that would be a nice side benefit) and more to do with
getting processes and files created by the rc script labeled with
specific domains and file types distinct for the service, not something
generic to all rc scripts, so that we can properly confine the daemon
process.

The particular use case is cloudera hadoop, where there are a set of rc
scripts for different services (namenode, datanode, jobtracker,
tasktracker) but all of the rc scripts are simple wrappers around a
shared helper script (hadoop-daemon.sh) that handles creation of
relevant files (pid, log) and runs the hadoop command with the right
arguments, which in turn is a script that runs java with the right
class.  By running the rc scripts in a particular domain (e.g.
hadoop_namenode_initrc_t), we can label the pid and log files properly
(e.g. hadoop_namenode_pid_t, hadoop_namenode_log_t) and transition to
the right domain for the daemon process (e.g. hadoop_namenode_t) upon
executing the hadoop command. We don't want to just run everything
directly in the daemon process domain, as the init script does perform
actions that we would prefer not to allow to the long running daemon.

-- 
Stephen Smalley
National Security Agency