MacTechNotes

Friday, September 23, 2005

Security Update 2005-008 for 10.4.2 Details

Overview
The 2005-008 (for 10.4.2) security update modifies several OS components: CoreServices' CoreTypes and SecurityAgent, ApplicationServices' ImageIO and QD frameworks, Message framework, System framework, prebinding info, ruby's xmlrpc, and securityd.

Read on for more detail


CoreServices
Two bits are updated here: the CoreTypes bundle and the SecurityAgent app.

  • CoreTypes bundle
    CoreTypes.bundle helps the OS (and apps which use OS-provided interfaces) in identifying file types from various bits of information (eg, file extension, MIME type, UTI) as well as providing icons for those files. Not sure which issue is fixed by this, perhaps that bit at the very end about Safe Download Validation?
    Files:

    /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist
    /System/Library/CoreServices/CoreTypes.bundle/Contents/version.plist
    /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/System


  • SecurityAgent app
    SecurityAgent.app handles several sensitive bits related to (duh!) security (eg, changing certain passphrases, authenticating the user for various tasks). This is the fix labeled SecurityAgent on Apple's description.
    Files:

    /System/Library/CoreServices/SecurityAgent.app/Contents/Info.plist
    /System/Library/CoreServices/SecurityAgent.app/Contents/version.plist
    /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent




ApplicationServices
Two parts are updated in ApplicationServices: the ImageIO framework and the QD framework.

  • ImageIO framework
    ImageIO.framework covers part of the CoreGraphics image system (reading and writing images). Fix labeled ImageIO on Apple's description.
    Files:

    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/Info.plist
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/version.plist


  • QD framework
    QD.framework is the QuickDraw framework, graphics programming from older Mac OS made available on Mac OS X. This is the fix labeled QuickDraw Manager on Apple's description.
    Files:

    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/Resources/Info.plist
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/Resources/version.plist




Message framework
Message.framework is the framework which contains messaging functionality (email mostly, or perhaps exclusively). This MAY fix what's labeled Mail about auto-reply and encrypted messages on Apple's description. I say MAY since it's not completely obvious, but this doesn't seem to apply to any other listed fixes, and makes sense.
Files:

/System/Library/Frameworks/Message.framework/Versions/B/Message
/System/Library/Frameworks/Message.framework/Versions/B/Resources/Info.plist
/System/Library/Frameworks/Message.framework/Versions/B/Resources/version.plist


System framework
System.framework is the very low level stuff for the OS. Most likely fixes the fix labeled malloc on Apple's description.
Files:

/System/Library/Frameworks/System.framework/Versions/B/Resources/Info.plist
/System/Library/Frameworks/System.framework/Versions/B/Resources/version.plist
/usr/lib/libSystem.B.dylib


prebinding info
A list of files of interest to the prebinding system was updated here, no idea why.
Files:

/private/var/db/dyld/update-prebinding-paths.txt


ruby's xmlrpc
Ruby (the scripting language) has a module for XML-RPC, which is what's been updated for the fix labeled Ruby on Apple's description.
Files:

/usr/lib/ruby/1.8/xmlrpc/utils.rb


securityd
securityd (née Security Server) handles some low-level bits for the SecurityAgent app. Fixes what's labeled securityd on Apple's description.
Files:

/usr/sbin/securityd



continues...

Tuesday, September 20, 2005

Special Logins in Mac OS X

Overview
The login window application (/System/Library/CoreServices/loginwindow.app) is what runs the login window (hey, something actually logical here). It has a few "special" accounts which start with the greater-than sign (>) and need no password. These have been documented in various locations, practically since 10.0, so this article will also show how to try and find new ones whenever loginwindow.app is updated.


Using These Accounts
First, these are only usable if you have the login window display as Name and password instead of the default List of users. This setting is available in System Preferences, under Accounts then Login Options (bottom of the pane on the left list where accounts are shown). You'll need to be an admin and use the lock at the bottom to authenticate prior to changing this setting.

