On Sun, Jul 14, 2019 at 05:18:39PM +0200, Klemens Nanni wrote: > On Sun, Jul 14, 2019 at 03:46:06PM +0200, Stefan Sperling wrote: > > Overriding gitdaemon_flags in /etc/r.conf.local will cause rc.d to > > run git-daemon run as root instead of the expected _gitdaemon user. > Well, you ought to check the existing daemon flags before changing them. > > Admittedly, this is suboptimal and users have to carry the options along > themselves, but some third-party daemons will not work with `daemon_user`, > and I believe git-daemon(1) is one of them. > > > > > To reproduce, try an rc.conf.local line such as: > > gitdaemon_flags=--listen=127.0.0.1 /git > > > > This happens because the rc script currently depends on git-daemon itself > > to switch the user ID, rather than using rc.d's built-in mechanism which > > forces a UID with su(1). If the user overrides the flags, no UID switch > > will happen. > Off the top of my head, I know that this is the case for security/hitch > and net/tinc as well. I remember discussion about putting `-u $user' > into `$daemon' itself to enforce the user for cases where our rc.subr(8) > framework is not applicable, but there were objections.
My position is that while we cannot prevent people from changing their configuration in a risky fashion, the default should be as secure as we can reasonably make it. I've gotten used to not having daemons, even from ports land, start up as root. I don't even think about it anymore, I just take this for granted. I suspect other users have similar expectations. Setting something like a --listen option should not affect this expectation. (Unless the service needs a privileged port, of course, which this one does not.) > > Anyone exposing git-daemon to the public internet on an OpenBSD system > > should check their system. This line in rc.conf.local will force the > > daemon to run under its dedicated user account: > > gitdaemon_user=_gitdaemon > This will also (partially?) break git-daemon(1)'s `--inetd' option, > I think. From the manual: Is there any reason to start git-daemon through rc.d(8) in --inetd mode? git-daemon isn't running persistently in the inetd case. It will be started by inetd on demand, based on configuration parameters in /etc/inetd.conf. I don't see how the rc.d script would be involved here in the first place. > --user=<user>, --group=<group> > Change daemon’s uid and gid before entering the service loop. When > only --user is given without --group, the primary group ID for the > user is used. The values of the option are given to getpwnam(3) and > getgrnam(3) and numeric IDs are not supported. > > Giving these options is an error when used with --inetd; use the > facility of inet daemon to achieve the same before spawning git > daemon if needed. > > Like many programs that switch user id, the daemon does not reset > environment variables such as $HOME when it runs git programs, e.g. > > So switching to "_gitdaemon" at runtime and starting as it through su(1) > is not the same. I don't understand which difference you mean. Could you please try to explain your point better? Are you referring to the environment being different when started as a non-root user? I would trust rc.d(8) to do the right thing with the environment. > > Note that git-daemon does not support any of the standard exploit > > mitigation measures regular OpenBSD daemons provide; there is not > > even support for chroot(8). > > > > Fix for the port: > This seems like the right direction and I support setups with less > potential to accidentially run things as root, but existing setups might > break. Break in what way? Please consider that any setup that runs this thing as root is a hazard. Can you name any potential consequences which the proposed change might introduce which are actually worse than running git-daemon as root? Even if there were people how wanted to run git-daemon as root on purpose I wouldn't see any reason for us to support them in doing so.
