On Wed, Aug 28, 2019 at 3:22 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund <andres@anarazel.de> wrote:
> > > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > > A prime example is madvise() which was a catastrophic failure that 1)
> > > > isn't preventable by any LSM including SELinux, 2) isn't used by PG
> > > > and is therefore a good candidate for a kill list, and 3) a clear win
> > > > in the dont-let-PG-be-a-vector-for-kernel-compromise arena.
> > >
> > > IIRC it's used by glibc as part of its malloc implementation (also
> > > threading etc) - but not necessarily hit during the most common
> > > paths. That's *precisely* my problem with this approach.
> > >
> >
> > As long as glibc handles a returned error cleanly the syscall could be
> > denied without harming the process and the bug would be mitigated.
>
> And we'd hit mysterious slowdowns in production uses of PG when seccomp
> is enabled.
It seems like complete system compromises should be prioritized over
slowdowns, and it seems very unlikely to cause a noticeable slowdown
anyway. Are there PG users that backed out all of the Linux KPTI
patches due to the slowdown?
I think we need to reign in the thread somewhat. The feature allows
end users to define some sandboxing within PG. Nothing is being forced
on anyone but we would like the capability to harden a PG installation
for many reasons already stated. This is being done in places all
across the Linux ecosystem and is IMO a very useful mitigation.
Thank you.