Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease ofattacking

[H. Peter Anvin]

On 11/29/2010 10:04 AM, Ingo Molnar wrote:
> 
> * Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote:
> 
>> On Fri, Nov 26, 2010 at 08:48:09AM +0100, Ingo Molnar wrote:
>>>
>>> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>>> On Fri, Nov 19, 2010 at 11:19 AM, Sarah Sharp
>>>> <sarah.a.sharp@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/