mouse@mcgill-vision.UUCP (der Mouse) (09/11/87)
In article <4901@jade.BERKELEY.EDU>, chapman@eris.BERKELEY.EDU (Brent Chapman) writes: > In article <2363@vdsvax.steinmetz.UUCP> barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) writes: >> In article <4341@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: >>> [Problem with Suns:] [They] are inherently insecure because anyone >>> using a 3/50 can just power off the machine and reboot it in single >>> user mode and become root. Don't even need to bother powering it off, just use L1-A. >> The solution we use here is to add >> login root >> to /.profile > I don't think this is sufficient, because if 'login' exits (in the > case of a timeout, or whatever), the execution of /.profile continues > as normal. Did you actually try it? I doubt that it would work this way, because the login command in sh (and csh as well, though that's irrelevant at the moment) does not just run /bin/login. It *exec*s /bin/login, meaning the original shell is not around any longer to continue doing anything. Thus, when the login times out, init thinks the single-user shell has exited and goes on with the boot procedure. > You might also want to add traps for interrupts to the /.profile, to > prevent someone from interrupting the /.profile execution before it > reaches the "login root" line (tricky, I know, but possible none the > less). Putting a trap in doesn't close the window, it just shrinks it. Now you have to interrupt it before the trap. However, all this discussion is pretty irrelevant anyway. If you have access to the console you can do all sorts of fun things anyway, like patching u.u_uid to zero for your shell process, or patching suser() to always return true, or patching the MMU to make kernel text/data read/write for user mode.... Basically, if you expect to withstand a hostile user community you *must* *not* give access to the console. der Mouse (mouse@mcgill-vision.uucp)