On 01/25/12 08:07, Stephen Smalley wrote:
> On Tue, 2012-01-24 at 11:22 -0500, David Quigley wrote:
>> 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?
>
> The /proc/pid files are labeled with the same security context as the
> associated task via security_task_to_inode() -> selinux_task_to_inode().
> There is presently no support for distinguishing /proc/pid files in
> policy, unlike other files in /proc. As processes are expected to be
> able to write to various files under /proc/self, this is allowed by
> policy.
And to be specific, all domains are allowed to rw their own /proc/pid files in refpolicy (see domain.te).
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
