linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ANN: libseccomp
@ 2012-04-09 18:58 Paul Moore
  2012-04-09 19:16 ` Kees Cook
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Paul Moore @ 2012-04-09 18:58 UTC (permalink / raw)
  To: libseccomp-discuss, linux-kernel, linux-security-module
  Cc: Will Drewry, Kees Cook

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

The library has only been in development for the past couple months, so it may 
be a little rough around the edges, and definitely could use more testing, but 
it is functional and has had some basic testing against the seccomp v17 
patches.  The project currently lacks any online documentation or a website 
beyond the basic SF.net tools, but there are current man pages in the source 
repository and the code is reasonably well commented.

For those of you who are interested in making use of the library, or 
contributing to its development and testing, we do have a mailing list setup 
(see the To/CC line above) and you can subscribe at the link below; all are 
welcome.

 * https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss

To demonstrate some of the basic libseccomp capabilities, I've included a 
short example below.  The example is trivial, it opens /dev/zero and writes to 
/dev/null, but it shows how to use libseccomp to create a simple filter and 
load it into the kernel; filtering both on just the syscall and a syscall with 
specific arguments.

> #include <errno.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <unistd.h>
> 
> #include <seccomp.h>
> 
> #define BUF_LEN		256
> 
> int main(int argc, char *argv[])
> {
> 	int rc;
> 	FILE *read_stream, *write_stream;
> 	unsigned char buf[BUF_LEN];
> 	size_t op_len;
> 
> 	/* initialize the seccomp filter */
> 	printf("scmp: initializing the seccomp filter ...");
> 	rc = seccomp_init(SCMP_ACT_KILL);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	printf("ok\n");
> 
> 	/* do the setup */
> 	printf("info: opening /dev/zero for reading ... ");
> 	read_stream = fopen("/dev/zero", "r");
> 	if (read_stream == NULL)
> 		goto failure;
> 	printf("ok\n");
> 	printf("info: opening /dev/null for writing ... ");
> 	write_stream = fopen("/dev/null", "w");
> 	if (write_stream == NULL)
> 		goto failure;
> 	printf("ok\n");
> 
> 	/* configure the seccomp filter */
> 	printf("scmp: configuring the seccomp_filter ... ");
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(read), 1,
> 			      SCMP_A0(SCMP_CMP_EQ, fileno(read_stream)));
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
> 			      SCMP_A0(SCMP_CMP_EQ, STDOUT_FILENO));
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
> 			      SCMP_A0(SCMP_CMP_EQ, STDERR_FILENO));
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
> 			      SCMP_A0(SCMP_CMP_EQ, fileno(write_stream)));
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(close), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(ioctl), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(mprotect), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(munmap), 0);
> 	if (rc < 0)
> 		goto failure_scmp;
> 	printf("ok\n");
> 
> 	/* load the seccomp filter into the kernel */
> 	printf("scmp: load the filter ... ");
> 	rc = seccomp_load();
> 	if (rc < 0)
> 		goto failure_scmp;
> 	seccomp_release();
> 	printf("ok\n");
> 
> 	/* perform the i/o */
> 	printf("info: attempting to read BUF_LEN bytes ... ");
> 	op_len = fread(buf, BUF_LEN, 1, read_stream);
> 	if (op_len != 1)
> 		return errno;
> 	printf("ok\n");
> 
> 	printf("info: attempting to write BUF_LEN bytes ... ");
> 	op_len = fwrite(buf, BUF_LEN, 1, write_stream);
> 	if (op_len != 1)
> 		return errno;
> 	printf("ok\n");
> 
> 	/* shutdown */
> 	printf("info: closing file streams and exiting\n");
> 	fclose(write_stream);
> 	fclose(read_stream);
> 	return 0;
> 
> failure_scmp:
> 	errno = -rc;
> failure:
> 	/* oops ... */
> 	printf("failed, errno = %u\n", errno);
> 	return errno;
> }

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 18:58 ANN: libseccomp Paul Moore
@ 2012-04-09 19:16 ` Kees Cook
  2012-04-09 21:32   ` Paul Moore
  2012-04-09 19:25 ` Josh Boyer
       [not found] ` <CAEXv5_jiZsd6t=H1KWMNhUdgMez0B-WdC5XAHzdHffjOQh_J4A@mail.gmail.com>
  2 siblings, 1 reply; 17+ messages in thread
From: Kees Cook @ 2012-04-09 19:16 UTC (permalink / raw)
  To: Paul Moore
  Cc: libseccomp-discuss, linux-kernel, linux-security-module, Will Drewry

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!

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?

-Kees

-- 
Kees Cook
ChromeOS Security

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 18:58 ANN: libseccomp Paul Moore
  2012-04-09 19:16 ` Kees Cook
