On Tue, Apr 16, 2019 at 11:46 AM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > > On 15.04.19 22:29, Andy Lutomirski wrote: > > <snip> > > > I would personally *love* it if distros started setting no_new_privs> for basically all processes. > > Maybe a pam module for that would be fine. > But this should be configurable per-user, as so many things still rely > on suid. > > Actually, I'd like to move all authentication / privilege switching > to factotum (login(1), sshd, etc then also could run as unprivileged > users). > > > And pidfd actually gets us part of the> way toward a straightforward way to make sudo and su still work in a> > no_new_privs world: su could call into a daemon that would spawn the> > privileged task, and su would get a (read-only!) pidfd back and then> > wait for the fd and exit. > > How exactly would the pidfd improve this scenario ? > IMHO, would just need to pass the inherited fd's to that daemon (eg. > via unix socket) which then sets them up in the new child process. > It makes it easier to wait until the privileged program exits. Without pidfd, you can't just wait(2) because the program that gets spawned isn't a child. With pidfd, the daemon can pass the pidfd back. Without pidfd, of course, you can wait by asking the daemon to tell you when the program exits, but that's a uglier IMO. > > I suppose that, done naively, this might> cause some odd effects with respect to tty handling, but I bet it's> > solveable. > > Yes, signals and process groups would be a bit tricky. Some signals > could be transmitted in a similar way as ssh does. > > But: how can we handle things like cgroups ? Find a secure way to tell the daemon what cgroups to use? --Andy
