[refpolicy] system_init.patch

[refpolicy] system_init.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F12/system_init.patch

Fix labels

Add policy to make upstart->daemon work, in addition to upstart->initrc_t->daemon

[refpolicy] system_init.patch

[Christopher J. PeBenito]

On Thu, 2009-11-12 at 17:09 -0500, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F12/system_init.patch
> 
> Fix labels
> 
> Add policy to make upstart->daemon work, in addition to
> upstart->initrc_t->daemon

This needs to go in a init_upstart tunable block.

initrc_tmp_t blk_files and chr_files needs explanation, otherwise its
completely unacceptable.

It looks like your patch reverses some upstream changes. eg:

+fs_register_binary_executable_type(initrc_t)
+# rhgb-console writes to ramfs
+fs_write_ramfs_pipes(initrc_t)
+# cjp: not sure why these are here; should use mount policy
+fs_mount_all_fs(initrc_t)
+fs_unmount_all_fs(initrc_t)
+fs_remount_all_fs(initrc_t)
+fs_getattr_all_fs(initrc_t)
+fs_search_all(initrc_t)
+fs_getattr_nfsd_files(initrc_t)

then later:

-fs_register_binary_executable_type(initrc_t)
-# rhgb-console writes to ramfs
-fs_write_ramfs_pipes(initrc_t)
-# cjp: not sure why these are here; should use mount policy
-fs_mount_all_fs(initrc_t)
-fs_unmount_all_fs(initrc_t)
-fs_remount_all_fs(initrc_t)
-fs_getattr_all_fs(initrc_t)

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

[refpolicy] system_init.patch

[Daniel J Walsh]

On 02/12/2010 03:00 PM, Christopher J. PeBenito wrote:
> On Thu, 2009-11-12 at 17:09 -0500, Daniel J Walsh wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F12/system_init.patch
>>
>> Fix labels
>>
>> Add policy to make upstart->daemon work, in addition to
>> upstart->initrc_t->daemon
> 
> This needs to go in a init_upstart tunable block.
> 
> initrc_tmp_t blk_files and chr_files needs explanation, otherwise its
> completely unacceptable.
>
I believe this has to do with initrc running mkinitd at some point.  Since we don't do this anymore, I guess we can leave it off.


 
> It looks like your patch reverses some upstream changes. eg:
> 
> +fs_register_binary_executable_type(initrc_t)
> +# rhgb-console writes to ramfs
> +fs_write_ramfs_pipes(initrc_t)
> +# cjp: not sure why these are here; should use mount policy
> +fs_mount_all_fs(initrc_t)
> +fs_unmount_all_fs(initrc_t)
> +fs_remount_all_fs(initrc_t)
> +fs_getattr_all_fs(initrc_t)
> +fs_search_all(initrc_t)
> +fs_getattr_nfsd_files(initrc_t)
> 
> then later:
> 
> -fs_register_binary_executable_type(initrc_t)
> -# rhgb-console writes to ramfs
> -fs_write_ramfs_pipes(initrc_t)
> -# cjp: not sure why these are here; should use mount policy
> -fs_mount_all_fs(initrc_t)
> -fs_unmount_all_fs(initrc_t)
> -fs_remount_all_fs(initrc_t)
> -fs_getattr_all_fs(initrc_t)
> 

I will fix this.

[refpolicy] system_init.patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://people.fedoraproject.org/~dwalsh/SELinux/F14/system_init.patch

systemd changes galore.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx2+aoACgkQrlYvE4MpobOgMwCfZb5sitRFbioCxm5hZQzk7P+7
z/EAoJ1xplYAxo3hE1TumvFzIalPsRuE
=Vvkz
-----END PGP SIGNATURE-----

[refpolicy] system_init.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F13/system_init.patch

Lots of changes to init.

Biggest change is handling of inherited fifo_file

domaina -> initrc_t -> domainb
Ends up with allow domainb domaina:fifo_file rw_inherited_fifo_file_perms;

Doing this with
+               attribute initrc_transition_domain;

[refpolicy] system_init.patch

[Christopher J. PeBenito]

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, and
init scripts should be configured by admins, so transitioning to init
script domains to configure init scripts seems wrong.

Fixed dontaudit_init_read_all_script_files() interface name to
init_dontaudit_read_all_script_files().

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?

Why does initrc need to delete /dev/null?

Why does initrc need to transition to passwd?

Dropped the init_upstart addition in init_daemon_domain() as it causes
duplicate type transition errors.

Why would we want to allow signal inheritance?

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

[refpolicy] system_init.patch

[Daniel J Walsh]

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

[refpolicy] system_init.patch

[Christopher J. PeBenito]

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

[refpolicy] system_init.patch

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

[refpolicy] system_init.patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://people.fedoraproject.org/~dwalsh/SELinux/F10/system_init.patch

label all /etc/rc\.d/rc\.[^/]+  as initrc_exec_t

system-config-services uses dbus to start and stop services via
+/usr/share/system-config-services/system-config-services-mechanism\.py
 --

So this needs to be labeled an initrc_script_t script


init_spec_domtrans_script and init_domtrans_script need to use all init
scripts not just the ones labeled initrc_exec_t.

dbus can be used to start any binary, so added init_bin_domtrans_spec to
transition bin_t to initrc_t, via dbus.

init_script_role_transition is used by unconifned_t to transion
initsscripts to system_r when the user executes an initrc_t script.

upstart has dbus capabilities.

init needs to list inotify

init communicates with initrc_t via stream sockets

init calls setsched

initrc_t under mls can call runuser which attempts to send and audit message

initrc_ needs to be able to talk to /dev/initctrl

initscripts create links in /var/run


initrc talks to lvm_control

initrc_t can chat with consolekit

Lots of dontaudit commands to quiet init scripts using passwd file
descriptors



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjamBkACgkQrlYvE4MpobOp+wCguq2QiyAbtI3KcGOfBmO0lHGh
Q2UAoItsiOAlq7nd470Ub3nL9XpGayVu
=4Y96
-----END PGP SIGNATURE-----