@ 2012-04-09 19:25 ` Josh Boyer
  2012-04-09 20:02   ` H. Peter Anvin
       [not found] ` <CAEXv5_jiZsd6t=H1KWMNhUdgMez0B-WdC5XAHzdHffjOQh_J4A@mail.gmail.com>
  2 siblings, 1 reply; 17+ messages in thread
From: Josh Boyer @ 2012-04-09 19:25 UTC (permalink / raw)
  To: Paul Moore
  Cc: libseccomp-discuss, linux-kernel, linux-security-module,
	Will Drewry, Kees Cook

On Mon, Apr 9, 2012 at 2:58 PM, 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
>
> The library has only been in development for the past couple months, so it may
> be a little rough around the edges, and definitely could use more testing, but
> it is functional and has had some basic testing against the seccomp v17
> patches.  The project currently lacks any online documentation or a website
> beyond the basic SF.net tools, but there are current man pages in the source
> repository and the code is reasonably well commented.

Do you think the GPLv2 license will limit adoption of it's usage across
a wider variety of software projects?  I'm not anti-GPL by any means
but I am slightly surprised libseccomp is using it.

josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 19:25 ` Josh Boyer
@ 2012-04-09 20:02   ` H. Peter Anvin
  2012-04-09 20:14     ` Josh Boyer
  0 siblings, 1 reply; 17+ messages in thread
From: H. Peter Anvin @ 2012-04-09 20:02 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Paul Moore, libseccomp-discuss, linux-kernel,
	linux-security-module, Will Drewry, Kees Cook

On 04/09/2012 12:25 PM, Josh Boyer wrote:
> 
> Do you think the GPLv2 license will limit adoption of it's usage across
> a wider variety of software projects?  I'm not anti-GPL by any means
> but I am slightly surprised libseccomp is using it.
> 
> josh

Yes, on the surface of it this would seem more like LGPL material.

Other than that, very much needed!

	-hpa


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 20:02   ` H. Peter Anvin
@ 2012-04-09 20:14     ` Josh Boyer
  2012-04-09 21:28       ` Paul Moore
  0 siblings, 1 reply; 17+ messages in thread
From: Josh Boyer @ 2012-04-09 20:14 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Paul Moore, libseccomp-discuss, linux-kernel,
	linux-security-module, Will Drewry, Kees Cook

On Mon, Apr 9, 2012 at 4:02 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/09/2012 12:25 PM, Josh Boyer wrote:
>>
>> Do you think the GPLv2 license will limit adoption of it's usage across
>> a wider variety of software projects?  I'm not anti-GPL by any means
>> but I am slightly surprised libseccomp is using it.
>>
>> josh
>
> Yes, on the surface of it this would seem more like LGPL material.
>
> Other than that, very much needed!

Agreed on both points.  I only brought this up now as it's very early
in the project's lifetime.  If a relicense were to happen it would be
better to do it before a larger number of developers started
contributing to the project.

josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 20:14     ` Josh Boyer
@ 2012-04-09 21:28       ` Paul Moore
  2012-04-10 20:29         ` Paul Moore
  0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2012-04-09 21:28 UTC (permalink / raw)
  To: Josh Boyer
  Cc: H. Peter Anvin, libseccomp-discuss, linux-kernel,
	linux-security-module, Will Drewry, Kees Cook

