mol@dutesta.UUCP (Marcel Mol) (05/20/87)
Probably this is found for the one-hundred-and-oned time,
but becoming root isn't that difficult.
Do the following:
Start up MINIX
Login as a casual user
unmount the /usr filesystem ('/etc/umount /dev/fd0' if /usr is mounted
on diskdrive 0)
type cntl-D
And now you are in superuser-mode.
-Marcel Mol | DELFT
-Arian Koster | THE NETHERLANDSabc@ncsuvx.UUCP (05/20/87)
In article <600@dutesta.UUCP> mol@dutesta.UUCP (Marcel Mol) writes: > Login as a casual user > unmount the /usr filesystem ('/etc/umount /dev/fd0' if /usr is mounted > on diskdrive 0) This brings up a point that may have been discussed before, but I don't remember it. Why do 'casual users' get to mount and unmount disks? This is a major problem with security on big systems, and seems to cause more problems than it is worth on even the little ones! Can't we check to see if the person is superuser before mount/unmount requests are allowed? This may cause problems when we are on a floppy only system, but would be so much nicer for those of us with hard disks. Would it be possible to allow mount and unmount of, say, the second unit (/dev/fd1) to be mount/unmountable by the casual user? -abc ps: How do you make the machine put the root stuff on the hard disk without loading it into /dev/ram? I know somebody has said how to do this, but I don't have any archives.. -- Alan B. Clegg | NCSU Comp Center | abc@ncsuvx.ncsu.edu
ast@cs.vu.nl (Andy Tanenbaum) (05/21/87)
In article <600@dutesta.UUCP> mol@dutesta.UUCP (Marcel Mol) writes: >Probably this is found for the one-hundred-and-oned time, >but becoming root isn't that difficult: > unmount the /usr filesystem > type cntl-D This is not a bug, it is intentional to help people who have mangled their /usr diskette. When a shell terminates (CTRL-D), init tries to exec /usr/bin/login. If that exec fails (e.g., because /usr has been unmounted or damaged), rather than panicking, it tries to exec /bin/sh. Thus if your /usr diskette gets munged, you can still log in and try to save things. If you don't like this feature, just modify init to panic if it can't exec login. Andy Tanenbaum
karel@dutesta.UUCP (Karel van Houten) (05/21/87)
In article <600@dutesta.UUCP> mol@dutesta.UUCP (Marcel Mol) writes: >Probably this is found for the one-hundred-and-oned time, >but becoming root isn't that difficult. Yeah... >Do the following: > Start up MINIX > Login as a casual user > unmount the /usr filesystem ('/etc/umount /dev/fd0' if /usr is mounted > on diskdrive 0) > type cntl-D What would you think the system should do when it can't execute 'login'? Rememeber that on MINIX login resides in /usr/bin (floppy A), and not in /bin, as result of the small root device. The system detects an error, and start a super user shell at the console. This is the normal procedure after an unrecoverable file system error after an automatic reboot at BSD systems. When you have a better solution (like shutting down the system, and only allowing rebooting from the original distribution), we are interested to know. -- Karel van Houten, Delft Univ. of Technology ..!seismo!mcvax!dutesta!karel
stuart@bms-at.UUCP (Stuart D. Gathman) (05/22/87)
The mount program should check to see if the user has access to the block special file being mounted. Set permissions for /dev/fd0 to 0600, and only root can mount/umount it. If the current mount doesn't check this, just make mount executable by root only. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuathis
allbery@ncoast.UUCP (Brandon Allbery) (05/23/87)
As quoted from <832@ncsuvx.ncsu.edu> by abc@ncsuvx.ncsu.edu (Alan B. Clegg): +--------------- | This brings up a point that may have been discussed before, but I don't | remember it. Why do 'casual users' get to mount and unmount disks? +--------------- Because Minix is based on V7, and V7 allowed it. System III (on the AT&T side) changed that. Actually, I used that feature quite a bit once under Xenix 2.3, back when ncoast was a Radio Shack Mod 16 with 8MB HD; I mounted /dev/fd2 as /u/allbery (after moving to /) and subsequently had 1.2MB to play with safely. However, it does seem a security hole. At least you have source so you can fix it. ++Brando -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. ---- Moderator for comp.sources.misc ---- Brandon S. Allbery {decvax,cbatt,cbosgd}!cwruecmp!ncoast!allbery Tridelta Industries {ames,mit-eddie,talcott}!necntc!ncoast!allbery 7350 Corporate Blvd. necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060 +01 216 255 1080 (also eddie.MIT.EDU)
rmtodd@uokmax.UUCP (Richard Michael Todd) (05/24/87)
In article <397@bms-at.UUCP>, stuart@bms-at.UUCP (Stuart D. Gathman) writes: > > The mount program should check to see if the user has access to the > block special file being mounted. Set permissions for /dev/fd0 to > 0600, and only root can mount/umount it. > > If the current mount doesn't check this, just make mount executable > by root only. In a sense, it already is. The code in fs/mount.c will only let root execute the mount and unmount system calls. Of course, in the default distribution, /etc/mount and /etc/umount are set-uid root, which allows anyone to use them. A quick chmod will give you the behavior you want. It shouldn't be too difficult to change mount and umount system calls to check if the real user can access the device in question, and if you want to give different logins different access priviledges, that's probably the way to go. Another thing you might want to keep in mind: If I remember correctly, all the devices in /dev are owned by bin, not root. -------------------------------------------------------------------------- Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd