Adding support for SE-Linux security

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, jd(at)commandprompt(dot)com, David Fetter <david(at)fetter(dot)org>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Adding support for SE-Linux security
Date: 2009-12-02 16:16:24
Message-ID: 200912021616.nB2GGOP24071@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.patch
email: 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(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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2009-12-02 16:23:18 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Previous Message Simon Riggs 2009-12-02 16:08:25 Re: Page-level version upgrade (was: Block-level CRC checks)