Re: RFC: Per-object manager controls in /selinux/config

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

Stephen Smalley wrote:
> On Fri, 2008-06-06 at 15:13 +0900, KaiGai Kohei wrote:
>> Stephen Smalley wrote:
>>> On Thu, 2008-06-05 at 15:12 -0400, Eamon Walsh wrote:
>>>> KaiGai Kohei wrote:
>>>>> KaiGai Kohei wrote:
>>>>>   
>>>>>> Eamon Walsh wrote:
>>>>>>     
>>>>>>> I am proposing adding a separate config line for each userspace object 
>>>>>>> manager, as follows:
>>>>>>>
>>>>>>> #    permissive - SELinux prints warnings instead of enforcing.
>>>>>>> #    disabled - SELinux is fully disabled.
>>>>>>> SELINUX=enforcing
>>>>>>> +
>>>>>>> +# SELINUX_MANAGER= can take one of these four values
>>>>>>> +#    enforcing - SELinux security policy is enforced by this object 
>>>>>>> manager.
>>>>>>> +#    permissive - The object manager prints warnings instead of 
>>>>>>> enforcing.
>>>>>>> +#    disabled - SELinux is fully disabled by this object manager.
>>>>>>> +#    default - The object manager will track the system setting.
>>>>>>> +SELINUX_DBUS=default
>>>>>>> +SELINUX_XSERVER=permissive
>>>>>>> +
>>>>>>> # SELINUXTYPE= type of policy in use. Possible values are:
>>>>>>> #    targeted - Only targeted network daemons are protected.
>>>>>>> #    strict - Full SELinux protection.
>>>>>>>       
>>>>>> Eamon,
>>>>>>
>>>>>> Could you tell me the purpose of this new feature?
>>>>>>
>>>>>> It seems to me this new feature prevents to keep consistency of
>>>>>> the SELinux state. I think the internal state of userspace object
>>>>>> managers should be just a copy from the in-kernel reference monitor...
>>>>>>
>>>>>> Thanks,
>>>>>>     
>>>>> In the previous discussion, I told as above.
>>>>>
>>>>> However, some people in pgsql-hackers suggested me a facility to turn on/off
>>>>> MAC within SE-PostgreSQL. It seems to me they want to deliver a original
>>>>> PostgreSQL and SE- version's one within a single package.
>>>>> What is the best answer for this issue?
>>>>>
>>>>> In my opinion, this kind of configuration should be managed globally in system,
>>>>> because it enables to guarantee the consistency of access controls.
>>>>> In addition, a "policy-free" storage created by unauthorized users makes
>>>>> a loophole of data-flow-control scheme.
>>>>> But I can also understand their demands to avoid shipping two similar packages,...
>>>>>   
>>>> Based on the earlier feedback provided by you and Josh, I figured that 
>>>> my proposal had been NAK'ed.  Since that time, the Xorg server has been 
>>>> patched to support a configuration file option to set 
>>>> enabled/disabled/permissive. 
>>>>
>>>> I would be glad to reopen the discussion though, if you've changed your 
>>>> mind. 
>>> I think a config option in the configuration file for the individual
>>> object manager is reasonable, with the default behavior being to track
>>> the kernel's setting.  For Xorg, we can disable just the XSELinux
>>> extension or make it permissive via xorg.conf while retaining the
>>> kernel's controls.  For PostgreSQL, I think we'd want a similar setting
>>> in its config file, whatever that might be, as long as the config file
>>> is administratively controlled.
>> Indeed, the configuration file of postgresql is labeled as postgresql_db_t
>> and it should not be modified without proper permission allowed by the policy.
>> I basically agree for your opinion.
>>
>> However, I have one unclear point of view.
>>
>> These configuration files have different security context.
>> It theoretically means different person can change the partial state.
>>
>> [root@saba ~]# ls -Z /etc/selinux/config    /etc/X11/xorg.conf  \
>>                      /var/lib/sepgsql/data/postgresql.conf
>> -rw-r--r--  root    root    system_u:object_r:selinux_config_t     /etc/selinux/config
>> -rw-r--r--  root    root    unconfined_u:object_r:etc_t            /etc/X11/xorg.conf
>> -rw-------  sepgsql sepgsql unconfined_u:object_r:postgresql_db_t  /var/lib/sepgsql/data/postgresql.conf
>>
>> I think /etc/selinux/config is better place to put these configuration
>> than /etc/X11/xorg.conf and $PGDATA/postgresql.conf
>>
>> What do you think?
>>
>> # No need to say, if a malicious user can access files labeled as postgresql_db_t,
>> # he don't need to access information stored within them via SQL. :-)
> 
> That is Eamon's view.  I'm not as clear on it.  As you note, if the
> process can directly access the raw data files, then whether or not the
> sepostgres controls are enforced on SQL queries is immaterial.  Also,
> suppose that you want to run multiple instances of postgres, where some
> instances are run single-context/level and thus do not need to act as
> object managers internally and some instances are run
> multi-context/level and do need to act as object managers internally.

Oh, I've left the case of multiple postgresql instances out of
my consideration. Indeed, the global /etc/selinux/config approach
cannot support such a situation.

Your explanation helps me to convince enough. In my current directionality,
it is the best way to add a mode parameter to turn on/off SE-PostgreSQL
feature within the postgresql configuration.

Thanks,

> The /etc/selinux/config approach doesn't seem to scale well and requires
> teaching libselinux about each new userspace object manager as they are
> introduced (which used to be true for the class and permission
> definitions, but is no longer the case due to the dynamic object class
> and permission discovery support).
> 
> Also, to fill out the picture, you also have to consider the security
> context on grub.conf and even the ability to enter kernel boot
> parameters interactively, as those can override the /etc/selinux/config
> settings.  The /etc/selinux/config SELINUX= setting was only introduced
> because of the alleged difficulty in changing kernel boot parameters on
> some platforms.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.