Re: add a MAC check for TRUNCATE - Mailing list pgsql-hackers

From Yuli Khodorkovskiy
Subject Re: add a MAC check for TRUNCATE
Date
Msg-id CAFL5wJcNYiHApkj0pn_VRvB1i00EsHi7HKzPg4RGosA-Mg7Ckg@mail.gmail.com
Whole thread Raw
In response to Re: add a MAC check for TRUNCATE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: add a MAC check for TRUNCATE
Re: add a MAC check for TRUNCATE
List pgsql-hackers
On Fri, Sep 6, 2019 at 11:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Yuli Khodorkovskiy <yuli.khodorkovskiy@crunchydata.com> writes:
> >>> 1) Get the sepgsql changes in without policy/regressions
> >>> 2) Send a patch to refpolicy for the new permission
> >>> 3) Once Redhat updates the selinux-policy-targeted RPM to include the
> >>> new permissions, I will send an update to the sepgsql regressions and
> >>> policy.
>
> >> That's going to be a problem.  I do not think it will be acceptable
> >> to commit tests that fail on less-than-bleeding-edge SELinux.
>
> > This is why I was suggesting up-thread that it'd be neat if we made this
> > somehow optional, though I don't quite see a way to do that sensibly.
> > We could though, of course, make running the regression test optional
> > and then have a buildfarm member that's got the bleeding-edge SELinux
> > (or is just configured with the additional control) and then have it
> > enabled there.
>
> Well, the larger question, independent of the regression tests, is
> will the new policy work at all on older SELinux?  If not, that
> doesn't seem very acceptable.  Worse, it implies we're going to
> have another flag day anytime we want to add any new element
> to sepgsql's view of the universe.  I think we need some hard
> thought about upgrade paths here --- at least, if we want to
> believe that sepgsql is anything but a toy for demonstration
> purposes.
>
>                         regards, tom lane

The default SELinux policy on Fedora ships with deny_unknown set to 0.
Deny_unknown was added to the kernel in 2.6.24, so unless someone is
using RHEL 5.x, which is in ELS, they will have the ability to
override the default behavior on CentOS/RHEL.

CIL was added to RHEL starting with RHEL 7. As stated before, an
integrator can export the base module and override the deny_unknown
behavior.

On RHEL 6, which goes into ELS in 2020, it's a bit more complicated
and requires rebuilding the base SELinux module from source.

Hope this helps,

Yuli



pgsql-hackers by date:

Previous
From: Alvaro Herrera from 2ndQuadrant
Date:
Subject: Re: Change atoi to strtol in same place
Next
From: Alvaro Herrera from 2ndQuadrant
Date:
Subject: Re: SQL-spec incompatibilities in similar_escape() and related stuff