Recent /proc/pid/mem exploit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So I read through the recent privilege escalation vulnerability using su and gpasswd which exploits weak permission checks in /proc/pid/mem and tried to figure out why we didn't stop it. What it comes down to is that /proc/pid and everything under it is given the same type as the process itself. In the case of the gpasswd that type is groupadd_t. Looking at the kernel code for /proc/pid/mem and its read/write functions it seems that the only permission checking we do on that node is done by the vfs. So from the SELinux perspective you would need allow groupadd_t groupadd_t file:{open read write} to have access to /proc/pid/mem. For some odd reason tons and tons of applications have file:{open read and write} on itself.

One question that should be asked is why is is that we have so many rules that contain sometype_t sometype_t file: {open read write}. Is it necessary or something that is just being pulled in from a macro. If this is necessary for other reasons the followup to this would be should /proc/pid/mem have the same type as the process or should we have some additional requirements permission wise for a process to read and write to its own memory through /proc/pid/mem. What are the valid reasons for a process to be poking around through its memory using /proc/pid/mem?

Dave
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux