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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 16:13:04 -0400 From: Oren Laadan <orenl@...rato.com> To: "Eric W. Biederman" <ebiederm@...ssion.com> CC: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>, Matt Helsley <matthltc@...ibm.com>, Daniel Lezcano <daniel.lezcano@...e.fr>, randy.dunlap@...cle.com, arnd@...db.de, linux-api@...r.kernel.org, Containers <containers@...ts.linux-foundation.org>, Nathan Lynch <nathanl@...tin.ibm.com>, linux-kernel@...r.kernel.org, Louis.Rilling@...labs.com, kosaki.motohiro@...fujitsu.com, hpa@...or.com, mingo@...e.hu, torvalds@...ux-foundation.org, Alexey Dobriyan <adobriyan@...il.com>, roland@...hat.com, Pavel Emelyanov <xemul@...nvz.org> Subject: Re: [RFC][v8][PATCH 0/10] Implement clone3() system call Eric W. Biederman wrote: > Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com> writes: > >> Eric W. Biederman [ebiederm@...ssion.com] wrote: >> | > Could you clarify ? How is the call to alloc_pidmap() from clone3() different >> | > from the call from clone() itself ? >> | >> | I think it is totally inappropriate to assign pids in a pid namespace >> | where there are user space processes already running. >> >> Honestly, I don't understand why it is inappropriate or how this differs >> from normal clone() - which also assigns pids in own and ancestor pid >> namespaces. > > The fact we can specify which pids we want. I won't claim it is as > exploitable as NULL pointer deferences have been but it has that kind > of feel to it. This security concern was first brought up by Linus, and to address it we made clone3() require that the user be privileged to select pids. But, honestly, a clone3() that allows the caller to request a specific pid is like a restart() syscall that allows the caller to restore a process with its original pid: you would simply checkpoint, and then alter the pid in the checkpoint image and restart, repeat ad infinitum. >From your security prism, they are equivalent: they practically allow a user to have an arbitrary process with a selected pid. So it doesn't really matter - for this security concern - if you select the pid in the kernel through restart() or from userspace through clone3(). Sure, you can also "choose" a pid today, by repeatedly forking until you get what you want... but that is harder to exploit. In contrast, both clone3() and restart() allow pid selection, instantaneously. Which is why both require privileges if the caller wants to select/ restore pids. Oren. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists