Re: [libseccomp-discuss] Python bindings
High level interface to the Linux Kernel's seccomp filter
Brought to you by:
pcmoore
|
From: Andy L. <lu...@am...> - 2013-10-01 22:53:10
|
On Tue, Oct 1, 2013 at 2:57 PM, Paul Moore <pm...@re...> wrote: > On Tuesday, October 01, 2013 06:50:28 PM Andy Lutomirski wrote: >> The python bindings are quite nice. > > That's good to hear. The main reason I'm holding back from enabling them in a > release is lack of feedback/experience; I don't have much Python experience > and I want to make sure we don't end having to support bad bindings. :) > >> I'm currently using them for a production web server like this: >> >> def load_seccomp(failure_action = None): > > ... > >> # At some point it would be nice to do a better job of this... >> f.add_rule(seccomp.ALLOW, 'open', >> seccomp.Arg(1, seccomp.MASKED_EQ, >> os.O_RDONLY, os.O_RDONLY | >> os.O_RDWR | os.O_WRONLY)) > > Suggestions? Sort of, but this isn't really libseccomp's fault. I want to restrict filesystem visibility to a subtree. Something like AT_DESCEND_ONLY that blocks '..' and symlink traversal could work, although it doesn't help that openat doesn't take AT_xyz flags. The usage would be clearer if the arguments were something like 'value' and 'mask' instead of datum_a and datum_b. (Also, I don't like the automatic fileno() call -- using an fd as a mask makes no sense and comparing syscall arguments to fds is so tricky and dangerous that I feel like making it easy is asking for trouble.) > >> I haven't found any real problems with the bindings. Can you enable >> them by default so they get packaged and can be widely used? > > Probably soon. Right now I'm focused on some bugfixes in the db/rule code. > >> So far, I have two minor improvements to suggest to the docstrings. >> They're here: >> >> https://github.com/amluto/libseccomp > > Can you post the patches here for review/comment? Done. |