[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5255D2FD.6050705@gmail.com>
Date: Thu, 10 Oct 2013 09:04:45 +1100
From: Ryan Mallon <rmallon@...il.com>
To: Joe Perches <joe@...ches.com>
CC: Andrew Morton <akpm@...ux-foundation.org>, eldad@...refinery.com,
Jiri Kosina <jkosina@...e.cz>,
jgunthorpe@...idianresearch.com,
Dan Rosenberg <dan.j.rosenberg@...il.com>,
Kees Cook <keescook@...omium.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
George Spelvin <linux@...izon.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] vsprintf: Check real user/group id for %pK
On 10/10/13 09:00, Joe Perches wrote:
> On Thu, 2013-10-10 at 08:52 +1100, Ryan Mallon wrote:
>> Some setuid binaries will allow reading of files which have read
>> permission by the real user id. This is problematic with files which
>> use %pK because the file access permission is checked at open() time,
>> but the kptr_restrict setting is checked at read() time. If a setuid
>> binary opens a %pK file as an unprivileged user, and then elevates
>> permissions before reading the file, then kernel pointer values may be
>> leaked.
>
> Please review the patch I sent you a little more.
>
>> Fix this by adding a check that in addition to the current process
>> having CAP_SYSLOG, that effective user and group ids are equal to the
>> real ids. If a setuid binary reads the contents of a file which uses
>> %pK then the pointer values will be printed as NULL if the real user
>> is unprivileged.
>
> []
>
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> []
>> @@ -1312,11 +1313,37 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
>> spec.field_width = default_width;
>> return string(buf, end, "pK-error", spec);
>> }
>
> Move the interrupt tests and pK-error printk
> into case 1:
>
> It's the only case where CAP_SYSLOG needs to be
> tested so it doesn't need to be above the switch.
Like I said, I think it is useful to do the pK-error check anyway. It is
checking for internal kernel bugs, since if 'pK-error' ever gets
printed, then some kernel code is doing the wrong thing. Therefore, I
think it is useful to print it always (I would argue it even makes sense
when kptr_restrict=0). I decided to just leave that part of the code alone.
~Ryan
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.
