This patch changes the permissions of the following procfs entries to
restrict non-root users from accessing them:
- /proc/devices
- /proc/cmdline
- /proc/version
- /proc/uptime
- /proc/cpuinfo
- /proc/partitions
- /proc/stat
- /proc/interrupts
- /proc/slabinfo
- /proc/diskstats
- /proc/modules
- /proc/schedstat
It's also available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_fs_proc_proc_misc.c.patch
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> This patch changes the permissions of the following procfs entries to
> restrict non-root users from accessing them:
>
> - /proc/devices
> - /proc/cmdline
> - /proc/version
> - /proc/uptime
> - /proc/cpuinfo
This is utterly absurd. You can find out anything thats in /proc/cpuinfo
by calling cpuid instructions yourself.
Please enlighten me as to what security gains we achieve
by not allowing users to see this ?
Restricting lots of the other files are equally absurd.
I'd also be very surprised if various random bits of userspace
broke subtley due to this nonsense.
Dave
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribi?:
> This is utterly absurd. You can find out anything thats in /proc/cpuinfo
> by calling cpuid instructions yourself.
Right, it doesn't make it worthy enough to represent any risk.
> Please enlighten me as to what security gains we achieve
> by not allowing users to see this ?
It's more obscurity than anything else. At least that's what privacy
means usually. It doesn't assure at all the unavailability of your
information to others, it just tries to hide it from the public eye.
> Restricting lots of the other files are equally absurd.
>
> I'd also be very surprised if various random bits of userspace
> broke subtley due to this nonsense.
I agree, as an example, grsecurity allows the configuration of a group
with rights over the restricted entries, that's why I split up the patch
for these entries.
Thanks for the comments.
Cheers.
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Dave Jones writes the following:
>
>On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> > This patch changes the permissions of the following procfs entries to
> > restrict non-root users from accessing them:
[snip]
> > - /proc/uptime
^^^^^^^^^^^^ ?!
[snip]
> > - /proc/cpuinfo
>
>This is utterly absurd. You can find out anything thats in /proc/cpuinfo
>by calling cpuid instructions yourself.
Also it's the backend of glibc's get_nprocs(), also known as
sysconf(_SC_NPROCESSORS_ONLN), a documented interface whose users are
probably not expecting it to suddenly become restricted to root.
>Please enlighten me as to what security gains we achieve
>by not allowing users to see this ?
>
>Restricting lots of the other files are equally absurd.
>
>I'd also be very surprised if various random bits of userspace
>broke subtley due to this nonsense.
Like uptime(1), a command which has existed basically unchanged since 3.0BSD
(note to observers: if you think that's a funny way of writing "FreeBSD 3.0",
you're off by at least a decade and a half).
Lorenzo Hern?ndez Garc?a-Hierro wrote:
>El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribi?:
>> This is utterly absurd. You can find out anything thats in /proc/cpuinfo
>> by calling cpuid instructions yourself.
>> Please enlighten me as to what security gains we achieve
>> by not allowing users to see this ?
>
>It's more obscurity than anything else. At least that's what privacy
>means usually.
Well, that's not what the word "privacy" means to me. It seems to me
there are plenty of "privacy" issues that are real and legitimate and
have nothing to do with obscurity.
I agree with Dave Jones. Security through obscurity makes no sense.