Adding support for SE-Linux security - Mailing list pgsql-hackers

[ Updated subject ]

We have been discussing support for SE-Linux for over a year and now
have a minimal patch submitted that maps SE-Linux permissions to
existing Postgres permissions:
patch:    http://momjian.us/tmp/sepgsql-01-lite-8.5devel-r2451.patchemail:
http://archives.postgresql.org/message-id/4B13856F.1090803@ak.jp.nec.com

That patch is the minimum required to support SE-Linux in some form. 
The majority of the patch is documentation, regression tests, small
catalog additions, and SE-Linux-specific C files.  It does add hooks
into the existing access permission functions.   There is no support for
row-level permissions or mandatory access control (MAC).  These were
removed to minimize code impact and might be added later.

Tom's email below highlights the lack of mainstream usage of SE-Linux
features, though it is supported by most Linux distributions. Tom's
opinion is adding support for a minimal set of SE-Linux security isn't
worth the code impact.

David Fetter felt SE-Linux was mostly a marketing/sales feature, rather
than something of general usefulness.  Others feel SE-Linux is valid for
limited use cases.

I understand SE-Linux to be like Kerberos --- Kerberos provides
single-signon site authentication, while SE-Linux provides single-signon
site security credentials.  While Kerberos is not useful for everyone,
SE-Linux similarly has limited adoption.  Kerberos has proven to be a
key technology for sites that need it, and SE-Linux might prove to be
similar.

If we decide not to support SE-Linux, it is unlikely we will be adding
support for any other external security systems because SE-Linux has the
widest adoption.

I think the big question is whether we are ready to extend Postgres to
support additional security infrastructures.

---------------------------------------------------------------------------

Tom Lane wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.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

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +