lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 29 Nov 2010 11:05:58 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Marcus Meissner <meissner@...e.de>,
	linux-kernel@...r.kernel.org, tj@...nel.org,
	akpm@...ux-foundation.org, w@....eu, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of
 attacking

On 11/29/2010 10:04 AM, Ingo Molnar wrote:
> 
> * Sarah Sharp <sarah.a.sharp@...ux.intel.com> wrote:
> 
>> On Fri, Nov 26, 2010 at 08:48:09AM +0100, Ingo Molnar wrote:
>>>
>>> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>>>
>>>> On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
>>>> <sarah.a.sharp@...ux.intel.com> wrote:
>>>>>
>>>>> .config and dmesg are attached.  The box is running klogd 1.5.5ubuntu3
>>>>> (from Jaunty).  Yes, I know that's old.  I read the bit in the commit
>>>>> about changing the permissions of kallsyms after boot, but if I can't
>>>>> boot that doesn't help.  Perhaps this can be made a configuration
>>>>> option?
>>>>
>>>> It's not worth a config option.
>>>>
>>>> If it actually breaks user-space, I think we should just revert it.
>>>
>>> Sarah,
>>>
>>> Does your system boot fine if we make /proc/kallsyms simply an empty file to 
>>> unprivileged users? Something like the (untested ...) patch below.
>>
>> Yes, that works.  The system boots as normal. `cat /proc/kallsyms`
>> returns an empty file, and `sudo cat /proc/kallsyms` does not.
> 
> Great! Marcus, mind respinning your patch with that approach?
> 

Can we please not use CAP_SYS_ADMIN for this?  Relying on CAP_SYS_ADMIN
is worse than anything else -- it is a fixed policy hardcoded in the
kernel, with no ability for the system owner to delegate the policy
outward, e.g. by adding group read permission and/or chgrp the file.

Delegating CAP_SYS_ADMIN, of course, otherwise known as "everything", is
worse than anything...
	
	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