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...
allbery@ncoast.UUCP (Brandon Allbery) (02/07/88)
[Why the H*LL was this crossposted to comp.arch?! EVERYTHING in unix.wizards ends up crossposted there -- maybe they should be merged?! ++bsa] As quoted from <16008@think.UUCP> by barmar@think.COM (Barry Margolin): +--------------- | 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. | | However, to answer your question about how this could be done in Unix, | the answer is to not inherit translations in setuid processes. +--------------- Probably a good idea anyway, but then you get into a very un-Unixy idea: separate translations per-process, per-user-id, and per-system. This would, on the other hand, be more general than just suppressing translations for setuid programs. I don't think filename translations of this type are a good answer to the original problem; too much rope for a user to hang (his/her/it)self with. The generalized mount from the LAST time we discussed this still sounds best to me; add a restriction that the mount must be on a directory writeable by the user to close the security hole, which is otherwise the same as with translations (mount .breakin /etc). Possibly also the directory should be empty, although this limits its usefulness over networks (NFS/RFS). (Note that the writeable-directory restriction would be too expensive to apply to filename translations, but for the mount call it's cheap.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it." Newsgroups: comp.unix.wizards,comp.arch Subject: Re: ITS translations: security problem? References: <1495@osiris.UUCP: <2126@haddock.ISC.COM> <1497@osiris.UUCP> <704@PT.CS.CMU.EDU> <1424@gumby.mips.COM> <9690@tekecs.TEK.COM> <16008@think.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.unix.wizards Distribution: Organization: Cleveland Public Access UN*X, Cleveland, Oh As quoted from <16008@think.UUCP> by barmar@think.COM (Barry Margolin): +--------------- | 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. | | However, to answer your question about how this could be done in Unix, | the answer is to not inherit translations in setuid processes. +--------------- Probably a good idea anyway, but then you get into a very un-Unixy idea: separate translations per-process, per-user-id, and per-system. This would, on the other hand, be more general than just suppressing translations for setuid programs. I don't think filename translations of this type are a good answer to the original problem; too much rope for a user to hang (his/her/it)self with. The generalized mount from the LAST time we discussed this still sounds best to me; add a restriction that the mount must be on a directory writeable by the user to close the security hole, which is otherwise the same as with translations (mount .breakin /etc). Possibly also the directory should be empty, although this limits its usefulness over networks (NFS/RFS). (Note that the writeable-directory restriction would be too expensive to apply to filename translations, but for the mount call it's cheap.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it."
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