From owner-freebsd-hackers  Mon Mar 27 14:25:11 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP
	id D341C37BB03; Mon, 27 Mar 2000 14:25:05 -0800 (PST)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa69356@salmon>; 27 Mar 2000 23:25:02 +0100 (BST)
To: Warner Losh <imp@village.org>
Cc: hackers@FreeBSD.ORG, des@FreeBSD.ORG, pb@FreeBSD.ORG
Subject: Re: Linprocfs observation. 
In-reply-to: Your message of "Mon, 27 Mar 2000 14:17:52 PDT."
             <200003272117.OAA99918@harmony.village.org> 
X-Request-Do: 
Date: Mon, 27 Mar 2000 23:25:02 +0100
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID:  <200003272325.aa69356@salmon.maths.tcd.ie>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> File was removed because it was a huge, gaping security hole.  It was
> effectively hard link to the file in question and circumvented some of
> the usual security protections that the file would otherwise be
> protected by.

I know - AFAIK I was the one who reported it ;-)

> : Linux itself is not subject to this problem because it's exe file
> : is a synthetic symlink pointing to the executable, not something
> : which returns the executables actual vnode. 
> 
> And that's why it is still in the tree.  A symbolic link doesn't have
> the security issues that the hard link has.

I think I wasn't clear. The real Linux code doesn't have this problem,
but the code in /usr/src/sys/miscfs/linprocfs, which was committed to
4.0 and 5.0 two days ago does.

> : Also, on Linux the
> : symlink is only readable by the process' owner. This suggests the
> : following possible work around:
> : 	1) Add a directory /linproc/pid/private which is only
> : 		executable and readable by the process' owner.
> : 	2) Make the "exe" file in /linproc/pid/ a symlink to
> : 		"./private/exe", which is the file which gives
> : 		you the executables real vnode.
> : I think this will give the same behavior as the Linux procfs, and
> : expose less suid stuff. It would be necessary to do something very
> : like this if we ever have to implement /linproc/pid/fd/xx.
> 
> Why bother?  No body should be using file/exe at all.  It is a useless
> misfeature.  What actually uses it?

I think Linux programs may actually use it, and it is included in
the linprocfs code to allow them to operate. Looking quickly on a
Redhat box here:

	turing% grep -l '/proc.*exe' /lib/* /bin/* /usr/bin/* /usr/local/bin/* 
	/lib/ld-2.1.2.so
	/lib/ld-linux.so.2
	/lib/libc-2.1.2.so
	/lib/libc.so.6
	/bin/ash.static
	/bin/rpm
	/usr/bin/killall
	/usr/bin/libgtop_daemon
	/usr/bin/ltrace
	/usr/bin/rpm2cpio

Given that libc is using it for something, it is probably important
to provide a working one in linprocfs, preferably without the
security hole!

	David.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message