Quoting Stéphane Graber ([email protected]): > On Tue, Jun 24, 2014 at 02:23:33PM +0000, Serge Hallyn wrote: > > Hi, > > > > Not too long ago we introduced the v2 seccomp policy format, which allows > > for blacklists. One problem with blacklists is that on a newer kernel there > > may be new syscalls which shouldn't be trusted. > > > > So I'd like to introduce a max-syscall-number option, so that any higher > > syscall number will be also blacklisted. This is actually efficient to do > > with a SCMP_CMP_GT comparison added to a rule. > > > > I'm wondering how this is best specified. There are a few otions: > > > > 1. if we think this is the only comparison rule we'll frequently want, we > > could extend the policy language so that > > > > 2 > > blacklist maxno 500 > > finit_module errno 1 > > > > Would mean that anything higher than 500 would be blacklisted. > > > > 2. We could define seccomp policy format version 3, which allows more > > general rules, like > > > > 3 > > blacklist > > finit_module errno 1 > > GT 500 errno 1 > > LT 3 kill > > > > Preferences? Other ideas? > > I'd prefer option 2 as it also allows you to set the default action. > However, can we easily make this even more flexible by allowing ranges? > > Basically supporting: > - GT 500 <action> (for > 500) > - LT 3 <action> (for < 3) > - RANGE 100 200 <action> (for >= 100 and <= 200) > > If it's easy, it'd also be nice being able to do that using the syscall > name rather than its number, so that you can basically say "I'm happy > with the syscall list up until the introduction of X" and not have to > care about the particular syscall number for each given arches.
Yeah, that was how I pictured it. > To block anything introduced after setns: > - GT setns errno 1 > > To make all the inotify functions return silently: > - RANGE inotify_init inotify_rm_watch errno 0 > > > Is that reasonably easy to implement or am I dreaming? :) Should be easy - the only reason I didn't add RANGE was that it didn't really seem useful, but it should just consist of adding a few more elements to the rule array being added. -serge _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