The Accounts
As of 10.4.2, there are four special accounts and one that may or may not be one. Their function can usually be inferred from the name:

  • >power
    Does a power-down of the system

  • >restart
    Simply restarts the OS

  • >exit
    Exits loginwindow.app which then respawns, so acts like a "restart loginwindow.app"

  • >console
    Switch to command-line interface console; useful if you like that kind of thing or need to do work outside the Aqua interface (changing some configuration information, removing cache files, etc).

  • >switch-user
    This is the one for which I have yet to find an actual function, if it is in fact a special account at all. It acts like a normal user account from the main loginwindow.app window, and judging from context of where it's located in loginwindow.app (see below), I thought maybe the screensaver username/password window, but no go there either.


Finding These Special Accounts
While the list of special accounts hasn't really changed since 10.0 or perhaps 10.1 (console, exit, restart, and power were there since at least 10.1) there's always the possibility of new accounts in the future. This is a description of how I've found these in the past and how to (possibly) infer functionality, or at least where they are used.

First, these accounts don't really exist anywhere (eg, in NetInfo where accounts usually live on Mac OS X), but are hardcoded into loginwindow.app. To find them, first fire up Terminal, then run

strings /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow | more

What this does is pull out the interesting strings from the loginwindow.app binary then send it to more so we can easily scroll through it.

What we're looking for is anything which starts with the greater-than sign, so (using more's search facility) we'll look for a greater-than sign at the beginning of a line. Typing

/^>

then Return will do it (that's / search for, ^ at the beginning of the line, a >; see any handy reference on regular expressions for more information, man re_format if you're still in Terminal and either comfortable with *nix technical manpages or are a masochist).

If you're following this in Terminal, the result will be at the top of the window, and should show the four well-known special logins: power, restart, console, and exit (greater-than sign removed for easy HTML editing here). If you use the k or up-arrow key to scroll up a few lines, you'll note there's nothing too interesting around them, suggesting a global use for these (we're assuming).

The n key will go to the next match, so hit it until you get just past exit, which should show (on 10.4.2) the unknown switch-user string. Again, using the k or up-arrow key, you'll note this one is around some stuff referring to the screen saver. Since the switch-user account doesn't work in the main login window window (that sounds funny), perhaps it works for the screen saver since it seems to live in code relating to it. Note there's even a button Switch User... on that window, so perhaps we're on to something. However, it doesn't seem to work here either. There's a good chance this is just a coincidence, and switch-user isn't a special login user at all.

Using the n key again to get past switch-user will show that this is the final match, ending our search.

What Happened?
Basically, what we've just done is look for interesting data in what's actually a binary, non-human-readable file (loginwindow.app's actual executable). In this case, we found four known special logins and one that may or may not be one (it doesn't work on the main login window, nor the screen saver one). If others are added in the future, this procedure should help in quickly discovering what they are called, and actually trying them should determine what they do.


continues...

Friday, September 16, 2005

ssh slowdown after 2005-007 update

To anyone who's noticed an odd slowdown in ssh since the 2005-007 security update on 10.4.x, and you've seen gssapi-with-mic in a verbose use of ssh, your problem may be that you don't need the GSSAPI authentication stuff enabled.

To test this theory, try running ssh -o GSSAPIAuthentication=no hostname to see if things work faster. If so, you can add the line


GSSAPIAuthentication no


to your ~/.ssh/config file. If you don't yet have one, create it with the following lines:


Host *
GSSAPIAuthentication no


so that the GSSAPI setting applies to all hosts.


continues...

Sunday, September 11, 2005

IPSec Interoperability Warning

For anyone trying to make IPSec work between Mac OS X (at least on 10.4.2) and OpenBSD (3.7), note that you need to be careful when choosing your cryptographic algorithm. Among the choices both OS's offer is AES (aka Rijndael), in the standard key sizes of 128, 192, and 256 bits. 128 bits is fine, but it seems (in my testing) that using AES-192 or AES-256 just does not work between Mac OS X and OpenBSD.

