with ridiculous defaults. World-writeable \system? come on!
Neither \Windows nor \Windows\System32 are world-writable by default.
And these fuckups are _very_ deep in the system, like their "case-preserving but not case-sensitive" filesystem, "ressource-forks" (or whatever they're called), again in the filesystem; unicode-or-not problems and so on..
Just because you don't like them, doesn't make them bad.
The end result is that a 'sploit which wants to run everywhere probably needs to be built on the target box with a 'configure && make && make install'.
For 99% of malware, the only "exploit" necessary is the one to get the end-user to run something. History has demonstrated this is not particularly difficult.
Firstly, despite the legal disputes surrounding the strategy, Microsoft has deliberately engineered IE into its OS. Windows 95 and NT4 and previous versions had no dependency on IE at all. On an "up-to-date Windows box" it is LITERALLY IMPOSSIBLE to completely "get rid of IE" on your system. You can remove the icon, make Firefox your default browser and so on, but IE remains in place. You cannot remove the IE rendering engine or any other "meat" of IE contained in system DLLs or you break a multitude of applications and important parts of Windows itself. No matter how hard you try to avoid it, you still need IE to do something as basic as keeping your system up-to-date and run your basic applications properly.
This applies to a whole bunch of various shared libraries on basically every contemporary platform. So....what's your point ?
The fundamental concepts behind Microsoft's Windows Update are seriously flawed and without constant vigilance on the part of Microsoft it could be the most serious vector of attack in the history of computer security.
And how is this different from, say, Apple's Software Update, or Redhat's RHN, or kernel.org ?
I'm sorry, the headline of this article putting Windows at par with ANYTHING in terms of security is unconvincing to me.
The biggest cause of security problems in Windows is end users, usually facilitated by poor applications requiring end users to run with higher privileges than they need. As such, such claims about security *in Windows itself* are reasonable.
Perhaps they would, but it's difficult to say. On a Unix box, the users cannot run an email attachment. They must first download the file to disk, mark the file as executable, then attempt to run it.
No, it's not difficult to say at all. Users are quite happy (and able) to follow the instructions in an email to open a password-prorected zipfile, save the contents and then execute them. Typing "chmod +x blah" (or maybe "sh blah" if the malware is distributed as a shar) is barely going to slow them down.
On OS X you can't even execute binaries directly from the GUI.
So you deliver your malware in a.dmg or.sit containg an AppFolder. No problem at all.
Not if the person who set up the system knows what they are doing. For starters, daemons/servers of whatever kind are meant to be run via a passworded dummy/non-root user, and only have access to the server's own directory. Thus, even if that user was to be compromised, the cracker wouldn't have access to the entire system, or even shell access for that matter.
You're misunderstanding (perhaps deliberately). He's talking about the scenario where "user" means the person sitting in front of the machine and that is the only person (or one of a very small group of people) who uses it. In this case, exploiting that user account (eg: by getting them to run some arbitrary code, like 90% of Windows exploits do) is basically as "bad" as getting root.
Code run by a user can delete everything on the machine that users can write to - which usually means everything important. A user can start a daemon listening for remote connections, possibly evening something that gives remote shell access. A user can send email. A user can configure some binary to start every time they login.
This is what people mean when they say that exploiting a user account is basically as bad as exploiting a root account on the typical single-user desktop.
OSX and Linux won't let a normal user do "rm -fr/*" or anything like that.
Which will delete anything writable by that user on the whole system. Ie: pretty much everything of value.
[...] system-wide installations are only possible as superuser [...]
This gets repeated ad nauseum, but it is not true. *Some* system-wide installations are only possible by root, but not many.
Any user that is an "Admin" (which is probably most of the OS X users out there) has the ability to write to/Applications (and some other "system" directories). Therefore, they *can* install "system-wide" apps and, more importantly, they have the ability to *modify* any already-installed Apps (ie: a virus could infect every application).
I'm not talking about 3rd party apps, I'm talking about explorer.exe. There are a lot of little quirks and workarounds you have to deal with, although it's not impossible.
Given a standard bios these machines should have an incompatable partition structure to current Macs (as has already been noted).
This is only relevant to the boot drive, while the system is booting (after which the BIOS becomes irrelevant). I'd say the number of people who want to pull the drive out of their PPC Mac and boot from it on their PC without repartitioning is fairly small...
I/strongly/ advise setting up another DC. Even if you just grab the Windows 2003 eval from the Microsoft website and throw it on some old P2 desktop and reinstall it every 6 months when the eval period expires. I've never actually had to do it, but from what I've heard actually restoring AD from a backup can be a painful experience - best to just keep your "backup" live and online with multiple DCs:).
Since Intel has always been shaky in floating point and probably doesn't really know the meaning of vector I'm wondering how those kinds of apps will fare on the Mactel boxes.
As usual, the Mac zealots' FUD is about ten years out of date.
Err, directory services aren't easy to setup even with MS solutions.
Say what ? Basic AD infrastructure is about half a dozen mouseclicks. Integration into Exchange, for a global address book (the other thing most people seem to want DS for) is, if anything, even easier.
If you just want simple authentication (ie: "is this username and password valid") then use winbind. Use this if you just have a samba server you want to auth back to your AD.
For something more complex (like specifying unix UIDs, login shells, home directories, etc) you need to look at Microsoft Services for Unix (to extend the AD schema) and optionally pam_ldap/nss_ldap. I say "optionally" because SFU comes with a NIS server that can authenticate unix users - but you might not want to use NIS. Use this if you want your basic unix authentication to be centralised around AD.
We are in the process of implementing the latter. Since our environment is somewhat more complex than average (multiple Domains) we're having some teething problems, but with just a single domain it's trivial.
I have been considering some form of distrubuted storage cluster. In other words an array of machines which presents a single logical drive with redundency on a machine basis. Do people here have any experience with this (GFS et al.)? Care to comment?
I am actually working on something similar.
The Roll Your Own SAN HOWTO:
On the back end, we will have "disk nodes". These are 1U or 2U machines holding either 1.2 or 2.8TB of usable storage (4 or 8 400GB SATA drives in a RAID5, 1.6 or 3.2TB raw). They will "export" all this space via either iSCSI, NBD or AoE (ATA-over-Ethernet).
These machines will be ca. 3Ghz P4s with 2GB RAM and one or two 4-channel 3ware RAID controllers. We'll be building them ourselves.
On the front end is a bridge machine (or more, if you want more redundancy). This machine takes pairs of disk nodes and mirrors them via software RAID. The resultant/dev/md? devices are then collected together into a VG using LVM. The VG then has appropriate bits of space carved off it into LVs which are "exported" from the bridge machine using iSCSI.
These machines will be dual processor Xeons (probably Dell 1850s) with 4GB of RAM and (optionally, depending on need) an additional one or two 4-port GigE NICs. We are also considering Sun's dual Opteron v20z.
The whole thing is interconnected by gig ethernet - with anywhere from two to ten bonded links on the bridge machines and one link per disk node.
So:
* Individual disk failures on disk nodes are handled by the RAID on the disk nodes.
* Entire disk node failures are handled by the software RAID mirror each pair of disk nodes is a part of.
* Bridge machine failures are handled by something like heartbeat (ie: a hot standby).
Note: There is a practical limitation as to how big your disk nodes can be, determined by how long it takes the RAID1 to build. With a dedicated GbE interconnect for each disk node, RAID [re]build speed will be in the ballpark of 50M/sec - so a [re]build of a 2.8TB mirror will take about 15 hours. During this time, of course, the whole shebang is vulnerable to the other side of that pair failing.
On the "client" side, iSCSI makes the shared space appear as if it were a physical disk - "clients" will typically be Windows or unix servers re-sharing the space out to desktop machines or other servers. We also plan to use GFS for a couple of clustered services that need to share common storage (although simple NFS may be adequate - testing continues). Theoretically it would also be possible to get iSCSI HBAs and boot from the iSCSI devices (ie: no physical disks in the server at all), but we probably won't be pursuing this path.
The mini-itx chipsets aren't really appropriate for server usage, especially considering the weak VIA processors and the high prices for the boards.
More importantly, the motherboards will have bugger all bus bandwidth (a single 32/33 PCI bus). Performance (particularly things like RAID [re]builds) will suck. That's assuming the awful VIA chipset can even handle so much bus traffic without tanking.
Of course, since he's built the things with both master and slave drives on each IDE channel, performance is going to suck anyway.
Had this project been finalised by using a single machine as a "front-end" to glue together all the space in the multiple "back-end" machines via something like iSCSI, NBD or ATA-over-Ethernet (ie: roll your own SAN) it would have at least have had some novelty. As it is, it's just 4 extremely slow fileservers in a rack.
Some kudos are due from the industrial side of things - making his own cases, etc - but from the technology side it's a disaster.
Australia will extradite them in a heart beat, we have already done it before, hell the Australian government doesn't even care that it has a citizen in Guantanemo Bay.
The Australian Government's actions might possibly because of how he acted.
Those "religious outcasts" *left* because of state-sponsored religion in Europe.
Yeah, they left because those "state-sponsored religions" were too "liberal".
Your post shows that you've never actually spent any time in the U.S. If you had, you would know that what is presented in the media is very unrepresentative of the average person in the U.S.
I've met quite a lot of US exchange students, and I work for an American company (in their Australian office) - they were all really nice people, as long as you didn't say or do anything that might trigger off their (as a relative measure) right-wing, religious-conservative beliefs (at which point it could get a bit awkward). Even Americans I've met that called themselves left-wing, would be considered right-wing here in Australia.
It's not so much Macs last longer, it's that they're replaced less. This is largely - particularly going back more than a few years - because they cost more.
(Modestly) upgrade a PC at the 2.5 - 3 year mark and you've probably spent as much as you would have on a Mac 3 years prior. Then you've effectively got a 3 year old Mac vs an almost up-to-date PC. Not to mention you almost always get much more "bang for buck" with PCs - particularly in the price ranges normal people can afford.
Yes, Apple is rumored to be looking at using some method to cripple the OS so that it only runs on their hardware, but who out there wants to buy something that's purposefully crippled?
I have to wonder, do you consider, say, a PS2 game (that can only run on a PS2), "crippled" ?
So yes, it's not necessarily just about which CPU Apple uses. I think the crippleware aspect is the most troubling consequence of the switch.
The future, with MacOS only running on Apple Macs is no different from the present and (most of) the past, where MacOS only runs/ran on Apple Macs. Apple customers do not appear to have perceived this as a problem in the past, nor in the present, why do you think they will perceive it as a problem in the future ?
I mean, let's face it, Windows _would_ let me do everything I need to, but I use Linux because of basically irrelevant technological advantages it has.
Slashdot Mirror
Neither \Windows nor \Windows\System32 are world-writable by default.
And these fuckups are _very_ deep in the system, like their "case-preserving but not case-sensitive" filesystem, "ressource-forks" (or whatever they're called), again in the filesystem; unicode-or-not problems and so on..
Just because you don't like them, doesn't make them bad.
For 99% of malware, the only "exploit" necessary is the one to get the end-user to run something. History has demonstrated this is not particularly difficult.
This applies to a whole bunch of various shared libraries on basically every contemporary platform. So....what's your point ?
The fundamental concepts behind Microsoft's Windows Update are seriously flawed and without constant vigilance on the part of Microsoft it could be the most serious vector of attack in the history of computer security.
And how is this different from, say, Apple's Software Update, or Redhat's RHN, or kernel.org ?
I'm sorry, the headline of this article putting Windows at par with ANYTHING in terms of security is unconvincing to me.
The biggest cause of security problems in Windows is end users, usually facilitated by poor applications requiring end users to run with higher privileges than they need. As such, such claims about security *in Windows itself* are reasonable.
No, it's not difficult to say at all. Users are quite happy (and able) to follow the instructions in an email to open a password-prorected zipfile, save the contents and then execute them. Typing "chmod +x blah" (or maybe "sh blah" if the malware is distributed as a shar) is barely going to slow them down.
On OS X you can't even execute binaries directly from the GUI.
So you deliver your malware in a .dmg or .sit containg an AppFolder. No problem at all.
You're misunderstanding (perhaps deliberately). He's talking about the scenario where "user" means the person sitting in front of the machine and that is the only person (or one of a very small group of people) who uses it. In this case, exploiting that user account (eg: by getting them to run some arbitrary code, like 90% of Windows exploits do) is basically as "bad" as getting root.
Code run by a user can delete everything on the machine that users can write to - which usually means everything important. A user can start a daemon listening for remote connections, possibly evening something that gives remote shell access. A user can send email. A user can configure some binary to start every time they login.
This is what people mean when they say that exploiting a user account is basically as bad as exploiting a root account on the typical single-user desktop.
Running purely as root is NOT a good idea.
OSX and Linux won't let a normal user do "rm -fr /*" or anything like that.
Which will delete anything writable by that user on the whole system. Ie: pretty much everything of value.
[...] system-wide installations are only possible as superuser [...]
This gets repeated ad nauseum, but it is not true. *Some* system-wide installations are only possible by root, but not many.
Any user that is an "Admin" (which is probably most of the OS X users out there) has the ability to write to /Applications (and some other "system" directories). Therefore, they *can* install "system-wide" apps and, more importantly, they have the ability to *modify* any already-installed Apps (ie: a virus could infect every application).
For example ?
/Running as a regular user for nearly 10 years...
This is only relevant to the boot drive, while the system is booting (after which the BIOS becomes irrelevant). I'd say the number of people who want to pull the drive out of their PPC Mac and boot from it on their PC without repartitioning is fairly small...
I /strongly/ advise setting up another DC. Even if you just grab the Windows 2003 eval from the Microsoft website and throw it on some old P2 desktop and reinstall it every 6 months when the eval period expires. I've never actually had to do it, but from what I've heard actually restoring AD from a backup can be a painful experience - best to just keep your "backup" live and online with multiple DCs :).
But by the time they did that, the $500 market had become the $250 market...
As usual, the Mac zealots' FUD is about ten years out of date.
Yes, but not as well. G4s are either "slow" or "fast", whereas the P-Ms can throttle across a range of different speeds.
I've yet to see this happen on any of our (9) DCs.
Why do people say this when Microsoft's Kerberos extensions were done in exactly the way the standard allowed for ?
Say what ? Basic AD infrastructure is about half a dozen mouseclicks. Integration into Exchange, for a global address book (the other thing most people seem to want DS for) is, if anything, even easier.
If anything, DS on Windows is *too easy*.
If you just want simple authentication (ie: "is this username and password valid") then use winbind. Use this if you just have a samba server you want to auth back to your AD.
For something more complex (like specifying unix UIDs, login shells, home directories, etc) you need to look at Microsoft Services for Unix (to extend the AD schema) and optionally pam_ldap/nss_ldap. I say "optionally" because SFU comes with a NIS server that can authenticate unix users - but you might not want to use NIS. Use this if you want your basic unix authentication to be centralised around AD.
We are in the process of implementing the latter. Since our environment is somewhat more complex than average (multiple Domains) we're having some teething problems, but with just a single domain it's trivial.
I am actually working on something similar.
The Roll Your Own SAN HOWTO:
On the back end, we will have "disk nodes". These are 1U or 2U machines holding either 1.2 or 2.8TB of usable storage (4 or 8 400GB SATA drives in a RAID5, 1.6 or 3.2TB raw). They will "export" all this space via either iSCSI, NBD or AoE (ATA-over-Ethernet).
These machines will be ca. 3Ghz P4s with 2GB RAM and one or two 4-channel 3ware RAID controllers. We'll be building them ourselves.
On the front end is a bridge machine (or more, if you want more redundancy). This machine takes pairs of disk nodes and mirrors them via software RAID. The resultant /dev/md? devices are then collected together into a VG using LVM. The VG then has appropriate bits of space carved off it into LVs which are "exported" from the bridge machine using iSCSI.
These machines will be dual processor Xeons (probably Dell 1850s) with 4GB of RAM and (optionally, depending on need) an additional one or two 4-port GigE NICs. We are also considering Sun's dual Opteron v20z.
The whole thing is interconnected by gig ethernet - with anywhere from two to ten bonded links on the bridge machines and one link per disk node.
So:
* Individual disk failures on disk nodes are handled by the RAID on the disk nodes.
* Entire disk node failures are handled by the software RAID mirror each pair of disk nodes is a part of.
* Bridge machine failures are handled by something like heartbeat (ie: a hot standby).
Note: There is a practical limitation as to how big your disk nodes can be, determined by how long it takes the RAID1 to build. With a dedicated GbE interconnect for each disk node, RAID [re]build speed will be in the ballpark of 50M/sec - so a [re]build of a 2.8TB mirror will take about 15 hours. During this time, of course, the whole shebang is vulnerable to the other side of that pair failing.
On the "client" side, iSCSI makes the shared space appear as if it were a physical disk - "clients" will typically be Windows or unix servers re-sharing the space out to desktop machines or other servers. We also plan to use GFS for a couple of clustered services that need to share common storage (although simple NFS may be adequate - testing continues). Theoretically it would also be possible to get iSCSI HBAs and boot from the iSCSI devices (ie: no physical disks in the server at all), but we probably won't be pursuing this path.
More importantly, the motherboards will have bugger all bus bandwidth (a single 32/33 PCI bus). Performance (particularly things like RAID [re]builds) will suck. That's assuming the awful VIA chipset can even handle so much bus traffic without tanking.
Of course, since he's built the things with both master and slave drives on each IDE channel, performance is going to suck anyway.
Had this project been finalised by using a single machine as a "front-end" to glue together all the space in the multiple "back-end" machines via something like iSCSI, NBD or ATA-over-Ethernet (ie: roll your own SAN) it would have at least have had some novelty. As it is, it's just 4 extremely slow fileservers in a rack.
Some kudos are due from the industrial side of things - making his own cases, etc - but from the technology side it's a disaster.
Have you bothered to tell them it doesn't work for you ?
The Australian Government's actions might possibly because of how he acted.
Yeah, they left because those "state-sponsored religions" were too "liberal".
Your post shows that you've never actually spent any time in the U.S. If you had, you would know that what is presented in the media is very unrepresentative of the average person in the U.S.
I've met quite a lot of US exchange students, and I work for an American company (in their Australian office) - they were all really nice people, as long as you didn't say or do anything that might trigger off their (as a relative measure) right-wing, religious-conservative beliefs (at which point it could get a bit awkward). Even Americans I've met that called themselves left-wing, would be considered right-wing here in Australia.
It's not so much Macs last longer, it's that they're replaced less. This is largely - particularly going back more than a few years - because they cost more.
(Modestly) upgrade a PC at the 2.5 - 3 year mark and you've probably spent as much as you would have on a Mac 3 years prior. Then you've effectively got a 3 year old Mac vs an almost up-to-date PC. Not to mention you almost always get much more "bang for buck" with PCs - particularly in the price ranges normal people can afford.
I have to wonder, do you consider, say, a PS2 game (that can only run on a PS2), "crippled" ?
So yes, it's not necessarily just about which CPU Apple uses. I think the crippleware aspect is the most troubling consequence of the switch.
The future, with MacOS only running on Apple Macs is no different from the present and (most of) the past, where MacOS only runs/ran on Apple Macs. Apple customers do not appear to have perceived this as a problem in the past, nor in the present, why do you think they will perceive it as a problem in the future ?
_Technological_ advantages ?
Probably because it's not especially difficult to have a Windows machines that does not suffer from these problems.