Yes, that's yet another instance where Cliff Stoll is wrong.
Re:How to totally screw up Win2k in less than 1 mi
on
Gnarly Error Messages
·
· Score: 4, Insightful
Changing a bunch of configuration settings in a GUI should not be something that's unrecoverable through normal, documented means.
not required--no "triangulation" involved
on
WiFi Triangulation
·
· Score: 2
If the system used triangulation, you would be right. But it doesn't. All that is required is that relative signal strengths are reasonably reproducible for each location and that you have enough measurements to distinguish all locations you are interested in. The system internally produces a map of which combinations of signal strengths correspond to which locations. To reduce the number of calibration points you need, you can try use interpolation between nearby measurements, which will usually work reasonably well/
parent post is complete nonsense
on
WiFi Triangulation
·
· Score: 3, Interesting
TCP/IP has nothing at all to do with this, nor Zipf's law, nor any inverse square law, nor any kind of physical model. The system simply builds an empirical numerical model relating received power at the access points to location. As long as received power varies reproducibly with distance (not even necessarily monotonically) and you get enough independent measurements, that is possible.
Just use a slightly directional antenna--anything that relies on signal strength to triangulate you will end up being way off. If you set it up carefully, you can even choose your "virtual" location. And, no, the government can't really outlaw directional antennas.
Have a look at Evolution Robotics. They sell hardware that gives wheels to your laptop. It also comes with software, unfortunately Windows-based (they also have a Linux version but they don't ship that).
Are you honestly suggesting that it is worse to expose a small portion of the system than to expose the whole system in one monolithic chunk,
I'm saying that the way to deal with security problems is to fix the software in question, not to make the problem even more complex with yet another software layer.
simply because it would make it harder for you to write threat analysis reports?
Understanding threats isn't some tedious exercise in satisfying management, it's something you have to do in order to be able to write secure software.
Your guess as to who I spend most of my time fighting.
And that won't change until people who write software (1) make an effort to understand security and threats and (2) address security problems by fixing the root cause rather than adding even more complex softawre into the mix.
However, then we'd have to say that Windows 98 is better than unix, because there is no security at all,
When I need a car to get me from point A to point B, a ham sandwich won't do. But among cars, I still prefer the ones that are safer.
Yes, they try, and they fail frequently, that's why we have buffer overflows in applications
And those buffer overflows won't go away through a complicated system of privileges. We need to get rid of the buffer overflows themselves, not make imperfect attempts to mask them.
If you are saying that all assumptions cause trouble, that's logically absurd. Or do you write your code assuming that assumptions cause trouble? Well, then you better stop right now making that assumption.
What it comes down to is that some assumptions lead to less security, other assumptions lead to more security. In particular, writing your program as if it were run as root--"assuming the worst case"--makes it more secure. On the other hand, writing your program assuming that something like systrace will protect the system even if your program has bugs will lead to less security overall. That's my point, and it seems that, except some confusion around the term "assumption", you actually agree with me.
Lets say that you have an smtp daemon. With systrace, I can very easily elevate it to be able to open port 25 on the system, and restrict it so that it can't fork or exec any programs and can do no i/o other than writing to files in/var/mail.
First of all, your logic is invalid. If there exist cases in which the consequences of elevating specific privileges are easy to understand, that does not mean that the consequences of elevating specific privileges are easy to understand in most cases.
but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon
Even though you hand-picked SMTP as an example to illustrate your argument, it even breaks down there. If I can acquire this privilege set you think of as so restrictive, for example by compromising the SMTP daemon, all of a sudden, I can intercept any mail message and deliver it to myself. That is very likely enough to break into someone's account because either passwords or information useful for social engineering get sent through the mail system.
On the other hand, if the SMTP daemon runs as root, the threat analysis for a user of it is much simplified. If the SMTP daemon is already compromised and runs as root, it doesn't matter whether I send information through it that might give an attacker root privileges on this machine.
Most of your comment seems to consist of platitudes about simplicity,
Most of your comments are platitudes that show little actual experience in how systems are skillfully broken into. Beyond script kiddies exploring spectacularly gaping holes in poorly written C programs that just give them root shells, systems are compromised carefully and incrementally, exploring one subtle flaw after another.
UNIX has evolved for nearly 30 years around the idea that processes either have root privileges or they have user privileges. It's a sound and simple system. If, against that background, you add support for giving processes individual privileges, you risk doing more harm than good. Existing programs will assume that if a process demonstrates one privilege that traditionally only a root process posesses, then it must also have all the others. So, if you give a process specific privileges, you risk that it can acquire more because other processes will give it more trust than it deserves.
In fact, even for OSes that start out with lots of different privileges, it's far from clear that it helps--programmers seem to have trouble understanding all the implications of all the different bits. For example, VMS, with its much-vaunted mess of security bits, ended up succumbing to a domino effect: you get one bit, then using that, the next one, then one more, until you can do whatever you want. The trouble is that when you tell a programmer that his code runs with "restore from backup privilege" (an example from a privilege happy OS of yore), they assume that's all they get and don't even consider all the other weird implications that that privilege may have. And who can blame them? Who can keep all the weird effects and interactions of dozens of different privileges in their head?
The simple UNIX privilege system is good: when programmers write code that runs as root, they know exactly what that code can do: everything. And they try to take appropriate care.
high-speed cross-continental train would be great
on
Jet Turbine Locomotives
·
· Score: 3, Interesting
At around 200mph, easily achievable using current train systems if you got high speed rail all the way, you should be able to go from downtown San Francisco or LA to New York in 15 hours. That is actually not that different from air travel if you take into account all the overhead associated with air travel (security, parking, transportation to/from airport, etc.), and it's a whole lot more pleasant. With improved technology, perhaps one could even get that down by a few more hours. And trains don't fly into buildings either.
As in: you need to keep track of whether a new version of the software exists, you download it, you end up with three weird looking files on your desktop, you open one of them up (if you double click on the wrong one, you get more weird looking files on your desktop), you need to figure out where you put the old version of the software, you drag it there, you get rid of the junk on your desktop--but in the right order please, or OS X will complain.
Well, or maybe not. Maybe the software came as an installable bundle, in which case you will still end up with lots of junk on your desktop but some wizard will also ask you bizarre questions, like "which of these drives do you want to install it on" when there is only one. Or maybe it's being updated through Apple's update system.
Software installation on the Mac is a mess. I have talked enough novice users through it to know.
Microsoft can change around their proprietary standards in ways that's bad for you and me because they have complete control. But open source works differently: if changes to an open source project screw too many users, the project just forks. The open source community is highly professional in this regard.
Overall, you need standards like those for TCP/IP and ANSI C much more urgently for closed-source products.
POWER OUTAGE! You have no control over them. Even with the 1500VA UPS I use, if the power is out long enuogh, my systems will suddenly find the floor dropped out from below them into the void of not-running-land. I haven't setup auto-shutdown based on UPS feedback, either, so it would be a crash-like situation.
Well, as I was saying: if you don't set up your servers properly, then journaling may be for you. The correct action on power failure is to shut down before the batteries run out.
The "better ways" depend on your environment and application. Many high-end servers just don't crash haphazardly; when they do crash, time spent fscking is irrelevant since something else is wrong. For something like a web server farm, aggregate performance matters, and that is higher if you don't journal, even if individual machines are out longer when they reboot.
If you run a flaky file server for a workgroup and users are breathing down your neck, then journaling may, of course, help you. But perhaps you should just upgrade to a collection of non-flaky file servers instead.
Journaling is most useful for desktops and laptops, which are at risk of being turned off or crashed frequently, and where you actually sit in front waiting for it.
You don't have to use the SysV init scripts on Linux. In fact, I think several Linux installations revert to/etc/rc if they can't find the other init scripts.
Of course, the reason why those init scripts are there is for package management. It's hard to see how you can have decent package management with a monolithic init file.
However it is relatively easy to attack a specific point of NTFS (its journaling) and make your filesystem do that specific thing better.
That's because NTFS journaling sucks--it makes very few guarantees about the state of your file system after a crash.
NTFS supports [blah blah blah]
I think the fundamental problem that Microsoft and Microsoft users have is that they think more is better. It isn't. Software generally gets better as you figure out what features are not needed and remove them. Most of NTFS's features fall into that category.
From a user's point of view, once it's installed, KDE or Gnome are no harder to use than OS X. Or, to put it differently, the OS X GUI has plenty of pitfalls, which you would discover if you actually tried to support novice OS X users.
OS X has far fewer drivers available for it than Linux.
While there is more commercial OS X software, OS X runs considerably less free and research software than Linux.
The OS X GUI is an key part of OS X, and it is not a universal win. While it is pretty, it is also proprietary, requires a complete rewrite for most software to be ported to it, and it's slow.
Software installation, packaging, and maintenance on OS X is a mess compared to Linux.
There are many nice things about OS X, and there are many not so nice things about it as well. Overall, there is no clear winner between OS X or Linux--it really depends on the application and the user. For many current Linux users, OS X simply is is not a workable alternative. For home users, however, OS X is an excellent choice, not because of any technical differences, but simply because it comes pre-packaged with its hardware and because lots of stores carry it.
We've got a good 15-50 years of "supernationalism" until some agreed-upon mechanism for punnishing extra-national criminals is agreed upon. Probably by an extension of the UN War Crimes court into a body to deal with inter-country legal affairs that aren't War Crimes.
The US has refused to ratify the treaty on the international criminal court because of the completely hypothetical possibility that US citizens might be tried elsewhere. I don't believe the US is going to subject its citizens to any form of foreign jurisdiction if it can help it.
The consulate has much more time to check than 60 seconds. Visa application forms are sent in weeks in advance. Furthermore, when appearing in person, the consular official still took hours (!) to process the application (I think that procedure doesn't exist anymore in many places). The consular office has all the time it wants to check whatever it wants. If it only takes 60 seconds per applicant, that's not a problem with the applicant or the system, it's incompetence on the part of the consulate.
"What do you need a case sensitive FS for? Because it means that file name equality translates into file identity." This has not been true since the 1970s. Hard links and internal shares can make multiple file names for the exact same file.
I'm sorry--I guessed you would be able to figure out the way in which hard links differ from case sensitivity yourself. Give it some thought--you may yet.
HFS+, on the other hand, allows you to specify the script system used for filenames, and uses it when if matches files. That means typing the name "Random" in the U.S. English script system will display as "Random" when localized to Japanese, and will match the file named "Random" typed in Romanji. With your method, they are three different files, two of which can't even by typed in the other script system.
Wow. HFS+ is even more broken than I thought it was. Allowing multiple different "script systems" in file names is just incredibly poor design. Even Windows is exorcising this demon.
There is software that assumes a filename is a unique identifier. Such software cannot be localized, breaks with external filesystems, and goes into infinite loops when it encounters symbolic links.
There may be such software, but it isn't the software we are talking about here.
What we are talking about here is the property that, given a directory entry, there is exactly one way of referring to it. If there are multiple ways, that greatly complicates some software. And if the set is open ended, as it seems to be on HFS+, a lot of things break in subtle ways; in particular, it has the potential of creating lots of security holes.
Well, it's pretty clear where our government's priorities are, and research into anything other than new weapons systems is pretty low on the list. But the government is falling all over itself to make available a few hundred billion (that's a "b") dollars for an ill-timed war with Iraq.
There is plenty of money. But it's not available for anybody other than big business and the military.
Slashdot Mirror
Yes, that's yet another instance where Cliff Stoll is wrong.
Changing a bunch of configuration settings in a GUI should not be something that's unrecoverable through normal, documented means.
If the system used triangulation, you would be right. But it doesn't. All that is required is that relative signal strengths are reasonably reproducible for each location and that you have enough measurements to distinguish all locations you are interested in. The system internally produces a map of which combinations of signal strengths correspond to which locations. To reduce the number of calibration points you need, you can try use interpolation between nearby measurements, which will usually work reasonably well/
TCP/IP has nothing at all to do with this, nor Zipf's law, nor any inverse square law, nor any kind of physical model. The system simply builds an empirical numerical model relating received power at the access points to location. As long as received power varies reproducibly with distance (not even necessarily monotonically) and you get enough independent measurements, that is possible.
Just use a slightly directional antenna--anything that relies on signal strength to triangulate you will end up being way off. If you set it up carefully, you can even choose your "virtual" location. And, no, the government can't really outlaw directional antennas.
Have a look at Evolution Robotics. They sell hardware that gives wheels to your laptop. It also comes with software, unfortunately Windows-based (they also have a Linux version but they don't ship that).
I'm saying that the way to deal with security problems is to fix the software in question, not to make the problem even more complex with yet another software layer.
simply because it would make it harder for you to write threat analysis reports?
Understanding threats isn't some tedious exercise in satisfying management, it's something you have to do in order to be able to write secure software.
Your guess as to who I spend most of my time fighting.
And that won't change until people who write software (1) make an effort to understand security and threats and (2) address security problems by fixing the root cause rather than adding even more complex softawre into the mix.
When I need a car to get me from point A to point B, a ham sandwich won't do. But among cars, I still prefer the ones that are safer.
Yes, they try, and they fail frequently, that's why we have buffer overflows in applications
And those buffer overflows won't go away through a complicated system of privileges. We need to get rid of the buffer overflows themselves, not make imperfect attempts to mask them.
If you are saying that all assumptions cause trouble, that's logically absurd. Or do you write your code assuming that assumptions cause trouble? Well, then you better stop right now making that assumption.
What it comes down to is that some assumptions lead to less security, other assumptions lead to more security. In particular, writing your program as if it were run as root--"assuming the worst case"--makes it more secure. On the other hand, writing your program assuming that something like systrace will protect the system even if your program has bugs will lead to less security overall. That's my point, and it seems that, except some confusion around the term "assumption", you actually agree with me.
First of all, your logic is invalid. If there exist cases in which the consequences of elevating specific privileges are easy to understand, that does not mean that the consequences of elevating specific privileges are easy to understand in most cases.
but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon
Even though you hand-picked SMTP as an example to illustrate your argument, it even breaks down there. If I can acquire this privilege set you think of as so restrictive, for example by compromising the SMTP daemon, all of a sudden, I can intercept any mail message and deliver it to myself. That is very likely enough to break into someone's account because either passwords or information useful for social engineering get sent through the mail system.
On the other hand, if the SMTP daemon runs as root, the threat analysis for a user of it is much simplified. If the SMTP daemon is already compromised and runs as root, it doesn't matter whether I send information through it that might give an attacker root privileges on this machine.
Most of your comment seems to consist of platitudes about simplicity,
Most of your comments are platitudes that show little actual experience in how systems are skillfully broken into. Beyond script kiddies exploring spectacularly gaping holes in poorly written C programs that just give them root shells, systems are compromised carefully and incrementally, exploring one subtle flaw after another.
In fact, even for OSes that start out with lots of different privileges, it's far from clear that it helps--programmers seem to have trouble understanding all the implications of all the different bits. For example, VMS, with its much-vaunted mess of security bits, ended up succumbing to a domino effect: you get one bit, then using that, the next one, then one more, until you can do whatever you want. The trouble is that when you tell a programmer that his code runs with "restore from backup privilege" (an example from a privilege happy OS of yore), they assume that's all they get and don't even consider all the other weird implications that that privilege may have. And who can blame them? Who can keep all the weird effects and interactions of dozens of different privileges in their head?
The simple UNIX privilege system is good: when programmers write code that runs as root, they know exactly what that code can do: everything. And they try to take appropriate care.
At around 200mph, easily achievable using current train systems if you got high speed rail all the way, you should be able to go from downtown San Francisco or LA to New York in 15 hours. That is actually not that different from air travel if you take into account all the overhead associated with air travel (security, parking, transportation to/from airport, etc.), and it's a whole lot more pleasant. With improved technology, perhaps one could even get that down by a few more hours. And trains don't fly into buildings either.
Well, or maybe not. Maybe the software came as an installable bundle, in which case you will still end up with lots of junk on your desktop but some wizard will also ask you bizarre questions, like "which of these drives do you want to install it on" when there is only one. Or maybe it's being updated through Apple's update system.
Software installation on the Mac is a mess. I have talked enough novice users through it to know.
Overall, you need standards like those for TCP/IP and ANSI C much more urgently for closed-source products.
Well, as I was saying: if you don't set up your servers properly, then journaling may be for you. The correct action on power failure is to shut down before the batteries run out.
If you run a flaky file server for a workgroup and users are breathing down your neck, then journaling may, of course, help you. But perhaps you should just upgrade to a collection of non-flaky file servers instead.
Journaling is most useful for desktops and laptops, which are at risk of being turned off or crashed frequently, and where you actually sit in front waiting for it.
Of course, the reason why those init scripts are there is for package management. It's hard to see how you can have decent package management with a monolithic init file.
That's because NTFS journaling sucks--it makes very few guarantees about the state of your file system after a crash.
NTFS supports [blah blah blah]
I think the fundamental problem that Microsoft and Microsoft users have is that they think more is better. It isn't. Software generally gets better as you figure out what features are not needed and remove them. Most of NTFS's features fall into that category.
It doesn't, really.
There are many nice things about OS X, and there are many not so nice things about it as well. Overall, there is no clear winner between OS X or Linux--it really depends on the application and the user. For many current Linux users, OS X simply is is not a workable alternative. For home users, however, OS X is an excellent choice, not because of any technical differences, but simply because it comes pre-packaged with its hardware and because lots of stores carry it.
And it's "only" a 10Mbyte download. However, I have to say, it does seem more responsive than Mozilla.
The US has refused to ratify the treaty on the international criminal court because of the completely hypothetical possibility that US citizens might be tried elsewhere. I don't believe the US is going to subject its citizens to any form of foreign jurisdiction if it can help it.
The consulate has much more time to check than 60 seconds. Visa application forms are sent in weeks in advance. Furthermore, when appearing in person, the consular official still took hours (!) to process the application (I think that procedure doesn't exist anymore in many places). The consular office has all the time it wants to check whatever it wants. If it only takes 60 seconds per applicant, that's not a problem with the applicant or the system, it's incompetence on the part of the consulate.
If you have been denied a visa, you may not be permitted to come to the US under the visa waiver program.
I'm sorry--I guessed you would be able to figure out the way in which hard links differ from case sensitivity yourself. Give it some thought--you may yet.
HFS+, on the other hand, allows you to specify the script system used for filenames, and uses it when if matches files. That means typing the name "Random" in the U.S. English script system will display as "Random" when localized to Japanese, and will match the file named "Random" typed in Romanji. With your method, they are three different files, two of which can't even by typed in the other script system.
Wow. HFS+ is even more broken than I thought it was. Allowing multiple different "script systems" in file names is just incredibly poor design. Even Windows is exorcising this demon.
There is software that assumes a filename is a unique identifier. Such software cannot be localized, breaks with external filesystems, and goes into infinite loops when it encounters symbolic links.
There may be such software, but it isn't the software we are talking about here.
What we are talking about here is the property that, given a directory entry, there is exactly one way of referring to it. If there are multiple ways, that greatly complicates some software. And if the set is open ended, as it seems to be on HFS+, a lot of things break in subtle ways; in particular, it has the potential of creating lots of security holes.
There is plenty of money. But it's not available for anybody other than big business and the military.