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'm not entirely sure you are real.
