Russell Coker wrote: >On Mon, 20 Jan 2003 01:43, Christoph Hellwig wrote: > > >>On Mon, Jan 20, 2003 at 01:39:39AM +0100, Russell Coker wrote: >> >> >>>>What's the reason you can't just live with DAC for sysctls? >>>> >>>> >>>What exactly do you mean by "live with DAC" in this context? If you mean >>>"allow UID==0 processes to do whatever they like" then it's not going to >>>work for any sort of chroot setup. >>> >>> >>This means check the unix file permissions / ACLs only overriden by >>CAP_FOWNER processes. >> >> >I don't think that would do for my chroot environments. I want to have root >owned processes running in a chroot with no ability to escape or to affect >the outside environment (and proc is mounted in the chroot). > Christoph's objection is that each module would have to list all the sysctl variables. Can the hook be modified so that a module need only decide whether or not the subject process can call sysctl? Or, somewhat more fine-grained, could we use the approach of opaque security blobs and pushing work back onto modules that want stuff. If a module wants to get more particular about what kinds of sysctl operations are permitted, let that module embed that information in the per-process opaque blob, and block the sysctl if it is not appropriate. The former hack should satisfy Christoph (I trust he'll speak up if it does not :) and may or may not be rich enough for SELinux. The latter hack should satisfy everyone, but may or may not be feasible: it depends on the hook providing enough information to the module to be able to determine which sysctl variables are being accessed. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html Just say ".Nyet"
This archive was generated by hypermail 2b30 : Sun Jan 19 2003 - 18:53:29 PST