From owner-freebsd-hackers Mon Nov 8 13:18:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 6061114C43; Mon, 8 Nov 1999 13:18:39 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40326>; Tue, 9 Nov 1999 08:12:45 +1100 Content-return: prohibited Date: Tue, 9 Nov 1999 08:18:32 +1100 From: Peter Jeremy Subject: Re: Procfs' pointers to files. To: green@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov9.081245est.40326@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 7 Nov 1999 10:15:42 -0500 (EST), Brian Fundakowski Feldman wrote: >The _REALLY_ obvious solution to this is to find the real path on exec() >and store the pointer in proc. How is this full of "overhead" and >"impractical"? Finding _an_ absolute path on exec() is not too hard (though it's not totally trivial). At worst, it requires knowledge of the process WD and then following a relative path (expanding symlinks along the way). The problems I can see are: - In theory, converting from a relative to absolute pathname can result in a pathname exceeding MAXPATHLEN bytes. - A process may not have the permissions to translate it's CWD into an absolute pathname. (Consider a couple of mode 111 directories). - Either proc would need to grow by MAXPATHLEN, or a suitable external buffer would need to be malloc'd to hold the path. - In the case of jail()d or chroot()d processes, the resultant path would be relative to the jail, not the `normal' filesystem. - The pathname used for the original exec() is not guaranteed to be valid after the exec() - parts of it could be deleted or moved. On Sat, 6 Nov 1999 15:54:50 -0500 (EST), Brian Fundakowski Feldman wrote: > does it seem as if the pathname of the executable being stored as >a virtual symlink in procfs as "file" would solve these security >problems? I'm not convinced that this solves all the security problems, though it does solve most of them. My major concern would be that it would leak information relating to the contents of execute-only directories (which may or may not be important). Maybe, rather than trying to solve the general case, we look at what (valid) uses there are for /proc/xxx/file, and what permissions they need. As far as I can see, the only purposes are to allow a debugger to access the executable and to allow the process to re-exec itself. In particular, I can't see any reason for UIDs other than root or the process itself having any access at all. In the case of non-setuid processes, this means that /proc/xxx/file should be owned by the process UID and the mode should be 500 or 100, depending on whether the UID had read permission to the original executable. Unfortunately, when you take setuid programs into account, it gets far less clear: Reasonable cases could be made for having the owner either the real or effective UID. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message