Date: Tue, 9 Nov 1999 08:18:32 +1100 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: green@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Procfs' pointers to files. Message-ID: <99Nov9.081245est.40326@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
On Sun, 7 Nov 1999 10:15:42 -0500 (EST), Brian Fundakowski Feldman <green@FreeBSD.org> 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 <green@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Nov9.081245est.40326>