On Sun, 5 Feb 2006, [ISO-8859-15] Björn König wrote: > unprivileged users of the host environment can see jailed processes with the > same user ID. Furthermore they are able to send signals to these processes. > I think since users are not allowed to imprison processes there is no reason > why they should see them or even kill them. > > Someone pointed me to this issue and I want to know what you think about > this. I recognize the concern, but the current behavior is consistent with the overall behavior of jail. In attempt to enforce stronger isolation between the host and the jail, you will run into other, more significant problems. For example, jail relies on chroot to segment the file system name space. Since the host environment is typically rooted at the "real" root, and guest environments are typically chrooted to specific subtrees, containment is enforced (subject to due care). However, file system access control isn't aware of jails, so a uid in the host environment still "owns" files that appear in the chrooted name spaces. I.e., uid 1000 can edit /home/rwatson/foo, but also /jail1/home/rwatson/foo if the uid matches. Changing this will be quite difficult, probably to the point of being undesirable. So I guess the question is: if we can't close the file system method of processes in the host influencing processes in the jail, does it make sense to, say, control the delivery of signals? Robert N M Watson > > These are some steps to reproduce: > > root_at_host # jail -Uuserxy / localhost 127.0.0.1 /bin/sleep 12345& > > root_at_host # ps a | grep sleep > > 2255 p2 IJ 0:00,01 /bin/sleep 12345 > > login as 'userxy' > > userxy_at_host $ ps a | grep sleep > 2255 p2 IJ 0:00,01 /bin/sleep 12345 > > userxy_at_host $ ps a | grep sleep > [nothing] > > This is a suggestion to eliminate this behaviour. I appreciate further > testing because I hadn't much time to do it. > > === patch starts here === > --- src/sys/kern/kern_jail.c.orig Wed Sep 28 02:30:56 2005 > +++ src/sys/kern/kern_jail.c Sun Feb 5 14:42:00 2006 > _at__at_ -405,6 +405,9 _at__at_ > return (ESRCH); > if (cred2->cr_prison != cred1->cr_prison) > return (ESRCH); > + } else { > + if (jailed(cred2) && suser_cred(cred1, 0)) > + return (ESRCH); > } > > return (0); > === patch ends here === > > > Regards > Björn > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Sun Feb 05 2006 - 13:17:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC