Hi! David W. Hankins [2005-05-17 8:39 -0700]: > On Tue, May 17, 2005 at 09:57:20PM +1000, Andrew Pollock wrote: > > Details on the patch can be found at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308832 > > On first glance, the patches as presently distributed in FreeBSD /usr/ports > look to me to be more complete (not the least of which is due to including > a chroot() and jail() implementation).
Interesting, I take a look at them. However, a chroot in Linux is not very efficient when it is meant to improve security (unless you are using grsecurity or similar)---chrooted processes that run as root can easily break out of the chroot, and processes which do not run as root cannot do much harm anyway; thus I'm rather aiming for letting processes run as root instead of chrooting them. > I think the 'capability' flag setting is overhead. We never open new > sockets after initialization - so long as you put the setuid calls after > configuration parsing (which you should do anyway since these should be > config-file configurable) there's no need for those capabilities. Right, for the server it might be a little exaggerated, but since the function is already there it does not do much harm to immediately drop capabilities which are never needed. Please note that the patch works fine on kernels which don't support capabilities, in that case the privileges are not reduced. Kernel capabilities are mainly important for dhclient, which I derooted as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308833 In that case they really make sense because dhclient needs them not only in an initialization phase, but throughout lifetime. > We're looking very closely at the FreeBSD ports changes, and these features > are definitely something that 'must' appear in a 3.1 release. > > You'd have to ask the ports maintainer, but I assume you would be most > welcome to include their changes in whatever upcoming debian releases. I'll ask them and take a look at their patches. > As it stands, these changes in ports represent a fork of our software, and > it would be good if the number of forks remained a relatively low number > until we can get a feature release out to address them. Right, that's why this stuff should eventually go upstream. The only problem that I see is the variety of methods to restrict Daemons -- one uses normal users with additional kernel capabilities in Linux, and apparently jails() in FreeBSD. This should be resolvable with some #ifdef'ed code, but it is certainly not very nice. (Things are so much easier if you just maintain a patch for a particular distro :-) ) The current patches are not perfect anyway since they have too much hardcoded stuff in them. I can make them more upstream-friendly if you are generally interested in them. Thanks for considering and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
