osx-secure

A Secure Prototype of OSX Developed for Nathan Hale High School

NOTE: The release of OS 10.2 makes this configuration essentially obselete. It is left here for academic purposes only. See the section on securing the Firmware however, which remains essential for security.

[SEE ALSO: Our secure Linux version of a student workstation using the Red Hat 7.3 Kiosk mode, Open Office, and Mozilla in place of Windows and Microsoft Office. Technical details to follow if time permits]

Apple's early relaeses of OSX caused some concerns over security issues. This kiosk version of OSX is a reaction to those issues. We also used to secure our machines to operate in OS9 only, pending release of additional security measures by Apple. Fortunately, these issues have all been addressed with Apple's release of Jaguar OS 10.2. The setup of this specially secured version of OSX may be of little interest now that there is such an elegant and effective way to secure OSX. The page will be left up anyway for those who might find it of interest.

Only a little study was required to realize that creating a secure, kiosk version of early releases of OSX was within the reach of personnel who possess a basic background in UNIX and some understanding of security issues. Furthermore, because almost all of these configurations are scriptable, easily securing pre-Jaguar versions of OSX is potentially within the reach of many.

Our prototype completely restricts the command line, prohibits all browsing of the harddrive, eliminates the the Finder's capabilities, removes the ability to connect to other networked machines via the "Go" menu, prohibits changes to global preferences, confines launching of applications to the dock, and recopies the entire user environment on each login. This latter function allows the user to make some changes to their environment during their work session without compromising the system for the next user. All of this was done from the command line, and required no additional software.

The purpose of our configuration is to allow students to access applications for OSX, to gain the benefits of the very stable OSX operating system, and to experience something of the "look and feel" of OSX, while presenting a very secure environment for student work. We feel we have achieved a good beginning with this prototype. Some of restrictions are rather severe in my opinion however, and we hope to restore some of the Finder capabilities which we've eliminated.

The configuration below will secure a single user on MacOSX. In our situation the non-privileged user's account was named 'openlab while the administrator account was 'admin'. Before beginning, configure the user's environment as you wish. This chiefly involves setting up the Dock so it functions as the sole application launcher.

Here is a general overview of our system:

1) Enable the root user in the NetInfo Manager. Move the Terminal and Netinfo apps to secure locations with admin only privileges.
2) Secure the Open Firmware with setenv and password commands
3) Substitute a different application for the Finder
4) Remove permissions for the global preferences file
5) Automatically destroy and recreate the entire user's home directory at each login
6) Insert a symbolic link from the documents folder so saved items will survive the home directory recreation
7) Disable automatic updates, autologon, and disable the root account in Netinfo.
8) Protect altering of browser protocol and file helpers to prevent launching of applications.

Below are details about the above along with the UNIX commands required to accomplish them

1) Enable root user in the NetInfo Manager. Move the Terminal and Netinfo apps to secure locations with admin only privileges.

The terminal, while presenting the non privileged user with only limited access, still presents the possibility for individuals to navigate the operating system and attempt various UNIX hacks. The Netinfo application contains many important system configuration files and, although password protected, if it could be accessed, would allow the user to make system changes and to see the encrypted form of passwords. The latter item presents the possibility of decryption using common password cracking tools. Even though these risks are remote, owning to built-in user restrictions, putting these applications out of reach is easy. From the command line,this could be accomplished like so:

mkdir /Users/admin/Applications/Sys
chown root /Users/admin/Applications/Sys
chgrp wheel /Users/admin/Applications/Sys
chmod o-wrx /Users/admin/Applications/Sys
mv /Applications/Utilities/Terminal.app /Users/admin/Applications/Sys
cp /Applications/Utilities/Netinfo\ Manager.app /Users/admin/Applications/Sys

Note that I copied the Netinfo Manager instead of moving it. This allows you to make sure it copied correctly in the desired location and that it functions properly before deleting it from the original location.

rm /Applications/Utilities/NetInfo\ Manager.app

Using the GUI, one could simply make a directory, drag the program icons to the directory and set permissions in the Show Info dialogue box(control click the icon). For our purposes, UNIX will be used whenever possible for these kinds of operations however.

2) Open Firmware presents a way for users to directly access important aspects of the operating system.

By setting up the open firmware as follows, users will need to enter a password before making open firmware changes which could affect functioning of the system. It will also require a password when booting from a different system folder, as might be attempted from a CD or external drive.

When booting the computer hold down the command-option-o-f keys
At the firmware prompt, type:

password <and press RETURN key>
<type a password and repeat when prompted for confirmation>

Type the following:
setenv security-mode command

Type the following:
reset-all

3) Substitute a different applicationfor the Finder

This eliminates the ability of the user to access and browse the hard drive, make new folders, or to manipulate networking via the go menu.

First decide which application you would like to substitute for the finder. I've successfully tried both Internet Explorer, and Apple Works.

I liked using Apple works, because after eliminating the large colored icons presented in the center of the screen on startup (Apple works Preferences :General: Starting Points: None) a nice Mac like blue screen is presented to the user. (see below for recent developments).

This substitution is very easily done, but must be performed from the user's account. So:

Then issue the following command:

defaults write com.apple.loginwindow Finder '/Applications/AppleWorks\ 6/AppleWorks 6.app'

Alternately, one could manually write this into the file /Users/openlab//Library/Preferences/com.apple.loginwindow.plist by adding the following lines:

<dict>
<key>Finder</key>
<string> /Applications/AppleWorks\ 6/AppleWorks 6.app </string>

4) Remove permissions for the global preferences file

Obviously, we don't want users to be able to change global preferences for the system. Remove user privileges as follows:

cd /System/Library/PreferencePanes
chmod o-rwx *

