>From my point of view, and my sole opinion, the process running as root from a long standing daemon, and which is not under a chroot, should not have the hability to write and/or create files (even better if it cannot even read). But we should reach a consensus once again, and if control_cleanup() should be brought back to the daemons I removed it from I won't be against it.
The combination of unveil/pledge, or even just by using unveil is very powerful and if we by all means can limit the access the most we can to the filesystem is really great against this type of attack vector. On 21:53 Tue 30 Oct , Sebastian Benoit wrote: > Florian Obser([email protected]) on 2018.10.30 18:32:15 +0100: > > On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote: > > > Remi Locherer <[email protected]> wrote: > > > > > > > On Tue, Oct 30, 2018 at 03:20:35PM +0000, Ricardo Mestre wrote: > > > > > Hi, > > > > > > > > > > After all files are opened ripd(8) can have the fs access disabled > > > > > just before > > > > > each process main loop. Its 2 childs already run under chroot, but > > > > > since they > > > > > are still not pledged at least they have no way to read/write/create > > > > > files within > > > > > the chroot. No loads or reloads of the config file happen through any > > > > > signal, > > > > > nor can we do it via ripctl(8). > > > > > > > > > > I was able to run a simple daemon with the example file. Comments? OK? > > > > > > > > control_cleanup() unlinks the control socket on exit. I think you should > > > > either unveil(conf->csock, "c") or remove control_cleanup(). > > > > > > I don't understand this latter comment, let me ask. > > > > > > You think it is smart to leave these sockets lying around? > > > > > > > Back in the summer the consensus was that it is fine to leave the > > sockets lying around. Furthermore the consensus was that it is worth > > to do so if we can drop the cpath pledge in daemons. (IIRC at least benno, > > claudio, deraadt, florian and mestre where in the loop.) > > > > mestre went on a rampage and removed control_cleanup and cpath pledge > > in a bunch of daemons. I think he stopped when he couldn't find any > > more daemons where the parent process was pledged. > > > > This was before the > > unveil("/", "r"); > > unveil(control_socket, "rwc"); > > pattern was discovered which is also very powerful. > > > > > I suspect there are a few oddball programs where it makes senes, but as > > > a general rule I think it is a bad idea; as stated in other threads it > > > means control programs and restart sequences have a bunch more oddball > > > behaviours which will be inconsistant. > > > > I want consistency, if we go with the unveil pattern, fine, then we > > should restore the control_cleanup code in a bunch of daemons. > > > > However: > > - the control program behaviour change had been discussed in the > > summer and the only difference discovered then was "file not found" vs. > > "connection refused". > > - benno's comment about only one instance of ospfd running is not > > effected by leaving the socket behind, it checks if the socket has a > > listener. a dead socket is no problem. > > - daemons/routers might crash and leave a socket behind anyway. they > > must be able to deal with this and I'm pretty sure they all do. I just > > checked ospfd, bgpd and rad. > > i agree with that. In the summer i first thought it would be better to clean > up, but the discussion back then convinced me otherwise, and florian summed > it up nicely.
