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