Since the 128 bit size works, it can't be a basic AES issue. Also, Blowfish works up to 448 bits, so it's not just a keysize issue either.

The neat trick is to figure out which side is "wrong" if one is...


continues...

NetInfo groups and group membership

If (on 10.4.x) you've added a new group and/or added a user to a group via NetInfo Manager (or the command line), but things like id don't seem to show that group, the problem may be a daemon called memberd.

This daemon (I believe new with 10.4) is a helper for group memberships (see the manpage for memberd for full information).

To tell it to reset its cache (so it sees new stuff), simply

sudo /usr/sbin/memberd -r

The user will still need to logout & back in, but this should get the group information updated properly.


continues...

Thursday, September 08, 2005

ssh-agent on Mac OS X

Overview
There are several methods one can use to make sure ssh-agent is running for you and that other Aqua apps can take advantage of it. This describes the one I use, which is simply two files: one to setup the environment for all Aqua apps, and one which is automatically run when a Terminal (or xterm, or iTerm, etc) window is opened.


Environment
The important part of using ssh-agent is an environment variable, SSH_AUTH_SOCK, which points to a socket used to communicate with ssh-agent. What I do is set this in ~/.MacOSX/environment.plist to point to /Users/blb/tmp/ssh/ssh-agent.socket (which, for the paranoid like myself, should be in a directory readable only to the user, ie, mode 700 for /Users/blb/tmp/ssh).

Setting it involves writing the file environment.plist, which is a property list (hence the plist extension). The format is XML, and mine is as such:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>SSH_AUTH_SOCK</key>
<string>/Users/blb/tmp/ssh/ssh-agent.socket</string>
</dict>
</plist>

This gets SSH_AUTH_SOCK in your environment on future logins. Be sure to restart Terminal (at least) so it can pick up the change. Of course, it doesn't do much until ssh-agent is running.

Running ssh-agent
ssh-agent itself needs to be running, and setting the environment variable doesn't help with that. The other step is to modify your login shell script to run one new script (which I've called check_ssh_agent) that runs ssh-agent if it isn't already running. This means that you do have to pop up a Terminal window once so your login shell script will run, but then no more worries. My check_ssh_agent is:

#!/bin/sh
#
# Check that the ssh-agent is running, and if not, kick it off
#

if [[ -z $SSH_AUTH_SOCK ]]; then
SOCKETFILE=/Users/${USER}/tmp/ssh/ssh-agent.socket
else
SOCKETFILE=${SSH_AUTH_SOCK}
fi

/bin/ps -wU ${USER} | /usr/bin/grep "[s]sh-agent" > /dev/null
if [[ $? -gt 0 ]]; then
/bin/rm -f ${SOCKETFILE}
/usr/bin/ssh-agent -a ${SOCKETFILE} > /dev/null
/bin/chmod 600 ${SOCKETFILE}
fi

You'll note that my paranoia continues as, after ssh-agent is run, the script sets the socket to mode 600 for extra safety.

Once ssh-agent is running, you can run ssh-add to add whichever keys you use.

