g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets
  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.


On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »





Book Plug:

Buy it and I get
money. I think.
BSD Mall




 10/6/2003 -  10/8/2003
 9/29/2003 -  10/5/2003
 9/22/2003 -  9/28/2003
 9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
 8/25/2003 -  8/31/2003
 8/18/2003 -  8/24/2003
 8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
 7/28/2003 -   8/3/2003
 7/21/2003 -  7/27/2003
 7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
 6/30/2003 -   7/6/2003
 6/23/2003 -  6/29/2003
 6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
 5/26/2003 -   6/1/2003
 5/19/2003 -  5/25/2003
 5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
 4/28/2003 -   5/4/2003
 4/21/2003 -  4/27/2003
 4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
 3/31/2003 -   4/6/2003
 3/24/2003 -  3/30/2003
 3/17/2003 -  3/23/2003
 3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
 2/24/2003 -   3/2/2003
 2/17/2003 -  2/23/2003
 2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
 1/27/2003 -   2/2/2003
 1/20/2003 -  1/26/2003
 1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
 12/9/2002 - 12/15/2002
 12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
 11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
 10/7/2002 - 10/13/2002
 9/30/2002 -  10/6/2002
 9/23/2002 -  9/29/2002
 9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
 8/26/2002 -   9/1/2002
 8/19/2002 -  8/25/2002
 8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
 7/29/2002 -   8/4/2002
 7/22/2002 -  7/28/2002
 7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
 6/24/2002 -  6/30/2002
 6/17/2002 -  6/23/2002
 6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
 5/27/2002 -   6/2/2002
 5/20/2002 -  5/26/2002
 5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
 4/29/2002 -   5/5/2002
 4/22/2002 -  4/28/2002
 4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
 3/25/2002 -  3/31/2002
 3/18/2002 -  3/24/2002
 3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
 2/25/2002 -   3/3/2002
 2/18/2002 -  2/24/2002
 2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
 1/28/2002 -   2/3/2002
 1/21/2002 -  1/27/2002
 1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001
Thursday, November 14, 2002
21:50 - Virii
http://www.denbeste.nu/cd_log_entries/2002/11/Virusmarketing.shtml

(top) link
Steven Den Beste has a post which claims that the lack of viruses on the Mac is a sociological/economical phenomenon, rather than a technical one.

I'd rather not get into the speculation over things like the vulnerability of OS9 and prior releases to viruses, other than to mention that the biggest risk in a virus lies in its ability to propagate itself, which in Windows manifests as a gleeful romp through Outlook and IE and IIS (after all, I'm sure Klez does a whole lot more damage in simple dental chafing over how many times it appears in people's inboxes, rather than in actual damage to people's systems). The Mac OS, while potentially more fragile in its memory structure, was much less likely to be exposed to worm-style exploits because the Mac lacked badly-written and widely-used vectors like Outlook. But that's a separate issue.

I just wanted to clarify something:

MacOSX is protected against that if properly used, as is WinNT/2K/XP. Of course, if a user routinely runs with an administrator account, they discard this protection. I don't. I have an administrator account on my Win2K systems which I use when need be, such as to do installations, but I routinely run with a "Power User" account, which does not permit me to seriously damage the system by mistake. I do that deliberately. I'm not a fool and I don't generally do things which are harmful, but this represents a level of protection that I choose to use, in part because it protects me from hostile programs which actually do end up fooling me. Unfortunately, a lot of people have gotten in the habit of routinely using an administrator account and by so doing they are throwing away one of the best protections their systems give them, to protect them against the actions of those who write hostile programs, even for OSX.

You can't discard this protection in OS X, though.


The fact is that unless you go under the hood and perform some serious monkey-wrench tweaking, you cannot log in with an administrator or "root" account in OS X. Admin security in OS X is done via the "sudo" model, in which any system-altering action (such as new software installations, modifying file permissions/ownership, or the unlocking of system-wide preferences that you have locked) must be authenticated by a designated admin user (of which there can be more than one) entering his own password. This establishes that the person who is using the current login session is the rightful owner of that account, and has the rights to perform an administrator-level action. (Non-admin users, by the way, can install software and such from within their own login sessions-- by entering an admin user's username and password.) It's on-demand action-level security, not session-level security (which, by the way, is prone to hijacking by malicious local users if the rightful user leaves himself logged in). Each unique action is assumed insecure and prompts for admin authentication. System preferences which alter global settings are unlocked at login time for admin users, but can be locked again at any time. Thus, the "root password" is irrelevant (the root account can't be accessed in the default installation, even from the command line), and for any new and potentially system-altering action, the user is given a challenge to prove he's a trusted admin, and a psychological reminder that the requested action is potentially dangerous (which may in fact be the more important benefit).

I've written our project-management system at work based on this model. Any data can be viewed by anybody; but anytime a user attempts to execute a data-altering command, he is prompted for a login and password. This has the dual effect of authenticating the user and making the user think twice about what he's doing. It's prevented a huge number of user errors that were a matter of daily maintenance to fix in our earlier system, which happily and transparently accepted any data-altering action from any user who had logged-in and authenticated once upon starting the client app.

The fact that so many people choose to run their Windows machines via administrator accounts is a symptom of the "convenience and security are orthogonal goals" axiom; if the system makes it unnecessarily inconvenient to operate in a secure manner (e.g. by running as a standard user and only using the admin account when absolutely necessary, or by using a "Power User" account, which offers limited admin power), then the user will choose to operate in a less secure manner (e.g. using an administrator account for day-to-day computing). Logging in and out of desktop sessions is inconvenient, and, today, something a user rarely wants or needs to do. If admin tasks are not made a part of the standard and convenient workflow (as OS X and best-practices UNIX server platforms do it), then users will make them part of their standard and convenient workflow, regardless of the risk involved.

Whether OS X is or is not inherently more or less porous than Windows is, again, a side issue. The crux of this particular point (granted, only one part of the larger thesis) is, however, based on the assumption that OS X admin security is done on the same asking-for-trouble model that Windows uses-- and that isn't the case.

Back to Top


© Brian Tiemann