From: Paul Moore <paul@paul-moore.com>
To: Kees Cook <keescook@chromium.org>
Cc: libseccomp-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Will Drewry <wad@chromium.org>
Subject: Re: ANN: libseccomp
Date: Mon, 09 Apr 2012 17:32:57 -0400 [thread overview]
Message-ID: <1580647.pAHyaBF6MS@sifl> (raw)
In-Reply-To: <CAGXu5jL5nAY4=5OKhA6VPdrzkUjVuBTcLQuMxUSEv_=N=ohbzQ@mail.gmail.com>
On Monday, April 09, 2012 12:16:30 PM Kees Cook wrote:
> On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <paul@paul-moore.com> wrote:
> > With the seccomp patches finally stabilizing a bit, it seems like now is a
> > good time to announce libseccomp: a library designed to make it easier to
> > create complex, architecture independent seccomp filters.
> >
> > * http://sourceforge.net/projects/libseccomp/
> > * git clone git://git.code.sf.net/p/libseccomp/libseccomp
>
> This looks really great; nice work!
Thanks.
> I see that the arch check happens during _gen_bpf_build_bpf(), which
> is excellent. Do you have any thoughts about including a call to
> prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) by default as well?
That is a good question, and I guess it comes down to another question of if
anyone would want to use seccomp without NO_NEW_PRIVS. If the answer is no
then I'm comfortable adding it into the seccomp_load() function; however, if
the answer is yes we might want to do something different.
I haven't given much thought to this yet, so if you or anyone else feels
strongly about the issue - either pro or con - I'd appreciate hearing the
argument.
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2012-04-09 21:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-09 18:58 ANN: libseccomp Paul Moore
2012-04-09 19:16 ` Kees Cook
2012-04-09 21:32 ` Paul Moore [this message]
2012-04-09 21:51 ` Will Drewry
2012-04-09 22:46 ` Paul Moore
2012-04-13 20:14 ` Paul Moore
2012-04-14 2:47 ` Henrique de Moraes Holschuh
2012-04-16 14:15 ` [libseccomp-discuss] " Paul Moore
2012-04-09 22:56 ` Serge Hallyn
2012-04-09 19:25 ` Josh Boyer
2012-04-09 20:02 ` H. Peter Anvin
2012-04-09 20:14 ` Josh Boyer
2012-04-09 21:28 ` Paul Moore
2012-04-10 20:29 ` Paul Moore
2012-04-11 0:27 ` Josh Boyer
[not found] ` <CAEXv5_jiZsd6t=H1KWMNhUdgMez0B-WdC5XAHzdHffjOQh_J4A@mail.gmail.com>
2012-04-15 16:20 ` Kees Cook
2012-04-16 14:09 ` [libseccomp-discuss] " Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1580647.pAHyaBF6MS@sifl \
--to=paul@paul-moore.com \
--cc=keescook@chromium.org \
--cc=libseccomp-discuss@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.