On Monday, April 09, 2012 04:14:15 PM Josh Boyer wrote:
> On Mon, Apr 9, 2012 at 4:02 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 04/09/2012 12:25 PM, Josh Boyer wrote:
> >> Do you think the GPLv2 license will limit adoption of it's usage across
> >> a wider variety of software projects?  I'm not anti-GPL by any means
> >> but I am slightly surprised libseccomp is using it.
> >> 
> >> josh
> > 
> > Yes, on the surface of it this would seem more like LGPL material.
> > 
> > Other than that, very much needed!
> 
> Agreed on both points.  I only brought this up now as it's very early
> in the project's lifetime.  If a relicense were to happen it would be
> better to do it before a larger number of developers started
> contributing to the project.

You both bring up a good point, the LGPL seems like a better choice.  I chose 
GPLv2 when I started simply out of habit; it is a license I am both familiar 
and comfortable with so it has a tendency to get used when I start a new chunk 
of code.

As you pointed out, the project is still very new with only a handful of 
authors beyond myself.  I'll get in touch with them privately to make sure 
they are comfortable with the relicense and assuming there are no problems 
I'll report back when everything has been changed.

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 19:16 ` Kees Cook
@ 2012-04-09 21:32   ` Paul Moore
  2012-04-09 21:51     ` Will Drewry
  0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2012-04-09 21:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: libseccomp-discuss, linux-kernel, linux-security-module, Will Drewry

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 21:32   ` Paul Moore
@ 2012-04-09 21:51     ` Will Drewry
  2012-04-09 22:46       ` Paul Moore
  2012-04-09 22:56       ` Serge Hallyn
  0 siblings, 2 replies; 17+ messages in thread
From: Will Drewry @ 2012-04-09 21:51 UTC (permalink / raw)
  To: Paul Moore
  Cc: Kees Cook, libseccomp-discuss, linux-kernel, linux-security-module

On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <paul@paul-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@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!

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 21:51     ` Will Drewry
@ 2012-04-09 22:46       ` Paul Moore
  2012-04-13 20:14         ` Paul Moore
  2012-04-09 22:56       ` Serge Hallyn
  1 sibling, 1 reply; 17+ messages in thread
From: Paul Moore @ 2012-04-09 22:46 UTC (permalink / raw)
  To: Will Drewry
  Cc: Kees Cook, libseccomp-discuss, linux-kernel, linux-security-module

On Monday, April 09, 2012 04:51:30 PM Will Drewry wrote:
> On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <paul@paul-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@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!
> 
> Agreed -- this is great to see!

Not as much as the actual kernel support :)

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

Okay, that seems reasonable: default to NO_NEW_PRIVS, but provide an override 
mechanism.

I've been wanting a mechanism/API for tweaking some of the default library 
parameters for the past few weeks, this is likely the last bit of motivation I 
need to start working on this.  I'll look into it once the license issue is 
sorted.

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [libseccomp-discuss] ANN: libseccomp
  2012-04-09 21:51     ` Will Drewry
  2012-04-09 22:46       ` Paul Moore
@ 2012-04-09 22:56       ` Serge Hallyn
  1 sibling, 0 replies; 17+ messages in thread
From: Serge Hallyn @ 2012-04-09 22:56 UTC (permalink / raw)
  To: Will Drewry
  Cc: Paul Moore, linux-security-module, libseccomp-discuss, linux-kernel

Quoting Will Drewry (wad@chromium.org):
> On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <paul@paul-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@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!
> 
> 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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 21:28       ` Paul Moore
@ 2012-04-10 20:29         ` Paul Moore
  2012-04-11  0:27           ` Josh Boyer
  0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2012-04-10 20:29 UTC (permalink / raw)
  To: Josh Boyer, H. Peter Anvin
  Cc: libseccomp-discuss, linux-kernel, linux-security-module,
	Will Drewry, Kees Cook

On Monday, April 09, 2012 05:28:41 PM Paul Moore wrote:
> On Monday, April 09, 2012 04:14:15 PM Josh Boyer wrote:
> > On Mon, Apr 9, 2012 at 4:02 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > > On 04/09/2012 12:25 PM, Josh Boyer wrote:
> > >> Do you think the GPLv2 license will limit adoption of it's usage across
> > >> a wider variety of software projects?  I'm not anti-GPL by any means
> > >> but I am slightly surprised libseccomp is using it.
> > >> 
> > >> josh
> > > 
> > > Yes, on the surface of it this would seem more like LGPL material.
> > > 
> > > Other than that, very much needed!
> > 
> > Agreed on both points.  I only brought this up now as it's very early
> > in the project's lifetime.  If a relicense were to happen it would be
> > better to do it before a larger number of developers started
> > contributing to the project.
> 
> You both bring up a good point, the LGPL seems like a better choice.  I
> chose GPLv2 when I started simply out of habit; it is a license I am both
> familiar and comfortable with so it has a tendency to get used when I start
> a new chunk of code.
> 
> As you pointed out, the project is still very new with only a handful of
> authors beyond myself.  I'll get in touch with them privately to make sure
> they are comfortable with the relicense and assuming there are no problems
> I'll report back when everything has been changed.

Just an update, the project has just been relicensed under the LGPLv2.1 
license.

-- 
paul moore
security and virtualization @ redhat


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-10 20:29         ` Paul Moore
@ 2012-04-11  0:27           ` Josh Boyer
  0 siblings, 0 replies; 17+ messages in thread
From: Josh Boyer @ 2012-04-11  0:27 UTC (permalink / raw)
  To: Paul Moore
  Cc: H. Peter Anvin, libseccomp-discuss, linux-kernel,
	linux-security-module, Will Drewry, Kees Cook

On Tue, Apr 10, 2012 at 4:29 PM, Paul Moore <pmoore@redhat.com> wrote:
> On Monday, April 09, 2012 05:28:41 PM Paul Moore wrote:
>> On Monday, April 09, 2012 04:14:15 PM Josh Boyer wrote:
>> > On Mon, Apr 9, 2012 at 4:02 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> > > On 04/09/2012 12:25 PM, Josh Boyer wrote:
>> > >> Do you think the GPLv2 license will limit adoption of it's usage across
>> > >> a wider variety of software projects?  I'm not anti-GPL by any means
>> > >> but I am slightly surprised libseccomp is using it.
>> > >>
>> > >> josh
>> > >
>> > > Yes, on the surface of it this would seem more like LGPL material.
>> > >
>> > > Other than that, very much needed!
>> >
>> > Agreed on both points.  I only brought this up now as it's very early
>> > in the project's lifetime.  If a relicense were to happen it would be
>> > better to do it before a larger number of developers started
>> > contributing to the project.
>>
>> You both bring up a good point, the LGPL seems like a better choice.  I
>> chose GPLv2 when I started simply out of habit; it is a license I am both
>> familiar and comfortable with so it has a tendency to get used when I start
>> a new chunk of code.
>>
>> As you pointed out, the project is still very new with only a handful of
>> authors beyond myself.  I'll get in touch with them privately to make sure
>> they are comfortable with the relicense and assuming there are no problems
>> I'll report back when everything has been changed.
>
> Just an update, the project has just been relicensed under the LGPLv2.1
> license.

Wonderful.  Thanks for the quick action on that.  Hopefully it will
spread the adoption of the library once the seccomp patches are in the
mainline kernel.

josh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  2012-04-09 22:46       ` Paul Moore
@ 2012-04-13 20:14         ` Paul Moore
  2012-04-14  2:47           ` Henrique de Moraes Holschuh
  0 siblings, 1 reply; 17+ messages in thread
From: Paul Moore @ 2012-04-13 20:14 UTC (permalink / raw)
  To: Will Drewry
  Cc: Kees Cook, libseccomp-discuss, linux-kernel, linux-security-module

On Monday, April 09, 2012 06:46:02 PM Paul Moore wrote:
> On Monday, April 09, 2012 04:51:30 PM Will Drewry wrote:
> > On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <paul@paul-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 wrote:
> > >> 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.
> 
> Okay, that seems reasonable: default to NO_NEW_PRIVS, but provide an
> override mechanism.
> 
> I've been wanting a mechanism/API for tweaking some of the default library
> parameters for the past few weeks, this is likely the last bit of motivation
> I need to start working on this.  I'll look into it once the license issue
> is sorted.

A quick update - I just added support for setting NO_NEW_PRIVS when loading 
the seccomp filter into the kernel.  By default libseccomp attempts to set 
NO_NEW_PRIVS but does not fail if prctl(NO_NEW_PRIVS) returns with an error; 
however, both the attempt to set NO_NEW_PRIVS and the fact that libseccomp 
does not fail on error are configurable via the application if you don't like 
the defaults for your particular use case.

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
  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
  0 siblings, 1 reply; 17+ messages in thread
From: Henrique de Moraes Holschuh @ 2012-04-14  2:47 UTC (permalink / raw)
  To: Paul Moore
  Cc: Will Drewry, Kees Cook, libseccomp-discuss, linux-kernel,
	linux-security-module

On Fri, 13 Apr 2012, Paul Moore wrote:
> the seccomp filter into the kernel.  By default libseccomp attempts to set 
> NO_NEW_PRIVS but does not fail if prctl(NO_NEW_PRIVS) returns with an error; 

Isn't that dangerous in non-obvious ways, as in it can actually
cause/activate/enable/open security issues on priviledged processes that
don't expect whatever filtering seccomp will subject them to?

Maybe it would be best if libseccomp were to (by default) bomb out with
an error if prctl(NO_NEW_PRIVS) fails?  Defaults are important, as
they're what people _who don't know any better_ are likely to use.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ANN: libseccomp
       [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
  1 sibling, 0 replies; 17+ messages in thread
From: Kees Cook @ 2012-04-15 16:20 UTC (permalink / raw)
  To: David Windsor
  Cc: Paul Moore, libseccomp-discuss, linux-kernel,
	linux-security-module, Will Drewry

Hi,

The seccomp mini-tutorial I wrote[1] could be extended to restart
system calls. That's the closest I've seen so far. Right now it just
needs to be run repeatedly until all the needed syscalls are found. :P

-Kees

[1] http://outflux.net/teach-seccomp/

On Sat, Apr 14, 2012 at 7:10 AM, David Windsor <dwindsor@gmail.com> wrote:
> Out of curiosity, are there any current efforts towards creating a "learning
> mode" type of application for seccomp?  I.e. creating a profile for a
> particular application based upon which syscalls it makes during normal
> operation.  I realize that many people consider this a security
> anti-pattern, but it could be useful for the initial creation of a seccomp
> filter for a particular application, and other security subsystems already
> do this (ala AppArmor's learning/complain mode).  IIUC, no other kernel
> mechanisms would need to be created; ptrace could accomplish syscall
> monitoring.
>
> Thanks,
> David Windsor
>
> On Mon, Apr 9, 2012 at 2:58 PM, 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
>>
>> The library has only been in development for the past couple months, so it
>> may
>> be a little rough around the edges, and definitely could use more testing,
>> but
>> it is functional and has had some basic testing against the seccomp v17
>> patches.  The project currently lacks any online documentation or a
>> website
>> beyond the basic SF.net tools, but there are current man pages in the
>> source
>> repository and the code is reasonably well commented.
>>
>> For those of you who are interested in making use of the library, or
>> contributing to its development and testing, we do have a mailing list
>> setup
>> (see the To/CC line above) and you can subscribe at the link below; all
>> are
>> welcome.
>>
>>  * https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
>>
>> To demonstrate some of the basic libseccomp capabilities, I've included a
>> short example below.  The example is trivial, it opens /dev/zero and
>> writes to
>> /dev/null, but it shows how to use libseccomp to create a simple filter
>> and
>> load it into the kernel; filtering both on just the syscall and a syscall
>> with
>> specific arguments.
>>
>> > #include <errno.h>
>> > #include <stdlib.h>
>> > #include <stdio.h>
>> > #include <unistd.h>
>> >
>> > #include <seccomp.h>
>> >
>> > #define BUF_LEN               256
>> >
>> > int main(int argc, char *argv[])
>> > {
>> >       int rc;
>> >       FILE *read_stream, *write_stream;
>> >       unsigned char buf[BUF_LEN];
>> >       size_t op_len;
>> >
>> >       /* initialize the seccomp filter */
>> >       printf("scmp: initializing the seccomp filter ...");
>> >       rc = seccomp_init(SCMP_ACT_KILL);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       printf("ok\n");
>> >
>> >       /* do the setup */
>> >       printf("info: opening /dev/zero for reading ... ");
>> >       read_stream = fopen("/dev/zero", "r");
>> >       if (read_stream == NULL)
>> >               goto failure;
>> >       printf("ok\n");
>> >       printf("info: opening /dev/null for writing ... ");
>> >       write_stream = fopen("/dev/null", "w");
>> >       if (write_stream == NULL)
>> >               goto failure;
>> >       printf("ok\n");
>> >
>> >       /* configure the seccomp filter */
>> >       printf("scmp: configuring the seccomp_filter ... ");
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(read), 1,
>> >                             SCMP_A0(SCMP_CMP_EQ, fileno(read_stream)));
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
>> >                             SCMP_A0(SCMP_CMP_EQ, STDOUT_FILENO));
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
>> >                             SCMP_A0(SCMP_CMP_EQ, STDERR_FILENO));
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
>> >                             SCMP_A0(SCMP_CMP_EQ, fileno(write_stream)));
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(close), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(ioctl), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(mprotect), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       rc = seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(munmap), 0);
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       printf("ok\n");
>> >
>> >       /* load the seccomp filter into the kernel */
>> >       printf("scmp: load the filter ... ");
>> >       rc = seccomp_load();
>> >       if (rc < 0)
>> >               goto failure_scmp;
>> >       seccomp_release();
>> >       printf("ok\n");
>> >
>> >       /* perform the i/o */
>> >       printf("info: attempting to read BUF_LEN bytes ... ");
>> >       op_len = fread(buf, BUF_LEN, 1, read_stream);
>> >       if (op_len != 1)
>> >               return errno;
>> >       printf("ok\n");
>> >
>> >       printf("info: attempting to write BUF_LEN bytes ... ");
>> >       op_len = fwrite(buf, BUF_LEN, 1, write_stream);
>> >       if (op_len != 1)
>> >               return errno;
>> >       printf("ok\n");
>> >
>> >       /* shutdown */
>> >       printf("info: closing file streams and exiting\n");
>> >       fclose(write_stream);
>> >       fclose(read_stream);
>> >       return 0;
>> >
>> > failure_scmp:
>> >       errno = -rc;
>> > failure:
>> >       /* oops ... */
>> >       printf("failed, errno = %u\n", errno);
>> >       return errno;
>> > }
>>
>> --
>> paul moore
>> www.paul-moore.com
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-security-module" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
>
> --
> PGP: 6141 5FFD 11AE 9844 153E  F268 7C98 7268 6B19 6CC9



