FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 01-24-2012, 03:22 PM
David Quigley
 
Default Recent /proc/pid/mem exploit

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 01-25-2012, 12:07 PM
Stephen Smalley
 
Default Recent /proc/pid/mem exploit

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.

Implementing support for labeling different /proc/pid inodes differently
might be an interesting project.

--
Stephen Smalley
National Security Agency

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

Thread Tools




All times are GMT. The time now is 08:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org