The key thing to understand here is that the machines aren't checking in to Microsoft, they're checking in to your companies servers. It isn't Microsoft locking you out, it's your corporate IT team. They can use this to ensure that the business is only paying for the licences it has in use. They can keep track of systems that have fallen into disuse or that Bob's manager has said he can take home because "nobody will mind". And they know that guy they had temping in Operations over summer didn't wander off with the cd key and start selling dodgy copies on Ebay, forcing them to go through the expensive and problematic task of re-keying machines.
Where they deem it inappropriate, they can choose to use MAK activation instead. And they can still keep track of how many and which machines were activated.
Yes. Vista offers full volume encryption as part of its secure startup using a TPM module (if available). Old "forgotten password" tricks will not work on a fully encrypted drive.
"if you've ever seen the design of NT, you'll know that the POSIX subsystem is pretty much separated from the rest of the system"
If you've ever seen the design of NT, you'll know that all the subsystems (POSIX, OS/2 and yes, Win32) are pretty much separated from the rest of the system.
Your point is?
"If the hardware were really the culprit, wouldn't linux also be affected and crash just like Windows does?"
Does your Linux install use the Windows device drivers? No? Doesn't prove a thing then.
You installed a buggy device driver somewhere along the way. Simple as that.
I run a network of aseveral hundred Windows boxes (a mix of 2k and XP) and I see maybe 2 or 3 bugchecks a year. Every one is failing hardware or device driver related.
They just don't happen daily unless you really have no clue.
"Anyone can secure a box running next to no services."
Except they actually enabled more services than a default S2003 box. And actually configured IIS to be less secure than the default.
IIS 6.0 would win by a country mile. There has only been one fix for it since its release and that was for WebDAV which isn't installed by default.
Apache, by contrast, has had a a lot of patches in the last year.
I haven't seen the.NET stuff, so I shouldn't really comment, but 'incredibly fine grained' has me worried.
.NET defines Zones which attempt to do "the right thing" by default (customizable for power users obviously) depending upon where an application came from (on current Windows platforms this is limited to where it was launched from) so an application downloaded from an untrusted web site runs in a Java-like sandbox wheras an application installed from CD runs with the full privileges of the user.
Once managed code is the norm, rather than native x86 as we have at the moment, I expect you'll see something closer to your vision. Applying those sort of restrictions to existing code without breaking the user experience drastically is probably a bit much to ask.
I looked at AIM, and it seems to be a similar mechanism. I'm not sure that it goes far enough
AIM is intended as a bridging technology. The goal is to allow old Windows applications to function in a locked down environment without all the faffing around with security permissions usually involved. That way user accounts can default to being Limited Users without problems, putting Windows on a par with Unix as far as "secure by default" goes.
They can still trash the users personal filestore/registry but can't actually damage OS files or other applications (remember there are a lot of legacy Windows applications which store configuration files or dlls straight in the Windows folder!)
Again.NET's security model allows sandboxed applications to write settings/files without actually knowing where they are and without necesarily being given arbitrary filesystem access (it's called Isolated Storage)
The move to truly securing personal information under Windows is, of course, NGSCB (aka Palladium) but it's getting people to accept such a draconian sounding security system which presents the largest problem there.
It would be better if the OS provided customizable permissions (grant networking access seperately from hard drive access, for example), but I've yet to see a good security setting setup or user interface to allow that sort of thing....NET does this for Managed Code on Windows and with an incredibly fine grained (and extensible) set of permissions.
For instance, the OS could intercept all calls to update files outside of a folder called "buggy-app" on the desktop, and use an overlay file system and copy-on-write to store the changes in a special directory. Only the spoofed program would use the files that it created and modified, and the changes it performed could be reversed by deleting the stuff the OS put in/tmp...
Application Impact Management - coming in Windows Longhorn
Mac OSX comes from a MULTI user heritage, but Windows is STILL basically a SINGLE user PERSONAL computer and most programs assume that the user has full privileges on the machine. On our Windows machines limiting users this way does not work, because many existing programs will not run properly if a user does not have admininstrator rights. For example, many programs want write access to the registry for some reason. Windows developers have to make sure that their programs run correctly in all ways even if a user is limited.
Firstly, poorly written third party applications do not consititute a security flaw in Windows. Secondly, Windows has a much more flexible and granular security system than a Unix based OS like Mac OS X. So if an application does need to write to a registry key that normally only an Administrator could, you can adjust the security on that key without granting full Admin access to the user. A decent Windows system administrator can do this easily - one who can't shouldn't have a job.
That said however, it is difficult for the average home user to do. This is why Windows needs to do more to protect them from badly written software like this. Application Impact Management and the Protected Administrator account in Longhorn will go a long way to redressing the balance and in a far better way than the use of Classic under OS X.
This means they are more likely to be secure--due to the nature of their development.
Absolute rubbish. Just because you read that on your favourite OSS-advocacy site doesn't make it true.
What's more, large chunks of OS X are not open source.
You also need to never open email attachments
FUD
tricking ActiveX to do what it was designed to do, which is provide ways for web site to run small Windows programs inside of IE. It's easier to trick a user into running these, because they have to constantly click 'yes' for every website they hit.
Clearly you are painfully unaware of the security updates present in XPSP2. If I visit a site which wants to install an ActiveX control there is no dialog, it's just refused. If I *want* to install it I have to take at least three additional steps to do so.
Additionally you have the Unix nature of OS X, which means no one runs as 'root'
The Windows Administor account is not the same as root under Unix. root is far more powerful.
Gaining root access to a Mac is easy, you use the same social engineering techniques used on Windows every day.
Send someone a "cool" screensaver or game. The average man in the street will blindy provide the Administrator password (they're used to having to type it in to run new software). Et voila. A Mac Admin can do almost anything, including changing the root password and enabling the root account. root can do anything.
Are you using NTFS or FAT? Do you have the Guest account enabled?
Unlike 9x based operating system you don't set a password on a per-share basis, you set passwords on user accounts and then grant permissions to users.
If you share a folder in XP HOME, your only choice of security is the very lowest. Full write privilages to anyone without a password! What the heck were they thinking?
Wrong.
All file sharing under NT based operating systems (including XP Home) requires you to have a valid user account. Furthermore XP doesn't allow access to network shares to an account with a blank password.
So, to access a shared folder on XP you need both a username and password. The nearest you can get to the, frankly weak, 95 model is to enable the Guest account with a password (as Guest will authenticate against any username provided it isn't a registered user.)
This is more than adequate for most home users. Anyone sufficiently technially minded to be able to manage ACLs manually is, in all likelyhood, going to be using Pro anyway.
Slashdot Mirror
The key thing to understand here is that the machines aren't checking in to Microsoft, they're checking in to your companies servers. It isn't Microsoft locking you out, it's your corporate IT team. They can use this to ensure that the business is only paying for the licences it has in use. They can keep track of systems that have fallen into disuse or that Bob's manager has said he can take home because "nobody will mind". And they know that guy they had temping in Operations over summer didn't wander off with the cd key and start selling dodgy copies on Ebay, forcing them to go through the expensive and problematic task of re-keying machines.
Where they deem it inappropriate, they can choose to use MAK activation instead. And they can still keep track of how many and which machines were activated.
Yes. Vista offers full volume encryption as part of its secure startup using a TPM module (if available). Old "forgotten password" tricks will not work on a fully encrypted drive.
"if you've ever seen the design of NT, you'll know that the POSIX subsystem is pretty much separated from the rest of the system" If you've ever seen the design of NT, you'll know that all the subsystems (POSIX, OS/2 and yes, Win32) are pretty much separated from the rest of the system. Your point is?
"If the hardware were really the culprit, wouldn't linux also be affected and crash just like Windows does?" Does your Linux install use the Windows device drivers? No? Doesn't prove a thing then.
You installed a buggy device driver somewhere along the way. Simple as that.
I run a network of aseveral hundred Windows boxes (a mix of 2k and XP) and I see maybe 2 or 3 bugchecks a year. Every one is failing hardware or device driver related.
They just don't happen daily unless you really have no clue.
"Anyone can secure a box running next to no services." Except they actually enabled more services than a default S2003 box. And actually configured IIS to be less secure than the default.
IIS 6.0 would win by a country mile. There has only been one fix for it since its release and that was for WebDAV which isn't installed by default. Apache, by contrast, has had a a lot of patches in the last year.
I haven't seen the .NET stuff, so I shouldn't really comment, but 'incredibly fine grained' has me worried.
.NET defines Zones which attempt to do "the right thing" by default (customizable for power users obviously) depending upon where an application came from (on current Windows platforms this is limited to where it was launched from) so an application downloaded from an untrusted web site runs in a Java-like sandbox wheras an application installed from CD runs with the full privileges of the user.
.NET's security model allows sandboxed applications to write settings/files without actually knowing where they are and without necesarily being given arbitrary filesystem access (it's called Isolated Storage)
Once managed code is the norm, rather than native x86 as we have at the moment, I expect you'll see something closer to your vision. Applying those sort of restrictions to existing code without breaking the user experience drastically is probably a bit much to ask.
I looked at AIM, and it seems to be a similar mechanism. I'm not sure that it goes far enough
AIM is intended as a bridging technology. The goal is to allow old Windows applications to function in a locked down environment without all the faffing around with security permissions usually involved. That way user accounts can default to being Limited Users without problems, putting Windows on a par with Unix as far as "secure by default" goes.
They can still trash the users personal filestore/registry but can't actually damage OS files or other applications (remember there are a lot of legacy Windows applications which store configuration files or dlls straight in the Windows folder!)
Again
The move to truly securing personal information under Windows is, of course, NGSCB (aka Palladium) but it's getting people to accept such a draconian sounding security system which presents the largest problem there.
It would be better if the OS provided customizable permissions (grant networking access seperately from hard drive access, for example), but I've yet to see a good security setting setup or user interface to allow that sort of thing... .NET does this for Managed Code on Windows and with an incredibly fine grained (and extensible) set of permissions.
For instance, the OS could intercept all calls to update files outside of a folder called "buggy-app" on the desktop, and use an overlay file system and copy-on-write to store the changes in a special directory. Only the spoofed program would use the files that it created and modified, and the changes it performed could be reversed by deleting the stuff the OS put in /tmp...
Application Impact Management - coming in Windows Longhorn
Mac OSX comes from a MULTI user heritage, but Windows is STILL basically a SINGLE user PERSONAL computer and most programs assume that the user has full privileges on the machine. On our Windows machines limiting users this way does not work, because many existing programs will not run properly if a user does not have admininstrator rights. For example, many programs want write access to the registry for some reason. Windows developers have to make sure that their programs run correctly in all ways even if a user is limited.
Firstly, poorly written third party applications do not consititute a security flaw in Windows. Secondly, Windows has a much more flexible and granular security system than a Unix based OS like Mac OS X. So if an application does need to write to a registry key that normally only an Administrator could, you can adjust the security on that key without granting full Admin access to the user. A decent Windows system administrator can do this easily - one who can't shouldn't have a job.
That said however, it is difficult for the average home user to do. This is why Windows needs to do more to protect them from badly written software like this. Application Impact Management and the Protected Administrator account in Longhorn will go a long way to redressing the balance and in a far better way than the use of Classic under OS X.
This means they are more likely to be secure--due to the nature of their development.
Absolute rubbish. Just because you read that on your favourite OSS-advocacy site doesn't make it true.
What's more, large chunks of OS X are not open source.
You also need to never open email attachments
FUD
tricking ActiveX to do what it was designed to do, which is provide ways for web site to run small Windows programs inside of IE. It's easier to trick a user into running these, because they have to constantly click 'yes' for every website they hit.
Clearly you are painfully unaware of the security updates present in XPSP2. If I visit a site which wants to install an ActiveX control there is no dialog, it's just refused. If I *want* to install it I have to take at least three additional steps to do so.
Additionally you have the Unix nature of OS X, which means no one runs as 'root'
The Windows Administor account is not the same as root under Unix. root is far more powerful.
Gaining root access to a Mac is easy, you use the same social engineering techniques used on Windows every day.
Send someone a "cool" screensaver or game. The average man in the street will blindy provide the Administrator password (they're used to having to type it in to run new software). Et voila. A Mac Admin can do almost anything, including changing the root password and enabling the root account. root can do anything.
People are stupid. They do stupid things.
Are you using NTFS or FAT? Do you have the Guest account enabled? Unlike 9x based operating system you don't set a password on a per-share basis, you set passwords on user accounts and then grant permissions to users.
If you share a folder in XP HOME, your only choice of security is the very lowest. Full write privilages to anyone without a password! What the heck were they thinking?
Wrong.
All file sharing under NT based operating systems (including XP Home) requires you to have a valid user account. Furthermore XP doesn't allow access to network shares to an account with a blank password.
So, to access a shared folder on XP you need both a username and password. The nearest you can get to the, frankly weak, 95 model is to enable the Guest account with a password (as Guest will authenticate against any username provided it isn't a registered user.)
This is more than adequate for most home users. Anyone sufficiently technially minded to be able to manage ACLs manually is, in all likelyhood, going to be using Pro anyway.