Re: Policy consensus on transition when removing initscripts.
On Tue, 27 Jun 2023 at 01:04, nick black <dankamongmen@gmail.com> wrote:
>
> Simon McVittie left as an exercise for the reader:
> > started as root and dropped privileges to some other uid, that permanently
> > restricts its ability to read information out of its own /proc, which is
> > not always desirable. If the daemon starts up unprivileged, then it can
>
> i assume by "its own /proc" you mean /proc/getpid()? i don't see
> how this is different from any other resource one might need
> consider acquiring prior to dropping privileges. if i want to
> open a privileged port, i'd better do that before i change my
> user (or otherwise yield CAP_NET_BIND_SERVICE).
>
> furthermore, this is only true when procfs is mounted with a
> nonzero hidepid, right? all my /proc/PID directories are 0755,
> with contents likewise generally world-readable. hidepid=off is
> the default according to
> https://www.kernel.org/doc/html/latest/filesystems/proc.html.
Resources are dynamic, and come and go - for example, file
descriptors. The 'run as root and drop privileges' pattern might have
been fine in the past century, but in 2023 we have much, much better
patterns to secure running services. And using hidepid (ie,
ProtectProc) and other sandboxing on services is one such pattern.
Kind regards,
Luca Boccassi
Reply to: