Thread: [libseccomp-discuss] ANN: libseccomp
High level interface to the Linux Kernel's seccomp filter
Brought to you by:
pcmoore
From: Paul M. <pa...@pa...> - 2012-04-09 19:28:35
|
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 |
From: Kees C. <kee...@ch...> - 2012-04-09 19:16:38
|
On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <pa...@pa...> 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 |
From: Josh B. <jw...@gm...> - 2012-04-09 19:25:55
|
On Mon, Apr 9, 2012 at 2:58 PM, Paul Moore <pa...@pa...> 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 |
From: H. P. A. <hp...@zy...> - 2012-04-09 20:02:21
|
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 |
From: Josh B. <jw...@gm...> - 2012-04-09 20:14:22
|
On Mon, Apr 9, 2012 at 4:02 PM, H. Peter Anvin <hp...@zy...> 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 |
From: Paul M. <pa...@pa...> - 2012-04-09 21:29:10
|
On Monday, April 09, 2012 04:14:15 PM Josh Boyer wrote: > On Mon, Apr 9, 2012 at 4:02 PM, H. Peter Anvin <hp...@zy...> 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 |
From: Paul M. <pa...@pa...> - 2012-04-09 21:33:06
|
On Monday, April 09, 2012 12:16:30 PM Kees Cook wrote: > On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <pa...@pa...> 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 |
From: Will D. <wa...@ch...> - 2012-04-09 22:22:48
|
On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <pa...@pa...> wrote: > On Monday, April 09, 2012 12:16:30 PM Kees Cook wrote: >> On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <pa...@pa...> 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 |
From: Serge H. <ser...@ca...> - 2012-04-09 22:56:37
|
Quoting Will Drewry (wa...@ch...): > On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <pa...@pa...> wrote: > > On Monday, April 09, 2012 12:16:30 PM Kees Cook wrote: > >> On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <pa...@pa...> 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 |
From: Paul M. <pa...@pa...> - 2012-04-09 22:46:13
|
On Monday, April 09, 2012 04:51:30 PM Will Drewry wrote: > On Mon, Apr 9, 2012 at 4:32 PM, Paul Moore <pa...@pa...> wrote: > > On Monday, April 09, 2012 12:16:30 PM Kees Cook wrote: > >> On Mon, Apr 9, 2012 at 11:58 AM, Paul Moore <pa...@pa...> 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 |
From: Paul M. <pm...@re...> - 2012-04-10 20:29:28
|
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 <hp...@zy...> 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 |
From: Josh B. <jw...@gm...> - 2012-04-11 00:27:08
|
On Tue, Apr 10, 2012 at 4:29 PM, Paul Moore <pm...@re...> 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 <hp...@zy...> 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 |
From: Paul M. <pa...@pa...> - 2012-04-13 20:14:54
|
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 <pa...@pa...> 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 |
From: Henrique de M. H. <hm...@hm...> - 2012-04-14 02:47:19
|
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 |
From: Paul M. <pa...@pa...> - 2012-04-16 14:15:48
|
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 |
From: David W. <dwi...@gm...> - 2012-04-14 14:10:35
|
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 <pa...@pa...> 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 maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- PGP: 6141 5FFD 11AE 9844 153E F268 7C98 7268 6B19 6CC9 |
From: Kees C. <kee...@ch...> - 2012-04-15 16:20:16
|
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 <dwi...@gm...> 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 <pa...@pa...> 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 maj...@vg... >> 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 |
From: Paul M. <pa...@pa...> - 2012-04-16 14:10:00
|
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 |