On Tue, 2016-01-19 at 10:16 +0100, Nikos Mavrogiannopoulos wrote:
> The issue is that blacklists are terrible from a security standpoint.
> That means that every new obscure system call added to the kernel
> will
> be available by default in your program.
Yes. This implies that seccomp should not
On Tue, 2016-01-19 at 08:08 -0800, Andrew Lutomirski wrote:
> One of these days I need to tidy up Sandstorm's seccomp policy and
> factor
> it into its own library. It's made a good showing for itself over
> the last
> year or so, and it's highly compatible.
I would be quite interested in this!
On Tue, Jan 19, 2016, at 11:08 AM, Andrew Lutomirski wrote:
>
>
On Jan 19, 2016 7:41 AM, "Colin Walters" wrote:
>
>
>
>
>
>
>
> On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote:
>
>
>
> > The issue is that blacklists are terrible from a security
> > standpoint.
>
> > That means tha
On Jan 19, 2016 7:41 AM, "Colin Walters" wrote:
>
>
>
> On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote:
>
> > The issue is that blacklists are terrible from a security standpoint.
> > That means that every new obscure system call added to the kernel will
> > be available by defau
On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote:
> The issue is that blacklists are terrible from a security standpoint.
> That means that every new obscure system call added to the kernel will
> be available by default in your program.
https://github.com/seccomp/libseccomp/iss
