mvw@eurtrx.UUCP (Maarten van Wijk) (10/26/88)
We have several VaxStations 2000 around the campus and a central VAX running Ultrix. The Stations have their own system disk. I want to prevent the users of the stations to boot their system single user. Is there a way to do this.(e.g. patching VMB.EXE or vmunix.) -- ***--*--*--------------------Maarten van Wijk--------------------------------+ ** * *KUB-University Phone: (+31) 13 662091 Bitnet: mvw@htikub5 | * * * Tilburg-Netherlands UUCP: ...!mcvax!kubix!mvw Surfnet: kubix::mvw | +-*--*-----------------------------------------------------------------------+
shankar@hpclscu.HP.COM (Shankar Unni) (10/29/88)
> running Ultrix. The Stations have their own system disk. I want to > prevent the users of the stations to boot their system single user. A simple trick is to prompt the user for a special password (from /etc/rc, using /dev/console for input) if booting single user. If the user cannot supply the password, reboot the system (and call security :-)). if /etc/singlepass; then # .. OK else echo "Sorry, buzz off!" /etc/shutdown # or reboot, if you're brave.. fi /etc/singlepass should read from /dev/console.. -- Shankar
mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum) (11/02/88)
In article <670030@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >> running Ultrix. The Stations have their own system disk. I want to >> prevent the users of the stations to boot their system single user. I kludge I used to do on Suns was to fix /etc/init so that is does not fork off single user shells, but rather forks off a /bin/login. The shell name to use is #defined at the top, and changing that breaks a lot of stuff, but there is a function, singlesh() I think it is, that starts the singleuser shell. Of course, after I did this on some of our systems I noticed some undocumented stuff that led me to believe that there was a way to tell it to boot a different init. Of course, a user could still boot off a kernel they stashed in /tmp, or a standalone copy, or whatever. This was not a fix, simply another level of difficulty to add for the potential cracker to overcome. I don't think there is really anything you can do if you haven't got the hardware secure. At that level there are too many holes. --mjr();
guy@auspex.UUCP (Guy Harris) (11/02/88)
>Of course, after I did this on some of our systems I noticed some >undocumented stuff that led me to believe that there was a way to tell it >to boot a different init. In SunOS 4.0 it's even documented in BOOT(8S): boot-flags The boot program passes all boot-flags to the kernel or standalone program. They are typi- cally arguments to that program or, as with those listed below, arguments to progams that it invokes. ... -i initname Pass the -i initname to the kernel to tell it to run initname as the first program rather than the default /single/init. Of course, you can also boot a different kernel, which lets you do even more than run a different "init", unless you've protected the machine's root file system so they can't install the new kernel (or have somehow kept them from rebooting the machine or, at least, from typing a "b" command with arguments - which would, I think, prevent either of those from working).