procfs privacy: misc. entries
PATCH 3/7 procfs privacy: misc. entries
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
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
fs/proc/proc_misc.c renamed from fs/proc/proc_misc.c~proc-privacy-1 +13 -12
@@ -552,18 +552,14 @@ void __init proc_misc_init(void)int (*read_proc)(char *,char **,off_t ,int ,int *,void *); } *p, simple_ones[] = { {"loadavg", loadavg_read_proc}, - {"uptime", uptime_read_proc}, {"meminfo", meminfo_read_proc}, - {"version", version_read_proc}, #ifdef CONFIG_PROC_HARDWARE {"hardware", hardware_read_proc}, #endif #ifdef CONFIG_STRAM_PROC {"stram", stram_read_proc}, #endif - {"devices", devices_read_proc}, {"filesystems", filesystems_read_proc}, - {"cmdline", cmdline_read_proc}, {"locks", locks_read_proc}, {"execdomains", execdomains_read_proc}, {NULL,}
@@ -571,25 +567,30 @@ void __init proc_misc_init(void)for (p = simple_ones; p->name; p++)create_proc_read_entry (p->name,0 ,NULL , p->read_proc,NULL ); +create_proc_read_entry ("devices" ,S_IRUSR ,NULL , &devices_read_proc,NULL ); +create_proc_read_entry ("cmdline" ,S_IRUSR ,NULL , &cmdline_read_proc,NULL ); +create_proc_read_entry ("version" ,S_IRUSR ,NULL , &version_read_proc,NULL ); +create_proc_read_entry ("uptime" ,S_IRUSR ,NULL , &uptime_read_proc,NULL ); +proc_symlink ("mounts" ,NULL ,"self/mounts" );/* And now for trickier ones */ entry =create_proc_entry ("kmsg" ,S_IRUSR , &proc_root);if (entry) entry->proc_fops = &proc_kmsg_operations; -create_seq_entry ("cpuinfo" ,0 , &proc_cpuinfo_operations); -create_seq_entry ("partitions" ,0 , &proc_partitions_operations); -create_seq_entry ("stat" ,0 , &proc_stat_operations); -create_seq_entry ("interrupts" ,0 , &proc_interrupts_operations); -create_seq_entry ("slabinfo" ,S_IWUSR |S_IRUGO ,&proc_slabinfo_operations); +create_seq_entry ("cpuinfo" ,S_IRUSR , &proc_cpuinfo_operations); +create_seq_entry ("partitions" ,S_IRUSR , &proc_partitions_operations); +create_seq_entry ("stat" ,S_IRUSR , &proc_stat_operations); +create_seq_entry ("interrupts" ,S_IRUSR , &proc_interrupts_operations); +create_seq_entry ("slabinfo" ,S_IWUSR |S_IRUSR ,&proc_slabinfo_operations);create_seq_entry ("buddyinfo" ,S_IRUGO , &fragmentation_file_operations);create_seq_entry ("vmstat" ,S_IRUGO , &proc_vmstat_file_operations); -create_seq_entry ("diskstats" ,0 , &proc_diskstats_operations); +create_seq_entry ("diskstats" ,S_IRUSR , &proc_diskstats_operations);#ifdef CONFIG_MODULES -create_seq_entry ("modules" ,0 , &proc_modules_operations); +create_seq_entry ("modules" ,S_IRUSR , &proc_modules_operations);#endif #ifdef CONFIG_SCHEDSTATS -create_seq_entry ("schedstat" ,0 , &proc_schedstat_operations); +create_seq_entry ("schedstat" ,S_IRUSR , &proc_schedstat_operations);#endif #ifdef CONFIG_PROC_KCORE proc_root_kcore =create_proc_entry ("kcore" ,S_IRUSR ,NULL );
_
Quoted 8 lines · Lorenzo Hernández García-Hierro
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
Quoted 2 lines · Dave Jones
This is utterly absurd. You can find out anything thats in
/proc/cpuinfoby calling cpuid instructions yourself.
Right, it doesn't make it worthy enough to represent any risk.
Quoted 2 lines
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.
Quoted 4 lines
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.
Signature · 2 lines
Lorenzo Hernández García-Hierro <[email protected]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Quoted 8 lines · Lorenzo Hern�ndez Garc�a-Hierro
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribi�:
Quoted 4 lines
This is utterly absurd. You can find out anything thats in
/proc/cpuinfoby 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.
Dave Jones writes the following:
Quoted 4 lines · Lorenzo Hernández García-Hierro
Quoted 2 lines
This patch changes the permissions of the following procfs entries to restrict non-root users from accessing them:
[snip]
Quoted 1 line
Quoted 1 line
-
/proc/uptime
^^^^^^^^^^^^ ?!
[snip]
Quoted 4 lines
Quoted 1 line
-
/proc/cpuinfoThis is utterly absurd. You can find out anything thats in
/proc/cpuinfoby 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.
Quoted 7 lines
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).