linux-kernel - Re: ANN: libseccomp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABqD9haXLBDxEkC3+3AN4d4PDVYE-JrqH4P6iTJ95mqYxoR=yA@mail.gmail.com>
Date:	Mon, 9 Apr 2012 16:51:30 -0500
From:	Will Drewry <wad@...omium.org>
To:	Paul Moore <paul@...l-moore.com>
Cc:	Kees Cook <keescook@...omium.org>,
	libseccomp-discuss@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: ANN: libseccomp

On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <paul@...l-moore.com> wrote:
> On Monday, April 09, 2012 12:16:30 PM Kees Cook wrote:
>> On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <paul@...l-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!

Agreed -- this is great to see!

>> 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.

I guess the question is if there is an expectation that this library
be used with something like lxc, where a whole, functional system with
suid/fcaps binaries is contained.  In that world, it may not be
desirable to set the nnp bit.   The same is true if, for some reason,
the init task was to set a system-wide filter.

Most likely, default use of nnp is probably "the right thing", but
it'd be nice to be able to annotate when you really want to allow
privileged contexts to set filters without nnp.

thanks!
will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/