jmason2@gpu.utcs.utoronto.ca (Jamie Mason) (06/22/91)
In article <1991Jun20.023256.12713@gpu.utcs.utoronto.ca> I wrote: | Of course, the administator's mistake was *not* that he had "." | in is path. His mistake was that he helped a user with a problem with | their personal files *as root*. What he/she should have done is su'ed to | the user with the problem, then used *that* shell to solve the problem. | Remember that root can su to anyone *without* entering a password. By | poking around the user's files *AS THE USER*, there is no chance of | accidentally executing something nasty as root. In article <677526078.470@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: > I don't think this is true on systems that support saved-set-user-ID. > A Trojan horse program could su back to root under some circumstances. I hope not. Su sets *real* and effective user ID. The saved-set-user-ID should be wiped out by the su program when SUing to the user's account. Otherwise SU is *horribly* broken. Please remember that SU is setuid root. So it runs as root, whether or not is was called by root. The difference is that it does not demand a password when called by root. So if you could use saved-set-user-ID to seteuid() back to root when SU had been called by root (your argument), then you could since SU is setuid rood, do it when it was called by J. Random User. Of course that is *really* horribly broken, so I hope your argument is wrong. >It's often worth trying to reproduce a problem from several different >logins. Problems caused by user environment settings can be >difficult to diagnose. And problems cause by sysadmins running pontentially dangerous user programs *as root* can be difficult to diagnose, detect, or repair. Jamie ... Lurker in the Process Table Written On Friday, June 21, 1991 at 07:29:37pm EDT
jc@minya.UUCP (John Chambers) (06/25/91)
> I hope not. Su sets *real* and effective user ID. The > saved-set-user-ID should be wiped out by the su program when SUing > to the user's account. Otherwise SU is *horribly* broken. OK, so if I wanted to write a version of su that wasn't "horribly broken", how would I do it? I've dug around in TFM on several occasions, trying to make sense of the saved-set-user-ID concept, to little avail. They seem to think that they should keep it a secret from me, because if I'm interested, I am obviously an Evil Hacker who is trying to violate system security. So far, I haven't seen any documented system call to set this third uid that some Unix kernels keep. If there's no (documented) way to set it, how can you accuse a program of being "horribly broken" if it doesn't set it correctly? BTW, this isn't purely hypothetical. I recently added a dumb terminal to this (Sys/VR3) system so that when X shoots itself in the foot and goes zombie on me, I have a back door to do something short of pushing the reset button. But what I can do there is very limited, because when I type "su" it just says "Sorry", without even asking me for a password. TFM hasn't helped at all to explain why su is so recalcitrant. I've done what any hacker would do - written my own version of su. Now I find that, according to the above, it is horribly broken. I'd like to know how to make it less so. How do I do that? If it's described somewhere in TFM (that I am too stupid to find), I'd like to know where, and how I missed it. -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc}
malte@techfak.uni-bielefeld.de (Malte Uhl) (06/26/91)
|> BTW, this isn't purely hypothetical. I recently added a dumb terminal |> to this (Sys/VR3) system so that when X shoots itself in the foot and |> goes zombie on me, I have a back door to do something short of pushing |> the reset button. But what I can do there is very limited, because |> when I type "su" it just says "Sorry", without even asking me for a |> password. TFM hasn't helped at all to explain why su is so |> recalcitrant. I've done what any hacker would do - written my own |> version of su. Now I find that, according to the above, it is horribly |> broken. I'd like to know how to make it less so. How do I do that? 1. You can get your "real" real user ID in the same way as who am i does by reading /etc/utmp and /var/amd/wtmp. The record there says as who you once logged in and is therefor inde- pendent from your real or effective ID. 2. Su will tell you it's sorry if you try to login (su -) as root at an unsecure terminal. Malte
tomas@u30003.rsv.svskt.se (Tomas Ruden) (06/28/91)
In article <867@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >> I hope not. Su sets *real* and effective user ID. The >> saved-set-user-ID should be wiped out by the su program when SUing >> to the user's account. Otherwise SU is *horribly* broken. > >OK, so if I wanted to write a version of su that wasn't "horribly >broken", how would I do it? I've dug around in TFM on several >occasions, trying to make sense of the saved-set-user-ID concept, to >little avail. They seem to think that they should keep it a secret >from me, because if I'm interested, I am obviously an Evil Hacker who >is trying to violate system security. > >So far, I haven't seen any documented system call to set this third >uid that some Unix kernels keep. If there's no (documented) way to set >it, how can you accuse a program of being "horribly broken" if it >doesn't set it correctly? Talking HP-UX, based on BSD Unix, the saved-user-ID is set to the effective-user-ID when the process preformes an exec. I think, but I'm not sure, that saved-user-ID isn't supported in AT&T V.3. >-- >All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: >Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc >Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc} -- Tomas Ruden, tomas@u30003.rsv.svskt.se Don't blame the Swedish Tax ! I wish I had an English Administration for my opinions ! spellingchecker
janm@dramba.neis.oz (Jan Mikkelsen) (06/29/91)
In article <867@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >BTW, this isn't purely hypothetical. I recently added a dumb terminal >to this (Sys/VR3) system so that when X shoots itself in the foot and >goes zombie on me, I have a back door to do something short of pushing >the reset button. But what I can do there is very limited, because >when I type "su" it just says "Sorry", without even asking me for a >password. TFM hasn't helped at all to explain why su is so >recalcitrant. I've done what any hacker would do - written my own >version of su. Now I find that, according to the above, it is horribly >broken. I'd like to know how to make it less so. How do I do that? > >If it's described somewhere in TFM (that I am too stupid to find), I'd >like to know where, and how I missed it. One place to look is probably getpass(3). It sounds to me like you have managed to loose /dev/tty. Does anything else have problems asking you for a password? -- Jan Mikkelsen janm@dramba.neis.oz.AU or janm%dramba.neis.oz@metro.ucc.su.oz.au "She really is."