Date: Fri, 18 Oct 1996 14:57:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@whistle.com (Julian Elischer) Cc: Guido.vanRooij@nl.cis.philips.com, freebsd-hackers@FreeBSD.org, Andrew.Tridgell@anu.edu.au Subject: Re: fix for symlinks in /tmp (fwd) FYI Message-ID: <199610182157.OAA02061@phaeton.artisoft.com> In-Reply-To: <3267F479.773C2448@whistle.com> from "Julian Elischer" at Oct 18, 96 02:19:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I believe this change fixes all the "symlink-in-/tmp" style of > > security holes while having a minimal impact on the normal use of > > symlinks. > > I wonder if anyone can comment on this... > My initial reaction is that it's breaking the expected behaviour > or the system to do this.... > If I see a symlink I expect it to be followed.. The problem is that when you export a directory hierarchy with a hosted OS/file server, all inferior directories (mounted or not) are expected to be exported. It's as if you had an NFS server that exported /home and /usr, which were on seperate FS's, just because you exported /. The problem comes in when you put a symlink in /tmp (or any other directory to which you have access) which targets a system file. Since the server runs as root, if it's in your hierarchy, it's yours. The cannonically correct fix would be for SAMBA to export on a per FS basis (just like NFS). It would have to do this anyway, if it were ever migrated to kernel space, where it really belongs. The "next best fix" would be to lstat targets, and readlink to expand paths to their correct values in user space, and then treat the path as relative to an exported "drive" if the prefix was the same as an exported drive "export point" in the FS hierarchy. Since lstat returns the same info as stat fron non-symlink targets, it would be an additional compare (for a link target) in the case that a symlnk was being used to (potentially) attempt a security violation by "going off the volume". This is a relatively trivial hack (about as trivial as speed optimizing the SAMBA directory lookup code or its read path -- both optimizations which need to be done, IMO). > > Can anyone see any problems with this proposal? > > I just don't like it? It's the wrong fix. There are at least two better fixes, both of which generally apply to systems where the proposed fix can't be applied (the "volume only" export" could be handled in user space on systems by comparing the s_dev field of the stat buffer with the "export point" s_dev field, and refusing the request -- even works on AIX). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610182157.OAA02061>