On Friday, July 27, 2012 09:20:16 PM Serge Hallyn wrote: > Quoting Paul Moore ([email protected]): > > On Friday, July 27, 2012 03:27:01 PM Serge Hallyn wrote: > > > Quoting Paul Moore ([email protected]): > > > > On Friday, July 27, 2012 01:47:44 PM Serge Hallyn wrote: > > > > > Quoting Serge Hallyn ([email protected]): > > > > > ... > > > > > > > > > > > > There have been discussions about disabling certain syscalls, > > > > > > > e.g. > > > > > > > execve(), in certain applications, but by default the kernel > > > > > > > doesn't > > > > > > > disallow any syscalls neither does libseccomp. The only things > > > > > > > that > > > > > > > libseccomp does by default is set the no_new_privs prctl() flag > > > > > > > and > > > > > > > verify that you are not trying to run a non-native binary. Both > > > > > > > are > > > > > > > tunable using the > > > > > > > seccomp_attr_{get,set}() functions, but it doesn't sound like > > > > > > > that > > > > > > > it > > > > > > > your > > > > > > > > > > > > Ah, that's good to know, I'll definately need to use that (lxc > > > > > > seccomp > > > > > > patch is what I'm really working on). > > > > > > > > > > That was the problem. I haven't looked back at the kernel code, but > > > > > when > > > > > I do seccomp_attr_set(SCMP_FLTATR_CTL_NNP, 0); then it works. I > > > > > remember > > > > > a patch going in about apparmor denying somethingorother with NNP, I > > > > > must > > > > > have run into that. > > > > > > > > > > Thanks! > > > > > > > > Great, glad to hear you found the problem. > > > > > > > > Also, just a heads-up for the lxc patch in case you missed it earlier > > > > this > > > > week, we're changing the API in the next release to include a filter > > > > context/handle. > > > > > > Yup, I'm only doing a proof of concept this week. In 2-3 weeks I'll try > > > to get something packageable and upstreamable, maybe the new API will > > > be packaged by then. > > > > Okay great. Any feedback you can share so far? > > You can see the code at either > https://code.launchpad.net/~serge-hallyn/ubuntu/quantal/lxc/lxc-seccomp or > git://github.com/hallyn/lxc.git#seccomp.3
Thanks for the pointer. > The biggest thing is that I'm not sure how to cleanly have userspace specify > a policy. Right now I'm having them list system call numbers, which are > not nice. I don't want users to have to muck with m4 and unistd.h to > convert NR_open to its number. I don't know if there is a clean way that > libseccomp could help here, i.e. some library function which takes a target > arch/personality and a system call name as a char*, and converts it? Yeah, this is something that popped up when we discussed supporting non-native archs, but it may have uses even in native applications as you've found. I'm also beginning to realize that the non-native support may be more important that we originally thought: imagine running a sandbox tool on x86_64 but wanting to run a 32bit x86 app inside the sandbox. This will require a bit more thought as I'd like to avoid having to define all the syscalls inside libseccomp, but I'm beginning to think that may be something I'll just have to get over. -- paul moore security and virtualization @ redhat ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libseccomp-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
