A Complex Explanation of Unix Permissions:

In cross-platform deployments, permissions may most often be Windows-style ACLs (access control lists), allowing a wide variety of context-sensitive settings but requiring a degree of administrative overhead to set up and maintain. On native Mac OS X systems, you’ll most likely be dealing with POSIX-style permissions (also known as Unix permissions) which define file access as granted to the owner, the group, and others. This information is available for every file and folder in the Finder by highlighting an item and choosing “Get Info” in the “File” menu, then selecting “Ownership and Permissions” in the window that appears.

The underlying Unix operating system keeps track of those file permissions as numeric values, where 4 represents read, 2 represents write, and 1 represents execute (which the Finder doesn’t report). These values are additive, so that a file which allows read and write access to it’s owner and read-only access to it’s group and others is denoted as 644, with the 6 being the sum of 4 for read and 2 for write. For a directory these read and write permissions are denoted as 755 (without execute permissions a user is unable to interact with or even list directory contents, so an additional 1 is added to each position). It’s these numeric values that are used by Unix commands like chown and chmod, which change ownership and permissions mode respectively.

When you create a new file the default permissions are defined by a value called the umask. This value is subtracted from 666 for regular files (and 777 for directories) to determine their access privileges. So when creating a new folder, a umask of 022 would yield permissions of 755, allowing the owner to both read and write enclosed files while the group and others are able to read them. Unfortunately, these are the settings used by the Finder in a new OS X installation.

A Simple Way to Improve Finder Security:

By default, the Finder creates folders with permissions that allow read access to anyone who can log in to your machine. This isn’t a problem if users only save files in the pre-existing folders in their home directory (like Documents), as their permissions already prevent access by anyone but the user.

When users create additional directories, however, the documents stored inside them can be accessed by other users on that computer (or in the case of servers and when file-sharing is enabled, by anyone on the network). This is seldom the behavior that users expect, and in many settings it can present a serious security problem.

There are lots of ways to adjust the umask system-wide, depending on the OS version you’re using (such as the GlobalPreferences.plist and the NSUmask property). Unfortunately, setting the umask for the entire system is also a really good way to break things unexpectedly.

The easy way to solve this issue is to adjust the Finder’s umask settings by creating a new preferences file on the command line. So long as the files your applications save are inside folders the Finder created, you’ll have the security you need to prevent casual snooping. While logged in as an administrative user, open the Terminal and type:

defaults write /Library/Preferences/com.apple.finder \
umask -int 077

On their next login, users who create new folders in the Finder will have their permissions set automatically to 700 — allowing them to read and write the contents but preventing access by any other users entirely.

Recommended Reading: Is there anything that Wikipedia can’t explain? I’m not sure, but for more information on this topic, take a look at their excellent file system permissions entry.

While these restrictions can be determined on a user-by-user basis, this approach can quickly become hard to manage. The more scalable option is to utilize groups, either from existing directory services or created specifically for this purpose on the local machine.

With your access model planned, open Server Admin as an administrative user and highlight your server name in the left column. Then choose the Access button from the strip along the top right, and you’ll see a list of the services available to regulate.

Simply uncheck “Use same access for all services” then choose a service on the left, adding users and groups to the list on the right with the plus button. When you’ve configured the services to your satisfaction, hit “Save” to enforce your policy.

The procedure is deceptively straightforward. Login Window can easily be configured to lock all users out of the machine, for instance, so it’s best to have a strategy for each service individually.

There’s also one service Server Admin doesn’t control access to at all. Just like individual client machines, the ability to remotely control your server is regulated in the System Preferences under the Sharing pane. Select “Apple Remote Desktop” from the list presented, then click “Access Privileges…” for the full complement of options.

With this approach, you can get some granular control over which services are available to which individuals, improving your security while diminishing your workload.

In a stock Mac OS X installation, the first account created during the installation process always has administrative privileges. That first account is also always assigned the UniqueID (the number by which the operating system identifies users) of 501. Since there’s a built-in preference setting that will hide accounts with a UID below 500, changing that number with the dscl command is a good place to start.

It’s advisable to do this from the root account (where you won’t need to use sudo for the following commands), or from another administrative account created for this purpose. Open the Terminal, and type:

sudo dscl . -change /Users/ADMIN UniqueID 501 NEWUID

Change ADMIN to the name of your actual administrative user, and NEWUID to the new UniqueID number you’d like to use. While many numbers below 500 are used by the operating system, 490-499 are left unused by default.

Because we’ve changed the UID, which is used to determine ownership of files, we’ll need to make sure that any files owned by that user (especially their home directory) have their ownership changed to the new UID as well. This can be accomplished by searching for those files with the Unix find command, then changing their ownership with chown to the new UID:

