Date: Sat, 4 Jul 1998 20:51:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: easmith@beatrice.rutgers.edu (Allen Smith) Cc: sthaug@nethelp.no, lada@pc8811.gud.siemens.at, hackers@FreeBSD.ORG Subject: Re: Variant Link implementation, continued Message-ID: <199807042051.NAA01973@usr02.primenet.com> In-Reply-To: <9807030628.ZM9030@beatrice.rutgers.edu> from "Allen Smith" at Jul 3, 98 06:28:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > If anybody should ever consider something similar to HP-UX CDFs, I'd > > strongly suggest that this should only be available to root by default. > > (on the assumption that root users know what they're doing). > > > > At one of my former employers we had a large number of HP-UX diskless > > hosts, using CDFs. We saw far too many cases of users inadvertently > > having their directories "disappear" (and similar problems) because > > they had turned the CDF bit on. It was a real support hassle. > > Another reason to have this limit is to prevent people from hiding > files using it from various security checking tools; see Garfinkel & > Spafford's _Practical Unix & Internet Security_, pages 136-137. (To > give you some idea, it's under "Oddities and Dubious Ideas" for a > reason.) CDF's have a number of technical problems, not the least of which is their abuse. The are similar in nature to Macintosh "resource forks". A better model is the OS/2 "extended attributes", which tend to scale vastly better (consider Macintosh PPC dual-mode binaries as an example of the wrong way to do things). True variant symbolic links (or even the more limited VMS "logical names", which are left-anchored instead of free-floating in the path), do not have these issues, primarily because the link target must be an exposed namespace. Even if you were to miss the consequences of a link target. The one real security issue that this introduces is suid/sgid binaries depending on a variant link. Consider /usr/bin/su, which is dynamically linked against: /usr/lib/libutil.so.2.2 /usr/lib/libskey.so.2.0 /usr/lib/libcrypt.so.2.0 /usr/lib/libc.so.3.0 One need only change the value that evaluates to "/usr/lib/" to stage a man-in-the-middle attack, right? This is very easily thwarted: 1) Use a system namespace introducer (such as "#"). 2) If the user directly calls an exec(3) family routine that takes an envp, and thus passes an envp to execve(2), then filter the incoming environment, removing system variables. 3) Reset the system variables per the normal methods used during loading the executable. In other words, protect regions of the namespace from user override. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199807042051.NAA01973>