[refpolicy] Defining per-service initrc domains

[refpolicy] Defining per-service initrc domains

[Stephen Smalley]

Hi,

We would like to be able to define a set of per-service initrc domains
for particular rc scripts.  Although there seem to be a number of
per-service rc script file types (e.g. ftpd_initrc_exec_t), init_t still
transitions to the single initrc_t domain on all of those file types.
We want to instead launch the different rc scripts in distinct domains
from which we can then define per-service domain and file type
transitions as well as different permissions.

At first I thought that the init_script_domain() interface might work
for this purpose, but that yields a transition to the single initrc_t
domain from init_t and unconfined_t and only transitions to the new
domain if we started from initrc_t.  Is that intentional or a mistake?
I presume it is happening as a result of rules on the type attributes
elsewhere outside of the interface itself.

Is there any precedent for creating such per-service initrc domains?
And do we have any interfaces for doing so?

-- 
Stephen Smalley
National Security Agency

[refpolicy] Defining per-service initrc domains

[Russell Coker]

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

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

[refpolicy] Defining per-service initrc domains

[Stephen Smalley]

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

[refpolicy] Defining per-service initrc domains

[Christopher J. PeBenito]

On 07/13/10 16:57, Stephen Smalley wrote:
> Hi,
>
> We would like to be able to define a set of per-service initrc domains
> for particular rc scripts.  Although there seem to be a number of
> per-service rc script file types (e.g. ftpd_initrc_exec_t), init_t still
> transitions to the single initrc_t domain on all of those file types.
> We want to instead launch the different rc scripts in distinct domains
> from which we can then define per-service domain and file type
> transitions as well as different permissions.
>
> At first I thought that the init_script_domain() interface might work
> for this purpose, but that yields a transition to the single initrc_t
> domain from init_t and unconfined_t and only transitions to the new
> domain if we started from initrc_t.  Is that intentional or a mistake?

Init_script_domain() was written to provide exactly what you're looking 
for, but it isn't well tested.  I added it at the same time Dan started 
labeling individual init scripts so that roles like webadm and dbadm can 
start/stop only the relevant services.

> I presume it is happening as a result of rules on the type attributes
> elsewhere outside of the interface itself.

Probably.  I also need to check to see if there are transitions from 
initrc_t to the other init script types.  I think this is required since 
we get from init_t to initrc_t right away since /etc/rc.d/rc is in the 
inittab and its initrc_exec_t.

> Is there any precedent for creating such per-service initrc domains?
> And do we have any interfaces for doing so?

Not upstream.

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

[refpolicy] Defining per-service initrc domains

[Jeremy Solt]

> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com 
> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Stephen Smalley
> Sent: Tuesday, July 13, 2010 4:58 PM
> To: refpolicy at oss1.tresys.com
> Subject: [refpolicy] Defining per-service initrc domains
> 
> Hi,
> 
> We would like to be able to define a set of per-service 
> initrc domains for particular rc scripts.  Although there 
> seem to be a number of per-service rc script file types (e.g. 
> ftpd_initrc_exec_t), init_t still transitions to the single 
> initrc_t domain on all of those file types.
> We want to instead launch the different rc scripts in 
> distinct domains from which we can then define per-service 
> domain and file type transitions as well as different permissions.
> 
> At first I thought that the init_script_domain() interface 
> might work for this purpose, but that yields a transition to 
> the single initrc_t domain from init_t and unconfined_t and 
> only transitions to the new domain if we started from 
> initrc_t.  Is that intentional or a mistake?
> I presume it is happening as a result of rules on the type 
> attributes elsewhere outside of the interface itself.
> 
> Is there any precedent for creating such per-service initrc domains?
> And do we have any interfaces for doing so?
> 
> --
> Stephen Smalley
> National Security Agency


Hi Stephen,

I know it's been a while, but were you able to get this working
correctly? If not, I need some clarification. Were you trying to go from
init_t directly to ftpd_initrc_t over ftpd_initrc_exec_t (skipping
initrc_t completely)? Or just init_t -> initrc_t -> ftpd_initrc_t ->
ftpd_t ?

I ran some tests on init_script_domain(). On a Fedora 13 system, I
tested this out with qpidd and saw the following transitions:
init_t -> initrc_t -> qpidd_initrc_t -> qpidd_t

On a RHEL 5 system, I installed reference policy (to make sure the
problem hadn't been fixed by Dan in Fedora's patches) and tried this
with the ntp daemon. My transitions:
init_t -> initrc_t ->ntpd_initrc_t -> ntpd_t

Is this the path you were looking for or am I misunderstanding the
problem? 

Jeremy Solt
Tresys Technology
jsolt at tresys.com | www.tresys.com

[refpolicy] Defining per-service initrc domains

[Stephen Smalley]

On Tue, 2010-12-07 at 11:20 -0500, Jeremy Solt wrote:
> Hi Stephen,
> 
> I know it's been a while, but were you able to get this working
> correctly? If not, I need some clarification. Were you trying to go from
> init_t directly to ftpd_initrc_t over ftpd_initrc_exec_t (skipping
> initrc_t completely)? Or just init_t -> initrc_t -> ftpd_initrc_t ->
> ftpd_t ?
> 
> I ran some tests on init_script_domain(). On a Fedora 13 system, I
> tested this out with qpidd and saw the following transitions:
> init_t -> initrc_t -> qpidd_initrc_t -> qpidd_t
> 
> On a RHEL 5 system, I installed reference policy (to make sure the
> problem hadn't been fixed by Dan in Fedora's patches) and tried this
> with the ntp daemon. My transitions:
> init_t -> initrc_t ->ntpd_initrc_t -> ntpd_t
> 
> Is this the path you were looking for or am I misunderstanding the
> problem? 

That sounds right, but it didn't seem to work for us.  We were trying it
for the hadoop policy that has subsequently been merged, in order to get
the hadoop daemons into the right domains.

-- 
Stephen Smalley
National Security Agency

[refpolicy] Defining per-service initrc domains

[Paul Nuzzi]

On 12/09/2010 02:49 PM, Stephen Smalley wrote:
> On Tue, 2010-12-07 at 11:20 -0500, Jeremy Solt wrote:
>> Hi Stephen,
>>
>> I know it's been a while, but were you able to get this working
>> correctly? If not, I need some clarification. Were you trying to go from
>> init_t directly to ftpd_initrc_t over ftpd_initrc_exec_t (skipping
>> initrc_t completely)? Or just init_t -> initrc_t -> ftpd_initrc_t ->
>> ftpd_t ?
>>
>> I ran some tests on init_script_domain(). On a Fedora 13 system, I
>> tested this out with qpidd and saw the following transitions:
>> init_t -> initrc_t -> qpidd_initrc_t -> qpidd_t
>>
>> On a RHEL 5 system, I installed reference policy (to make sure the
>> problem hadn't been fixed by Dan in Fedora's patches) and tried this
>> with the ntp daemon. My transitions:
>> init_t -> initrc_t ->ntpd_initrc_t -> ntpd_t
>>
>> Is this the path you were looking for or am I misunderstanding the
>> problem? 
> 
> That sounds right, but it didn't seem to work for us.  We were trying it
> for the hadoop policy that has subsequently been merged, in order to get
> the hadoop daemons into the right domains.
> 

We were having an issue where five different domains were being started with the same executable (hadoop_exec_t).  If I remember correctly, init_script_domain or init_daemon_domain wasn't allowing us to have multiple domain entries for one executable.  init_script_domain(hadoop_$1_initrc_t, hadoop_$1_initrc_exec_t) seemed to solve the problem.