Re:Won't somebody please think of the ATM machines
on
IBM Officially Kills OS/2
·
· Score: 4, Informative
I don't think you've checked very recently. The vast majority of ATM's have been Windows based for at least 2 or 3 years.
The big transition started happening around Y2K. They needed to upgrade the hardware in many of the systems anyways, so they took the opportunity to bail on OS/2 as well (given IBM's "don't ask, don't tell" stance on it).
Well, yes... if you MOVE a file on the same partition, it will retain it's old permissions (as well as any new inherited ones), but if you copy the file (or create a new one) it will get the folders permissions.
But even on Unix when you move a file it will retain its ownership and permissions. One would think even a Unix admin would understand that detail.
What you're effectively saying is "Because unix admins expect it to work one way, and doesn't, that's a bad thing". That's really the same argument as saying "Because Unix doesn't act like Windows, that's a bad thing".
I mean, Windows users expect the clipboard to work everywhere. Unix users expect the middle mouse button to copy the current selection. There's lots of this kind of stuff that anyone moving from one system to another has to get used to.
Well, I stand corrected on Palladium, but then I was really considering the TCPA organizations argument, not Microsoft's. It's true that TCPA *MAY* increase some security, but that's a side-effect, not the purpose.
Also, I still don't agree with you about the passsword thing. It doesn't take someone that "knows what they're doing" to set a password. The dialog *ASKS* You for one. Yes, if you don't enter one, it would happily continue (until default password complexity restrictions happened in Windows 2003), but I wouldn't really call that a default in the same way you originally phrased it.
In your original wording, it made it seem like Windows created an administrator account by itself with no password, and you had to go out of you way to add one.
As for bypass traverse checking, you also have to turn off object inheritance to set an individual file to different permissions. So one would assume they know what they're doing.
Umm.. what exactly do you think regmon is for? Finding when registry writes fail. Duh!
Also, you only need to do this once. You can write a script to fix it on every machine after that.
Now, granted, if this was a single program for a single user, it may not be as worth your time, but that's your job as an admin. Not breaking security to ease your job.
Except that Apache actually *HAS* had more vulernatilities in the last 2 years than IIS6 has. But that's really beside the point since your premise is flawed.
Apache doesn't have 60% of the marketshare. They have 60% of the *hostnames*, not 60% of the servers.
It's been a while since netcraft did a physical server survey (2001) but the ratio of hosts (apache : IIS) hasn't changed that much so I would suspect the numbers for physical servers are not that different.
In that survey, Windows had > 50% of the physical servers, largely because big hosting sites skewed the hosts with 10's of thousdands of sites on a single server (or server farm).
Actually, Apache has had more vulnerabilies in the last 2 years than IIS6 has. But that's beside the point anyways, since your premise is flawed. your 60% share argument is *hostnames* not servers.
It's been a while since netcraft did a physical server survey (2001) but the percentages of hosts are still roughly the same as they were so I would expect the physical server count hasn't changed much. In it, Windows had > 50% of the actual physical web servers. This was largely because the host numbers are skewed by large hosting companies running 10's of thousands of hosts on a single server (or server farm).
Wrong on several accounts. First, SP2 still gives you the grace period before activation. Second, it enables the firewall by default so you won't get infected unless you are deliberately going somewhere, download an infected program, and run it.
Umm.. Windows NT based system (the only Windows system with an Administrator account) have never had a default administrator account with no password.
It may be that some OEM you bought from created an default account with no password, but NT has always asked you to enter the password for the adminsitrator account, even in NT 3.1 12 years ago.
Also, Palladium was never billed as a way to ensure your computer is secure. It's billed as a way to make your *INFORMATION* more secure. Big difference really. TCPA will be available on all kinds of platforms, not just Windows. Linux is adopting it as well.
I really don't quite get your problem with Bypass traverse checking. If you set the permissions on a file explicitly, then any OS should honor that. Not doing so would be brain dead, counter-intuitive, and confusing. "I Said give joe access, why isn't it doing it!"
Further, why should you have to give someone rights to the directory to give them rights to a file? That's just plain stupid.
Wrong. Name one of these programs, and I'll show you how you can run it without being an administrator.
Just because it takes more work to do so doesn't mean you can't do it. Most adminstrators are just too lazy to use the readily available tools to determine what resources a user needs to access.
There is no worm out there that will infect a default XP SP2 machine. The only way for you to infect an XP SP2 machine is through user action (ie, running an infected program).
Actually, COM+ addresses most of your security concerns with role based security. It greatly simplifies both the rollout, configuration, and maintenance of security on DCOM. XP SP2 and 2003 SP1 both improved on that as well.
You don't need direct SMTP access to send spam. The Unix way of sending email (through MTA's called by user processes) means that any program can send spam simply by having access to mail or sendmail.
Now, unless you propose not allowing them to send ANY mail at all, you can't really stop that.
There is *NOTHING*, other than programs which explicitly check for administrator rights and refuse to run if they're not (that's pretty rare, in my experience) that requires them to run.
Any time you think it requires administrator rights, you can pretty easily figure out what resource it needs and give them access to it explicitly using tools like regmon and filemon.
Most admins (yourself included, it seems), however, are too lazy to bother to figure this stuff out and just give them admin privs or refuse to help them at all.
Let's look at the most recent vulnerability there, MFSA-2005-56. Unfortunately, the details are being hidden until July 20th. However, we can see the Bugzilla report numbers. The first, 294795, won't let me view it. But if we view 294796, the bug created right after we see it was created on May 19th. Nearly 2 months ago.
Is 2 months "quickly"?
You seem to be blindly making assumptions without bothering to check the facts.
This is NOT evidence that Open Source fixes bugs quickly. If anything, it proves that just like Closed source, they can keep the bugs quiet and sit on them as long as they like.
12 vulnerabilities in this patch, the oldest was created in APRIL! And it's marked as high severity.
The newest we don't know, because Mozilla is keeping it hidden until July 20th, but if you take the Bugzilla report number, and add one to it you can get the bug that was created directly after it, and that was created in MAY!
So yes, Mozilla DOES sit on critical bugs for months.
I will thank you to stop putting words in my mouth. I didn't say Intel was innocent in anything, so don't go claiming I did. For someone claiming the high moral ground in the argument you are showing a remarkable lack of it by fabricating what I said.
You might start by looking at yourself before complaining of others lack of ethics.
What I said, in no uncertain terms, is that what is being claimed (that intel is deliberately looking for AMD CPU's and then feeding them bad code) is not the case. Whether Intel's behavior is right or wrong, that doesn't make exagerating and even falisifying the situation ok.
The fact is, Intel is optimizing only for their CPU's. They are not targeting AMD (though they're certainly feeling the effects). In my opinion, I can't see how AMD can compel Intel to optomize for anyone given that Intel's compiler is a minority player in the market.
No, what Intel is saying is that if you are an intel processor, we know we can move double word. Everyone else (including 386's, 486's, Transmeta's, Via C3's, etc..) we don't know that. And what about CPU's that don't exist yet, but still need to run the code?
Could Intel have specifically checked for Athlon's? probably. But they're really under no requirement to do so.
Is the CPU manufacturer irrelevant? What if the manufacturer claimed support of a feature, but it was flawed or incomplete?
I'm not saying AMD is like that, but Intel can't control it's competitors. If Intel wants to generate "safe" code that can't possibly cause problems, they can only optimize for CPU's they are certain fully implement the features, and fall back to default for everyone else.
There are technical differences between AMD and Intel CPU's. That much alone is enough for Intel to justify wanting to optimize only for their own chips. The claimed presence of a given feature is irrelevant to that. What if next month AMD decides to "extend" SSE in an incompatible way?
Inte's compiler is not the dominant compiler on the market. If it were, AMD might have a point. Maybe. But since it's not, I can't see how it matters.
That's just it. There *ARE* differences. The P4 and Athlon have different pipeline lengths, therefore significant performance improvement (or loss) can happen strictly by the way instructions are ordered. There's no such thing as a 'generic 686' CPU other than the original Pentium Pro anymore.
But all that aside, if you were to specify generic 686, one would assume it wouldn't use *ANY* specific registers like MMX or SSE. All you would be doing is removing the P4 optmizations entirely.
I think that's creative writing on the part of AMD's lawyers. They don't really give any real evidence in their complaint, and "detected an amd chip" could mean "didn't detect an intel chip"
What they're doing is creating two code paths. One for Intel processors, one for everyone else. AMD is "everyone else" and thus falls into code that has to work on 386's, 486's, Via C3's, Cyrix, etc.. They're not deliberately inserting poor code, they're falling back to the most basic code that works for all processors (which often have wildly different boundary restrictions and "quirks" that have to be worked around).
They're not unoptimizing for AMD because they're not specifically looking for AMD. They're ARE optimizing only for intel. Period.
Slashdot Mirror
I don't think you've checked very recently. The vast majority of ATM's have been Windows based for at least 2 or 3 years.
The big transition started happening around Y2K. They needed to upgrade the hardware in many of the systems anyways, so they took the opportunity to bail on OS/2 as well (given IBM's "don't ask, don't tell" stance on it).
Well, yes... if you MOVE a file on the same partition, it will retain it's old permissions (as well as any new inherited ones), but if you copy the file (or create a new one) it will get the folders permissions.
But even on Unix when you move a file it will retain its ownership and permissions. One would think even a Unix admin would understand that detail.
What you're effectively saying is "Because unix admins expect it to work one way, and doesn't, that's a bad thing". That's really the same argument as saying "Because Unix doesn't act like Windows, that's a bad thing".
I mean, Windows users expect the clipboard to work everywhere. Unix users expect the middle mouse button to copy the current selection. There's lots of this kind of stuff that anyone moving from one system to another has to get used to.
Well, I stand corrected on Palladium, but then I was really considering the TCPA organizations argument, not Microsoft's. It's true that TCPA *MAY* increase some security, but that's a side-effect, not the purpose.
Also, I still don't agree with you about the passsword thing. It doesn't take someone that "knows what they're doing" to set a password. The dialog *ASKS* You for one. Yes, if you don't enter one, it would happily continue (until default password complexity restrictions happened in Windows 2003), but I wouldn't really call that a default in the same way you originally phrased it.
In your original wording, it made it seem like Windows created an administrator account by itself with no password, and you had to go out of you way to add one.
As for bypass traverse checking, you also have to turn off object inheritance to set an individual file to different permissions. So one would assume they know what they're doing.
Umm.. what exactly do you think regmon is for? Finding when registry writes fail. Duh!
Also, you only need to do this once. You can write a script to fix it on every machine after that.
Now, granted, if this was a single program for a single user, it may not be as worth your time, but that's your job as an admin. Not breaking security to ease your job.
Isn't that a little like saying "Sure Windows is less secure than OSX, but then it has 250 ports open. Open 250 ports on OSX and we'd be the same"?
When will people realize that installing every application under the sun is *NOT* Secure.
doh! Slashdot gave me an error so I resubmitted.. looks like it got posted twice, sorry.
Except that Apache actually *HAS* had more vulernatilities in the last 2 years than IIS6 has. But that's really beside the point since your premise is flawed.
Apache doesn't have 60% of the marketshare. They have 60% of the *hostnames*, not 60% of the servers.
It's been a while since netcraft did a physical server survey (2001) but the ratio of hosts (apache : IIS) hasn't changed that much so I would suspect the numbers for physical servers are not that different.
In that survey, Windows had > 50% of the physical servers, largely because big hosting sites skewed the hosts with 10's of thousdands of sites on a single server (or server farm).
Actually, Apache has had more vulnerabilies in the last 2 years than IIS6 has. But that's beside the point anyways, since your premise is flawed. your 60% share argument is *hostnames* not servers.
It's been a while since netcraft did a physical server survey (2001) but the percentages of hosts are still roughly the same as they were so I would expect the physical server count hasn't changed much. In it, Windows had > 50% of the actual physical web servers. This was largely because the host numbers are skewed by large hosting companies running 10's of thousands of hosts on a single server (or server farm).
Wrong on several accounts. First, SP2 still gives you the grace period before activation. Second, it enables the firewall by default so you won't get infected unless you are deliberately going somewhere, download an infected program, and run it.
Umm.. Windows NT based system (the only Windows system with an Administrator account) have never had a default administrator account with no password.
It may be that some OEM you bought from created an default account with no password, but NT has always asked you to enter the password for the adminsitrator account, even in NT 3.1 12 years ago.
Also, Palladium was never billed as a way to ensure your computer is secure. It's billed as a way to make your *INFORMATION* more secure. Big difference really. TCPA will be available on all kinds of platforms, not just Windows. Linux is adopting it as well.
I really don't quite get your problem with Bypass traverse checking. If you set the permissions on a file explicitly, then any OS should honor that. Not doing so would be brain dead, counter-intuitive, and confusing. "I Said give joe access, why isn't it doing it!"
Further, why should you have to give someone rights to the directory to give them rights to a file? That's just plain stupid.
Wrong. Name one of these programs, and I'll show you how you can run it without being an administrator.
Just because it takes more work to do so doesn't mean you can't do it. Most adminstrators are just too lazy to use the readily available tools to determine what resources a user needs to access.
Dell does ship with SP2 by default. Dell will load SP1 if your company requests it, but this is not the default configuration.
I call bullshit.
There is no worm out there that will infect a default XP SP2 machine. The only way for you to infect an XP SP2 machine is through user action (ie, running an infected program).
Actually, COM+ addresses most of your security concerns with role based security. It greatly simplifies both the rollout, configuration, and maintenance of security on DCOM. XP SP2 and 2003 SP1 both improved on that as well.
You don't need direct SMTP access to send spam. The Unix way of sending email (through MTA's called by user processes) means that any program can send spam simply by having access to mail or sendmail.
Now, unless you propose not allowing them to send ANY mail at all, you can't really stop that.
There is *NOTHING*, other than programs which explicitly check for administrator rights and refuse to run if they're not (that's pretty rare, in my experience) that requires them to run.
Any time you think it requires administrator rights, you can pretty easily figure out what resource it needs and give them access to it explicitly using tools like regmon and filemon.
Most admins (yourself included, it seems), however, are too lazy to bother to figure this stuff out and just give them admin privs or refuse to help them at all.
That would be Mission: Earth, not Battlefield Earth.
M:E was a drawnout series that miraculously seemed to keep going even after his death.
BE was a single book (though it was huge, even by jordanian standards)
Out of curisity, what do you consider "quickly"?
l nerabilities.html#Firefox
http://www.mozilla.org/projects/security/known-vu
Let's look at the most recent vulnerability there, MFSA-2005-56. Unfortunately, the details are being hidden until July 20th. However, we can see the Bugzilla report numbers. The first, 294795, won't let me view it. But if we view 294796, the bug created right after we see it was created on May 19th. Nearly 2 months ago.
Is 2 months "quickly"?
You seem to be blindly making assumptions without bothering to check the facts.
This is NOT evidence that Open Source fixes bugs quickly. If anything, it proves that just like Closed source, they can keep the bugs quiet and sit on them as long as they like.
You think so? Check out the patch list for FF 1.05
l nerabilities.html#Firefox
http://www.mozilla.org/projects/security/known-vu
12 vulnerabilities in this patch, the oldest was created in APRIL! And it's marked as high severity.
The newest we don't know, because Mozilla is keeping it hidden until July 20th, but if you take the Bugzilla report number, and add one to it you can get the bug that was created directly after it, and that was created in MAY!
So yes, Mozilla DOES sit on critical bugs for months.
I will thank you to stop putting words in my mouth. I didn't say Intel was innocent in anything, so don't go claiming I did. For someone claiming the high moral ground in the argument you are showing a remarkable lack of it by fabricating what I said.
You might start by looking at yourself before complaining of others lack of ethics.
What I said, in no uncertain terms, is that what is being claimed (that intel is deliberately looking for AMD CPU's and then feeding them bad code) is not the case. Whether Intel's behavior is right or wrong, that doesn't make exagerating and even falisifying the situation ok.
The fact is, Intel is optimizing only for their CPU's. They are not targeting AMD (though they're certainly feeling the effects). In my opinion, I can't see how AMD can compel Intel to optomize for anyone given that Intel's compiler is a minority player in the market.
No, what Intel is saying is that if you are an intel processor, we know we can move double word. Everyone else (including 386's, 486's, Transmeta's, Via C3's, etc..) we don't know that. And what about CPU's that don't exist yet, but still need to run the code?
Could Intel have specifically checked for Athlon's? probably. But they're really under no requirement to do so.
Is the CPU manufacturer irrelevant? What if the manufacturer claimed support of a feature, but it was flawed or incomplete?
I'm not saying AMD is like that, but Intel can't control it's competitors. If Intel wants to generate "safe" code that can't possibly cause problems, they can only optimize for CPU's they are certain fully implement the features, and fall back to default for everyone else.
There are technical differences between AMD and Intel CPU's. That much alone is enough for Intel to justify wanting to optimize only for their own chips. The claimed presence of a given feature is irrelevant to that. What if next month AMD decides to "extend" SSE in an incompatible way?
Inte's compiler is not the dominant compiler on the market. If it were, AMD might have a point. Maybe. But since it's not, I can't see how it matters.
That's just it. There *ARE* differences. The P4 and Athlon have different pipeline lengths, therefore significant performance improvement (or loss) can happen strictly by the way instructions are ordered. There's no such thing as a 'generic 686' CPU other than the original Pentium Pro anymore.
But all that aside, if you were to specify generic 686, one would assume it wouldn't use *ANY* specific registers like MMX or SSE. All you would be doing is removing the P4 optmizations entirely.
I think that's creative writing on the part of AMD's lawyers. They don't really give any real evidence in their complaint, and "detected an amd chip" could mean "didn't detect an intel chip"
No, that's not what Intel is doing.
What they're doing is creating two code paths. One for Intel processors, one for everyone else. AMD is "everyone else" and thus falls into code that has to work on 386's, 486's, Via C3's, Cyrix, etc.. They're not deliberately inserting poor code, they're falling back to the most basic code that works for all processors (which often have wildly different boundary restrictions and "quirks" that have to be worked around).
They're not unoptimizing for AMD because they're not specifically looking for AMD. They're ARE optimizing only for intel. Period.