Re: add a MAC check for TRUNCATE

On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Greetings,
>
> * Kohei KaiGai (kaigai(at)heterodb(dot)com) wrote:
> > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>:
> > > Since all DAC checks should have corresponding MAC, this patch adds a
> > > hook to allow extensions to implement a MAC check on TRUNCATE. I have
> > > also implemented this access check in the sepgsql extension.
> > >
> > > One important thing to note is that refpolicy [1] and Redhat based
> > > distributions do not have the SELinux permission for db_table {truncate}
> > > implemented.
> > >
> > How db_table:{delete} permission is different from truncate?
> > >From the standpoint of data access, TRUNCATE is equivalent to DELETE
> > without WHERE, isn't it?
> > Of course, there are some differences between them. TRUNCATE takes
> > exclusive locks and eliminates underlying data blocks, on the other hands,
> > DELETE removes rows under MVCC manner. However, both of them
> > eventually removes data from the target table.
> >
> > I like to recommend to reuse "db_table:{delete}" permission for TRUNCATE.
> > How about your opinions?
>
> There's been much discussion and justifcation for adding an independent
> TRUNCATE privilege to GRANT (which actually took many years to be
> allowed). I don't see why we wouldn't represent that as a different
> privilege to external MAC systems. If the external MAC system wishes to
> use db_table:{delete} to decide if the privilege is allowed or not, they
> can, but I don't think core should force that when we have them as
> independent permissions.
>
> So, perhaps we can argue about what the sepgsql extension should do, but
> it's clear that we should have an independent hook for this in core.
>
> Isn't there a way to allow an admin to control if db_table:{truncate} is
> allowed for users with db_table:{delete}, or not? Ideally, this could
> be managed at the SELinux level instead of having to have something
> different in sepgsql or core, but if it needs to be configurable there
> too then hopefully we can come up with a good solution.

If I understand you correctly, you are asking if an SELinux domain can
have the db_table:{truncate} permission but not db_table:{delete}
using SELinux policy? This would only work if the userspace object
manager, sepgsql in this case, reaches out to the policy server to
check if db_table:{truncate} is allowed for a subject accessing an
object.

I think it should be okay to use db_table:{delete} as the permission
to check for TRUNCATE in the object manager. I have attached a second
version of the hook and sepgsql changes to demonstrate this.

Thank you.

>
> Thanks,
>
> Stephen