Re: Five Architectural Flaws in Windows Solved In Mac OS X

On 2005-10-15 22:31:21 -0400, ZnU <znu@xxxxxxxxxxxx> said:

In article <2005101514091016807%danieljohnson@vzavenuenet>,
 Daniel Johnson <danieljohnson@xxxxxxxxxxxx> wrote:


1) Interactive Services

It is possible to construct a service that interacts with the user and is highly privileged in Windows. This is unsafe, since UI code is complex and very difficult to harden sufficiently.

But it is still an improvement over Unix, wherein *any executable* can be highly privileged and interact with the user. Just flip the setuid bit and set the owner to root, and Bob's yer uncle.

At least the problem is restricted to services in Windows. This way it is harder to implement a program with this hole.

GUI apps almost never actually run as root, though. Instead, they just use Authorization Services (see below) to escalate privileges for specific operations.

Sure. But then Windows services almost never display a UI. If they do it is a bad security practice, just as building a GUI program that is set-uid-root. Neither is common, but the later is easier to do (and can, in fact, be done by the end user!)

[snip] 
4) Single Sign On

Windows takes the user's password at login, and he can then do whatever he is allowed to do without further authorization. Since Windows uses a Secure Attention Key, it is not possible to leech passwords with a fake password dialog. It is never possible to log in as 'local system', but since all necessary administration can be done with access rights short of that, this isn't a problem.

Mac OS X, on the other hand, is stuck with coarse-grained Unix security. Sometimes you actually need 'root', for which all security checks are disabled. Apple prompts you for the admin password whenever they need this, which is better than just running as root all the time. But they wind up prompting for this password very, very often.

With ACLs in Tiger, OS X supports file system permissions as fine-grained as you want, and for processes, "Authorization Services lets you control access to specific features or data within an application." 

Sure. Apple is well aware of these problems and is trying to address them.

It may be that someday, Mac OS X will not require any use of 'root' whatever.

Still, today what authentication services is mostly for is... obtaining root access.

(http://developer.apple.com/documentation/Security/Conceptual/Security_Ov
erview/index.html#//apple_ref/doc/uid/TP30000976%23)

In a lot of the cases where OS X prompts for a password (when the user is logged in as an admin), it isn't because it's necessary to escalate privileges, because actual root privileges are needed. It's simply an extra security mechanism to make sure certain potentially harmful actions aren't performed by someone who just sits down at a machine that happens to be logged into an administrator account.

I did not realize this. But it seems to me this just make the leeching issue worse.

Maybe you can argue Apple should use a two-tired system, with the admin account's password just used for these sorts of checks, and a separate password used for actual superuser access, but that's not a basic architectural issue. And there's always a tradeoff with that kind of thing; make security too complicated, and fewer people understand it, which can actually make everything less secure.

I don't think two passwords is workable, just as you say. But demanding the password for every little setting change trains users to enter the supposedly secret password far too easily. And there's no way to tell if a given installer that wants it is genuinely authorizing itself, or is leeching the password.

A compromise approach might be to incorporate a secure attention key in the Authorization Services; maybe it prompts you to hit option-command-control-shift-capslock-tab-escape-ejectbutton, and only then accepts the password. Making the UI for this palatable is a little tricky but should be possible. This would replace the little 'lock' icons, so instead of clicking the lock you hit the secure attention key, maybe.

I *devoutly* hope Vista will do this; I read it is copying Mac OS X's approach here, but every malware author on the planet will steal passwords this way if they don't prevent leeching in some way. Windows is everyone's favorite malware target, and a hole this big will be exploited massively.

Since Mac OS X has no secure attention key, fake but convincing password dialogs are easily constructed and password leeching is simplicity itself.

99% of Windows users, of course, wouldn't find a password prompt that didn't ask for the secure attention key suspicious in the least. In fact, XP doesn't even require it for login by default unless you're on a domain. 

Yes, but XP doesn't prompt for passwords when installing Kazaa or whatever. :D

It is possible to write an XP program that apes the new, less secure, login screen, and some users might run that program, think they had been logged out, and try to log back in. But many would realize that something bad had happened, at least.

Mac OS X normally prompts for the password for all sorts of reasons. It would be easy to write a program that prompts a the normal, expected time (say, during a program install) but steals the password. The user would have no way to know he'd be had, provided the naughty program would then install itself normally.


.

Quantcast