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. :-)
Thanks.
> In a given environment, you may choose to run X or Postgres entirely
> within a single context (not allowing connections from other contexts)
> and not require object manager functionality within it, while still
> wanting the kernel's controls.
>
>>
>>> --------------------------------------------
>>> Subject: Re: [HACKERS] [0/4] Proposal of SE-PostgreSQL patches
>>>
>>> Dawid Kuroczko wrote:
>>> > On Wed, May 7, 2008 at 7:52 AM, KaiGai Kohei <kaigai@xxxxxxxxxxxxx> wrote:
>>> >> Tom, Thanks for your reviewing.
>>> >>> The patch hasn't got a mode in which SELinux support is compiled in but
>>> >>> not active. This is a good way to ensure that no one will ever ship
>>> >>> standard RPMs with the feature compiled in, because they will be entirely
>>> >>> nonfunctional for people who aren't interested in setting up SELinux.
>>> >>> I think you need an "enable_sepostgres" GUC, or something like that.
>>> >>> (Of course, the overhead of the per-row security column would probably
>>> >>> discourage anyone from wanting to use such a configuration anyway,
>>> >>> so maybe the point is moot.)
>>> >> We can turn on/off SELinux globally, not bounded to SE-PostgreSQL.
>>> >> The reason why I didn't provide a mode bit like "enable_sepostgresql"
>>> >> is to keep consistency in system configuration.
>>> >
>>> > Hmm, I think ACE should be a CREATE DATABASE parameter.
>>> >
>>> > If I were to create a SE-database I would wish that disabling it was
>>> > more difficult than changing a GUC in database. And being able to
>>> > set it on per-database basis would help get SE/ACE enabled by
>>> > packagers.
>>> >
>>> > Regards,
>>> > Dawid
>>> --------------------------------------------
>>>
>>> Thanks,
>>>
>>>
>>>>> However, I am a little unclear on how runtime setenforce calls should
>>>>> be dealt with. The way it currently works is if the userspace object
>>>>> manager is initialized without an enforcing mode specified in the call
>>>>> to avc_open(), it will track the system setting and conform to netlink
>>>>> "setenforce" messages. However, if avc_open() is called with an
>>>>> enforcing mode specified, it will stay in that mode and not respond to
>>>>> the netlink messages. Users might thus be confused if they issue a
>>>>> "setenforce 0" and the X server stays in enforcing mode because it was
>>>>> specified that way in the config file. But I'm of the opinion that
>>>>> runtime setenforcing is an abnormal event, and anyone who edits the
>>>>> config file away from "default" and then runs setenforce will
>>>>> understand how it works.
>>>>>
>>>
>>
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
