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. 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. > >>> > > > > > > -- Stephen Smalley National Security Agency -- 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.
