On Monday, August 06, 2012 11:06:26 AM Eric Paris wrote: > On Mon, 2012-08-06 at 11:02 -0400, Paul Moore wrote: > > 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. > > I'll be there too. I know when the interface was originally designed > the interface that I suggested it should take a string and do a > lookup/translation at BPF generation but that wasn't the chosen > implementation. Maybe we can or should revisit?
Yeah, I think we definitely need to revisit things to support what we want to do with containers, but I don't think we need a wholesale revamp of the API, just some tweaks. The current API seems reasonable for the more conventional app developer scenario so I don't want to sabotage that. There are basically three things I think we need to accomplish in the near term: 1. Support specifying syscalls as string. 2. Support non-native architectures in the API, e.g. x86 filters on x86-64. 3. Support multiple architectures in a single filter. Of the three items, #1 and #2 seem intertwined to some extent. I suspect we can support #1 with an auxiliary function that converts a string to an int which we can feed into the existing API. Once we have that done, we can build upon it for #2, although there will be some tricky work around what the int will actually represent but I have some thoughts on that, I just need to start coding it up to make sure I haven't missed anything. Finally, #3 is going to be a perhaps the most unusual, but I think once we have #1 and #2 in place it shouldn't be too difficult to add multiple filter support. Some modifications to generate multiple concurrent db_filters, each for a separate arch, and then some magic BPF selector glue when we generate the final filter; it isn't too different from our current non-native check, we would just add a few jumps for the initial version. Anyway, those are my thoughts - anyone care to add their own? -- 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
