morgan@ms.uky.edu (Wes Morgan) (02/15/90)
While performing a security audit on our AT&T 3B20, I discovered a
user's subdirectory with protection drws--x--x. Sure enough, chmod
will allow you to do this. I've never seen any code to make use of
a SUID directory, so my first reaction was that the user merely
mistyped an argument to chmod. Later, however, it occured to me
that since this is an undocumented capability, it may have either
properties or side effects detrimental to our security <or the
user's>.
Has anyone ever run into problems or benefits from an SUID directory?
If these are particularly gaping security holes, please email this
information rather than posting to the entire net. I can always
summarize any responses and post a neutered version for all those
hacker wanna-bes.... 8)
Wes Morgan
--
The opinions expressed above are not those of UKECC unless so noted.
Wes Morgan \ {rutgers,rayssd,uunet}!ukma!ukecc!morgan
University of Kentucky \ or morgan@engr.uky.edu
Engineering Computing Center \ or morgan%engr.uky.edu@UKMA.BITNETgwyn@smoke.BRL.MIL (Doug Gwyn) (02/16/90)
In article <14198@s.ms.uky.edu> morgan@ms.uky.edu (Wes Morgan) writes: >While performing a security audit on our AT&T 3B20, I discovered a >user's subdirectory with protection drws--x--x. Sure enough, chmod >will allow you to do this. I certainly hope so. >I've never seen any code to make use of a SUID directory, ... It can't be set-UID. Probably if it has a meaning (which I cannot tell without access to your system source) it is "only the owner is permitted to remove entries from this directory". That sort of thing is a fairly common extension to the standard UNIX file permissions scheme. Note also that what you might think are set-GID bits for files without the group "execute" bit set actually mean that mandatory file/record locking is to be enforced for the file, in recent UNIX releases. >... since this is an undocumented capability, it may have either >properties or side effects detrimental to our security <or the user's>. Look, it is not your business to tell the user how to set the modes on files he owns. There should be no security issue involved with this. What you have to worry about are modes on PUBLIC files.
guy@auspex.auspex.com (Guy Harris) (02/18/90)
>>I've never seen any code to make use of a SUID directory, ... > >It can't be set-UID. Probably if it has a meaning (which I cannot tell >without access to your system source) it is "only the owner is permitted >to remove entries from this directory". That sort of thing is a fairly >common extension to the standard UNIX file permissions scheme. The common extension of that flavor with which I'm familiar uses the "sticky bit" rather than the set-UID bit - at least it does in 4.3BSD and System V Release 3.2.
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (02/19/90)
In article <2946@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > >>I've never seen any code to make use of a SUID directory, ... > > > >It can't be set-UID. Probably if it has a meaning (which I cannot tell > >The common extension of that flavor with which I'm familiar uses the >"sticky bit" rather than the set-UID bit - at least it does in 4.3BSD There's another option, that is the capital S. That translates to "keep the same permissions below this directory" - or so I hear. -Kartik -- subbarao@{phoenix,bogey or gauguin}.princeton.edu - Internet subbarao@pucc.princeton.edu - Bitnet
dold@mitisft.Convergent.COM (Clarence Dold) (02/20/90)
> In article <2946@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >> >>I've never seen any code to make use of a SUID directory, ... I would suspect that code was written on a SysV 3.x system, that uses chmod to set the directory permissions to the new protections, and the code, now being run pre-3.x, produces bits that aren't understood, although they can still be set. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
net@tub.UUCP (Oliver Laumann) (02/20/90)
The set-UID bit on directories is ignored (at least in all version of UNIX that I'm familiar with). However, in SunOS the set-GID (GID, not UID) bit controls the group-ID of newly created sub-directories. If it is set, a sub-directory inherits the parent directory's group-ID (i.e. the standard BSD semantics), otherwise it is set to the process's current group-ID. Sub-directories inherit the parent directory's set-GID bit (see mkdir(2)). Regards, -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
shankar@hpclisp.HP.COM (Shankar Unni) (02/22/90)
> As an interesting note under HP-UX 7.0 . . . > > If you make a directory, then do "chmod +s mydir", you make the directory > disappear. Its inode is still in use, but there is no way to access the > directory. I assume that its entry in the parent directory is somehow > corrupted, as I can make as many directories with the same name as I wish. > > Any ideas why this might happen (addressed more-or-less specifically to > HP-UX support types at HP)? Yes, the directory gets changed to a "context-dependent file". (Context-dependent files are used for diskless clusters on HP-UX - the "context" is, for example, a hostname of a client, or generic designators like "remoteroot"). For example: % ll total 2 drwxrwxr-x 2 shankar c++ 24 Feb 21 13:59 JUNK % chmod +s JUNK % ll total 0 % ll -H (show CDF's) total 2 Hrwsrwsr-x 2 shankar c++ 24 Feb 21 13:59 JUNK+ Since there are no context entries inside this CDF, it becomes invisible. To "get it back", try: % chmod -s JUNK+ % ll total 2 drwxrwxr-x 2 shankar c++ 24 Feb 21 13:59 JUNK ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar DISCLAIMER: This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.
guy@auspex.auspex.com (Guy Harris) (02/23/90)
>>> >>I've never seen any code to make use of a SUID directory, ... > >I would suspect that code was written on a SysV 3.x system, that uses >chmod to set the directory permissions to the new protections, and the >code, now being run pre-3.x, produces bits that aren't understood, although >they can still be set. I repeat: I've never seen any code to make use of an SUID directory. System V Release 3 uses the setGid bit on files for mandatory locking, and V.3.2 uses the sticky bit for "sticky directories". V.4 uses the setGid bit on directories to get BSD-style file creation semantics for files in that directory (SunOS 4.x-style).
tml@hemuli.tik.vtt.fi (Tor Lillqvist) (02/25/90)
In article <26270009@hpclisp.HP.COM> shankar@hpclisp.HP.COM (Shankar Unni) writes:
)) As an interesting note under HP-UX 7.0 . . .
)Yes, the directory gets changed to a "context-dependent file".
)(Context-dependent files are used for diskless clusters on HP-UX - the
)"context" is, for example, a hostname of a client, or generic designators
)like "remoteroot").
The context-dependent files in HP-UX is IMHO a rather clever idea. A
bit like Apollo's symbolic links containing environment variables. Is
there any chance of other vendors taking up the idea?
--
Tor Lillqvist,
working, but not speaking, for the Technical Research Centre of Finlandchris@yarra.oz.au (Chris Jankowski) (02/26/90)
In article <4555@hemuli.tik.vtt.fi> tml@hemuli.tik.vtt.fi (Tor Lillqvist) writes: > In article <26270009@hpclisp.HP.COM> shankar@hpclisp.HP.COM (Shankar Unni) writes: > The context-dependent files in HP-UX is IMHO a rather clever idea. A > bit like Apollo's symbolic links containing environment variables. Is > there any chance of other vendors taking up the idea? Pyramid has been using conditional symbolic links for years. This is neatly integrated into Pyramid's OSx to support transparently the two universes - ATT and UCB. For example if you type cd /bin you end up in /.attbin if your universe is ATT at this point of time or in /.ucbbin if your universe is UCB. The mechanism is quite general and could be easily extended to more than two universes. -m------- Chris Jankowski - Senior Systems Engineer chris@yarra.oz{.au} ---mmm----- Pyramid Technology Corporation Pty. Ltd. fax +61 3 820 0536 -----mmmmm--- 11th Floor, 14 Queens Road tel. +61 3 820 0711 -------mmmmmmm- Melbourne, Victoria, 3004 AUSTRALIA (03) 820 0711 ``If you're crossing the nation in a covered wagon, it's better to have four strong oxen than 100 chickens. Chickens are OK but we can't make them work together yet.'' - Ross Bott, Pyramid U.S., on multiprocessors at AUUGM '89.
jim@cs.strath.ac.uk (Jim Reid) (02/26/90)
In article <4555@hemuli.tik.vtt.fi> tml@hemuli.tik.vtt.fi (Tor Lillqvist) writes: >The context-dependent files in HP-UX is IMHO a rather clever idea. A >bit like Apollo's symbolic links containing environment variables. That's your opinion. I strongly dislike both ideas though I can see why people have invented these kludges. [Both ideas are quick and dirty hacks that make a mess of the simple elegance of the UNIX filesystem.] Context-dependent files (CDF) uses supposedly invisible directories. They aren't. [It's also ugly that an extra character - '+' - is added to a CDF name so one can "see" the context-dependent entries. What can you do if you need a CDF filename that has to end with a '+'? It also adds an unnecessary and unsightly complication to the kernel's namei() routine.] On the more general point, I find it distasteful that a process can manipulate its visible filename name space by altering environment variables or contexts or whatever. When someone or something specifies a pathname, the resulting file that is found should not be conditional on the setting of external process-specific factors like an environment variable. [i.e. If I ask someone to look at /foo/bar, the file they see should be the one that I see. Neither of us should have to worry about the value of the likes of an environment variable that will influence the way that the kernel parses that pathname.] >Is there any chance of other vendors taking up the idea? I sincerely hope not. Jim
tchrist@convex.COM (Tom Christiansen) (02/27/90)
In article <4555@hemuli.tik.vtt.fi> tml@hemuli.tik.vtt.fi (Tor Lillqvist) writes: >The context-dependent files in HP-UX is IMHO a rather clever idea. A >bit like Apollo's symbolic links containing environment variables. Is >there any chance of other vendors taking up the idea? In ConvexOS, you have conditional symbolic links that work this way: you've a one-byte field in your user entry called u_warp which is the current "universe". When evaluating the symbolic links, the kernel takes into consideration your current u_warp value, and uses this as an index into the "|"-delimited contents of the links. There are system calls to set and get your current warp. If an /etc/warps exists, it defines the mapping between string and numeric universes for use by library routines. Watch: % cat /etc/warps # # warp logical name to physical value translation file. # # entries are of the form: # value name optional_aliases 0 release default base zero # installed system 1 patch fixes # patched system 2 new # up-coming release % warp release % warp patch % Watch: % mv /bin/ld /usr/old/ % ln -s "/usr/old/ld|/usr/new/ld" /bin/ld % ll /bin/ld lrwxrwxrwx 1 tchrist 23 Feb 26 10:15 /bin/ld -> /usr/old/ld|/usr/new/ld If you're in universe 0, you get /usr/old/ld, universe 1 you get /usr/new/ld, and anything else (like universe 2) you get universe 0, which is /usr/old/ld. This is utterly undocumented, unsupported, and subject to change without notice. We merely use it internally for more flexible build environments, for which it's a nice solution. If you think regular symblic links introduce another order of complexity into the file system that have the potential for massive confusion, just consider what these do. --tom -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
wesommer@athena.mit.edu (Bill Sommerfeld) (02/27/90)
[i.e. If I ask someone to look at /foo/bar, the file they see should be the one that I see. ] It all depends on your definition of "same". You seem to imply that it should always mean "having the exact same bit pattern as contents", but that's not always meaningful. If I tell someone to execute "~wesommer/bin/demo" they should wind up executing the "demo" program appropriate to their machine's CPU type.. I shouldn't have to tell them "if you're on an xxx type of machine, run "~wesommer/xxxbin/demo". There are other approaches to this, such as the "compound executable" found in Domain/OS (essentially an "archive"-like file containing multiple executable formats; the program loader uses the portion of the file that it finds interesting). I agree, CDF's look like a kludge, and can be confusing *because you have to do something special to see them as CDF's*. However, other context-dependant-naming schemes which *are* visible using normal tools -- like the various forms of variant symlinks in Domain/OS and in other "multi-universe" systems, or the "magic cookie" approach of the Andrew File System, are not particularly confusing, and are quite useful. - Bill -- Henry Spencer is so much of a | Bill Sommerfeld at MIT/Project Athena minimalist that I often forget | sommerfeld@mit.edu he's there - anonymous |
loverso@Xylogics.COM (John Robert LoVerso) (03/06/90)
In an article Tom Christiansen <tchrist@convex.COM> writes: > In ConvexOS, you can have conditional symbolic links that work this way: > % ln -s "/usr/old/ld|/usr/new/ld" /bin/ld ... > This is utterly undocumented, unsupported, and subject to change without > notice. What happens if I want to have a symbolic link with a "|" in it? John -- John Robert LoVerso Xylogics, Inc. 617/272-8140 x284 loverso@Xylogics.COM Annex Terminal Server Development Group
budd@bu-it.bu.edu (Phil Budne) (03/06/90)
In article <2960@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >V.4 uses the setGid bit on directories to get BSD-style file creation >semantics for files in that directory (SunOS 4.x-style). Therefore by logical extension SUID on a directory should cause the newly created files to take on the UID of the directory! -Phil Budne, Boston University
tchrist@convex.COM (Tom Christiansen) (03/06/90)
In article <8611@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes: >In an article Tom Christiansen <tchrist@convex.COM> writes: >> In ConvexOS, you can have conditional symbolic links that work this way: >> % ln -s "/usr/old/ld|/usr/new/ld" /bin/ld > >What happens if I want to have a symbolic link with a "|" in it? Don't do that. :-) You're right: there's no mechanism in the kernel for interpreting \| as a literal |. --tom -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"
guy@auspex.auspex.com (Guy Harris) (03/08/90)
>Therefore by logical extension SUID on a directory should cause the >newly created files to take on the UID of the directory! Had Berkeley made that the behavior in 4.2BSD, it probably would have ended up working that way. I don't think they would have made that behavior, though (they certainly didn't in *this* universe).