Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755936Ab2FESNN (ORCPT ); Tue, 5 Jun 2012 14:13:13 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:46365 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755744Ab2FESNI convert rfc822-to-8bit (ORCPT ); Tue, 5 Jun 2012 14:13:08 -0400 MIME-Version: 1.0 In-Reply-To: References: <4FCE3C18.4080302@amacapital.net> Date: Tue, 5 Jun 2012 13:13:05 -0500 Message-ID: Subject: Re: Docs for PR_SET_NO_NEW_PRIVS From: Will Drewry To: Kees Cook Cc: Andy Lutomirski , Linux Kernel Mailing List , Andrew Morton , linux-security-module@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, hpa@zytor.com, mingo@redhat.com, peterz@infradead.org, tglx@linutronix.de, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, indan@nul.nu, pmoore@redhat.com, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org, coreyb@linux.vnet.ibm.com, jmorris@namei.org, linux-man@vger.kernel.org, Michael Kerrisk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4017 Lines: 97 On Tue, Jun 5, 2012 at 12:33 PM, Kees Cook wrote: > Hi, > > As-is, this could probably live in > Documentation/security/no-new-privs.txt (maybe with some examples > added). Or Documentation/prctl/no-new-privs.txt Just a decision between what it does and how you get to it, but I'd think either would make sense! > As for a manpage section, I think Michael Kerrisk would happily add a > section for PR_[SG]ET_NO_NEW_PRIVS to prctl if this could be > summarized into a paragraph or two. > > (And this reminds me I should send an update for the seccomp section > in the prctl manpage too.) Faster on the draw than me - thanks! > > On Tue, Jun 5, 2012 at 10:04 AM, Andy Lutomirski wrote: >> Hi all- >> >> As promised (although belatedly), I wrote up some proposed documentation >> for the no_new_privs feature. ?What should I do with it? ?I don't speak >> groff/troff/whatever man pages are written in. >> >> I would be happy to license this text appropriately for whatever tree >> it might end up in. ?In the mean time, it's GPLv2+. >> >> --- cut here --- >> >> The execve system call can grant a newly-started program privileges >> that its parent did not have. ?The most obvious examples are >> setuid/setgid programs and file capabilities. ?To prevent the parent >> program from gaining these privileges as well, the kernel and user >> code must be careful to prevent the parent from doing anything that >> could subvert the child. ?For example: >> >> ?- The dynamic loader handles LD_* environment variables differently >> if a program is setuid. >> ?- chroot is disallowed to unprivileged processes, since it would >> allow /etc/passwd to be replaced from the point of view of a process >> that inherited chroot. >> ?- The exec code has special handling for ptrace. >> >> These are all ad-hoc fixes. ?The no_new_privs bit (since Linux 3.5) is >> a new, generic mechanism to make it safe for a process to modify its >> execution environment in a manner that persists across execve. ?Any >> task can set no_new_privs. ?Once the bit is set, it is inherited >> across fork, clone, and execve and cannot be unset. ?With no_new_privs >> set, execve promises not to grant the privilege to do anything that >> could not have been done without the execve call. ?For example, the >> setuid and setgid bits will no longer change the uid or gid; file >> capabilities will not add to the permitted set, and LSMs will not >> relax constraints after execve. >> >> Note that no_new_privs does not prevent privilege changes that do not >> involve execve. ?An appropriately privileged task can still call >> setuid(2) and receive SCM_RIGHTS datagrams. >> >> There are two main use cases for no_new_privs so far: >> >> ?- Filters installed for the seccomp mode 2 sandbox persist across >> execve and can change the behavior of newly-executed programs. >> Unprivileged users are therefore only allowed to install such filters >> if no_new_privs is set. >> >> ?- By itself, no_new_privs can be used to reduce the attack surface >> available to an unprivileged user. ?If everything running with a given >> uid has no_new_privs set, then that uid will be unable to escalate its >> privileges by directly attacking setuid, setgid, and fcap-using >> binaries; it will need to compromise something without the >> no_new_privs bit set first. >> >> In the future, other potentially dangerous kernel features could >> become available to unprivileged tasks if no_new_privs is set. ?In >> principle, several options to unshare(2) and clone(2) would be safe >> when no_new_privs is set, and no_new_privs + chroot is considerable >> less dangerous than chroot by itself. >> >> --- cut here --- >> >> --Andy > > > > -- > Kees Cook > Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/