Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Search \| Test`

Home » Learning Curve

Outsourcing Security

Alphasubzero949 tells an interesting tale.

Now here's something interesting. I had a chance to look at a colleague's iBook issued by her IT department. It was running 10.2.0 and missing a lot of software updates, despite her having admin privileges. I gave her a copy of Firefox 1.5 (despite the sys requirements calling for Panther) and added a few goodies including AppleJack in case something borked. This person knows absolutely ZILCH about computers, security, or the like except to find the Firefox and Safari icons. The admins installed Norton this and that for God knows what reason. Unfortunately I didn't want to get my colleague into too much trouble, so I let it be. I'm pretty sure they won't find Privoxy once the proxy settings get switched back. (I showed how to uncheck the boxes.) /Library/StartupItems was indeed present with a bunch of Norton shit. Care to take a guess at the permissions? Hold on to your seats, folks... admin:admin 0775. I kid you not.

The basic dilemma when you have an easy attack vector (or weakness) is that every software vendor on the planet has to play by the same rules. Veritable Norton obviously didn't understand the name of the game. Even if StartupItems had been locked down correctly, their installers, equipped with an admin password, would have botched things again and left the machine wide open.

Any hacker out there not totally bored with life but aware of this flaw in the Norton and perhaps other installers could have probed for the weakness and owned a lot of computers. For all anyone knows, this has happened in any number of individual 'inside job' cases.

There's no easy way out of this. The error was in allowing anyone to write to a directory and inject code which would run not only as root but as root in single user mode on next startup. Simply refusing to recognise the directory on system startup only relegates matters to the other one in /System which requires the same admin password and which the installer can still botch.

Checking permissions on reboot seems to be the safe and careful thing to do. There might never be a time when 'startup items' cannot be modified. It therefore rests on each vendor - each installer - to use the privileges granted by the admin password correctly.

It's also fuel to the argument that low-end corporate users not be given admin accounts or be allowed to install software on their own.

You can always lock the StartupItems directory down on your own, but any installer can botch it again. You could lock both InputManagers and StartupItems with the system immutable flag, but then you'd have a time modifying things. You must always be critical of 'installers' and know why they're needed and what they're going to do.

And you must always check the quality of their work afterwards. Online or especially at the office, carelessness can be catastrophic.

Outsourcing security doesn't imply outsourcing responsibility. Responsibility is still your own.

Postscript: Level 4 Security

Locking both InputManagers and StartupItems with immutables.

mkdir /Library/InputManagers /Library/StartupItems
chmod 0700 /Library/InputManagers /Library/StartupItems
sudo chown 0:0 /Library/InputManagers /Library/StartupItems
sudo chflags 1600017 /Library/InputManagers /Library/StartupItems