sudo find / -user 501 -exec chown NEWUID {} \;

With file ownership now matching the new administrative UID, the last task is to tell the system not to display the administrative user at login or in the Fast User Switching menu. This is accomplished by editing the LoginWindow preferences file, by typing:

sudo defaults write /Library/Preferences/com.apple.loginwindow \
Hide500Users -bool TRUE

With this command, the initial administrative account will be hidden entirely, but it’s home directory will still be visible in the /Users directory. This is fine for most environments, but if you want that home directory hidden, you can move it to a hidden location and tell the OS to look there with the dscl command.

OS X keeps the root home directory in the hidden /var directory. That’s unusual for Unix, but it sets a precedent you might as well follow. To hide your administrative account’s home directory in the same manner, move it by typing:

sudo mv /Users/ADMIN /var/ADMIN

With the directory now hidden from the Finder, set its new location with:

sudo dscl . -change /Users/ADMIN NFSHomeDirectory \
/Users/ADMIN /var/ADMIN

In both these cases, change ADMIN to the name of your actual administrative user account. With this method, your administrative account should be entirely hidden from view, allowing you to keep both it’s name and it’s existence a secret from typical users.

Now this process has the potential to destroy all the data on your machine, so make sure you have a current backup of the drive you’re going to mirror and confirm the backup is both restorable and bootable. Also, if you’re mirroring your existing startup disk, you’ll need to boot off an installation DVD or external drive for the first part of the operation. But if you have a system disk that isn’t already mirrored, this procedure can save you a lot of time and frustration.

First, from the Terminal, type:

diskutil list

This will produce a listing of the attached disks, along with their types, names, sizes, and identifiers, like so:

/dev/disk1
#: type name size identifier
0: Apple_partition_scheme *465.8 GB disk1
1: Apple_partition_map 31.5 KB disk1s1
2: Apple_HFS Server Disk 465.6 GB disk1s2

Use the name of the volume you wish to mirror to find it’s identifier. If your machine only has one internal hard drive, for instance, the identifier of your boot volume will most likely be disk1s2, the second slice (after the partition scheme and map) of disk 1. Once you’ve determined which disk you’re working with, type the following, replacing IDENTIFIER appropriately:

sudo diskutil enableRAID mirror IDENTIFIER

If all goes well, the disk will unmount, reappearing in the Finder a moment later along with “The disk has been converted into a RAID” reported in the Terminal. At this point you can insert the additional disk you wish to use in the mirrored RAID array (assuming it’s not installed already), then reboot the machine off the original drive.

Now when when you run diskutil list from the Terminal you should see two new listings, one for the new virtual RAID array (the one without slice information) and the other for the additional physical disk you installed.

/dev/disk2
#: type name size identifier
0: Apple_HFS Server Disk *465.6 GB disk2
/dev/disk3
#: type name size identifier
0: GUID_partition_scheme *465.6 GB disk3
1: EFI 200.0 MB disk3s1
2: Apple_HFS New Disk 465.4 GB disk3s2

Now with the necessary identifier information, you can assign the physical disk to the mirrored RAID array, replacing RAIDARRAY with the RAID volume (in our example disk2) and NEWDISK with the hard drive being added (here disk3):

sudo diskutil addToRAID member NEWDISK RAIDARRAY &

How long the RAID mirror takes to build depends on how much data is on the original volume, but the ampersand at the end of the command tells it to run in the background. When the process is completed you’ll have two fully mirrored and redundant disks, built from your existing installation without ever having to erase the original volume.

Listening For Syslog Data:

Like all Unix systems, Mac OS X logs it’s system activity through syslogd, the system logging daemon. This facility keeps track of all the system activity specified in /etc/syslog.conf, which details the kind of information to log (based on its process of origin) and its level of priority (set by its parent process). This system is well documented by simply typing “man syslog” at the command line. What isn’t so easy to find is how to configure OS X clients to send this data to a central collection server for analysis.

The secret is hidden in /System/Library/LaunchDaemons/com.apple.syslogd.plist. The last item in the file is a key named NetworkListener, and by removing the comment characters around it you can tell your Mac server to listen for any and all logging information sent to it via UDP port 514. Once that’s done, you’ll need to restart the syslog mechanism by opening the Terminal and typing:

sudo launchctl unload \
/System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load \
/System/Library/LaunchDaemons/com.apple.syslogd.plist

With syslogd restarted, your server can now receive and store remote logging data from Macintosh clients, networking devices, and other Unix-compatible systems.

Sending Remote Syslog Data:

Now you’ve got a brand new syslog server. It’s listening, but nothing’s talking to it yet. For that, we’ll need to edit /etc/syslog.conf on your client machines, telling them what (and where) to report.

Open the file in any text editor, and you’ll see the following format on the very first line:

auth.info;authpriv.*;remoteauth.crit /var/log/secure.log

On the left side are a series of “selectors”, each separated by a semi-colon. Each selector is made up of a “facility” (before the period), which indicates the category being logged to, and a “level” (after the period), which indicates the level of importance that a message from that category needs to reach before it’s logged. An asterisk acts as a wildcard, including any possible facility or level.

On the right side is an “action”, preformed when syslogd receives a message matching the specified selector. This is most often expressed as a local log file, but can also be another machine listening for syslog data.

So if you wanted to log every possible message to the syslog server, you could simply add the following line (replacing server.example.com with the name of your local server):

*.* @server.example.com

That would send all that messages from any facility at any level of priority to your new syslog server. That configuration’s fine for testing a single machine, but unless your goal is to completely flood your local network with logging traffic, you’ll need to narrow down your selectors significantly before you push your revised file out to all your client machines.

Once you determine what information is important to your organization, you can build a custom syslog.conf file to install across your whole network, and begin collecting system log information for all your machines.

Recommended Reading: For in-depth information on configuring remote logging, check the manpages for syslogd, syslog, syslog.conf, and logger.

Keep in mind that those files hold comments and folder views for the Finder, so you’ll be annoying your Mac users by disabling them. But if your own obsessive-compulsive tendencies outweigh other people’s convenience (and whose don’t?), it’s as simple as running the following command on each client machine:

sudo defaults write /Library/Preferences/com.apple.desktopservices \
DSDontWriteNetworkStores true

If you push this out with ARD, Casper Suite, or LANrev, you can leave off “sudo” as you’ll be running the command as root. Once the prefernces have changed, just reboot your machines for it to take effect. Just like magic, no more .DS_Store!

Special Thanks: It’s a beautiful lazy holiday weekend in Seattle as I write this, and there’s nothing lazier than stealing an old trick from the Creativetechs Tips blog.

At the heart of this practice is a default set of user data, carefully designed around the needs of the group and applied to each account when it’s first created. For Windows that data is typically stored in C:\Documents and Settings\Default User, while Unix systems have traditionally used /etc/skel. Mac OS X keeps its user template deep within the /System hierarchy, but while finding it can be difficult, customizing it to your needs is quite easy.

Start with a new account created specifically for this purpose. Choose the system preferences, dock items, browser bookmarks, server shortcuts, and application settings appropriate to your user base, leaving out anything you can instead control via Open Directory’s managed preferences. If you install individual applications or fonts on a per-user level, include those in ~/Applications and ~/Library/Fonts (where the tilde represents the user’s home directory).

Once you’ve finished, open Keychain Access from the /Applications/Utilities folder and delete the “login” keychain (both references and files when prompted) so new users will get their own keychain file created for them. You’ll also want to delete the cache files stored in ~/Library/Caches, clear out the “Recent Items” from the Apple menu, and (if you’ve used the Terminal) discard the ~/.bash_history file.

Now log out of the template, and log in to an Admin account. From here, you’ll be clearing Apple’s existing user template and copying your new template user in its place. In Leopard, that work can’t be done using the sudo command, and instead must be preformed as the root user, meaning you run the risk of doing serious damage if you don’t understand what you’re typing. If you’re at peace with that, just open the Terminal, and very carefully type:

su -

After prompting you for a password, this will let you assume the role of root, the Unix “superuser”. This allows you to modify and delete any file on the machine.

rm -r /System/Library/User\ Template/English.lproj/*

This removes everything inside the English-speaking template folder. If you’re utilizing another language, you’ll need to change this to the appropriate template.

cp -R /Users/TEMPLATE/* /System/Library/User\ Template/English.lproj/

In the command above, replace TEMPLATE with the actual name of the template account you’ve created. This copies your prepared user environment into the template location. After which you can:

exit

Now, when you add a new user account, it’ll be created with your customizations already in place. You can then delete the original account from the install you built it on, but be sure to back up the home directory. The process can be repeated on multiple machines, deployed on your server, or incorporated into a system image, all using the same template.

Updated: This post appeared in an earlier form for Tiger back in October 2007. We thought the technique was important enough that we dragged it out of the mothballs and updated it for Leopard.

As much time as this saves, however, you’re still cloning one machine at a time. What if you have tens or even hundreds of machines in your organization? Fortunately, there’s a built-in system to handle that as well. All you have to do is deploy NetInstall.

Creating NetInstall Images:

Ten years ago, when Apple’s administrative tools were aimed more squarely at academia, schools began using NetBoot to deploy their lab machines. By booting workstations off a central server-side system image, machines could run custom configurations that reset cleanly for each user. NetInstall was built on that same technology, allowing your servers to host similar custom images, but install them over the network onto each machine’s local disk.

Creating that image is now done with the System Image Utility, found on OS X Server in the /Applications/Server directory. While an image can be built directly from the OS X installation DVD, they’re hard to customize and seldom up-to-date. You’re better off creating a customized installation on an external drive (or saved as a disk image), then mounting it on your server. While Leopard theoretically allows network installation onto both Intel and PowerPC hardware from the same image, preparing separate images can save time and frustration in the long run.

When you’re ready, launch System Image Utility, and in the “Create an Image” window select “NetInstall Image”. Click “Continue”, then on the next screen enter a name and description of the image you’re preparing. For basic deployment just click “Create”, and save the image in the default location of /Library/NetBoot/NetBootSP0. For more complex configurations, click “Customize” to add post-install scripts, filtering by hardware type, or allow more client-side installation options.

You may want to go take lunch while your image builds, but when it’s done you can repeat the process for each image you’ll need to deploy over your network.

Configuring The NetBoot Service:

Once your images are prepared, the next step is to configure NetInstall on your network. Launch Server Admin and select the NetBoot service from the left column. Click the “Settings” icon in the toolbar, then choose the “General” pane. Here you’ll choose the network interface for NetInstall to run on (typically Ethernet 1), and the volume to store images and client data (the system array, in this example, though you may prefer another volume if you’re mixing NetBoot and NetInstall).

Now move to the “Images” pane. Check “default” if you’ve got a single image, or there’s an image you’d like to force if one isn’t specified. Next check “enable” for each of the images you’re planning to deploy, and choose the protocol over which you’ll offer them.

The NetBoot service can run over either HTTP or NFS. Given that most companies filter HTTP traffic, or engage some kind of web proxy for port 80, utilizing NFS is usually the better choice. In these circumstances, be sure to allow traffic over port 1049 on your internal network.

With these options set, click “Save”, then click “Start NetBoot” to take the service live.

Configuring Clients For NetInstall:

Once NetInstall is running happily on your network, all that’s left is to boot your client machines. If you’re only offering one image (and you’ve marked it as the “default” in the “Images” pane), you can simply restart your machines while holding down the “n” key. If you’re offering multiple NetInstall images, open System Preferences on your client machines, and choose the appropriate image to install from the “Startup Disk” pane. When you restart, the computer will boot into the installer automatically. You’ll need each computer connected to the network during this procedure, and you’ll save yourself a world of trouble if they’re using ethernet rather than wireless.

That’s all there is to it. Allowing you to save hours, if not days, of work on every rollout, NetInstall is one of the most powerful, and easiest, tricks up the Macintosh administrator’s sleeve.

Recommended Reading: There’s no better, or more extensive, explanation of BSDP (the protocol on which NetInstall is built) than the amazing How NetBoot Works by the even more amazing Mike Bombich.

If you never again want your users annoyed and flummoxed by this user interface puzzle, you can easily change the default display setting for the print dialog. Just open the Terminal and type:

defaults write -g PMPrintingExpandedStateForPrint -bool TRUE

This changes the print settings for the current user, defaulting to the expanded print dialog above and exposing the options previously stored in the “Page Setup” dialog.

One option is to disable use of certain hardware components at a system level. Kernel extensions, the software which allows the system to access hardware, are kept in the /System/Library/Extensions folder. Removing specific extensions from that folder will disable the associated hardware, preventing it from being used. Remove the wrong ones, unfortunately, and the your operating system won’t boot.

If you want to prohibit wireless access, those files are AppleAirPort.kext, AppleAirPort2.kext, and AppleAirPortFW.kext. To disable Bluetooth capabilities (and therefore Bluetooth file transfer), you’ll want IOBluetoothFamily.kext and IOBluetoothHIDDriver.kext. Apple’s iSight cameras can be disabled to prevent video and photographs of your facility by replacing AppleUSBVideoSupport.kext and Apple_iSight.kext. The use of external hard drives is regulated by IOUSBMassStorageClass.kext and IOFireWireSerialBusProtocolTransport.kext.
For every hardware interface, there’s a kernel extension file to match.

If your goal is to disable your chosen hardware permanently (so that software updates won’t re-enable it), just replace the missing files with empty text files of the same name, then “Get Info” on each file in the Finder and check the “Locked” option so they won’t be reinstalled.

Using this technique, you can insure that even users with administrative privileges can’t get around the hardware restrictions on your standard installation.

Recommended Reading: Apple’s very technical explanation of kernel extensions can be found at their developer site. You might also consider controlling hardware access through Open Directory’s managed preferences, explained previously in this very blog.