On Tue, Jan 7, 2020 at 12:56 PM Tomas Vondra
wrote:
> I think the "hook issue" is that the actual code is somewhere else. On
> the one hand that minimizes the dev/testing/maintenance burden for us,
> on the other hand it means we're not really testing the hooks. Meh.
I don't care about the testin
On Tue, Jan 07, 2020 at 11:33:07AM -0500, Robert Haas wrote:
On Tue, Jan 7, 2020 at 7:59 AM Tomas Vondra
wrote:
Barring objections, I'll mark it as rejected.
I think that's right.
Done.
Since I just caught up on this thread, I'd like to offer a few belated
comments:
1. I don't think it w
On Tue, Jan 7, 2020 at 7:59 AM Tomas Vondra
wrote:
> Barring objections, I'll mark it as rejected.
I think that's right. Since I just caught up on this thread, I'd like
to offer a few belated comments:
1. I don't think it would kill us to add a few hooks that would allow
this feature to be added
On Tue, Jan 07, 2020 at 06:02:14AM -0500, Joe Conway wrote:
On 1/6/20 8:37 PM, Tomas Vondra wrote:
Hi,
This patch is currently in "needs review" state, but the last message is
from August 29, and my understanding is that there have been a couple of
objections / disagreements about the architect
On 1/6/20 8:37 PM, Tomas Vondra wrote:
> Hi,
>
> This patch is currently in "needs review" state, but the last message is
> from August 29, and my understanding is that there have been a couple of
> objections / disagreements about the architecture, difficulties with
> producing the set of syscall
Hi,
This patch is currently in "needs review" state, but the last message is
from August 29, and my understanding is that there have been a couple of
objections / disagreements about the architecture, difficulties with
producing the set of syscalls, and not providing any built-in policy.
I don't
On 8/29/19 10:00 AM, Tom Lane wrote:
> Joe Conway writes:
>> Clearly Joshua and I disagree, but understand that the consensus is not
>> on our side. It is our assessment that PostgreSQL will be subject to
>> seccomp willingly or not (e.g., via docker, systemd, etc.) and the
>> community might be b
On Thu, Aug 29, 2019 at 10:01 AM Tom Lane wrote:
>
> Joe Conway writes:
> > Clearly Joshua and I disagree, but understand that the consensus is not
> > on our side. It is our assessment that PostgreSQL will be subject to
> > seccomp willingly or not (e.g., via docker, systemd, etc.) and the
> > c
Joe Conway writes:
> Clearly Joshua and I disagree, but understand that the consensus is not
> on our side. It is our assessment that PostgreSQL will be subject to
> seccomp willingly or not (e.g., via docker, systemd, etc.) and the
> community might be better served to get out in front and have f
On 8/28/19 4:07 PM, Peter Eisentraut wrote:
> On 2019-08-28 21:38, Joshua Brindle wrote:
>> 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
>
> Features come with a maintenance cost. If we s
On 2019-Aug-28, Joshua Brindle wrote:
> 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.
My own o
On Thu, Aug 29, 2019 at 7:08 AM Joshua Brindle
wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Andres Freund 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)
On 2019-08-28 21:38, Joshua Brindle wrote:
> 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
Features come with a maintenance cost. If we ship it, then people are
going to try it out. Then we
Hi,
On 2019-08-28 15:38:11 -0400, Joshua Brindle wrote:
> It seems like complete system compromises should be prioritized over
> slowdowns, and it seems very unlikely to cause a noticeable slowdown
> anyway.
The point isn't really this specific issue, but that the argument that
you'll not cause p
On Wed, Aug 28, 2019 at 3:22 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
> > > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > > A prime example is madvise() which was a catastrophic fai
Hi,
On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Andres Freund 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,
Andres Freund writes:
> 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
On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
>
> Hi,
>
> 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 candida
Andres Freund writes:
> On 2019-08-28 14:30:20 -0400, Tom Lane wrote:
>> Admittedly, you can't get per-subprocess restrictions that way, but the
>> incremental value from that seems *really* tiny. If listen() has a bug
>> you need to fix the bug, not invent this amount of rickety infrastructure
>
On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
>
>
> (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
Just going to address this one now. SELinux is an LSM and therefore
only makes decisions when LSM hooks are invoked, which are not 1:1 for
syscalls (not even close). F
Hi,
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-ve
On Wed, Aug 28, 2019 at 2:47 PM Joshua Brindle
wrote:
>
> On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
> >
>
> >
> > (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
>
> Just going to address this one now. SELinux is an LSM and therefore
> only makes decisions when L
On 2019-08-28 14:30:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Maybe I'm missing something, but it's not clear to me what meaningful
> > attack surface can be reduced for PostgreSQL by forbidding certain
> > syscalls, given the wide variety of syscalls required to run postgres.
>
> I t
Hi,
On 2019-08-28 14:23:00 -0400, Joshua Brindle wrote:
> > or some similar technology where the filtering is done by logic
> > that's outside the executable you wish to not trust.
> > (After googling for libseccomp, I see that it's supposed to not
> > allow syscalls to be turned back on once turn
Andres Freund writes:
> Maybe I'm missing something, but it's not clear to me what meaningful
> attack surface can be reduced for PostgreSQL by forbidding certain
> syscalls, given the wide variety of syscalls required to run postgres.
I think the idea is to block access to seldom-used syscalls b
On Wed, Aug 28, 2019 at 1:42 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 2019-08-28 17:13, Joe Conway wrote:
> >> Attached is a patch for discussion, adding support for seccomp-bpf
> >> (nowadays generally just called seccomp) syscall filtering at
> >> configure-time using libseccomp.
Hi,
On 2019-08-28 13:28:06 -0400, Joe Conway wrote:
> > To compute the initial set of allowed system calls, you need to have
> > fantastic test coverage. What you don't want is some rarely used error
> > recovery path to cause a system crash. I wouldn't trust our current
> > coverage for this.
Hi,
On 2019-08-28 11:13:27 -0400, Joe Conway wrote:
> Recent security best-practices recommend, and certain highly
> security-conscious organizations are beginning to require, that SECCOMP
> be used to the extent possible. The major web browsers, container
> runtime engines, and systemd are all ex
Peter Eisentraut writes:
> On 2019-08-28 17:13, Joe Conway wrote:
>> Attached is a patch for discussion, adding support for seccomp-bpf
>> (nowadays generally just called seccomp) syscall filtering at
>> configure-time using libseccomp. I would like to get this in shape to be
>> committed by the e
On 8/28/19 12:47 PM, David Fetter wrote:
> On Wed, Aug 28, 2019 at 11:13:27AM -0400, Joe Conway wrote:
>> SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall
>> filtering mechanism which allows reduction of the kernel attack surface
>> by preventing (or at least audit logging) norma
On 8/28/19 1:03 PM, Peter Eisentraut wrote:
> On 2019-08-28 17:13, Joe Conway wrote:
>> * systemd does not implement seccomp filters by default. Packagers may
>> decide to do so, but there is no guarantee. Adding them post install
>> potentially requires cooperation by groups outside control of
On 2019-08-28 17:13, Joe Conway wrote:
> * systemd does not implement seccomp filters by default. Packagers may
> decide to do so, but there is no guarantee. Adding them post install
> potentially requires cooperation by groups outside control of
> the database admins.
Well, if we are intere
On Wed, Aug 28, 2019 at 11:13:27AM -0400, Joe Conway wrote:
> SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall
> filtering mechanism which allows reduction of the kernel attack surface
> by preventing (or at least audit logging) normally unused syscalls.
>
> Quoting from this li
SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall
filtering mechanism which allows reduction of the kernel attack surface
by preventing (or at least audit logging) normally unused syscalls.
Quoting from this link:
https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
34 matches
Mail list logo