Caveats
There are a few issues which must be pointed out with this method. The first is the previously-mentioned one where you have to open a Terminal window to get ssh-agent running. For me, this is simple since I have Terminal running most of the time. For some, it may be a bit annoying. One solution to this would be to change the check_ssh_agent script to be a .command file and set that to be run on login (I haven't tested this method, however).

Another is that ssh-agent will continue to run after logout. Since the process is running with your ID, and is communicating through a socket to which only you have access, you only need to worry about others accessing your account, and root. But this also applies for the time while you are logged in as well, so it shouldn't be to major a concern. And if you don't trust root on your machine, you shouldn't be using sensitive passwords with any process on that machine. Besides, how often do you log out anyway?


continues...

Sunday, September 04, 2005

Mac OS X as an NFS Server

Overview
This covers the steps necessary to export filesystems on Mac OS X via NFS. This was originally written in the 10.1 days, but is still applicable as of 10.4.2 (non-server versions).
Like setting up a client, configuring OS X to be a server involves updating NetInfo. For a server, there are several Unix daemons which need to run (one of which needs to be notified if it is already running).
The example filesystem to be exported in this document will be /external/path; obviously change this to something useful.
The steps are to add a new directory to NetInfo, called /exports, and add directories to that which are to be exported.


NetInfo Changes, via Graphical Interface

  1. To accomplish this in Aqua, run NetInfo Manager (located in /Applications/Utilities) and authenticate as an administrator (the little lock at the bottom of the window).
    Authenticate lock
    Authenticate lock


  2. We need to create a new directory, so click on the left-most directory (called simply, /), and create a new directory (through the button, menu option, or shortcut Cmd-N).
    This will create a new directory called new_directory, which we need to rename.
    root in the directory browser
    root in the directory browser

    Ways to create a directory
    Ways to create a directory


  3. In the bottom-part of the window, double-click on new_directory in the Value(s) column, which will highlight new_directory and place the insertion point there. Simply type exports to rename it, then save changes (Cmd-S or Domain menu, and select Save) to update the browser portion of the window.
    Renaming the newly-created directory
    Renaming the newly-created directory

    Now renamed, but not saved
    Now renamed, but not saved

    Now renamed and saved
    Now renamed and saved

    All exported filesystems will be listed under this new directory. Let's add one.


  4. Click on exports in the browser, and create a new directory. The value of the name property for each subdirectory in exports specifies the local filesystem to be exported (in our example, /external/path).
    Double-click new_directory in Value(s), and enter /external/path (make sure there is no trailing slash on this). This specifies the local path to export to clients, but nothing about which clients should be allowed access, or what options to use. For that, we need to add two more properties.


  5. Under the Directory menu is a command, New Property, which is what we will use to add the properties. Select this command twice, as we'll be specifying the clients who will be allowed access, and the export options.
    Two new properties added
    Two new properties added


  6. Double-click the first new_property and rename it to opts; set the value of this property to ro to export this filesystem as read-only (see the manpage for exports for the options which can be used). Change the second new_property to clients, and set the value to a blank (delete what is currently there), which means export to all clients (see the note about default entry, below).
    Properties are now set
    Properties are now set


  7. Save changes. All required information is now in NetInfo for the system to export filesystems via NFS. What's left is to notify or start the NFS server-related daemons.


You can repeat this procedure for any other directories you wish to export (but be sure to read the note about default entry, below, if you export several directories to empty clients properties).

NetInfo Changes, Command Line
Adding NFS export information to NetInfo from a command line involves running a few simple commands: one to create the entry, and two more to add the necessary options.


  1. To create the new entry, run

    sudo nicl . -create /exports/\\/external\\/path

    Since NetInfo uses the / to separate path components, and we have / characters in the entry we want to create, those / have to be escaped. This is done with the backslash, \, and since we are running in a shell, we need to double them up. After the shell is done examining the command, the string \\/ becomes \/ which is what we need to pass to nicl. If we don't use any backslashes, nicl will end up creating an entry /exports/external which has a subdirectory path. This is definitely not what we want.
    Basically, double-backslash the forward slashes in the path to export (/external/path), but not the NetInfo path (/exports/). Note also the part /\\/ as the path we are exporting is /external/path which includes the leading /.
    If you added /exports/external\\/path then the path exported would be external/path which is a relative path, but relative to what?
    Make sure to not put in a trailing slash on the path.


  2. Now we need to add the two properties which specify the allowed clients and any options we need. These properties are clients which we'll set to an empty string (which means all clients, but read the note on default entry, below); and opts, set to ro so the directory is mounted read-only (see the manpage for exports for the options which can be used). The commands to accomplish this are:

    sudo nicl . -append /exports/\\/external\\/path clients ""
    sudo nicl . -append /exports/\\/external\\/path opts ro



You can repeat this procedure for any other directories you wish to export (but be sure to read the note about default entry, below, if you export several directories to empty clients properties).

Starting Daemons or Notifying mountd
For serving NFS, Mac OS X has three daemons which need to be running: portmap which tells clients how to contact the NFS daemons, mountd which handles mounting of NFS filesystems, and nfsd which handles all the rest of serving NFS. See the respective man pages for more information on these.
The first thing to know is, if a machine has no exports listed, these daemons will not be started when the OS starts. portmap is started by /System/Library/StartupItems/Portmap/Portmap (prior to 10.4, and by launchd in 10.4 and later), and both mountd and nfsd are started by /System/Library/StartupItems/NFS/NFS. If you're curious, a look at these scripts will show where they check for exports before starting the respective daemons. The NFS script also starts the NFS client daemons, FYI.
The point of this information is, if this is the first time you add NFS exports, these daemons have to be started before anything works. If this is the case, you'll need to start the daemons (mentioned below). If they are already running, you merely need to notify mountd of export changes (also below).

Starting Daemons
If the daemons aren't running yet (ie, you just added your first exports), you can either start them up by hand, or simply reboot. To start them, run (don't start portmap if you're running on 10.4 or later):

cd /
sudo /usr/sbin/portmap
sudo /usr/sbin/mountd
sudo /sbin/nfsd -t -u -n 6

The order is important. The arguments given to nfsd are the default; if you've added your own to NetInfo's /config/nfsd, use those instead. Once they are started, you're ready to test them.

Notifying mountd
If the daemons are already running, modifying /exports requires a notification be sent to only mountd. This can be done simply by running:

sudo kill -1 `cat /var/run/mountd.pid`

Note those are backticks, not single quotes.

Testing The Exports
To see what mountd is offering, you can run:

showmount -e

This shows the exported filesystems on your machine. You can also run this against another machine as:

showmount -e nfsserver

The output from showmount should look like:

Exports list on localhost:
/external/path Everyone

This indicates the exports are setup properly and mountd is aware of them. The next test is to actually attempt to mount the filesystem. This is accomplished by running:

sudo mount localhost:/external/path /private/mnt

This mounts the exported filesystem into /private/mnt, so an ls of /private/mnt should show the same files as under /external/path.
Once this is verified, unmount it by running

sudo umount /private/mnt

The only testing left is to try mounting the filesystem on a different machine. If that doesn't work, you'll have to consult further documentation, as a full NFS troubleshooting discussion is beyond the scope of this document.

Notes About Being an NFS Server

  • default entry
    One big issue is where you try to export more than one directory on the same filesystem to a blank clients property. The first one is picked up, labeled as the "default entry" for that filesystem, and any other directory on that same filesystem with a blank clients list will not in fact be exported. This is covered in the manpage for exports, but the wording is quite vague.
    The fix for this is to add the additional directories to the name property of the first one you add. For example, if you want to export /Users/user1 and /Users/user2 to everybody and both directories are on the same filesystem, you would set it up as follows,

    sudo nicl . -create /exports/\\/Users\\/user1
    sudo nicl . -append /exports/\\/Users\\/user1 name /Users/user2
    sudo nicl . -append /exports/\\/Users\\/user1 clients ""
    sudo nicl . -append /exports/\\/Users\\/user1 opts ro

    This then causes both /Users/user1 and /Users/user2 to be the default entry.


  • Security Information
    One note about security. Be very careful with exports which use an empty clients property, as that means any machine can see the exported files. Whenever possible, only specify machines which need to access the exported filesystem. Also, whenever possible, export filesystems read-only (an opts value of ro).


  • Viewing /exports from the command line
    If you want to look at what's currently in /exports from the command line, run

    nidump -r /exports .

    This will dump out the information recursively (what's in /exports, and all the information pertaining to it). It should look something like

    {
    "name" = ( "exports" );
    CHILDREN = (
    {
    "name" = ( "/external/path" );
    "clients" = ( "" );
    "opts" = ( "ro" );
    }
    )
    }




continues...