On Monday, August 06, 2012 09:47:54 AM Serge Hallyn wrote: > Quoting Paul Moore ([email protected]): > > On Friday, July 27, 2012 09:20:16 PM Serge Hallyn wrote: > > > 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. > > Perhaps this is something worth discussing in person at LSS or plumber's? > (alas I won't be there, but I doubt I'm needed)
Yep, I suspect we'll have one or two discussions about syscall filtering in general. There is a containers/libvirt/systemd hacking session on Tuesday before the LinuxCon/LPC/free-for-all later in the week; I'm not exactly sure what to expect there but I plan on attending. -- 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
