Re: add a MAC check for TRUNCATE

From: Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Mike P <mike(dot)palmiotto(at)crunchydata(dot)com>, Joe Conway <joe(at)crunchydata(dot)com>
Subject: Re: add a MAC check for TRUNCATE
Date: 2019-09-06 18:13:01
Message-ID: CAFL5wJfshrxBTQ2ZxKqa=AAsaiMiWX84Z_cTa-c_uLsypE8w=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

As Joe Conway pointed out to me out of band, the build animal for RHEL
7 has handle_unknown set to `0`. Are there any other concerns with
this approach?

On Fri, Sep 6, 2019 at 1:00 PM Yuli Khodorkovskiy
<yuli(dot)khodorkovskiy(at)crunchydata(dot)com> wrote:
>
> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > >> Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-09-06 18:18:13 Re: add a MAC check for TRUNCATE
Previous Message Tom Lane 2019-09-06 18:11:12 Re: SQL-spec incompatibilities in similar_escape() and related stuff