From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 19 Mar 2010 08:47:47 -0400
Subject: [refpolicy] system_init.patch
In-Reply-To: <4BA25C50.9090708@redhat.com>
References: <4B8455C5.5000808@redhat.com>
	<1268921993.5623.60.camel@gorn.columbia.tresys.com>
	<4BA25C50.9090708@redhat.com>
Message-ID: <1269002867.5623.104.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, 2010-03-18 at 13:01 -0400, Daniel J Walsh wrote:
> On 03/18/2010 10:19 AM, Christopher J. PeBenito wrote:
> > On Tue, 2010-02-23 at 17:25 -0500, Daniel J Walsh wrote:
> >    
> >> http://people.fedoraproject.org/~dwalsh/SELinux/F13/system_init.patch
> >>
> >> Lots of changes to init.
> >>      
> > Dropping startx and system-config-services fc, as they don't make sense.
> > The former stops unpriv users from running startx from the terminal,
> I don't think this is a bad thing.  I don't want confined users 
> transitioning to xserver_t.

I can't agree with this.  Users have been able to log into the console
(tty) and run startx since forever.

> >   and
> > init scripts should be configured by admins, so transitioning to init
> > script domains to configure init scripts seems wrong.
> >    
> This gets us out of system_dbusd_t system-config-services is a service, 
> not an application to be run by one admin.  dbus is a client server 
> mechanism.  The service has got to be running as something that can do 
> its job.  In this case it is a service that starts and stops init 
> scripts.  So defining a domain that can start and stops initrc scripts 
> rather then just labeling it initrc_exec_t seems crazy.

I thought it was an admin application, so I'll chalk it up to naming
inconsistency in Red Hat tools.  The line should go in a distro_redhat.


> > What is an example of an init script doing a kernel module load request?
> >
> >    
> Anything that would bring up a network device (ipv6).

But wouldn't that be something like that happen in ifconfig_t,
networkmanager_t, or dhcpc_t?


> > Why does initrc need to transition to passwd?
> >
> >    
> I can't find a reason.  For either,  I will remove and see if it comes 
> back.  Although you have
> allow initrc_t self:passwd rootok;

True.  git annotate tells me that the line has been there since April
14, 2005, which is at the beginning of refpolicy, so it was taken from
the NSA example policy w/o question.  I guess that means I'm questioning
it now :)

> > Dropped the init_upstart addition in init_daemon_domain() as it causes
> > duplicate type transition errors.
> >
> >    
> This is just going to cause bugs as daemons move from SysV scripts to 
> upstart.
> I commented this out in init_ranged_daemon_domain  probably to stop 
> conflicts.
> #    init_daemon_domain($1,$2)

I think the problem may be the type_transition from initrc_t to the
daemon being both unconditional and conditional (in init_upstart).  The
problem is that I can't cut the transition from initrc_t otherwise it
breaks the distros that don't use upstart.

> > Why would we want to allow signal inheritance?
> >
> >    
> Appa starts initrc_t which starts a process

We shouldn't be allowing App A from influencing initrc_t, which is
extremely privileged.  Something narrow like writing a pipe inherited
from initrc_t's parent is reasonable, but I can't think of a case for
siginh that would make it reasonable to allow across the board.  What
prompted this?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150