Linus Torvalds wrote: > On Thu, Jan 12, 2012 at 5:11 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > > > > What if you're a daemon that needs something like CAP_NET_BIND but > > also wants to be able to run other helpers without CAP_NET_BIND? > > > > (Also, preventing dropping of privileges will probably make a patch > > more complicted -- I'll have to find and update all the places that > > allow dropping privileges.) > > Hey, if it actually makes it more complicated to say "don't change > privileges", then I guess my argument that it should be simpler is > wrong. > > That said, the thing you bring up is *not* the actual use-case for the > suggestion. The use-case is a "run untrusted code". So the use-case > would be to set the flag after you've dropped CAP_NET_BIND, and > *before* you actually run the other helpers. You clearly must have a > fork() or something like that there, since you want to keep the > NET_BIND in the original daemon. Well suppose you don't trust the daemon either. It might be running in a network namespace where it's safe for untrusted code to bind to low ports. Or maybe you just need to let it bind willy-nilly among a restricted subset of low ports - which of course you would like to restrict with the seccomp filter. (This can't happen right now because the filter can only look at arguments, not memory pointed to - so it can't look at the port number. Can it even see when sys_bind is called on archs like x86 that use sys_socketcall?!) Anyway the principle is there - CAP_NET_BIND doesn't necessarily mean the daemon code is trusted. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
