One of the things that I can now talk about (and I'm very excited about it!) is application sandboxing.
How of you remember the Nimda worm from 2001? This was a rather nasty worm that spread via (among other vectors) Outlook e-mail clients on Windows. The victim didn't even have to double-click on an attachment; all the victim had to do was *look* at the e-mail in Outlook, and the attachment (an executable file disguised as a WAV) would be run automatically.
Quick Look on Leopard would appear to have the potential for a similar vulnerability, especially since any application developer can provide a Quick Look plug-in to preview the contents of a file. Even assuming the best of intentions (which we can't since malware writers will gleefully take advantage of any hole that they find), some overworked, underpaid programmer somewhere is going to make a mistake and leave an opening where a malformed document of some type can be used to trigger the vulnerability and allow the execution of arbitrary code. If that happens, then a worm could spread by sending out a file that would be looked at using the Quick Look in the Finder (which is used for document previews in column view or cover flow as well as larger previews), The mere act of opening the folder that contains the file could cause the worm to spread.
Well, I'm sure that this occurred to the engineers at Apple, and they came up with a way of preventing Quick Look from becoming a hazard. The Quick Look server daemon runs in a sandbox, which prevents it from making outbound network connections (except to unix sockets) or accepting inbound network connections, running any kind of debug mode tools. This is controlled by a configuration file in /usr/share/sandbox. There are a number of additional files that contain the sandbox configurations for a dozen additional processes; it's pretty interesting to look into the files and see what kinds of protections are important. I'm not sure that this is sufficient to make quicklookd truly safe, or whether the restrictions can or should be tightened down further. I'll be experimenting with this in the near future.
I'm sure this is not a problem for anyone on this list, but don't move over to Leopard just yet! I am still setting up testbeds to see what happens under different combinations of circumstances. I'm sure you are as well. Some of the situations that I'm looking at are:
One particular concern is administering 10.4 servers. Apple has announced that you can administer servers with the Leopard tools if they have been upgraded to 10.4.11. Even then, I may need to hold on to the 10.4 Server Admin tools for some clients. I have a report from another Apple consultant that if you use Pacifist, you can extract the applications themselves (not the parts in /System/Library) and administer Tiger servers.
Another important reason to wait is that developers have not had a chance to test their packages against the GM version of Leopard — we didn't get it until last Friday, just like the rest of the public. I have my own remarks about that, but they're not reproducible here as they are quite unprofessional. Although the initial fixes may only take a short time, testing, debugging, and documentation will take a lot longer even for a small application. I'd say it will take until early December before we get a critical mass of applications straightened out on Leopard. (FYI, Baby Banger downloaded from my website, a four year old PPC-only build, still works perfectly! :-)
If you want to look at file system ACLs from the command line, don't include a trailing slash on a directory name. For some reason, the /bin/ls tool has a bug where if you execute the command
ls -lae /Path/to/directory/
it does not print out the ACLs associated with each file or folder. Using
ls -lae /Path/to/directory
(without the trailing slash) gives the expected result.
I am releasing a neat little script engine and AppleScript Studio application that lets you run and manage multiple LoginHook and LogoutHook scripts. I'm calling it a 0.9b beta release — it's a bit rough around the edges, but it works and it doesn't have any known bugs. Get it from <http://ps-enable.com/software/LoginHookMultiScriptManager0.9b.dmg/view>.
--Paul
A small selection of random stuff this time around:
Mac OS X in its default state does not have an active root account. Mac OS X Server, on the other hand, does have an active root account. Why is this the case? Mac OS X Server has an active root account for one and only one reason: when you first create an Open Directory replica, the Open Directory master *must* have an active root account. The root account is not needed for normal replication, only for the initial creation of the replica. Thus, as a best practice, you should disable the root account on a Mac OS X Server. You can do this using the NetInfo Manager application, by going to the Security menu and selecting Authenticate, then selecting "Disable Root User". Alternatively, you can use the Unix command:
dsenableroot -d
Run it as an admin user and enter the admin's password when it is requested. There is no need to use sudo for this command; in fact, it should be run without sudo.
When you need to set up a new Open Directory replica, you can activate the root account temporarily by using NetInfo Manager or giving the command:
dsenableroot
Again, done as an admin user without sudo. Create the replica, then disable the root account on the master.
(By the way, do not ever, *ever*, EVER try to delete the root account. I ended up reconstructing someone else's root account from single user boot mode while wearing only a towel at 7:30 in the morning when someone tried to do that!)
An interesting one from a colleague, Peter Yorgin:
I was reviewing a client's firewall logs and found an unusual number of intrusion detections, all labeled as 'WEB-PHP friends.php access" coming from a mac in the office. I've searched around for information on it and the only useful information I was able to find was that OS X is vulnerable to this and the recommended solution is to install a new version of vbportal. It appears that this machine has been sending out unauthorized email. I have since changed the setting on the firewall to prevent this but I want to understand what is going on and how to address the problem on the machine that is 'infected.'
The machine this is happening on (and presumably infected) belongs to the receptionist who only uses her computer for email, internet access, Office, etc. I know nothing about php or vbportal.
VBPortal is a commercial content management based on PHP.
<http://en.wikipedia.org/wiki/VbPortal>
There was a known security problem that allows e-mail to be relayed through the friends.php referral page. From the description, it sounds like the receptionist's Mac was being used to send e-mail via a friends.php page located on another server. There was nothing that could be done to upgrade or patch the VBPortal installation, as it was located somewhere else. However, it was likely that there was a script or daemon running on the receptionist's Mac that was initiating the connections to the VBPortal server.
What was going on? Again from Peter Yorgin:
I also spoke to a person at Apple about this and they suggested clearing the caches from the browser (in this case Firefox) on the machine from which the problem was occurring. It would appear that a script was installed on the browser unknowingly when the user went to some web site. I cleared the cache on the problem machine and the friends.php problems went away immediately.
I find it very interesting that a JavaScript could persist across reboots like this. I wasn't aware that it was possible. I'll definitely be investigating the potential for such problems more thoroughly in the future. Firefox in particular is suspect, as it essentially runs on JavaScript internally. I'd be interested to see how it was possible to lodge something into the cache that would persist across reboots.
This has been in the news again lately, both from Qwest and Verizon revealing differing levels of cooperation with authorities, but more importantly there is legislation beginning to work its way through Congress. It recently passed the House Committee on the Judiciary and the House Permanent Select Committee on Intelligence. A direct link to the text of the bill and an interesting summary of the bill's provisions is here:
<http://judiciary.house.gov/Printshop.aspx?Section=712>
It's a whole lot better than the travesty we have right now, although I still have my reservations. The President is threatening to veto the bill unless provisions are added to give retroactive immunity to telecom companies that gave more information to the government than was requested. I have a couple of points to make on this:
--Paul
A short newsletter this week with a couple of tidbits.
Several clients of mine have wanted to push out Open Directory bindings via a package, using ARD or Casper or allowing users to do it on their own. It's not hard to set up, but there's a twist. Also, this won't work properly for a trusted bind.
#!/bin/sh
# set authentication search path
/usr/bin/dscl localhost -create /Search CSPSearchPath /NetInfo/DefaultLocalNode
/usr/bin/dscl localhost -append /Search CSPSearchPath /LDAPv3/<server node>
/usr/bin/dscl localhost -create /Search SearchPolicy CSPSearchPath
Obviously, substitute the actual server IP address or DNS name (whichever you used for the binding) in for <server node> in the script. The reason for doing this is that the DirectoryService process will overwrite the file /Library/Preferences/DirectoryService/SearchNodeConfig.plist with what it has in memory, so if you push out that file it will be overwritten and the custom path that you set on the exemplar won't work. By scripting the search path using dscl, we can avoid the problem.
When I get a chance I'll create a package creation skeleton for setting this i[. For creating the package, I recommend that you use Iceberg, a freeware app that is much better than Apple's PackageMaker. <http://s.sudre.free.fr/Software/Iceberg.html>
Joe Moreno wrote a very well-reasoned and elegant letter to Brian Bilbray, his congressman, about changes to the current electronic surveillance laws. With his kind permission, I'm including a link here. <http://www.joemoreno.com/CongressionalLetter.pdf>
--Paul
This newsletter is a week late due to a trio of software releases. A lot of work went into these and I hope that you find them useful.
This is the official release version of MOSXSWebPassword. I fixed a few bugs from the beta — one Property key was misspelled ("entryPage" should be "entryPageName"), the success page redirect now uses a relative URL which should give you the correct destination protocol (http vs. https) and host by default, and the postupgrade script should do a better job of restarting the application.
Grab the release version from <http://ps-enable.com/software/MOSXSWebPassword1.5.dmg>
A while back on afp548.com, Joel Rennich posted an article about the bannersample project that ships with the XCode tools. While it's a neat idea, to quote a buddy of mine, "we looked at it, and it's kinda neat, but somebody needs to make it really work." That somebody was me. You can customize it by editing the Policy.rtf file inside the package, replacing the logo.gif file, and editing the timeout parameter in the info.plist file.
Grab it from <http://ps-enable.com/software/PolicyBanner1.0.dmg>.
If you need to replace every instance of a particular file inside a directory structure (e.g., distribute a set of bookmarks to every user's home directory), you can use my File Distributor application. You put in the path to the file that you want to use as a replacement, the name of the file that you want replaced, and the path to the folder where you want to start the replacement process. You can do this by typing it in, drag and drop, or selecting from a standard file dialog.
Grab it from <http://ps-enable.com/software/FileDistributor1.0.dmg>.
Joe Moreno (the guy responsible for getting me a job at Apple in the first place) sent me another cool thing that you can do with /usr/bin/screen — you can use it to emulate a serial terminal. In his words:
I've ... used screen to emulate Hyperterminal or Procomm when sending commands to my GSM modems:
screen /dev/tty.KeySerial1 19200
(connect to device KeySerial1 at 19,200 baud).
Joe also asked, "Isn't there also a way to have multiple users attach to the same screen session?" I looked into it and you can do it. One person starts a screen session, and then someone else can execute:
screen -x <screen number>
Both people need to be logged in as the same user on the target machine. There is a way to use ACLs to give multiple users access to the same screen session, but it's too complex to get into here.
If you are setting up a server remotely and your Server Assistant crashes, you won't be able to reconnect to the server to start the setup process again. To recover from this, ssh into the server and delete the file:
/System/Library/ServerSetup/.RemoteSetupInProcess
You can now reconnect using Server Assistant.
--Paul
First, a few troubleshooting quickies:
If you are having trouble communicating with a USB or Firewire device what's the first thing you should do? Go to the Apple menu, select "About this Mac", and click on the "More Info" button in the About box. This will launch System Profiler. Once System Profiler launches, click on the USB (or Firewire) line in the sidebar on the left. See if the device that you're trying to use shows up at all in the upper pane on the left. If it doesn't appear, then you have some sort of electrical connection problem -- a bad cable, a bad connector on your Mac or on your device, maybe your device isn't plugged in or turned on, or you might have a bad USB or FireWire hub in the middle.
Why you shouldn't change a home directory name, and how to fix it if you did — and why you shouldn't run as an admin user.
Apparently some folks have tried to change their home directories' name, by going into the /Users folder, clicking on their home directory, and editing it. And then everything stops working. To fix this, the easiest way is to use another administrator account. Go into the Accounts preference pane and get the exact spelling of the user's short name. Go into the /Users folder and change the user's home directory to match the short name, log out, and log in again.
What if you don't have another administrator account? Things go downhill from there. The next way is to boot into target disk mode, plug into another Mac, and fix it that way. However, you will need to use the command line to get the exact spelling of the user's short name.
sudo nicl -raw /Volumes/<Target HD name>/private/var/db/netinfo/local.nidb -list /users
If the troubleshooting machine has a hard drive that has the exact same name as the target machine's hard drive, you might want to temporarily change the hard disk's name to something else to be sure you're hitting the right disk. Be sure to use the private/var/ path, as using just var/ points you back to the troubleshooting machine's hard drive.
If you don't have another Mac handy, another alternative is to enable the root account on the machine. You can do this by booting from an install DVD, going to the menu and selecting Reset Passwords. Reset the root password, and you can log in to the machine as root and follow the first set of steps. Once you are done, log in as an admin user, launch /Applications/Utilities/NetInfo Manager.app, click on the lock and authenticate, and select from the menus Security --> Disable Root User.
If you don't have another Mac or an install DVD, you can fix things by booting into single user mode. Fsck and mount the drive, and use the following command to look up the correct short name for the user:
nicl -raw /private/var/netinfo/local.nidb -list /users
Then, look up the bad home directory name:
ls /Users
and rename the home directory
mv /Users/<bad name> /Users/<correct name>
What's the easiest and absolutely best way to prevent this from happening? Run as a standard user, not an administrator user. A standard user could not have renamed the home directory. This on top of all of the usual security issues involved with running as an administrator users. If you want to convert your account from an administrator account to a standard account, please see my earlier newsletter <http://ps-enable.com/articles/newsletters/newsletter11.html>.
Thanks to Kim Whittington, one of the one-on-one trainers at the Bethesda Row Apple Store, for inspiring these two.
A while back, I was hanging at the genius bar at the Tyson's Corner store and we ran into a weird one. The customer's iMac was set to autologin on boot, which it did, displaying the user's long name. However, after logging out, we couldn't log in again using the user's long name. We were able to log in using her short name just fine. What was going on? It turned out the user's long name had two extra spaces — one in the middle and one at the end. It looked like "Firstname<space><space>Lastname<space>". A little bit of quick editing in the Accounts prefs pane fixed that, but it was a frustrating 45 minutes to figure out what was going on.
I'm not big on politics in these newsletters, but we really need to do something about the wiretapping legislation that's going through Congress right now. The current administration has shown once again that the executive branch cannot be trusted to limit itself and will attempt to arrogate powers beyond those it is given, unless it is specifically required to have its actions reviewed by another branch of government. Mike McConnell, the Director of National Intelligence, was forced to admit that the current temporary wiretapping law did not help capture the recent terrorist cell in Germany. See <http://www.washingtonpost.com/wp-dyn/content/article/2007/09/12/AR2007091202267.html>.
Please write your Congressman and Senators and urge them to require that all electronic surveillance be reviewed by the judicial branch. In my mind, this is not a Republican vs. Democratic party issue; while I am a registered Democrat, if you feel that you can trust the Bush administration, consider how you would feel if a Hillary Clinton administration had the same powers. Quite frankly, I'd feel just as uncomfortable either way. Without some sort of required review, there is just to much temptation to overextend the executive branch's powers.
To lookup your Congressman and Senators, you can go to <http://house.gov/> and <http://senate.gov/> and enter your zip code or select your state at the top of the page. An e-mail is good, a fax or phone call is better, a hard-copy letter is even better. Since I live in the Washington, DC area, I may make a personal visit to my elected representatives to express my concern over this issue. Another way to help is to donate to the Electronic Frontier Foundation <http://www.eff.org/>.
This goes beyond the usual problems with Windows; it has to do with Microsoft's behavior. Microsoft just pushed a stealth update to ALL Windows systems — whether or not they were set to auto-update or not, and without notifying the owner of the computer. <http://blogs.zdnet.com/hardware/?p=779>. The potential for disaster is quite clear — anyone who depends on their system running smoothly, since you can't always tell when an update will cause a problem with a mission-critical application.
I trust Apple to test updates to the Mac OS, but I will verify for myself whether or not they work in my environment before I push them out to all of my systems. I specifically do not want automatic updates and I will move away from Apple if it should take the attitude that Microsoft is taking, which is one of minimizing the whole thing. <http://www.pcworld.com/businesscenter/article/137208/microsoft_downplays_stealth_update_concerns.html>
A couple of people have reported that Policy Banner 1.0 hangs the system at the login window. I'll take a look at it, but I'd like to get confirmation from anyone else who's seen it happen as well. A system profiler dump would be useful as well. To recover from it, just boot into single user or target disk mode and copy the /etc/authorization.backup file to /etc/authorization.
--Paul
I'm trying to be a bit more regular about sending out this newsletter, so here goes.
A fantastic little command line tool that seems to be little known. It allows you to set up a virtual terminal window that you can detach from, but it keeps running. This is great if you need to ssh into a server, set a long-running process going, then go home. If you just opened a terminal window and did that, the process would die once you disconnected from the ssh session by logging out or taking your laptop home.
Instead, before launching the long-running command, just type:
screen
at the command prompt. You will get a splash screen and then a new command prompt. Except for one thing -- this is now running inside a /usr/bin/screen session. Type in the long-running command, then hit:
<control-a>d
That's control-a, followed by the 'd' key. You're now back at your original command prompt, but the screen session is still running in the background. Disconnect, log out, go home, come back the next morning. Ssh into the server, then type:
screen -ls
This will give you a listing of currently running screen sessions. You should see something like:
There is a screen on:
1805.ttyp1.dhcp18 (Detached)
1 Socket in /tmp/uscreens/S-plsuh.
You can then type:
screen -r 1805
and you will be reconnected with your screen session. You can detach and reattach multiple times to the same session. The only downside is that it doesn't have a scrollback buffer, so if you're counting on scrolling back to see the printout this won't work. You'll need to redirect output to a file instead.
To end a screen session when you're done, type:
<control-D>
or
exit
Unlike detaching from the screen session, this kills it off entirely.
There was a bit of a kerfluffle recently over a journalist named Bob Keefe, who asked Steve Jobs, "Why doesn’t Apple participate in Intel’s 'Intel Inside' program (which pays computer makers for putting their stickers on its boxes and logos in their ads)?"
Regardless of whether or not question was an insightful one or not, I got some puzzled looks when I was discussing this with some colleagues, so I thought it might be useful to explain what the program is all about. "Intel Inside" is a co-op advertising program -- Intel will pick up part of the cost of running advertising if a computer manufacturer participates in the program, by putting stickers on their computers and including the logo in their flyers and other marketing materials.
Intel is not the only company that has a co-op advertising program; most manufacturers do. The idea is to build a brand in consumers' minds for a manufacturer further up the supply chain. For a commodity, the brand association for a buyer is the immediate supplier of the product. For instance, if you buy a head of lettuce at the supermarket, your association of the quality of that head of lettuce is with the supermarket — Safeway, Kroger, Stop & Shop, etc. However, if you buy a computer, your association of the quality of the computer is not necessarily with the shop that sold you the computer. More likely it's with the company that built the computer — Apple, Dell, HP, etc. By using co-op advertising programs, the computer manufacturers are trying to build their brands down the line, so that the brand of the computer is more important than the place you bought it from.
Most manufacturers co-op advertising programs are very attractive to the retailers who participate. Participation is likely to pay for most if not all of the costs of a newspaper flier in the Sunday ad sections, for instance. A retailer is in general trying to to out-advertise (or at least keep up with) its primary competitors — other retailers. The boost that the retailer gets from co-op advertising programs can be significant. I have heard anecdotally that co-op advertising programs can make up 50% of the advertising budget for a retailer.
Given that there's a lot of money potentially available, why doesn't Apple add the sticker and take advantage of Intel's advertising dollars? The answer is three-fold, I think. First, as most of the pundits have opined, Apple and Steve Jobs don't want to wreck the clean design of Apple's hardware with stickers. Second, and I think most of the pundits missed this, Apple already has a huge advertising budget that gets spent on ads in major publications and prime time TV spots, and Apple has the gross margins to support that budget. The amount that Intel can add to this for Apple is much less significant than if you compared it to your typical computer hardware manufacturer's advertising budget. Steve Jobs is a coldly rational and very creative businessman. If Intel was going to be able to contribute significantly to Apple's advertising budget through a co-op program, he would have found a way to make it work.
Third, I think that Apple is thinking long run. One of the points to note about co-op advertising is that it has the potential to make the downstream partner less important in the consumer's mind. A retailer has to get its name in front of consumers every week, since its competitors will do it no matter what, even if the advertising collectively builds the manufacturer's brand more than it does the retailer's. E.g., Best Buy needs to include an insert in every Sunday paper, or Circuit City will gain ground on them for mindshare, even though the ads (both Best Buy's and Circuit City's) build Sony's brand more than they do any individual retailer's. People think, "I want a Sony TV", rather than, "I want to buy a TV at Circuit City". Apple faces a different decision compared to Best Buy or Fry's. There's already a huge differentiation built up in people's minds between Macs and Windows PC's. If consumers are looking for Intel-based computers rather than Macs, then the distinction between a Mac vs. some Windows PC becomes much less sharp — which runs counter to Apple's whole marketing thrust.
At long last, the "Joel made me do it" release. Back in March, Joel Rennich posted an article to afp548.com, where he wrote: "A more secure way of handling the need for password resets would be to create a script, probably presented to the users as a webpage, that would allow a non-admin to change passwords only for non-admin users. I believe some of those among us have ginned something up along these lines. If you have we'd love for you to share."
OK, it took me a while, but I finally got the bugs worked out. Here it is in all its lush, plush smoothness! The new features are:
Configure the entry page
Configure whether to show a link to the admin reset password page
Configure the URL that the user will be taken to after a successful reset
Protect admin users' passwords from resets
Non-admin users in a specific group can reset non-admin users' passwords
Configure whether the status of non-admin user password resets is shown
I reworked the installer package to make it more reliable as well. You can download it from <http://ps-enable.com/software/MOSXSWebPassword1.5b1.dmg>.
Robert Watson is one of the true geniuses in the security research community. He recently gave a paper at the Usenix Workshop on Offensive Technologies (WOOT).
He was kind enough to explain what was going on in these attacks to me back at WWDC. System call wrappers are an attempt to prevent attackers from exploiting system vulnerabilities by constraining the actions of processes running as root. For instance, you might allow a web server to run as root but allow it to listen only on a port 80. This would prevent an attacker who compromised the web server from putting in a TCP listener back door. Some examples of system call wrappers are Systrace, the TIS Generic Software Wrappers Toolkit, and CerbNG.
Unfortunately, these all assume that kernel operations are atomic — i.e., there is no way to interrupt them while they happen. It seems trivial once it's pointed out (but I can tell you it was a huge light bulb for me) that on a multi-process, multi-threaded system, kernel interruptions happen all the time. As a result, you can send in an innocuous operation, have it approved by the wrapper, then interrupt the kernel and substitute a dangerous operation instead.
A truly brilliant paper, and actually quite short — only 8 pages long.
Well, that's all for now. I still have a ton more stuff that I want to write up: how to push OD settings to clients via packages, how to tweak user account information from Open Directory using Excel & BBEdit, a script to reset a user's login keychain, and a login policy banner. Maybe next week.
--Paul
A couple of quick notes on the iPhone, based on conversations with some of the staff at the Bethesda Row Apple store:
I had an absolutely jaw-dropping conversation with a kid in my son's Boy Scout troop. He didn't realize that "SQL" meant the language, not the database server from Microsoft. He also didn't realize that (depending on the application) there were lots and lots of alternatives to ASP.NET, and that the AJAX support might be better across browsers without so many problems if you don't focus on IE. Shudder
Once I pointed stuff out to him in a gentle way (he is just a kid, after all, and is pretty quick to pick up on things), he realized just how much he had to learn. I don't fault him at all; I fault the people who have been advising him on the tools to use, most of whom don't really know what they're doing. But really, I find it amazing that Microsoft has so brainwashed many people that they don't even realize that there is an alternative, and that the Microsoft way is more difficult and more expensive, both in terms of licensing and in terms of time.
I read about Universal's latest shot at trying to win leverage against the iTunes store, and thought, "here we go again." The same bunch of not-too-bright record company executives are trying to get more money out of the consumer by just squeezing, instead of providing more value. They're trying to roll things back to where they were before the digital music era; it didn't work back in 2005 when Warner Music CEO Edgar Bronfman, Jr. tried it and it's not going to work any better now. It all goes back to the concept of disruptive change in markets — and once the market is disrupted, it won't go back to the way it was.
There are many management/business/whatever books that talk about disruptive change in markets. The idea goes back to Joseph Schumpeter, an Austrian economist, who coined the phrase "creative destruction" in the 1940's. His insight was that as old industries fail, they release resources that are used by new industries that have a much greater growth rates. The logical conclusion in macroeconomic terms is that using economic policy (tax breaks, subsidies, protection from imports) to prop up old, established industries is a losing proposition. This has been shown many times over in real life — e.g., studies have shown that simply paying displaced steelworkers their annual salary would have cost us half of what the import tariffs used to try to save their jobs actually cost us. (And the tariffs didn't save their jobs in the long run anyway.)
On a microeconomic scale, the same holds true — a company should go ahead and kill an existing product if a new product comes along that is better and more profitable, even if the old product is still making money. However, how many businesses actually accomplish this? How many of you, faced with the choice, would actually say, "I will close down my retail storefront and move entirely to a web/phone-based business model"? Most companies are loathe to do this, even though their web-based business needs more people and office space to grow, and is growing very quickly.
Apple is one of the rare companies that has actually done this. It replaced the iPod Mini (released in January 2004) with the iPod Nano (released September 2005), even though the Mini was the hottest, best-selling iPod at that time; it was only in early 2005 that iPod Mini supplies finally caught up with demand. How many companies are willing to go that route?
Contrast this with a known set of dinosaurs — the record companies and the RIAA. All of them are bemoaning the drop in CD sales. All of them are trying desperately to gain control of the digital download market, with various schemes that seem destined to cut off their noses to spite their faces. EMI has gotten a clue and realized that non-DRM-encumbered music will gain market share, vs. Universal which is waffling on a long-term contract and trying to gain more leverage. The digital download market is where the growth is, but the record companies are too hung up on CD sales to realize that they ought to stop bothering with them (or at least de-emphasize them) and look for where the growth is. The record companies can assist in the digital download market in many ways, such as by coordinating the various national-level copyrights and publishing restrictions into a consistent international practice. But they haven't, and as far as I can tell, they're not even trying.
This newsletter is a bit light on technical content, because I've been trying to get a new release of my MOSXSWebPassword app out the door. Unfortunately, there's a persistent bug in the Directory Services frameworks that's causing problems. I hope to work around it soon.
--Paul
It's been a while, but I have a bunch of small stuff that you might be interested in.
Here are a bunch of interesting links that have come up in the last few weeks.
A chatty, fictionalized account of the ways that on-line bad guys make money off of the evil things that they do.
<http://www.cio.com/article/117150/How_Organized_Crime_Uses_Technology_to_Make_Money/>
A rather amusing "Dear John" letter written to Windows XP.
<http://darkbrownhole.blogspot.com/2007/07/breaking-up-is-hard-to-do.html>
An automobile parts manufacturer switches from Windows to the Mac.
<http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=operating_systems&articleId=298043&taxonomyId=89&intsrc=kc_feat>
<http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=operating_systems&articleId=297826&taxonomyId=89&intsrc=kc_feat>
Duke University's IT department eats crow. Note the passive voice in their linked press release to avoid taking responsibility. Anyone know what happened to Kevin Miller, the guy who proclaimed that the problem was the iPhone?
<http://www.macworld.com/news/2007/07/20/dukecisco/index.php?lsrc=mwrss>
An absolutely hilarious video on how NOT to make a PowerPoint (or Keynote for that matter) presentation.
<http://www.i-am-bored.com/bored_link.cfm?link_id=23724>
I've been seeing a boatload of spam recently that looks like this:
Hi. Family member has sent you a greeting card.
See your card as often as you wish during the next 15 days.
SEEING YOUR CARD
If your email software creates links to Web pages, click on your card's direct www address below while you are connected to the Internet:
http://72.174.224.251/?2b54ce75338ee7c634591933434671c1
Or copy and paste it into your browser's "Location" box (where Internet addresses go).
We hope you enjoy your awesome card.
Wishing you the best,
Webmaster,
funnypostcard.com
What a total pain in the neck. It's immediately obvious from the body of the spam that it's not something you want to click on, but you can't tell from the header/subject/from lines alone, so you have to at least look at the body if it isn't caught by your spam filters.
I've been playing with the /usr/bin/jot command line tool. It can print out either a sequential or random series of numbers/characters. For instance:
jot -r 1 10 253
prints out one number (the 1 parameter) at random (the -r flag) that is between 10 and 253, inclusive. This is really useful when you are setting up a new network in say, the 192.168.X.0/24 range, since you don't want to use 192.168.0.0/24 or 192.168.1.0/24, because you can run into IP address conflicts if you are using VPN to connect to or from the network. by running jot you can let the computer pick a good third octet — e.g., if the command prints out "141", then you can set up your network to be in the 192.168.141.0/24 range.
I put this into a random password generator shell script. I've been using the script to generate random passwords for several Open Directory transfer or re-construction engagements that I've been working on lately, and thought that you might find it useful as well.
]]>It's been just over a week since I spoke at WWDC and I'm pretty much still floating! It was pretty nerve wracking, and I was a nervous wreck starting the previous Sunday, when I realized that my OD session was the only IT track session in that time slot on Friday.
This strikes me as a potentially huge security issue. Many of the Outlook e-mail worms spread because of buffer overflows in the IE engine that was used to render the content. These buffer overflows allowed the worm to execute arbitrary code in the user context, not the system context. As a result, the mere act of viewing a message would trigger the worm to attempt to propagate itself to everyone in the user's address book and also act to trigger an attempt to escalate privileges to take over the machine. Granted, a lot of this was made easier by the fact that most Windows users were (at the time) running with Administrator privileges — but that isn't all too different from the way that many Mac users run right now.
QuickLook presents the same kind of vulnerability — multiplied by 100 or 1000! Application vendors will be asked to create rendering engines for their file formats, and if the rendering engine does not handle incorrect input properly, an attacker may cause arbitrary code to execute in the user context, just by having the user click on the file in the Finder. This needs to be sandboxed very carefully or it becomes a huge security vulnerability. Some techniques to harden the system would be a stack canary, address-space layout randomization, and systrace-style constrained file access. I can't comment on which of these (if any) are included in Leopard due to the NDA's, but even with these it is a serious concern. I'd really want a virtual machine-style constraint on what the QuickLook plugin is allowed to do.
Just to give you the quick run-down on this, in case you want to try it yourself.
First, steps 1-4 should be executed on Solaris, as root.
passwd: files ldap
group: files ldap
ldapclient -v manual -a credentialLevel=anonymous -a defaultSearchBase=dc=od-master,dc=example,dc=com -a serviceSearchDescriptor=passwd:cn=users,dc=od-master,dc=example,dc=com -a attributeMap=passwd:gecos=cn -a serviceSearchDescriptor=group:cn=groups,dc=od-master,dc=example,dc=com -a serviceAuthenticationMethod=pam_ldap:simple 10.17.1.1
The elements break down as follows:
-v Verbose output
manual Manual configuration (as opposed to using a config file or creating a config file)
-a credentialLevel=anonymous Use an anonymous bind for basic communication
-a defaultSearchBase=dc=od-master,dc=example,dc=com Default search base
-a serviceSearchDescriptor=passwd:cn=users,dc=od-master,dc=example,dc=com Where to look for user info
-a attributeMap=passwd:gecos=cn Map the gecos attribute in a standard passwd file to the cn attribute for users (long name on Mac OS X)
-a serviceSearchDescriptor=group:cn=groups,dc=od-master,dc=example,dc=com Where to look for group info
-a serviceAuthenticationMethod=pam_ldap:simple Use simple, cleartext LDAP binding for authentication
10.17.1.1 IP address of the Open Directory Master
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
to
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth binding pam_unix_auth.so.1 server_policy
other auth required pam_ldap.so.1
Your Open Directory users can authenticate to Solaris via ssh, telnet, or what have you.
Now to do Kerberos integration. It's pretty easy.
sudo kadmin.local
Once you have the kadmin.local prompt, export the necessary principals to a keytab file by using the following command, substituting the appropriate fully qualified host name and Kerberos domain as necessary.
ktadd -k /var/root/solaris_host_principals.keytab host/solaris.example.com@EXAMPLE.COM
Exit the kadmin.local tool by giving the command "quit".
For maximum security, export the keytab to a root-readable-only directory on an encrypted disk image.
You should now be able to get a TGT from the Open Directory master and connect to the Solaris machine using ssh without typing a password.
Slides from my preso are available at: <http://ps-enable.com/articles/WWDC2007Slides.pdf>
--Paul
I've been pretty quiet on the newsletter for a while, for a reason. I'm presenting at a session on Friday at WWDC — Session 542, Managing and Deploying Open Directory, 9:00 AM Pacific time.
I'll be posting my slides and demos a little bit later, but my part is a case study of a client where we're doing an Open Directory integration. In most of the case studies of directory services integration, people are taking Macs and tying them into some other directory services network -- generally Active Directory.
In this case, the company is using Open Directory as a central identity store, tying in other systems. Open Directory's standards-based design makes it easy to tie in other systems.
I've discovered a royal pain in the neck resulting from VPN with automounted share points.
In my network at home I have automounts for /Network/Applications, /Network/Library, and a home directory automount at /Network/Servers/crocus.goodeast.com/Volumes/raid/Users. This works fine for machines that are on the local network, but it turns into a problem for machines that connect via VPN.
Here's what happens: As long as I'm on the road with my laptop, it doesn't connect to the LDAP server so there's no automounts. However, when I connect via VPN the laptop gets an address on the local network and it loads the automounts — and then the automounts happen. The problem comes when I disconnect from the VPN. The automounts are still connected, but the server is no longer accessible. The result is long-running beach balls and hung apps. Also, the portable home directory mount also runs into problems since it will also be triggered and then gets cut off when I disconnect.
To work around this, I changed the way that DNS was resolved for VPN, using BIND 9 views. (You can also do this by running a different DNS server for the VPN clients.) It helped that I configured my VPN so that it was in a neatly separable network range: 192.168.1.64-79. In CIDR notation this is 192.168.1.64/28. Since all of the automounts come from my file server, crocus.goodeast.com whose IP address is 192.168.1.129. I set up a view that gave a different result for DNS clients in the VPN range. Instead of returning 192.168.1.129, the view returns 192.168.1.131 (an OpenBSD server that does not serve AFP). There is also a separate entry to allow for manual connections (where I want to retrieve a file by hand from the Finder, and I will do a manual disconnect.)
There is a lot of neat stuff from the keynote that we can discuss publicly. For me, the big pieces from Leopard are:
iChat Theater
Time Machine
Cross-client search
Quicklook
iChat theater is a radical improvement to remote collaboration.
Time Machine will transform the way we do backups.
Cross-client search will make it easy to find stuff. But the problem will be security and privacy in a networked environment. Who can get access to certain files across the network as a result of searches will be a serious issue.
Quicklook is neat, but I am seriously concerned in terms of security. Lots of Outlook worms on Windows work because of holes in the IE engine that allowed a malicious message to execute arbitrary code by just looking at it. A badly written Quicklooks plugin could lead to a buffer overflow and arbitrary code execution.
iPhone application development is Web 2.0/AJAX. This is really neat from a variety of angles. For an enterprise, it means that almost all of your existing apps just work with the iPhone if they work with Safari. The downside is that if you don't have cell coverage, none of your applications work. I'd like to see what I can find out as far as allowing Safari to access iPhone services. I wonder if I can somehow set up inbound access to the iPhone.
I won't be able to say much about the rest of the week, since we're under a non-disclosure agreement here.
The WorldWide Training and Certification department was merged with the Sales Training department, all of the training rooms in the Apple Market Centers will be closed, the course development will be outsourced, and Training Units will no longer be sold (although existing ones will be honored). A lot of details are still to be decided, and there's a meeting for us trainers tomorrow morning where we'll get more information.
--Paul
I received some seriously professional-looking spam, and I thought it would be interesting to analyze it. This e-mail slipped right through my spam filters. Currently most of what is getting through is full of junk to try to evade bayesian filters, but this one got through by mostly having good, meaty looking content. Note that the SpamAssasin score is only one * — a sign that it looks very unlike spam. In reality it's a phishing message that looks like a Bank of America message about suspicious account activity.
There are only two clues in the e-mail that this is not a legitimate message.
Neither of these would be easy to detect by your typical end user.
Once a user clicks on the link, they might notice that the URL line doesn't look like a real Bank of America URL, but then again many users don't bother to look at or understand the URL line, and the page may utilize JavaScript techniques disguise the URL. I did not view the page that the link leads to at the time, and it has since been taken down.
Bank of America could have helped this situation by checking the referrer header when their webserver returns their logo and other images. The spam message pulls the logo and other images directly from Bank of America's website. The BoA could have checked to see if the logo or other images were being requested by a legitimate page or by a page coming from outside their domain. If the request is associated with a page outside their realm, they could then return a different image that says, "Warning, you could be a victim of an identity theft attack!".
I've archived the message contents on my website at <http://ps-enable.com/images/articles/spam_source.txt/view>. You can see what the message looks like at <http://ps-enable.com/images/articles/spam_image.gif>
Finally! And only after a bunch of last minute shenanigans, the likes of which I have never seen before. The original bills, House Bill 18 (HB18) and Senate Bill 392 (SB392) were very close and were solid bills. HB18 was passed a long time back, unanimously and without killer amendments. On March 23, the Senate committee responsible for SB392 produced a bill with amendments that completely gutted it. On March 26th, the bill was sent back to committee by the Senate leadership without a vote, for reasons unknown. The suspicion is that the Senate leadership found out that they would not have had the votes to pass such an obviously dismembered bill, and had to take it back. On April 4th, the SB 392 came back out of committee with a different set of amendments that require a voter-verified paper trail, but that did not have an audit requirement.
The eventual form of the two bills that was finally passed on April 9th (the last day of the legislative session) requires a hand-marked, optical scan paper ballot, but does not have an audit requirement. Nevertheless, it's a HUGE victory. We can now have true audits, even though they're not required, and the bill does not require implementation until 2010, too late for the 2008 elections. There is also a budget issue, although studies have shown that two years of maintenance costs on the Diebold electronic voting machines would be enough to pay for the optical scan machines outright.
If the Maryland State Board of Elections staff gets going right now there is no question that we can be ready in time for the 2008 elections. However, the chance of their doing that is slim to none, since they have been dragging their feet on this issue and being apologists for Diebold since day 1. I should point out that the board itself has been neutral to helpful towards a paper trail. The problem has been the staff, headed by Chief Administator Linda Lamone. One of the new members of the board is Chuck Thomann, a Republican from Anne Arundel county. His wife, Joyce, has been a stalwart in the fight for a voter-verified paper ballot, and I know that Chuck is of a similar mind. Linda Lamone and the SBE staff will be facing a very different environment shortly.
Time to celebrate a little bit and start getting ready for next year, when we want to enact an audit requirement and try to push for a 2008 implementation.
One of the goodies that got in the MacWorld speaker gift bag is the Griffin iTrip. It is a little FM transmitter that clips into the dock slot of an iPod and lets you send your music to an FM receiver. I brought along to Omaha, NE (which is where I'm writing this), and I've been using it in the car where it's been a great convenience. It can tune from 87.7 MHz to 107.9 MHz using a rocker switch on the side and has a small LCD display that lights up for a short time so that you can read it at night. The range of frequencies is very important, since most major cities have a *lot* of radio stations. I had an old FM transmitter that had a choice of four stations: 88.1, 88.3, 88.5, and 88.7. In Washington, DC and San Francisco, at least, the thing was unusable since there were regular radio stations that could easily overpower the little thing (2 x AAA batteries) on or close to all of those frequencies.
Griffin used to make an older iTrip that would plug into the top of a non-dock connector iPod. You had to adjust the transmitter frequency by playing a special song, which always seemed a bit awkward to me. The new UI with a rocker switch and a lighted LCD display makes the iTrip much more user friendly.
Comparing the iTrip to the DLO TransPod that I use in my car at home, the iTrip does not have the same amount of power to put out a signal as strong as the TransPod's. As a result, I found that the iTrip is badly affected by interference from things like high-tension electrical lines. Despite that, when traveling the small size and light weight of the iTrip makes it much more attractive than the TransPod.
--Paul
A year ago on March 13, I left Apple and started ps Enable, Inc. Thanks to everyone who's helped me along the way. :-D
If you like this newsletter, please forward it to any colleagues who might be interested. They can sign up for their own copies at: <http://lists.ps-enable.com/mailman/listinfo/newsletter>.
Now that we've finished taking care to move our clocks forward three weeks early, we should also beware of systems that spring forward again on the old date. I had to move the clock for my old VCR forward manually, because the automatic DST function can't be updated. In another week or so it will spring ahead another hour, and I will need to move it back an hour when that happens. There may be any number of embedded systems like this in your organization that you had to "spring forward" manually; only now you're going to have to "spring them back" manually again.
Oh, and don't forget these same systems come October and November.
Q: What should you do with the personal firewall on Mac OS X?
A: Turn it off and leave it off.
Say WHAT?!?!
The personal firewall isn't actually protecting you against anything, since it's linked to the various sharing services. Anyway, firewalling at the endpoints (the client or the server) is not very useful — proper firewalling happens at the router.
First, let's look at how the personal firewall works in detail, then let's look at the consequences.
Since the Sharing prefs pane services are integrated with the firewall, what happens in the four possible states?
Notice anything? The state of the port depends only on the state of the service, not the state of the firewall. Thus, the firewall has NO effect on the state of the ports. The firewall does have a marginal effect in that it may slow down an attacker's port scan if you turn on stealth mode, but in practical terms that has little effect. Most scans are done by automated tools that don't really care how long it takes.
Now, what are the consequences? In a low-threat environment, by turning on the firewall you interfere with services like Bonjour-based iTunes and iPhoto sharing, SubEthaEdit, etc. In a high-threat environment, what the heck are you doing with those services running, anyway?
The personal firewall is a feel-good, marketing-driven measure that can be safely turned off on Mac OS X, which ships with all TCP ports closed by default (although UDP 5353 is open for Bonjour). On Windows you need a personal firewall on every single machine, since there is no way to turn off the System or RPC services, and NetBIOS is generally on. Thus, TCP ports 135, 139 and 445 and UDP ports 137, 138, and 139 are always open unless they are blocked by a firewall.
I have long suggested (and yes, it is filed in Radar) that there should be an option to have the firewall restrict connections to those coming from just the local subnet, with an option to allow connections from anywhere. This would allow people to share files with someone locally without opening themselves up to the full Internet. Configuring the firewall this way would have a significant effect in slowing the spread of a zero-day exploit since the malware would face difficulties propagating itself beyond the local subnet.
I ran across some pretty funny IT stories on ComputerWorld's website, in the Sharkbait section. Read a few if you need a short break.
<http://sharkbait.computerworld.com/>
--Paul
]]>Hey, I got quoted in Network World magazine. :-)
http://www.networkworld.com/news/2007/022707-mac-os-going-corporate.html
The title of the article is "Mac OS being infused with the tools of the corporate IT trade, but can it catch on?" The gist of the article is that the Mac is ready, but a lot of IT shops haven't properly evaluated it yet. I got the last tagline as well, "'I guess I still don’t see Mac having crossed the awareness gap,' says ps Enable’s Suh. 'It has started to seep into IT consciousness, but there is still a lot of prejudice out there, with some saying Mac is not ready for prime time. Until that awareness gap is closed, then everything else is secondary.'”
canard
1 an unfounded rumor or story : the old canard that LA is a cultural wasteland.
...
ORIGIN mid 19th cent.: from French, literally ‘duck,’ also ‘hoax,’ from Old French caner ‘to quack.’
Now that the Mac is being seriously considered by enterprise customers, the old single-source canard has been raised by a few "analysts" (most of whom as far as I can tell have never analyzed anything, instead just spewing the words of others). It runs something like this: "Since the Mac is produced only by Apple, if you don't like Apple or Apple treats you badly or you don't like the price, you can't go somewhere else for your systems. On the Windows platform, you can go to HP or Dell or IBM and get compatible equipment if your current vendor treats you badly."
Bull. What a load of. Complete nonsense. Sewage best dealt with by flushing down the toilet.
Why? There are two parts that need to be addressed: the part that is common across the various vendors and the part that is specific to each vendor.
First, the part that is common to each vendor — Windows. If there is some part of Windows that you don't like, you have two choices. One is to buy into an open source solution such as Linux or FreeBSD, which has its own costs. The other is to switch to the Mac. If Windows is a problem then switching from IBM to Dell is not going to solve anything. Not technical issues and not license pricing issues either. Any license pricing that you can get from one you can get from the other, since it is all dictated by Microsoft anyway.
Second, the part that is specific to each vendor — the hardware and the hardware support. The single source canard has a hidden assumption — that you can replace all of a disliked vendor's hardware at once. Not going to happen. Never. Not at the enterprise scale, anyway. Different chipsets have different driver requirements. The lights-out management systems are just a little bit different between vendors, and between different models from the same vendor. Stuff will get stomped on or stop working in the face of system updates or service packs or security patches. Once that happens you're going to have to fix up your deployment images and in-place systems. To do this, you will need to continue to deal with the old company's support. Only now, since you're no longer buying any new hardware from them, you're at the back of the line as far as their account reps are concerned. Lotsa luck, chief.
So, any time that someone raises the, "but if I buy from Apple I'm stuck with a single source" argument, ask them what considerations exist when they want to switch to a different vendor with non-Apple equipment.
I've updated my website so that you can subscribe to this newsletter from the website. I put a link on the front page and also at the top of the newsletter page. If you have friends or colleagues who want to sign up as well, please have them go to:
http://lists.ps-enable.com/mailman/listinfo/newsletter
Again, please let me know if you like the articles or have a topic that you would like me to cover.
You've heard of Snakes on a Plane, right? Well how about Macs on a Train? I took Amtrak up to New York City a couple of weeks ago, and on the way back I noticed that every single open laptop in my car (which was about 3/4 full) was a Mac! Even in the other cars, there were at least one or two Macs among the Windows laptops that people were using. And, it wasn't just students or leisure travelers -- the people using the Macs were dressed in business suits, not jeans.
http://blogs.zdnet.com/security/?p=109
Be afraid. Be very afraid. This is a really neat trick to defeat PCi- or FireWire-based RAM snapshot utilities by hacking the RAM controller on the motherboard. It just goes to show that you absolutely cannot check the security on a computer system while it is running. My hat is off to Ms. Rutkowska for this very excellent hack. It's worth going through her presentation slides from the link at the bottom of the article.
--Paul
http://projects.info-pull.com/moab/
To jump ahead to the punch line, only one bug is problematic, and even that one requires that the user take a positive action. It can't just happen to an otherwise idle machine, or be triggered just by looking at an e-mail or web page. Even that last one can be patched by a sysadmin so that it can be neutralized even before Apple releases an official patch.
So, let's look at what constitute worrisome bugs, i.e. ones that would give potential root-level access, in order of increasing severity:
With a few very rare exceptions, these are the hardest for an attacker to exploit since there is no guarantee that any particular machine will have the application installed. Most of the time a user can easily switch to an alternative application with little or no loss of functionality.
These are things that install kernel extensions and root-level daemons. Easier to exploit since they work at a lower level than user applications, but again many if not most users will not have these installed and most users can switch away to a different extension or daemon.
These are vulnerabilities that require an admin user who is logged in to the Mac to take some positive action like clicking on a link or running an application. Running as a standard user makes these a non-issue.
These are vulnerabilities that require that an admin user be logged in, but not take deliberate action to trigger the bug. An example would be a bug in WebKit where simply viewing an HTML-formatted e-mail triggers the vulnerability. Many Outlook worms on Windows spread this way.
Like category 3, but running as a standard user does not protect against them.
Like category 4, but running as a standard user does not protect against them.
These are more dangerous, in that the machine only has to be on with the sharing protocol turned on. No one has to be logged in. However, the network protocols associated with this category of vulnerabilities are turned off by default.
Same as category 7, but the network protocols are on by default.
Bug 21 - System Preferences writeconfig Local Privilege Escalation Vulnerability - The preference pane's setuid helper, writeconfig, makes use of a shell script which lacks of PATH sanitization, allowing users to execute arbitrary binaries under root privileges.
This one is a case of really bad programming practice by Apple. Anything executing as root should not run a shell script as a sub-process in the first place.
Bugs 12, 13, 25, 29, 30 - These are denial of service bugs that don't lead to code execution. While annoying and potentially worrisome as a part of a more sophisticated attack, none of them are by themselves serious security threats.
Bug 31 - This one has not been released, so it's hard to say what it's worth. It is presented as a kernel vulnerability, potentially the most severe category of threat. In most cases the courteous thing to do is to give the vendor a chance to release a patch for the bug before disclosing it. On the other hand, the MoAB people have not been shy about disclosing other potentially serious bugs, so why should they delay on this one?
I would say that Apple came off pretty well in this month of bugs. Seven out of 30 are not even Apple's problem, leaving only 23. Five more are denial of service and not code execution, leaving only 18. Of the 18, none can be exploited without some sort of positive user action — opening a file, clicking a link, or turning on a service. Running as a standard user eliminates 14 of the bugs, leaving only four, or even two if you don't have the vulnerable services turned on.
Does this mean that you can ignore Mac security? Of course not. However, it shows that a Mac faces a relatively low security threat level. First, if you've followed my advice you are running as standard user and have all unnecessary services turned off. This means that you are only open to three of the bugs. Second, since the Mac has so many fewer vulnerabilities, the *propagation rate* of a piece of malware is vastly slowed, giving sysadmins and Apple time to put up defenses.
Here is one case where a biological analogy is actually useful — it's the difference between the spread of a disease in a population that is partially vaccinated vs. one that is unvaccinated. Even though only some of the population is immune, that is enough to slow the spread of the disease so that public health authorities can get ahead of the curve and stop the epidemic easily.
FYI, Apple has patched bug #1 in Security Update 2007-001 and #'s 9, 20, 22, and 29 in Security Update 2007-002, leaving only one (#21) that is truly troublesome. If you follow the procedure in http://projects.info-pull.com/moab/MOAB-21-01-2007.html then you can neutralize this last bug.
--Paul
I sent part of this week's newsletter out last week, so this one is a little bit light.
One of the more annoying things in setting up Mac OS X is the QuickTime movie that plays when the Setup Assistant runs. The first time, it's kinda neat, but by the tenth time it's getting old and by the twentieth time you're thinking, "enough, already!" You can't do anything with the default install DVD, but if you are building a custom install image then you can cut these out or replace them by changing two files on your image:
/System/Library/CoreServices/Setup Assistant.app/Contents/Resources/TransitionSection.bundle/Contents/Resources/intro.mov
/System/Library/CoreServices/Setup Assistant.app/Contents/Resources/TransitionSection.bundle/Contents/Resources/intro-sound.mp3
The first is the movie that plays, the second is the sound track. I haven't tried deleting them entirely, but it's easy enough to cut them down to a second or so using QuickTime Player Pro. Alternatively, you can replace them with a movie and sound that is customized for your organization.
I was investigating a VPN problem for another consultant, and thought that some of the information I used as a part of the investigation might be of interest to folks. Mac OS X Server has two VPN protocols, PPTP (Point-to-Point Tunneling Protocol) and L2TP (Layer 2 Tunneling Protocol, technically, L2TP over IPSec).
PPTP uses port 1723 TCP and the GRE protocol as well. GRE is IP protocol 47 — this is at a network layer similar to TCP or UDP. By way of comparison, TCP is IP protocol 6 and UDP is IP protocol 17. See http://www.iana.org/assignments/protocol-numbers for a list of all of the various protocols. The router must be set to pass both TCP port 1723 and GRE to the VPN server, or the VPN will fail.
L2TP uses ports 500, 1701, and 4500 UDP, and the ESP protocol (IP protocol 50). 4500 is not strictly necessary as it is only used if the VPN traverses a NAT layer, but it doesn't hurt anything to turn it on at the router. Again, the router must be set to pass both the UDP ports *and* the ESP protocol to the server.
I just finished shoveling the sidewalk and driveway in front of our house. We got about three inches of snow plus freezing rain, which made for very heavy, wet, hard-to-shovel stuff. We didn't lose power this time, but I think this is a good reminder for all of us to think through what is acceptable in terms of unplanned outages for our organizations. What do the various levels of reliability translate to?
99% uptime = 3 days 16 hours unplanned downtime per year
99.9% uptime = 8 hours 45 minutes unplanned downtime per year
99.99% uptime = 53 minutes unplanned downtime per year
99.999% uptime = 5 minutes unplanned downtime per year
Each time you add a 9, figure on increasing your costs by an order of magnitude. How critical are computers to your operations? What systems need the full five nines treatment and what systems can get by with lesser uptime needs? Another way to look at it was written about by the software company FWB back in the early nineties. (Some of you may remember them for their disk and backup utilities, which were excellent for their time.) They called it the rule of twos, with respect to downtime:
2 seconds - Full clustered environment with automatic failover
2 minutes - Spare equipment ready to go - just turn it on
2 hours - Spare equipment is set up but not plugged in - take it out of the closet, plug it in, turn it on
2 days - Spare equipment is on-site but not set up - take it out of the box, set it up, plug it in, turn it on
2 weeks - No spares on-site, need to order equipment and wait for it to arrive
Here, decreasing the recovery time increases costs by an order of magnitude at each step.
A monkey wrench in all such calculations are systems that change in priority depending on the time of day or time of year. A computer in a classroom used for a games and drills may be a 2 week machine most of the time, but what if you need it for No Child Left Behind testing this week? Is your Point-of-Sale computer system a 2 hour system most of the time, but a 2 minute system the day after Thanksgiving? Just some food for thought.
--Paul
