Re: add a MAC check for TRUNCATE

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