[228] in linux-security and linux-alert archive
Re: Security problem in proc fs
daemon@ATHENA.MIT.EDU (Ian Jackson)
Sun May 7 12:45:06 1995
Date: Sun, 7 May 95 13:53 BST
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: linux-kernel@vger.rutgers.edu, linux-security@tarsier.cv.nrao.edu
(Crossposted to linux-security as well as linux-kernel.)
Peter Alban writes ("Security problem in proc fs"):
> I think I found a BIG security bug in the proc file system.
> The permission and ownerships for the file descriptor entries in the fd
> subdirectories are wrong.
> The permission for such a file are (if the file was opened O_RDWR) readable
> and writable for all processes with the same euid as the process which owns
> these file descriptor CURRENTLY has.
> eg: A suid program which opened /dev/mem (O_RDWR) and later does a
> 'seteuid(getuid())' (like every svgalib program) allows every user to
> clone a read and writable fd to /dev/mem.
I have reproduced this and it is a security hole. It should be fixed
urgently. Unfortunately I'm not competent enough as a kernel hacker
to do so.
> I think a file descriptor entry in the proc fs should have the same owner
> (uid) and group (gid) as the inode which belong to the descriptor. ( if this
> field has a meaningful value -- in socket inodes these fields are always
> zero ) and the permissions should be a mix of the permission of the inode and
> the permissions of the file descriptor. (the directory is only read and
> searchable for processes with the same euid)
No. This is the *wrong* thing to do. The permissions and ownerships
of the file referred to by the file descriptor are not really relevant
here (even if they can be determined).
Access to /proc/.../fd should be allowed iff the process doing the
access would be allowed to ptrace the process being accessed.
Clearly restricting the use of /proc/.../fd any more would be futile,
as the `attacker' could just ptrace the process owning the descriptor
and access it that way.
Restricting the use of /proc/.../fd any less is very dangerous,
because it allows a user to attack (for example) a set-uid program in
a way that breaches the usual assurances that the kernel gives to
priveliged programs that their operation will not be interfered with.
File descriptor integrity is one of these key assurances that setuid
programs, daemons and so on rely on.
I have said this before. I'm disappointed that I'm having to say it
again.
Ian.
