Date: Sun, 14 Aug 2011 13:50:10 +0400 From: Solar Designer <solar@...nwall.com> To: kernel-hardening@...ts.openwall.com Cc: Chris Evans <scarybeasts@...il.com>, djm@...drot.org Subject: Re: 32/64 bitness restriction for pid namespace Vasiliy, On Sat, Aug 13, 2011 at 08:55:02PM +0400, Vasiliy Kulikov wrote: > Some thoughts about prctl() approach. Here's a further thought: The feature makes sense not only for pid namespaces, but also for some daemons, and especially for their privsep child processes - regardless of whether they make use of namespaces (vsftpd) or not (openssh). So maybe the restriction should apply to a process tree rather than to a namespace? Sure, in some cases it could be bypassed via ptrace(), but the intended uses would be either in containers (separate pid namespace) or in daemons' privsep child processes, which are hopefully running as a pseudo-user dedicated to the daemon - so can't ptrace() anything else because of uid mismatch, and can't ptrace() other instances because of their dumpable flag having been reset on setuid(). Specifically, the prctl() could set your two proposed flag bits affecting the following execve(), but it could also set a third bit, which, when set, would immediately lock the current process to its current bitness (or to current ABI in general) and would also lock execve()'d binaries in the same way (although in practice such processes will tend to be chrooted to /var/empty). So we have three bits: bit 0 - lock next execve() to 32-bit bit 1 - lock next execve() to 64-bit bit 2 - lock current process and execve() to current bitness/ABI Specific bit combinations are interpreted as follows: 0 - no locking (current behavior) 1 - lock next execve() to 32-bit, fail it if not 32-bit ELF 2 - lock next execve() to 64-bit, fail it if not 64-bit ELF 3 - lock the next execve()'d process to its actual bitness 4 - lock current process and execve() to current bitness 5 - lock current process to current bitness, but execve() to 32-bit ELF 6 - lock current process to current bitness, but execve() to 64-bit ELF 7 - lock current process to current bitness, but next execve() to its actual bitness 5 to 7 are probably not very useful, but are defined for consistency. Maybe when bit 2 is set, it should also disable ptrace() for the current process (so that it can't ptrace() other processes even of matching uid). How does this sound to you? Concern/to-do: need to figure out how x32 and other ABIs fit into this. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.