dupuy@amsterdam.columbia.edu (Alexander Dupuy) (08/27/87)
In article <4341@elroy.Jpl.Nasa.Gov> (David Robinson) writes: >This brings up a problem that exists with Suns that I have. The Suns >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. > [he suggests a hardware switch, like the lock on PC/ATs to remedy this] While there will always be some vulnerability, there are a number of measures which can be taken to give a reasonable amount of security for Suns, even without physical security. The primary vulnerability is that a Sun in an accessible place can be aborted or power-cycled, and brought up in single-user mode. This would give root access (on the local machine only) to the intruder, allowing them to do anything on that machine, and through staff ids, in some cases, to wreak some havoc on other machines. The first, and easiest, way to reduce the vulnerability of other machines is to make sure that the vulnerable sun is not a trusted host (in /etc/hosts.equiv) or trusted (in ~/.rhosts) by any users with special access to critical system files. There are also two ways to reduce the vulnerability of the publicly accessible sun. While it is practically impossible to prevent someone from power-cycling the sun, or causing a cpu reset (abort), it is possible to reduce their ability to bring the machine up in single user mode. When a Sun comes up (whether in single- or multi- user mode) the first thing /etc/init does is to run a script called /etc/rc.boot. In this script, it is possible to determine whether the machine is being brought up in single- or multi- user mode. A simple password checking program could be used to prevent unauthorized single user boots. [Sample from /etc/rc.boot:] if [ $1x = singleuserx ] && /bin/access then (echo "Singleuser boot -- fsck not done") >/dev/console else # fsck and go multi-user fi [/bin/access uses getpass, crypt, getpwdent, etc. and is left as an exercise for the reader.] Alternately, (or in addition to this) another approach can be taken. After the rc.boot script is finished, a root /bin/sh is started. This (Bourne) shell reads the file /.profile which can also tell whether this is a normal root login, or a single-user boot. In the latter case, a password check could be enforced. [Sample from /.profile] trap "" 1 3 if [ "$USER" = "" ]; then # singleuser boot if /bin/access then : else exec su nobody # or something similar fi fi While there are still methods of bypassing these checks, they are rather obscure - bypassing the first relies on a feature which is incorrectly documented to do something else (that may have been intentional...) and bypassing the second is not always effective, (an intruder would have to try several times) as it relies on interrupting the shell before the "trap". So in summary, it is possible to make a Sun secure enough that only a person with some Sun system admin experience would be able to bring it up single user without authorization. @alex --- arpanet: dupuy@columbia.edu uucp: ...!seismo!columbia!dupuy
chapman@eris.BERKELEY.EDU (Brent Chapman) (08/27/87)
In article <4946@columbia.edu> dupuy@amsterdam.columbia.edu (Alexander Dupuy) writes: >In article <4341@elroy.Jpl.Nasa.Gov> (David Robinson) writes: >>This brings up a problem that exists with Suns that I have. The Suns >>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. >> >When a Sun comes up (whether in single- or multi- user mode) the first thing >/etc/init does is to run a script called /etc/rc.boot. In this script, it is >possible to determine whether the machine is being brought up in single- or >multi- user mode. A simple password checking program could be used to prevent >unauthorized single user boots. > >[/bin/access uses getpass, crypt, getpwdent, etc. and is left as an exercise > for the reader.] > >Alternately, (or in addition to this) another approach can be taken. After the >rc.boot script is finished, a root /bin/sh is started. This (Bourne) shell >reads the file /.profile which can also tell whether this is a normal root >login, or a single-user boot. In the latter case, a password check could be >enforced. Using "login root" is much simpler than having to write your own "access" program, and works about as well. I've significantly hacked the /etc/rc* and /.profile files on my Suns to do two things: automaticly execute scripts in single-user mode, and ask for a root password on single-user boots. If the machine is booted single user (or "shutdown" to single user mode) and a file called "/single_user" exists and is less than a certain amount of time old (1 day? 1 hour? I don't remember), that file is executed, then moved to "/single_done". This allows me to do things like automatic unattended dumps by creating a file "/single_user" that has the necessary commands for the dump, then doing a "shutdown". When the single-user shell exits, the boot sequence continues, and the systems comes (back) up multi-user. [The idea for this was taken from some stuff on autodumps posted a while back, but I've modified and simplified what was posted quite a bit.] If the machine is booted single-user, a file called "/singleuserboot" is created (this is done in /etc/rc.boot). If the test for the automatic single-user script ("/single_user") in /.profile, outlined above, fails, then the existence of "/singleuserboot" is checked for. If it's there, the system does a "login root". If the login fails (timed out, wrong password, whatever), the system halts. If the login succeeds, the a csh is brought up for root (I prefer csh), and the /.cshrc erases the "/singleuserboot". I probably should do traps for interrupts in /.profile, but I haven't bothered to figure that out yet. When I exit the csh, the boot sequence continues, just as it would normally. Anyway, any reasonably bright sysadmin should be able to implement something like this to suit their system's needs. -Brent -- Brent Chapman Senior Programmer/Analyst chapman@mica.berkeley.edu Capital Market Technology, Inc. ucbvax!mica!chapman 1995 University Ave., Suite 390 Phone: 415/540-6400 Berkeley, CA 94704
gdelong@cvbnet.UUCP (09/01/87)
In article <4946@columbia.edu>, dupuy@amsterdam.columbia.edu (Alexander Dupuy) writes: > In article <4341@elroy.Jpl.Nasa.Gov> (David Robinson) writes: > >This brings up a problem that exists with Suns that I have. The Suns > >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. > > > [he suggests a hardware switch, like the lock on PC/ATs to remedy this] >[he suggests a copule of scripts to run in single user mode] I would first like to point out that if you provide someone who knows the system (hardware & software) acces to your system console on almost any system, he owns your system. There is a very easy way to keep the average to above average person from playing with your sun system in single user mode. As David mentioned, when you boot the sun with the -s option, root will me up in /bin/sh. Edit your /.profile and place the following command as the first line: login root This will require the user to know the root password on your system to bring it up in single user mode. Yes, this 'can' be defeated, but its takes a well above average user to do it. But, as I mentioned above, if you give them access to the system console, they own your system. -- _____ / \ / All spelling errors | Gary A. Delong, N1BIP | \ / intentional for testing | linus!raybed2!cvbnet!gdelong \____\/ rn spellcorrector v1.02A. | (617) 275-1800 x5232
ron@topaz.rutgers.edu (Ron Natalie) (09/05/87)
As probably has been pointed out. Putting "login root" in the /.profile to fix single user access only works when your root account has something braindamaged like the csh as the login shell. If you have the real shell as the root login, then you go into a loop. -Ron