Re: init system policy
Simon McVittie <smcv@debian.org> writes:
> I can see the functional regression ("minidlna is running as a totally
> unprivileged user now, and can't read my music any more!") but not the
> security hole: its default user presumably has as little access as
> "nobody", so I don't see how that's insecure?
The scenario I'd be concerned about is if the init script were modified to
run the program as a different user that was subject to, say, a SELinux
policy. Changing users back might escape additional security measures
like that.
Another scenario is if the default Debian user conflicted with some user
on the local system that was already being used to do something else.
In general, I would treat anything involving running daemons as users
other than the intended user as a potential security vulnerability unless
proven otherwise, given how fundamental user and group are to the entire
UNIX security model.
>> A second option is to migrate on upgrade the uid/gid information into
>> an override in /etc/systemd/system. Requires dealing with a
>> dynamically generated config file in preinst/postinst, though, which
>> means the tools that help proper config file handling in maintainer
>> scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited
>> help.
> I think I'd be inclined to do this, as a one-time migration,
Yeah, this seems like the right solution to me too. Drop a configuration
fragment in /etc/systemd that overrides the user and group and then don't
touch it again.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: