[refpolicy] system_init.patch

[dwalsh@redhat.com (Daniel J Walsh)]

On 03/19/2010 08:47 AM, Christopher J. PeBenito wrote:
> 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.
>
>    
SELinux is all about changing users behaviours.  I also do not allow 
user_t from running su and sudo.
Staff_t can not run su.  We are confining users, this means stopping 
them from running setuid applications.  If you want to run startx, then 
log in as unconfined_t.  Confined users can only run a small set of 
Setuid apps that have to have a transition.
My definition of a confined User is he does not know the root password.  
So he should not be allowed to run su.  If you need to run sudo you need 
to be staff_t.  One problem we have in reference policy is it was based 
on example policy back in RHEL4 days where we were trying to allow all 
the expected access, instead of making real security decisions.
>>>    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?
>
>    
I am talking about unexpected commands that use the network.  If you 
disable IPV6 lots of network apps tell the kernel to load the module.  
Even though the network config tools disable it.  We now have an 
setroubleshoot plugin that ignores this avc.  But I have no problem 
dropping this since initrc_t tends to run as unconfined_t, which would 
handle this situation, and if someone wants to confine initrc_t they 
should have to deal with this.

>    
>>> 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 :)
>
>    
Might have been before a transition to sulogin?  Lets remove them both.  
It will not effect the vast majority of users and MLS environment should 
be more secure.
>>> 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?
>
>    
Might be dbus integration.  But I will remove and see what happens.