5) Automatically destroy and create the entire user's home directory at each login

This allows the user (openlab in our case), to make whatever changes they like while they are using the computer but restores the original configuration when the computer is rebooted. This automatically repairs any damage intentionally or unintentionally done by the user during their session.

First, set up the user's environment exactly as you wish as mentioned above. Then make a directory to store a copy of the entire user's home directory which does not have user privileges. In our example, we can just use the /Users/admin/Applications/Sys directory which we made previously.

Copy the entire user's home directory into the Sys directory using the ditto command:

ditto -rsrcFork /Users/openlab /Users/admin/Applications/Sys/openlab_bak

Now write a script which will remove the openlab directory and copy the directory back from the one we just stored in /Users/admin/Applications/sys/openlab_bak , using thereverse of the above command:

Make a file called openlab_rep with this text

#!/bin/sh
rm /Users/openlab
ditto -rsrcFork /Users/admin/Applications/Sys /Users/openlab

make the file owned by root with group membership of wheel with this command:

chown root openlab_rep
chgrp wheel openlab_rep

Make sure it is executable by root but not by an ordinary user:

chmod o-wrx openlab_rep

Next, get the script to run automatically at startup by changing this lines in the /etc/ttys file as indicated in the Kiosk project at http://www.macosxlabs.org/documentation/initial_setup/details/details.html

=======================================================================
Change:

mv /Applications/Internet\ Explorer.app/Contents/MacOS/Preference\ Panels/File\ Helpers.cfm /Users/admin/Applications/Sys

==============================================================================================

If you actually attempt to do the operations above by hand, you should know what you're doing - I make no assurances that I've presented all the above information here exactly correctly or that it will work on your system. If you are like me, you'll manage to damage your OS before you get things "right". Don't try this on your precious machine. Use a test machine instead. You'll also want to know how to recover from system damage by booting into single user mode to get to a command line (hold command-s on boot) and running fsck and mounting the '/' directory. The fsck and mounting procedures are described in text which appears in single user mode however, so this requires no knowledge.

The smarter way to do this would be with a script. The following is NOT a script, so please don't even think of trying to run it. But, with some work, it COULD be a script. In that case, doing most of the above configuration might take all of 2 seconds. If we take all of the UNIX commands above in red and place them together (along with the openlab_rep file creation and copying of a loginhook-enabled form of the ttys file), one could imagine the simple scope that such a script might assume.

&&&&&&&&&&&&&&&&&&& NOT A SCRIPT!!! &&&&&&&&&&&&&&&&&&&&&&&

#!/bin/NOT A SCRIPT!!

mkdir /Users/admin/Applications/Sys
chown root /Users/admin/Applications/Sys
chgrp wheel /Users/admin/Applications/Sys
chmod o-wrx /Users/admin/Applications/Sys
mv /Applications/Utilities/Terminal.app /Users/admin/Applications/Sys
cp /Applications/Utilities/Netinfo\ Manager.app /Users/admin/Applications/Sys
su openlab
defaults write com.apple.loginwindow Finder '/Applications/AppleWorks\ 6/AppleWorks 6.app'
# Backup and copy loginhook-enabled version of ttys to /etc/ttys
cp /etc/ttys /etc/ttys.orig
cp ttys.alt /etc/ttys
# create the following file called openlab_rep:
##!/bin/sh
#rm /Users/openlab
#ditto -rsrcFork /Users/admin/Applications/sys /Users/openlab
chown root openlab_rep
chgrp wheel openlab_rep
chmod o-wrx openlab_rep
cd /Users/admin
mkdir docs
chown openlab docs
chgrp staff docs
chmod u+wrx docs
cd /Users/admin
ln -s docs /Users/openlab/Documents
mv /Applications/Internet\ Explorer.app/Contents/MacOS/Preference\ Panels/Protocol\ Helpers.cfm /Users/admin/Applications/Sys
mv /Applications/Internet\ Explorer.app/Contents/MacOS/Preference\ Panels/File\ Helpers.cfm /Users/admin/Applications/Sys

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

It might be possible, without too much work, to build a bona fide GUI installer which could run such a script either via UNIX commands as suggested above, or using Apple Script.

Or, an image of a completed machine could be copied to an external drive and copied to any desired Mac to create a clone of the original prototype. Some additional configuration might be required to enable proper networking.

The point is, securing OSX could be done, and done rather simply by someone with very few technical skills using disk images, pre-made scripts, or installers.

Credit should be given to talented student Patrick Tescher whose partnership in this project has been very helpful. Read about some of Patrick's interesting expolorations below. Also, the kiosk project at the www.macosxlabs.org website was the inspiration and sometimes the template for much of the above.

Patrick has come up with a finder replacement which we are experimenting with in place of the original configuration with Apple Works. So far, this is limited, with just a blue screen and the ability to display a text box with relevant information.

Updating changes to the openlab user's home directory is difficult when removing and copying of that directory from the openlab_bak directory takes place at admin login. We need to adjust the script which performs recreation of the user's directory so that it only runs at the user's login. Setting this up should be easy.

If a student saves data in some location other than the Documents folder, that data will be lost when the home directory is recreated.

Our system is pretty severely crippled in terms of features one would expect to find in OSX. Patrick is looking at a file management browser source code which could be plugged into our tailor made finder application which would allow one to see file systems on the harddrive, but only open certain file types in certain directories. It appears that the code will allow one to stipulate that only certain files may be opened (eg., rtf, doc, pdf) and only with the application explicitly stated in the code. No applications would be able to be launched directly from the browser. We'll see if this is actually workable.

Tony Hand
tghand@seattleschools.org
http://hale.ssd.k12.wa.us/~tonyh/template.html