Re: Five Architectural Flaws in Windows Solved In Mac OS X
- From: GreyCloud <mist@xxxxxxxxxxx>
- Date: Sun, 16 Oct 2005 12:40:04 -0600
Daniel Johnson wrote:
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.
It is?? Then why all the viruses then??
Windows is, I think, an improvement in this regard.
Hardly.
[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.
Such as?
But then Mac OS X does not use HPFS.
Yes it does. Go take another look.
It uses "Mac OS Extended", which has some of the nice features NTFS has (like Journaling) but not others (like transparent encryption and compression).
Again, your ignorance is showing. Kerberos is part of the o/s. File Vault is the name.
Apple's filesystem is a lot more competitive than HPFS would be today, though!
HPFS is the default for Apple. I just got thru upgrading the wifes Mac to Tiger and hpfs is the default.
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.
The admin isn't root tho. A big difference.
The setup also requests you to go thru the hoops of creating a user account that isn't admin or root.
It'll never ask you to enable root... it is shut off by default.
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.
It is also 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.
Doesn't matter in this case. OS X works fine and doesn't get the viruses or trojans that windows suffers from.
Out in the wild exploits happen to windows. In two years of OS X use I've yet to see any exploits happen.
That tells you alot about the o/s design.
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.
The only improvement is in Apples means of making a UNIX system user friendly thru a GUI.
If you'd only buy a copy of Solaris 10 x86 for $45 from Sun (and check the Hardware Compatibility List for your components) you'll see where UNIX has gone these days. It hasn't sat on its laurels in one fixed state like most windows users seem to think it has.
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.
Doesn't matter. Its the security that counts and it sure works very well.
[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.
Guffaw!! Now that we know... you can't get one into OS X. This is just wishful thinking on your part.
This is why OS X doesn't get viruses. So the password leeching won't work on OS X.
They're called rootkits, but I haven't heard of any done to OS X. One has to physically gain entry for this to happen.
Better know your workers then.
Physical security is the last step to real security. You'll never see any level A secure systems without a barbed wire fence and guards.
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.
And it is because of the operating system, not the processors this time. Face it... windows doesn't scale very well.
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.
True. That is why these UNIX companies do not sit on their laurels.
Did you know that Windows doesn't implement the POSIX standards for threads, while all the others do??
Did you know that windows threads do not implement any thread conditionals?
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.
You thougt wrong then. Like I said, UNIX vendors have not been sitting idly while M$ forges ahead.
They do compete. And the Solaris o/s has something that the other o/ses do not have... predictive hardware failure logs, self-healing system due to other failures, Dtrace for dynamically tracing a multi-system failure, etc. Their hardware can do hot swapping of hard drives. The list goes on.
You don't need a pretty gui to do things under UNIX, tho it makes it easier to do things. Did you know that Suns Looking Glass project is going into M$ Vista as 3D windows?? So far it may happen. I'm not sure that this will be useful tho.
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.
Doesnt' need to.
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.
But M$ is saying their own languages are unsafe. I find this amusing.
Yet Sun uses C, C++, and Fortran 95 for their work and do not use .NET methods and don't need them.
All M$ has to do is rewrite the o/s from scratch with security in mind... better yet, make a buy offer to HP for OpenVMS.
At least they'd have a very secure o/s.
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
Who? From Price fisher??
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.
All M$ has done is to jack up the price for developers. And they've also complicated the field.
That's why M$ sales are staying relatively flat. I'd rather have an elegant development approach, than a convoluted one.
That is *another* reason why forking is inferior to safe languages.
No, it is the bad design of an o/s that forces one to use other methods. Using a good o/s makes life very easy.
Only M$ has made email dangerous.
Just keep telling yourself that. :D
It's a known fact... I LOVE YOU. (the name of the email virus) .
- References:
- Re: Five Architectural Flaws in Windows Solved In Mac OS X
- From: GreyCloud
- Re: Five Architectural Flaws in Windows Solved In Mac OS X
- From: Daniel Johnson
- Re: Five Architectural Flaws in Windows Solved In Mac OS X
- Prev by Date: Re: Five Architectural Flaws in Windows Solved In Mac OS X
- Next by Date: Re: Mac Mini hard as *** to use.
- Previous by thread: Re: Five Architectural Flaws in Windows Solved In Mac OS X
- Next by thread: Re: Five Architectural Flaws in Windows Solved In Mac OS X
- Index(es):