The problem isn't that it's behind the scenes, it's what part of it is in kernel space. The user of tame() quite sensibly wants to specify a simple filter base

The problem isn't that it's behind the scenes, it's what part of it is in kernel space. The user of tame() quite sensibly wants to specify a simple filter based on what things they might need to do in the future. i.e. "I need to be able to loop up details about local users". At the system-call level this implies a number of things should be allowed i.e. "can open /etc/group for read-only access, can read NIS configuration files, ..." In the OpenBSD implementation of tame() all of these rules are hardcoded into the kernel. Using LDAP instead of NIS? Well, you'll have to patch and recompile I guess. Since ultimately the userland process is opting-in to the restrictions there's no security reason that it can't specify the rules to the kernel. (Assuming here that care is taken so it can't DoS the kernel by pushing down a billion-entry list or something) Again, what OpenBSD gets right here is the API -- it should be as simple as possible for a process to say "I need to look up users, use DNS, and read files; block all else" Making that a simple call like tame() is a great step forward. I hope the seccomp-bpf people do something similar. However, tame() should be a library function, not a syscall. The kernel shouldn't know or care what "I need to use DNS" means, it should just be told what files I can open and what sockets ops I'm allowed to do. The OpenBSD implementation is simultaneously too rigid for some things (since things like plugable nsswitch.conf modules can't work at all) and too loose to support other useful ones (per-application policies like "block any attempt to open a file for writing unless it's an append to $HOME/.ssh/known_hosts") In UNIX there is a very long tradition of not baking policies like this into the kernel, and for good reason.