Date: Thu, 17 Feb 2000 18:30:39 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Philipp Buehler <lists@fips.de> Cc: Andrey Novikov <novikov@webclub.ru>, freebsd-security@FreeBSD.ORG Subject: Re: Nonpriveleged daemons and pid files Message-ID: <Pine.BSF.3.96.1000217182204.37287A-100000@fledge.watson.org> In-Reply-To: <20000217192613.A25807@pohl.fips.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Feb 2000, Philipp Buehler wrote: > Andrey Novikov wrote To freebsd-security@FreeBSD.ORG: > > restart. What is the common way to overcome that problem - > > it's very convinient to store them in one place. > > Put them in a group and give g+w on /var/run. This would allow a compromised daemon to allow arbitrary signal delivery to other processes, or to shut down the machine. This is because many tools for managing processes take advantage of the PID file to direct the behavior of kill (sometimes in unsafe ways that might result in arbitrary shell commands being executed). Any user able to write to a PID file could direct signals elsewhere, including to the init process. > Or create/touch the pidfile at startup and give writepermissions > to the group in which the daemons runs. Just put that in the > startup script. This is a better idea. That said, you need to be careful to avoid the situation where the follow is run as an inappropriate uid: kill -HUP `cat /var/run/untrustedfile.pid` For the obvious reason. I have suspected for a while that a better way to do most process management would be via a management unix domain socket, per-daemon, stored in /var/run/daemonname with appropriate permissions on the directory. This would allow the daemon to provide a more controlled management mechanism than signals (a big plus given the current overloading of signals and differences between signal interpretations with different daemons), and also allow for more fine-grained authentication of requests by the daemon, optionally using ancillary data to carry uid/gid information. For example, the daemon could make its own decisions about who could deliver management requests based on strong kernel-provided authentication infomration (pid, uids + gids + whatever). Local procedure calls of various sorts could be employed, simple control messages, etc. These messages would also be queued, and so on. This is harder to manage without a multi-threaded daemon, but with Bind and friends becoming more complicated (BIND9 does pthreads, I believe) anyway, this seems like a useful direction. This doesn't help you with run-away processes which still require signals, but most processes don't need to be nastily terminated, it's quite sufficient to tell them to reload a config file/etc. Having a directory per-daemon would also work for even the signalling approach, although I think one does have to be careful about scripts employing untrusted data from daemon-writable files, when running as root. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000217182204.37287A-100000>