-- 
Kees Cook
ChromeOS Security

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [libseccomp-discuss] ANN: libseccomp
       [not found] ` <CAEXv5_jiZsd6t=H1KWMNhUdgMez0B-WdC5XAHzdHffjOQh_J4A@mail.gmail.com>
  2012-04-15 16:20   ` Kees Cook
@ 2012-04-16 14:09   ` Paul Moore
  1 sibling, 0 replies; 17+ messages in thread
From: Paul Moore @ 2012-04-16 14:09 UTC (permalink / raw)
  To: libseccomp-discuss
  Cc: David Windsor, linux-security-module, Will Drewry, linux-kernel

On Saturday, April 14, 2012 10:10:28 AM David Windsor wrote:
> Out of curiosity, are there any current efforts towards creating a "learning
> mode" type of application for seccomp?  I.e. creating a profile for a
> particular application based upon which syscalls it makes during normal
> operation.  I realize that many people consider this a security anti-
> pattern, but it could be useful for the initial creation of a seccomp filter
> for a particular application, and other security subsystems already do this
> (ala AppArmor's learning/complain mode).  IIUC, no other kernel mechanisms
> would need to be created; ptrace could accomplish syscall monitoring.  

I'm not aware of any serious efforts, but as Kees already pointed out, his 
seccomp tutorial could be extended to do something similar to what you 
describe.  Kees' tutorial uses raw BPF, but the same basic principles would 
work with libseccomp as well if you wanted a higher level interface.

The libseccomp sources also contain a simple little script which runs an 
application via strace and presents a slightly cleaned up version of the 
strace report which shows the syscalls, their frequency (important if you want 
to tune the seccomp filter), and some of the arguments you're likely to want 
to filter on.  Simple example:

 # ./tools/sys_inspector -h
 usage ./tools/sys_inspector [-f] [-a] [-o <file>] <command> [<args>]
 # ./tools/sys_inspector -f /bin/true
 ============================================================
 Syscall Report ("/bin/true")
    freq syscall
 ============================================================
       8 mmap
       4 mprotect
       2 open
       2 fstat
       2 close
       1 read
       1 munmap
       1 exit_group
       1 execve
       1 brk
       1 arch_prctl
       1 access

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [libseccomp-discuss] ANN: libseccomp
  2012-04-14  2:47           ` Henrique de Moraes Holschuh
@ 2012-04-16 14:15             ` Paul Moore
  0 siblings, 0 replies; 17+ messages in thread
From: Paul Moore @ 2012-04-16 14:15 UTC (permalink / raw)
  To: libseccomp-discuss
  Cc: Henrique de Moraes Holschuh, linux-security-module, Will Drewry,
	linux-kernel

On Friday, April 13, 2012 11:47:08 PM Henrique de Moraes Holschuh wrote:
> On Fri, 13 Apr 2012, Paul Moore wrote:
> > the seccomp filter into the kernel.  By default libseccomp attempts to set
> > NO_NEW_PRIVS but does not fail if prctl(NO_NEW_PRIVS) returns with an
> > error;
>
> Isn't that dangerous in non-obvious ways, as in it can actually
> cause/activate/enable/open security issues on priviledged processes that
> don't expect whatever filtering seccomp will subject them to?

We could debate this point but it turns out it is a bit of a non-issue as the 
kernel code requires NO_NEW_PRIVS unless CAP_SYS_ADMIN is set; if neither 
conditions are true the seccomp filter with fail (check Will's patches).

If prctl(NO_NEW_PRIVS) fails the error is always returned, and the 
attribute/boolean to disable this functionality has been removed since it 
likely serves little purpose.

> Defaults are important, as they're what people _who don't know any better_
> are likely to use.

Agreed.  You'll never hear me argue otherwise.

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2012-04-16 14:15 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-09 18:58 ANN: libseccomp Paul Moore
2012-04-09 19:16 ` Kees Cook
2012-04-09 21:32   ` Paul Moore
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).