From patchwork Mon Jul 10 07:57:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 9832529 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8039D60363 for ; Mon, 10 Jul 2017 07:59:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 75D4426E3A for ; Mon, 10 Jul 2017 07:59:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6790D283F9; Mon, 10 Jul 2017 07:59:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0F47026E3A for ; Mon, 10 Jul 2017 07:59:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753560AbdGJH7s (ORCPT ); Mon, 10 Jul 2017 03:59:48 -0400 Received: from mail-pg0-f46.google.com ([74.125.83.46]:36010 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753584AbdGJH5p (ORCPT ); Mon, 10 Jul 2017 03:57:45 -0400 Received: by mail-pg0-f46.google.com with SMTP id u62so45411497pgb.3 for ; Mon, 10 Jul 2017 00:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=YAe+2b2yLXnscpP2VB9PZEtGJFtPtxSfSWD87eoJ8HM=; b=VHKPKkqzLwOXUWAYzR6OUhkVDbo+TDdAXOSgVOGl04zHID7pIlg2qpGLzpY330baP6 h7OvgNBzqg3HrzM1MtMH9Ct6HliFPTqnDwuWFQXYSJwR4LRoMAHAmWEyserzuyb1zUr7 xXbKuCAo4JoEkyn1770yJUwtX1lqO9xjg0kH0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=YAe+2b2yLXnscpP2VB9PZEtGJFtPtxSfSWD87eoJ8HM=; b=gIgovIGcvBdKt7vllgIAoXHldpF3hS12p85HE0Kapecb1WZuvUYMM9TJCCqQrjRZHh qVT2Hd7B0HPP1aai6ixS/3IjU0f68+9MC6wwv5pozNyUsCtlPnKiPeVL9Q6t7pXgvSVl DXKJhtvOPoTTysrMN72dEO5EpeplCvKF0MmvcAj3Y+47pNQBNiWv+IcrxOcBA0h9RIl+ 4RWdpBItNJ9jrCRaZUV+fXH0B6iXcVu2PMs5Ur4RJJEgQF/IkHtEj1W84SRKlEpfm77S Bi+/hN6SMoAjPmOKL4KM5TeyYAafgxMd9yNBvANmpA6c+jTfpcimjY6WJz47nkEr+BF1 y7Lg== X-Gm-Message-State: AIVw112uW6v/hcULwiFXgknfCUJHXGzt2cmFljwtcC6J9rD2FxSHBqym Tx1Ujsq0nfwMMO/c X-Received: by 10.99.143.94 with SMTP id r30mr13381918pgn.102.1499673464540; Mon, 10 Jul 2017 00:57:44 -0700 (PDT) Received: from www.outflux.net (173-164-112-133-Oregon.hfc.comcastbusiness.net. [173.164.112.133]) by smtp.gmail.com with ESMTPSA id b7sm23520225pfl.44.2017.07.10.00.57.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 00:57:42 -0700 (PDT) From: Kees Cook To: Linus Torvalds Cc: Kees Cook , Andy Lutomirski , David Howells , Serge Hallyn , John Johansen , Casey Schaufler , "Eric W. Biederman" , Alexander Viro , Michal Hocko , Ben Hutchings , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , James Morris , Greg Ungerer , Ingo Molnar , Nicolas Pitre , Stephen Smalley , Paul Moore , Vivek Goyal , =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , Tetsuo Handa , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov Subject: [PATCH v2 8/8] exec: Use sane stack rlimit under secureexec Date: Mon, 10 Jul 2017 00:57:31 -0700 Message-Id: <1499673451-66160-9-git-send-email-keescook@chromium.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499673451-66160-1-git-send-email-keescook@chromium.org> References: <1499673451-66160-1-git-send-email-keescook@chromium.org> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP For a secureexec, before memory layout selection has happened, reset the stack rlimit to something sane to avoid the caller having control over the resulting layouts. $ ulimit -s 8192 $ ulimit -s unlimited $ /bin/sh -c 'ulimit -s' unlimited $ sudo /bin/sh -c 'ulimit -s' 8192 Signed-off-by: Kees Cook --- fs/exec.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/exec.c b/fs/exec.c index e0186db02f90..1e3463854a16 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1343,6 +1343,16 @@ void setup_new_exec(struct linux_binprm * bprm) /* Make sure parent cannot signal privileged process. */ current->pdeath_signal = 0; + + /* + * For secureexec, reset the stack limit to sane default to + * avoid bad behavior from the prior rlimits. This has to + * happen before arch_pick_mmap_layout(), which examines + * RLIMIT_STACK, but after the point of no return to avoid + * needing to clean up the change on failure. + */ + if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM) + current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM; } arch_pick_mmap_layout(current->mm);