From: dwalsh@redhat.com (Daniel J Walsh)
Date: Thu, 18 Mar 2010 13:01:04 -0400
Subject: [refpolicy] system_init.patch
In-Reply-To: <1268921993.5623.60.camel@gorn.columbia.tresys.com>
References: <4B8455C5.5000808@redhat.com>
	<1268921993.5623.60.camel@gorn.columbia.tresys.com>
Message-ID: <4BA25C50.9090708@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.
>   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.
> Fixed dontaudit_init_read_all_script_files() interface name to
> init_dontaudit_read_all_script_files().
>
>    
Sorry.  I applied a patch from some one else and did not notice this.
> Dropped init_t and initrc_t audit capabilities; use logging interfaces.
>
> What is an example of an init script doing a kernel module load request?
>
>    
Anything that would bring up a network device (ipv6).
> Why does initrc need to delete /dev/null?
>    
> 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;

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

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