Mac OS in a Lab
jmu1 wishes to get to the core of the following issue: "I run a medium sized lab of Mac OS 8.6/9.x machines. They all have (shudder) FoolProof as an attempt of keeping the systems usable. Unfortunatly, it is quite easy to bypass the software, or even to remove it using AppleScript, etc. What I want to know is, what is a usable solution for securing a lab of Macs?"
install OS X?
'jfb
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
I would definitely go with something that returns the system to a default state on reboot as opposed to locking down the whole thing. In our Mac lab at my school, we used Assimilator. You can actually use the desktop and download a little program or two if you want, and on reboot, the system syncs back to a default state. Works great.
If you want to make an apple pie from scratch, you must first create the universe. -- Carl Sagan
For each diffrent configuration, make a copy of the Applications and System Folder (you could burn them onto a CD).
Let the kids do whatever they want. When a system becomes unusable delete the existing Applications and/or System Folder and copy a fresh one from you backup copy.
You can just copy the folders or use Disk Copy or Stuffit to create single files out of the folders. I have know users that have had great sucess using Disk Copy and System Restore to restore custom configurations.
This is one of the many reasons I love Mac's. I can restore an OS 9.2 or newer computer to a default configuration as fast as I can copy files off a CD or over the network.
I'd like for students to not feel inhibited in their activities... but then again, I put a whole lot of work into getting the machines into the state they are in. I tend to not like having to re-image them every morning.
Netboot is some nice technology from Apple. It allows you to set up a default system on some server, then have the computers on your network boot from that server. When the computer reboots, it reloads the system from the image on the server, rather than from something on the hard disk. It is very difficult for a user to change the information on the server. It's not impossible, but we all know that undefeatable security doesn't exist.
But NetBoot was made for exactly this sort of situation, so it's definitely worth checking out.
=Brian
There is nothing so good that someone, somewhere, will not hate it.
We are trying to get a copy of OS X 10.2 Server. We have a copy of OS X Server 1.2 but it doesn't seem to like me messing with it much, and as per usual, I can't find any documentation for that software... anywhere. There is no telling if we will actually get the funding at this point, hince the story submission.
revrdist is a free (public domain) program with the same basic function. Its setup is a bit more involved and it doesn't have all of Assimilator's features, but it's a well-tested program that definitely works. Use it if you can handle the extra administration and prefer a free solution. The reverdist home page also has links to other Mac administration programs.
Let's see...The OS X Server Admin Guide is a very long document that should tell you anything you need to know about setting up the server. All of the rest of the information is at Apple's OS X Server Site.
Net boot shouldn't need Jaguar Server. If you can get, or have, a copy of a later AppleShare server software, then you should be able to use the Macintosh Manager on that.
=Brian
There is nothing so good that someone, somewhere, will not hate it.
I really did try using the documentation but it wasn't of any use to me at all. I couldn't find out how to create a new image to use with it, nor how to specify what image to use, nor how to control it. It really was a pain. The OS X Server version I have is really really old. I still don't know why they even shipped it. I've had to reinstall it several times because it would just lock up... not doing anything with it... it'd just lock up. As far as MM goes, I really couldn't find any useful docs on it. It seems the more I read Apple documentation, the more it seems that Apple documentaion is another form of marketing. At every turn it seems that instead of describing the steps to get something done, they are telling you all the great things that the software can do. I've spent countless hours and bottles of carbonated caffine trying to get some useable stuff out of those docs(and their Carbon docs... trying to write for OS 9 and X is not nearly as easy as they make it sound). I'm just at my wit's end.
For those who have never used it, it's a cheesy-looking program, but it's a great solution for computers that run MacOS 9 and below. You can set it so you can't get info, move files, and there is a list of allowed/disallowed programs. Bypassing by holding down shift at startup won't work, etc.
There's a whole lot of other stuff it can do. All in all, when set up correctly, there is one way to bypass it, and one way to mess up a system, which I will not go into detail about. Our setup apparently works well, because I haven't seen any students bypass it.
Seriously, anyone who's used it knows that you just click on a bunch of check boxes and maybe disallow a few programs. Changing the default password is a good idea also. This is not a difficult thing to do.
Sten
MacAdministrator is the network-aware product from the same company as MacPrefect, Hi Resolution Systems.
My buddy and I run a network composed in part of around 100-110 Macs in a High School environment. We've had fairly good success with MacAdministrator, although using "Target Disk Mode" is a way to defeat it with a firewire cable and a handy student-supplied notebook. I assume the same applies to MacPrefect. Nonetheless, it keeps the kids from making stupid mistakes that would otherwise cost big support time.
It also has some neato features that log you in automagically to servers and puts an alias to a home folder on the user's desktop. You can also deploy software remotely, although we prefer Retrospect for workstation production. We use remote deployment when appropriate.
The guys at Hi Resolution are top-notch, IMO, and always provide sensible answers. The documentation leaves a lot to be desired because while every module is extensively and exhaustively documented, there are no solution-oriented/howto guides. Their tech support fills that gap pretty well.
cat
Older Macs don't have the OpenFirmware ROMs, and so don't have the ability to lock out alternate boot devices, I recall they also can't boot to the network. You don't mention what type of protection level you are trying to achive, or the repricutions of a security failure, I can't really get a handle on that from the responses either. Is this just a lab on campus where you want to keep games and P2P apps off the systems, or is this a research lab where a breach could cause panic or lost money or saftey concernes?
Unless you remove or disable the floppy, CD-ROM drive, and external SCSI connector you have little chance of truely securing a Mac lab. There will always be some way for a malcontent to get control, rather easily in fact.
I recall some stuff like DiskVault, I think, that would alter the directory layout or something so that unless you booted to the drive that was protected, you couldn't use the protected volumes. Of course, installing the software on a bootable CDR would get you around this, as would booting to an external drive that the hacker controlled and had installed the software on.
Personally, I have never encountered a disk/system lockdown utility on older Macs that I couldn't bypass with an alternate boot disk and, at most, a few hours of tinkering. The most you could ask for is that wandering lab monitors might find people hacking the thing before it goes too far. Anectodally, at one place I worked they installed GraceLAN to keep track of app lauches, prevent software installs, force LAN-wide software installs, etc. I used ResEdit and a disk editor on a floppy to locate the admin password. I then installed the admin program on my own system and force installed the old "Energizer Bunny" init on all 120 systems in the office. Of course I renamed it to something like "Apple SoundManager Tuner". THAT was a blast!
If it's just simple protection to keep the honest people honest: use SimpleFinder or AtEase that each limit what users can do. For all its problems, AtEast is a nice little application/Finder replacement for labs. It allows you to create a tab for each type of application, or on a per-course basis.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
A year ago I was the admin for an edu network with ~200 macs. I used MacManager on them. I never had any problems with the any of the brighter students breaking it. None of my macs were ever screwed up from tampering. I did have problems with earlier versions of AtEase though...
Assimilator sucked hard in it's early days (circa 1998.) It was pretty easy to bypass. I'm not sure how it is now.
YMMV
Now I work on a corporate network with Win2k. PCs may be "real computers" in the eyes of most geeks, but being the admin for a Mac network is a hell of a lot more fun.
I work for the computing department of Rutgers University. We secure our macs with assimilator, and we dont have many "misuse" issues. This is with G4 450Mhz towers and 700Mhz eMacs but I hear the system has been used for a while so I imagine your results would be similar
Viva La Revolucion! Buy a Mac!
OnGuard, a program by the guys at PowerOn Software, has many security holes in it, so I can't reccomend it. It is easy to get by (like accessing someones files on a server is just as easy as going into Netscape and going file:///Server/), and only protects from normal file and OS stuff, like launching, deleting, moving, etc. Anything that bypasses the OS, like Internet Explorer, AppleWorks 6, and others can get by easily. (Ex: AppleWorks 6's normal open dialog shows everybody's folders (While ClarisWorks 5 does not), and Internet Explorer allows anybody to launch any apps that are on any of the hds.)
You can try it, download the demo, but try and get past it and you you'll see how easy it is. Or not. At my school, the security is a joke. So test it, if you like it, use it, but I reccomend against it.
More info here: http://poweronsoftware.com/products/onGuard/.
Orange
I administer a high school mac lab with Foolproof, and I don't see anything wrong with locking them up fairly tight.
They have access to all the tools they need for classes and research, but most other things are locked. And everything that could make life miserable for the next person to use that machine is locked. Storage is available for each student on the server.
We occationally do games after school, and I unlock those programs at that time.
I inherited the FoolProof solution, and can't say anything about it's overall security, but we haven't had any troubles with it. I do think it's important to recruite any students that are showing enough interest in doing things that make your life tougher (might as well just put them to work).
It's also important for the students to know what type of things will get their computer access terminated.
AtEase anyone? :-D
Are you secure enough in your masculinity to run 'man touch'?
It drived my teacher insane.
If that was your English teacher, I doubt that's the only thing that drove her crazy.
Look Lisa: I learnded!
Me fail English? That's unpossible!
Yes, it's a blog. Sorry if that offends you.
There's tons of different solutions that have been outlined here, it seems from your comments you dismiss them because they "encumber" your students and make them feel bad and icky. It is not their network nor are the computers theirs, they don't have rights to them. Lab computers belong to whoever owns them and not whatever student sits down in front of them. If you're worried about them feeling encumbered by your security you're not doing your job properly.
You make the systems secure so no one can easily screw them up preventing other students from using them. There's a lot of jackasses that love to break systems or "customize" them preventing anyone else from getting any use out of them at all. There's also the people who feel that because a school has a particular amount of bandwidth, they ought to be able to monopolize it to download ripped DVDs and MP3s. You secure your systems and your network so everyone can use it because it is a shared resource. You aren't supposed to leave systems wide open for them to be abused.
Let people do what they need to do with as little hassle as possible. Don't allow people to abuse your systems though. I've managed a Mac lab before and the previous admin decided not to lock down any of the systems. The computers crashed constantly and hardly anyone could get on the web. I spent weeks getting Carracho servers, SETI@Home clients, and copies of Starcraft off all the systems. After the systems were locked down we didn't have any problems. If people want to play Starcraft or run a Carracho server (which was probably used to ship off copies of software we had) they can do it at home. They don't need to use your lab for it unless you specifically allow them to.
I'm a loner Dottie, a Rebel.
They use rev r disk here to manage the macs.. not sure if its good persay, but it seems to get the job done.. then again not that many people use the macs.. and the ones that do bitch about them taking 15 minutes to load up because the previous users killed it before rev r disk could finish.
I once worked in a place where they got rid of a bad employee who had installed foolproof on a production machine (without permission). After he left, they asked me to get into the machine. Tried a few basic things inside foolproof, which didn't work. So, I grabbed my tools drive, hooked it up to the SCSI port and forced an external boot. Did a little HDT fiddling, and the system was back. It could have been done with one of those System 7.5/HDSC Setup floppies too.
You sort of have to know how macs use hard drives, but beyond that, if the user has physical access to the boot drive there's not much you can do.
The Netboot suggestion is a good one.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
FoolProof's developers trapped the API at a point where it would interfere with MOST applications.
:). They used some wacko dialect of Basic called TrueBasic.
In fact, in the cases of applications where FP was defeatable, only certain parts of that application might bypass FoolProof.
Specifically, back in high school about 6 years ago, I took a BASIC course (easy A
Well, FP worked to block file access for TB's normal file open/close functions. (Specifically, the editor open/close)
But anything that you compiled would access files like FoolProof wasn't there.
3 lines of code replaced the FoolProof program with a 0-byte text file.
retrorocket.o not found, launch anyway?