Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755789Ab3H2DdX (ORCPT ); Wed, 28 Aug 2013 23:33:23 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:60217 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755760Ab3H2DdV (ORCPT ); Wed, 28 Aug 2013 23:33:21 -0400 MIME-Version: 1.0 In-Reply-To: <87li3l5mnh.fsf@xmission.com> References: <1377534240-13227-1-git-send-email-tixxdz@opendz.org> <871u5gqtw3.fsf@xmission.com> <20130826172054.GE27005@ZenIV.linux.org.uk> <20130827172406.GA2664@dztty> <20130828201141.GA21455@dztty> <20130828211116.GA22184@dztty> <87sixt735b.fsf@xmission.com> <87li3l5mnh.fsf@xmission.com> Date: Wed, 28 Aug 2013 20:33:20 -0700 X-Google-Sender-Auth: -QbtbTuYM_QRqfju1PgU0E4P_Bo Message-ID: Subject: Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality} From: Kees Cook To: "Eric W. Biederman" Cc: Djalal Harouni , Al Viro , Andrew Morton , Solar Designer , Vasiliy Kulikov , Linus Torvalds , Ingo Molnar , LKML , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2339 Lines: 60 On Wed, Aug 28, 2013 at 6:08 PM, Eric W. Biederman wrote: > Kees Cook writes: > >> On Wed, Aug 28, 2013 at 5:26 PM, Eric W. Biederman >> wrote: >>> Can someome please state what they are worried about in simple language >>> step by step? >>> [...] >>> The closest I saw in the thread was people were worried about ASLR being >>> defeated. All I see are kernel addresses and we don't have much if any >>> runtime or even load time randomization of where code is located in the >>> kernel address map on x86_64. So I don't understand the concern. >> >> I showed the output of "syscall", since that contains user-space >> addresses and shows a leak of ASLR from a privileged process to an >> unprivileged process. >> >> The flaw as I see it is that an unprivileged process opens >> /proc/$priv_pid/syscall and passes it to a setuid process which is >> able to read it, and provides those contents to the unprivileged >> process. >> >> The unprivileged process should not be able to the open the file in >> the first place. > > I see so the complaint is that we don't give read permission but we do > give open permission. Which is a variant of: the permissions used to > open are not the permission used to access the file. > > This does seem to be a legitimate concern. > > I think there are several discussions that have been going on lately > with respect to this class of problems in proc files. > > Given the existence of suid exec we can not in general prevent this > class of bugs with a check at open time. I'm not suggesting removing the read check -- that's certainly needed. > I believe the solution needs to be to enhance the ptrace_may_access > checks to verify that both the creds of the current task and the creds > of the opening process would have allowed the access. As in, DAC perms are insufficient? > We may want to put this check in permission so open fails quickly but > we absolutely need to put this check in at the time we call > ptrace_may_access. -Kees -- 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/