km@emory.uucp (Ken Mandelberg) (10/01/88)
We are starting to think about using A/UX for student Unix workstations
in our lab. One concern in this environment is security. There are
probably lots of issues to consider but the first one that comes to
mind is the floppy disk.
1) It would seem that a student could do mischief by putting in a MacOS
systems floppy and pushing reset. Once in MacOS he could have his way
with the hard disk. Is there a way to disable boots from floppy without
physically disconnecting it?
2) Even from A/UX the floppy is a problem. It seems a shame not to
allow students to have small personal filesystems on floppy, but if
mount access is allowed there is little to stop the student from
presenting a file system with a setuid program on it. I guess the thing
to do here is write a setuid frontend to mount that does a fsck, mounts
only in a prescribed place, and searches the floppy for setuid
program.
What are the other security issues to consider?
--
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {decvax,gatech}!emory!km UUCP
Dept of Math and CS | km@emory NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963dyer@arktouros.MIT.EDU (Steve Dyer) (10/01/88)
At Project Athena, people have recognized that worrying about "security"
relative to any individual workstation is a hopeless task. Students can take
control of the entire machine by simply booting some program of their own
via the floppy, so any hope of security goes out the window. In fact,
every publically-accessible workstation has the same root password, and
it is well-known and freely publicized. Disabling the floppies or tapes
is not considered an option, since they are the only backup media easily
accessible to students.
The Athena model of computation assumes only a vestigial root file system with
most utilities provided via remote virtual disk (RVD), a local ND-like
protocol, and NFS, with these and other network services authenticated using
the Kerberos system, which was described in the Winter 88 USENIX proceedings.
Right now the environment exists for the RT/PC running ACIS 4.3 and the
VAXstation 2000 running 4.3BSD, both with NFS.
In any event, we are porting the Athena environment to A/UX on the Mac II
right now, at this point to see just how easy or hard it will be. This
doesn't solve your problem now, but it does point out that the issues you
present are difficult to solve without a methodical, holistic approach.
Typical UNIX (or worse, NFS) security measures just won't measure up.
---
Steve Dyer
dyer@arktouros.MIT.EDU
dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyerwtr@moss.ATT.COM (10/04/88)
In article <3242@emory.uucp> km@emory.uucp (Ken Mandelberg) writes: >We are starting to think about using A/UX for student Unix workstations >in our lab. One concern in this environment is security. There are >probably lots of issues to consider but the first one that comes to >mind is the floppy disk. >1) It would seem that a student could do mischief by putting in a MacOS >systems floppy and pushing reset. Once in MacOS he could have his way >with the hard disk. Is there a way to disable boots from floppy without >physically disconnecting it? Disable reset? Or lock the main cabinet away. If you don't need to allow the students access to the main console, then just run dumb terminals off the box and lock it up. >2) Even from A/UX the floppy is a problem. It seems a shame not to >allow students to have small personal filesystems on floppy, but if >mount access is allowed there is little to stop the student from >presenting a file system with a setuid program on it. I guess the thing >to do here is write a setuid frontend to mount that does a fsck, mounts >only in a prescribed place, and searches the floppy for setuid >program. another possible solution would be to show the students how to use cpio to backup a filesystem (their own) then a student could just carry around a disk with their files on it, and move them easily between machines. not as "neat" as mounting the floppy, but safer and also a lot faster disk access for the student once they've uploaded. >What are the other security issues to consider? a similar problem as #1, but with the student gaining root privlege by rebooting the machine and bringing it up single user. also, if you are going to be using this setup for homework/class assignments where the students are all doing individual work of an identical nature (e.g. "problem #5 on page 69 of your text"), then it's a good idea to warn students to set their file access to 700 (rwx------) to prevent the 'shared homework' syndrome. i'm not real familiar with A/UX, having only played with it a couple of times. however, these problems are inherent in any small pc-base-unix/workstation where the user has access to the hardware itself. ( I'm running microport SV/AT on an AT-clone ). good luck with it! hope this has helped. >Ken Mandelberg | km@mathcs.emory.edu PREFERRED ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ att ulysses allegra ]!moss!wtr ...![ att akgua watmath ]!clyde!wtr =====================================================================
falken@caen.engin.umich.edu (David R Falkenburg) (10/09/88)
Forget about worrying about students with suid programs on floppy. The porblem is that anyone who can access snarf (i.e. pirate) a copy of sash, along with chmod & cp commands can make their own root shells by simply reseting their machine, inserting their own sash floppy & hacking away in the traditional "make a root shell procedure" there aren't even any footprints left in wtmp, utmp, lastlog etc. to see who might have done these things... sash is nice for PERSONAL AU/X workstations but HELLISH for administrators of public labs with A/UX macintoshes.. -dave -- Dave Falkenburg @ University of Michigan Computer Aided Engineering Network Internet: falken@caen.engin.umich.edu UUCP: umix!caen.engin.umich.edu
chn@a.lanl.gov (Charles Neil) (10/09/88)
If the init program were set to boot all the way to multiuser with passwords required, and the floppie(s) were not available, would there be any way to break out into sash? Is such a system secure? -- Charlie Neil (chn@lanl.gov) Los Alamos National Laboratory (505) 665-0978
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (10/10/88)
In article <756@a.lanl.gov> chn@a.lanl.gov (Charles Neil) writes: >If the init program were set to boot all the way to multiuser with passwords >required, and the floppie(s) were not available, would there be any way to >break out into sash? Is such a system secure? Well, you power off and reboot the system, then press the programmer switch to get to the debugger,... (maybe just holding shift-option-clover or whatever to rebuild the desktop will do it). Secure from what? Marc Kaufman (kaufman@polya.stanford.edu)
nghiem@ut-emx.UUCP (Alex Nghiem) (10/11/88)
> Well, you power off and reboot the system, then press the programmer switch to > get to the debugger,... (maybe just holding shift-option-clover or whatever > to rebuild the desktop will do it). > > Secure from what? How about networking serveral Mac II's into one Mac II fileserver using NFS and then locking up the fileserver. Anyone can press buttons on the remote machines all they want, but unless they have super-user priviledges on the fileserver, isn't the fileserver untouchable?
matthew@ucscb.UCSC.EDU (73550000) (10/11/88)
Physical Security. Lock the machine up somewhere,... there are many things that can be done to exposed UNIX (and other) systems... like demagnetizing them,... using a screwdriver,... much worse than someone casually logging in as root (also easy to do if there isn't physical security), Remember to include protection of disk and tape loading and mounting. Matthew Kaufman matthew@ucsck.ucsc.edu ...!ucbvax!ucscc!ucsck!matthew