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

On 2005-10-16 01:13:09 -0400, GreyCloud <mist@xxxxxxxxxxx> said:

Daniel Johnson wrote: 
On 2005-10-12 05:58:18 -0400, Alan Baker <alangbaker@xxxxxxxxx> said:

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.


And only done manually, and not under program control.
Windows is NOT an improvement over UNIX.

It is certainly possible for a program to set this bit; an installer might well do so. The usual security precautions prevent unauthorized people (or programs) from doing this, but that's true on Windows also.

Windows is, I think, an improvement in this regard.

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

2) Windows filesystem is very much like Mac OS X

It is not clear to me how this is a flaw. 

Guffaw!!  You've got a pant load on this one.
NTFS isn't HPFS.

The original article referred to the directory structure actually, not the low- level implementation.

But never mind. NTFS is indeed not HPFS; it is much nicer. It has many features that HPFS lacked.

But then Mac OS X does not use HPFS. It uses "Mac OS Extended", which has some of the nice features NTFS has (like Journaling) but not others (like transparent encryption and compression). Apple's filesystem is a lot more competitive than HPFS would be today, though!

3) "Plain User" accounts are not very practical

This is a genuine problem; the application support to run as a plain user is not adequate, and most users just run as an administrator. That is the default anyway.

Of course, Mac OS X is the same way. It's a tough problem.

It isn't a tough problem for OS X. Just for XP.

OS X also gives you an admin account by default, and many programs can only install with admin access, just as on Windows.

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.

BS! Ever heard of Kerberos??

That is an authentication system, used by both Unix and Windows these days. It's beside the point.

The issue is authorization: giving a user the rights to do the proper things, but not 'bad' things. Windows is still not fine-grained enough, but Mac OS X is very much coarser.

You're pulling up old UNIX stuff, when things have changed many years ago.
Yer pulling old stories.

I am talking about Mac OS X as it is today, and that's a real improvement over traditional Unix- but it is still not the equal of Windows in this area.

There is, for instance, a real authorization service in Mac OS X. But it can only authorize you to run programs as root. That's not "fine grained"; but it is a foundation on which something finer grained could be built.

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

Yeah, sure it is. Now that your ignorance is showing greatly, how do you proprose to leech a password off of OS X Keychain??

"Leeching" means you have a malware program that impersonates a legitimate password dialog, but steals the passwords that it is given. On Mac OS X this will get your the root password typically, and after that you can do whatever you want. You could install a compromised version of the keychain software that stole passwords in the keychain whenever they were decrypted, for instance.

However, that is a lot harder that just leeching the root password on Mac OS X, and it seems a little superfluous too.

5) Windows uses Heavyweight Processes

It does. Windows uses the OS/2 process-and-thread approach. Heavyweight processes are a non-issue if you spawn threads instead. This is a more advanced design that Unixes have been trying to duplicate by adding thread support. But, as I will explain, thread support is not enough.

Guffaw!!! Still spewing your FUD. You know no more about the o/s ability to scale processes than the dog knows about Sundays.
It'll take 8 Xeon boxes to do the work of one good Sparc box.

Err, you can run Unix on a Xeon and it will spawn processes very fast too. It can use the same the same copy-on-write technology that Solaris does.

While no-one implements a fork() anymore but for compatibility with Unix, Unixes everywhere have been implementing better and better threading services. It's clearly the right way to do a computation sever.

The advantage of forking processes instead of spawning threads is that you get memory protection, but this is important only for services written in unsafe languages like C. Microsoft encourages developers to use safe languages like VB or, more recently, C#. And indeed these are widely used and have been for many years.

The Unix world is still lagging, perhaps because Sun has not been open enough with Java to get it widely adopted by the influential open-source community. Or maybe because it is just too slow. Anyway today C, C++ and Objective-C are used on Unix, and all are unsafe in varying degrees.

That's because their Solaris design happens to be more advanced that Windows o/s design... by miles.

Solaris, I thought, was a fairly conventional modern Unix. It is *Java* that is advanced.

And Java, you will note, offers built-in threading support in a really first class way, but no easy way to spawn processes at all.

The issue with safe languages is a poor marketing hype by M$ to turn the publics attention away from their poor operating system design.

The advantages are clear and rather overwhelming. Thus the important of Java, and you can hardly blame that on Microsoft.

That is where the real problems lay.

One of the great ironies is the high-level *design* of Windows is really first rate; they copied it from the best. :D

But the devil is in the details; the best design in the world won't help if your kernel has buffer overflow bugs or something.

"Safe" languages offer a solution to this- they eliminate this class of exploit (and several others). Forking processs helps stability but does *nothing* for security- if a child process gets hacked it won't crash, after all.

That is *another* reason why forking is inferior to safe languages.

Only M$ has made email dangerous. 

Just keep telling yourself that. :D

.

Relevant Pages

  • Re: Apple Notebook
    ... die gerne mit Unix Befehlen arbeiten und sich freuen, ... mich stören weder UNIX-Befehle (neben Mac OS X benutze ich selbst z.B. u.A. auch HP-UX, UNIX ist für mich also kein Fremder) noch Leute, die mit ihrem Mac zufrieden sind. ... Mich stört auch nicht, dass Windows mit Ausnahme von Windows Server 2003 R2 keine UNIX-Befehle kann, genauer gesagt geht mir das ziemlich am Allerwertesten vorbei, einfach weil der Bedarf nicht vorhanden ist. ... Und das nicht nur deswegen, weil Apple schlichtweg keinen professionellen Support anbietet, sondern weil die Masse der wichtigen Anwendungen eben nicht unter Mac OS X läuft, sondern unter Windows oder allenfalls noch Linux. ...
    (de.comp.sys.notebooks)
  • Re: Five Architectural Flaws in Windows Solved In Mac OS X
    ... But it is still an improvement over Unix, wherein *any executable* can be highly privileged and interact with the user. ... The usual security precautions prevent unauthorized people from doing this, but that's true on Windows also. ... NTFS is indeed not HPFS; ... But then Mac OS X does not use HPFS. ...
    (comp.sys.mac.advocacy)
  • Re: Looking at Macs from a PC users perspective
    ... > I spend a lot more time keeping my PC clean than my Mac. ... >> Is Unix integration all it is cracked up to be? ... >> versus just running a seperate Unix/Linux partition on a PC? ... and windows as well, in my book. ...
    (comp.sys.mac.advocacy)
  • Re: Cult Of Mac Members List
    ... As a user fo Apple computers myself, ... Actually I find most Mac users in here to be informed. ... found in OS X than Windows XP. ... So are Linux and Unix users. ...
    (comp.sys.mac.advocacy)
  • Re: Five Architectural Flaws in Windows Solved In Mac OS X
    ... "What was intended to be a short aside about Mac OS X's strengths turned into an entire series on Windows NT/2000/xp flaws! ... But it is still an improvement over Unix, wherein *any executable* can be highly privileged and interact with the user. ... This is a more advanced design that Unixes have been trying to duplicate by adding thread support. ... Forking processes in the same situation leaves you with a dilemma: if you copy eagerly, it is very slow and burns a whole lot of memory. ...
    (comp.sys.mac.advocacy)
Loading