andrew@frip.gwd.tek.com (Andrew Klossner) (01/30/88)
[]
"Suppose you wanted to change rm. Adding an alias, or an rm
command in your path doesn't suffice because some scripts etc.
say /bin/rm. So you add s|^/bin/rm$|/user/me/bin/rm| to your
translation list."
What about the security implications? Under Unix, I could use these
translations to spoof setuid programs, e.g., make my own /etc/passwd
then invoke /bin/su.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]barmar@think.COM (Barry Margolin) (02/02/88)
In article <9690@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: > So you add s|^/bin/rm$|/user/me/bin/rm| to your > translation list." > >What about the security implications? Under Unix, I could use these >translations to spoof setuid programs, e.g., make my own /etc/passwd >then invoke /bin/su. Well, ITS doesn't have much security, and what little it did have wasn't based on the contents of some particular file that was read by the user's process. However, to answer your question about how this could be done in Unix, the answer is to not inherit translations in setuid processes. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
aj@zyx.UUCP (Arndt Jonasson) (02/02/88)
In article <9690@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: >[About file name translations in ITS (using Unix syntax)] > "Suppose you wanted to change rm. Adding an alias, or an rm > command in your path doesn't suffice because some scripts etc. > say /bin/rm. So you add s|^/bin/rm$|/user/me/bin/rm| to your > translation list." > >What about the security implications? Under Unix, I could use these >translations to spoof setuid programs, e.g., make my own /etc/passwd >then invoke /bin/su. In Unix, were this feature to be implemented, it would have to be restricted in order not to compromise security. In ITS, however, there is no security problem, since ITS is not at all concerned with security. Any process can do anything at all with any other process, including the monitor (known as the kernel in the Unix world). A perhaps viable restriction in Unix could be not to apply the user's translations when the effective uid is different from the real uid. Would this be enough to guarantee security? -- Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden email address: <backbone>!mcvax!enea!zyx!aj = aj@zyx.SE
mjr@osiris.UUCP (Marcus J. Ranum) (02/05/88)
>In article <9690@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: > So you add s|^/bin/rm$|/user/me/bin/rm| to your > translation list." > Rather than building things like this into the OS, they can just as easily be handled in the shell. Rather than forcing everyone to worry about security problems, etc, etc, why not simply have your shell support all the translation you can handle, since the UNIX file system layout is pretty straightforward. Sure, there'd be a performance hit, but it's better to keep those in the shell, and keep everything else as straightforward as possible. Golly, I can see it now: s/\/usr\//C:/g s/\/$HOME\/D:/g ... --mjr(); -- ------------------------------------------------------------------------------ ...ich bin in einem dusenjet ins jahr 53 vor chr...ich lande im antiken Rom... einige gladiatoren spielen scrabble...ich rieche PIZZA...
aeusesef@csuna.UUCP (sean fagan) (02/07/88)
>In article <9690@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: > So you add s|^/bin/rm$|/user/me/bin/rm| to your > translation list." Well, our Elxsi (running EMBOS) has this feature, and, after seeing this, I decided to try it. I tried making my own copy of the password file (it's unreadable by mere peons [and most of the support personel, grumble], so I had to guess about the format from the documentation). I then did an 'equate' (the translation scheme), telling it that '/systemfiles/groups' should be accessed as '/user/1.fagan/mygroups'. It seemed to work, when I did a copy or anything like that, so I then tried a 'changeid' (su), but it didn't allow it. Sigh. I would assume from my experiment that either I screwed up the password format (probably), or there is a way of bypassing the 'file equates' (also probably). I thought of a few nice twists I could do to test it, so all hope is not yet lost 8-). ----- Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!csuna!aeusesef
kers@otter.hple.hp.com (Christopher Dollin) (02/08/88)
"mjr@osiris.UUCP Marcus J. Ranum" writes: |> So you add s|^/bin/rm$|/user/me/bin/rm| to your |> translation list." |> | | Rather than building things like this into the OS, they can just as |easily be handled in the shell. Rather than forcing everyone to worry about |security problems, etc, etc, why not simply have your shell support all the |translation you can handle, since the UNIX file system layout is pretty |straightforward. repeat 1000 times 'No!\n'.pr endrepeat ... If you do that, then EVERY *ING PROGRAM has to know how to handle translations. No all programs get all their filenames from the shell. Editors and cpp (for #include) are obvious examples. It belongs in the filesystem (which, for heavens sake, shouldn't be part of the *ing KERNAL). I get peeved enough when some futility doesn't understand "$" (or "~") in filenames. Regards, Kers | "Why Lisp if you can talk Poperly?"