KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> Joshua D. Drake wrote:
>> I just did a little research and it appears the other two big names in
>> this world (Novel and Ubuntu) are using something called App Armor.

> As far as I can see, SUSE, Ubuntu and Debian provide SELinux option.
> But they are more conservative than RedHat/Fedora, because it is not
> enabled in the default installation.

> I don't think it is unpreferable decision. Users can choose the option
> by themself according to requirements in the system.

Based on Red Hat's experience, it is a safe bet that not enabling
SELinux by default guarantees the feature will remain useless to the
average user.  As was pointed out upthread (and I can confirm from
personal experience), it's taken *years* for Red Hat to develop the
security policy to a point where it's even marginally usable by anyone
who isn't willing to put up with a great deal of annoyance because they
have an extreme need.  And that's despite having a well-defined, not too
ambitious goal for what it is they are trying to secure: for the most
part, RH's default policy doesn't try to lock down anything except
network-accessible services.  SUSE and the rest of them may "have the
feature", but they don't have it in a usable form, and won't ever have
it without a much larger effort than they're making.

Even if we were to accept the SEPostgres patches lock stock and barrel
tomorrow, I don't foresee that it will ever get to the point of being
useful except to an extremely small group of users who are driven by
extreme need.  Nobody else is going to have the motivation needed to
develop custom security policies, and there simply isn't any chance
of anyone developing any generally useful default policy.  Red Hat's
policy has been trying to cope with cases like "which directories should
Apache be allowed to read, *given that it's running a Red-Hat-standard
configuration*?"  That's far more circumscribed than any useful database
policy would be, because database applications aren't nearly that
standardized.

If SEPostgres were a small patch that wouldn't need much ongoing effort,
I might think it's reasonable to adopt it for the benefit of only a small
group of users.  However, it's not small, it's not simple, and it will
not be low-maintenance.  I'm afraid the cost-benefit ratio from the
project's perspective is just not reasonable.

			regards, tom lane

In response to

• Re: SE-PgSQL patch review at 2009-12-02 02:07:19 from KaiGai Kohei

Responses

• Re: SE-PgSQL patch review at 2009-12-02 05:11:22 from KaiGai Kohei
• Adding support for SE-Linux security at 2009-12-02 16:16:24 from Bruce Momjian
• Re: SE-PgSQL patch review at 2009-12-02 23:05:51 from Greg Stark

pgsql-hackers by date

Next:	From: Bruce Momjian	Date: 2009-12-02 03:34:11
	Subject: Re: Page-level version upgrade (was: Block-level CRC checks)
Previous:	From: Robert Haas	Date: 2009-12-02 03:21:41
	Subject: Re: Page-level version upgrade (was: Block-level CRC checks)