lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 Apr 2019 14:31:44 -0700 From: Andy Lutomirski <luto@...nel.org> To: "Enrico Weigelt, metux IT consult" <lkml@...ux.net> Cc: Andy Lutomirski <luto@...nel.org>, Aleksa Sarai <cyphar@...har.com>, Christian Brauner <christian@...uner.io>, Linus Torvalds <torvalds@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, Jann Horn <jannh@...gle.com>, David Howells <dhowells@...hat.com>, Linux API <linux-api@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, "Serge E. Hallyn" <serge@...lyn.com>, Arnd Bergmann <arnd@...db.de>, "Eric W. Biederman" <ebiederm@...ssion.com>, Kees Cook <keescook@...omium.org>, Thomas Gleixner <tglx@...utronix.de>, Michael Kerrisk <mtk.manpages@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Oleg Nesterov <oleg@...hat.com>, Joel Fernandes <joel@...lfernandes.org>, Daniel Colascione <dancol@...gle.com> Subject: Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD] On Tue, Apr 16, 2019 at 11:46 AM Enrico Weigelt, metux IT consult <lkml@...ux.net> 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
Powered by blists - more mailing lists