linux-kernel - Re: [libseccomp-discuss] 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]

Date:	Mon, 9 Apr 2012 17:56:25 -0500
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	Will Drewry <wad@...omium.org>
Cc:	Paul Moore <paul@...l-moore.com>,
	linux-security-module@...r.kernel.org,
	libseccomp-discuss@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [libseccomp-discuss] ANN: libseccomp

Quoting Will Drewry (wad@...omium.org):
> 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.

Right, check out Eric's posting of v24 of userns yesterday.  lxc will
be fine with no new privileges in the parent user ns, but in its
child user ns it will definately want to be free to do what it likes
with userids and capabilities.

-serge
--
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/