With all the hype surrounding Daikatana for years prior to its release, I don't understand how anyone could accuse it of being a game with bad advertising.
Guess what? noexec doesn't do jack shit on the majority of Linux systems, and does not prevent anybody from running a. You know why?/lib/ld-linux.so.2. (On x86_64, there's also/lib64/ld-linux-x86-64.so.2.)
This little file is in the ELF header of basically every single ELF-format Linux binary, under a field called INTERP (you can see this by dumping a binary with readelf). Yes, even though the executable is a binary, it calls an interpreter to handle all of the run-time module loading. By a really obnoxious design decision in Linux that laughs in the face of security, this library, despite its.so extension, is executable by design and by necessity on every single Linux system in the world. And by passing it the path to a program as its arguments, you can run any binary your little heart desires, whether the filesystem is mounted noexec or not. You can't possibly turn this behavior off unless you have a system with no dynamically linked binaries.
I don't see why this binary couldn't have added a check to see whether or not the program it's passed is mounted on a noexec filesystem, but to this day, it doesn't care.
It's also one of the reasons Solaris guys didn't take the idea of "Linux security" seriously for a very, very, very long time.
Not all is lost, though. SELinux can prevent the system from invoking this directly, outside the context of a freshly-executed process. It just relies on SELinux being properly set up on your systems.
This still doesn't completely fix the problem. On many (most?) systems, a user can still get around this by abusing LD_PRELOAD to preload a library with the same name and same symbols as one being loaded by some arbitrary program they're executing. Then, instead of compiling an executable binary, they're stuffing their code into a library instead and abusing the system's module loader to execute it. (This was the source of Oracle's SA10043 advisory, among others. It's the application's responsibility to validate LD_PRELOAD, especially where privilege escalation can occur.)
It's safest just to assume that if the user can run any arbitrary program the administrator put there, they can also run any arbitrary program the user put there.
In 1989, Westwood released a little-known game called "Battletech: The Crescent Hawk's Revenge." This game developed a lot of the ideas that would later be polished in Dune 2 and, in my opinion, deserves more credit for really kicking off the genre than Dune 2 does: Dune 2 really just took the same ideas and refined them into a more successful game.
And someone could much more easily put a knife to your throat, walk you to an ATM and ask you very politely to withdraw all your cash.
Of course it's not a perfect system. If there was a perfect system, everybody would be using it and nobody would be developing stuff like the SecurID. The point of these things is that they're:
Better than what we have now
Cost-effective to implement
If you don't think a window of opportunity of several minutes is preferable to a nearly unlimited window of opportunity, you've either got a severe ideological bias towards the nonexistent utopian solution, or you're a broken robot incapable of tears.
If this is true, and that hasn't been shown to be the case yet (and I certainly doubt that be the case for the majority of widgets, which are basically just prettying up XML web service calls), what's the difference between running a widget which may be malicious and any other program full of untrusted code that runs natively instead of through a widget scripting engine? What makes a bunch of images and Javascript on the desktop any worse than a C++ Qt/KDE application that does the same thing?
Can you explain to me, from an accomplished software engineer's perspective, what's so bad about modular components that can be reused in multiple applications?
The problem with Internet Explorer was never that it was coupled too deeply into the file manager and it was therefore buggy and insecure, and only someone with no clue whatsoever would tell you that. Internet Explorer is problematic because it has multiple zones with different security settings, and as history has shown, it's very, very easy to trick Internet Explorer into thinking that a script executing from the Internet zone is actually in the Local Computer zone, and thereby able to overwrite files, instantiate arbitrary ActiveX/COM components, and do all manners of naughty things that it shouldn't be able to.
While they've still got a long way to go, each successive release of KDE is substantially improved in terms of required CPU power and memory usage. KDE 3 ran a great deal faster than KDE 2 despite all sorts of added functionality, and KDE 3.4 RC1 is the fastest yet by a pretty big margin. The upcoming Qt 4 has a whole slew of performance improvements which should reduce requirements further.
While I appreciate your ability to plagiarize George Carlin's "Brain Droppings" almost word-for-word, this is not entirely founded in fact. Here's an article from The Straight Dope addressing this very issue:
What's the truth about the origin of the term "American Indian"? Schoolchildren have long been taught that Columbus thought he had reached the Indies, and therefore called the inhabitants "Indians." But lately I've been hearing the story that: (a) The Indies weren't even called the Indies at the time, but Hindustan; (b) Columbus didn't call the locals "Indians" but referred to them as "una geste in Dios", meaning "a people in God"; (c) somehow this caused people in Spain to start using the term "Indians"; and (d) Europeans then started using the geographical term "Indies" through back-formation. This explanation sounds like wishful thinking to me, with (c) and (d) particularly hard to swallow. Yet I've seen this stated as fact on some Indian Web sites, and it's doubtless being taught as fact in some schoolrooms. Is it possible to find the truth in this matter? --Steven Doyle, Atlanta, Georgia
SDSTAFF George replies:
The best way to determine the truth in cases like this, Steve, is to go to the source--in this case, Columbus's original letter, through which word of the new lands and their inhabitants was disseminated throughout Europe (see links below). In this letter Columbus repeatedly refers to India and Indians, and says nothing whatever about "a people in God."
First, let's get the supposed phrase right. The Spanish word for people is gente, not geste. Note that the supposed derivation requires Columbus to have made an error in spelling, since "in" in Spanish is en; the word in doesn't exist in the language. I'll have more to say on this point later.
Second, let's dispose of the notion that India was called something else at the time. The name, derived from the Indus River (from Sanskrit sindhu, "a river"), goes back to antiquity. Alexander the Great referred to the Indus (Indos), and to the region's inhabitants as Indikoi, as early as the third century B.C. The name passed from Greek into Latin and thence into other European languages, the earliest citation in English being in 893 A.D. by King Alfred the Great. At the time of Columbus's voyage, "India" or "the Indias/Indies" was often used to refer to all of south and east Asia. Columbus carried with him a passport from Ferdinand and Isabella of Spain, written in Latin and dispatching him "toward the regions of India" (ab partes Indie) on their behalf. Martin Beheim's globe of 1492, which predated the voyage, clearly labels the region as "Indie." "Hindustan," also derived from the Indus River, is a much later term, not appearing in English until 1665. In any case, in Spanish that name is not Hindustan but Indostan.
Third, let's look at what Columbus actually said. The admiral wrote a letter, in Spanish, detailing his discoveries while off the Azores during his homeward voyage. He forwarded this to the royal court, then at Barcelona, shortly after his storm-driven arrival in Lisbon on March 4, 1493. The original manuscript has not survived, but a printed copy made shortly after its receipt has. In the first paragraph Columbus says "In 33 days I passed from the Canary Islands to the Indies" (en 33 días pasé de las islas de Canaria a las Indias). His first reference to the inhabitants comes in the second paragraph: "To the first [island] which I found I gave the name San Salvador . . . the Indians call it Guanahaní" (A la primera que yo hallé puse nombre San Salvador . . . los Indios la llaman Guanahaní). In all he makes six references to India or the Indies, and four to Indios. Nowhere in the letter does he use a phrase resembling una gente in Dios. He says little of the spiritual beliefs of
I can't fathom why this idea even exists. All these USB devices show up as USB Mass Storage Devices, right? So why not just add a feature to the OS to allow USB Mass Storage Devices to be installed by administrators only, or not at all, that can be set via a Group Policy template? There's no problem here that requires a hardware solution.
Re:Once you beat the bottlenecks, it's very snappy
on
GNOME 2.8 Released
·
· Score: 1
Did you manage to somehow completely miss the next sentence or what?
Re:Once you beat the bottlenecks, it's very snappy
on
GNOME 2.8 Released
·
· Score: 1
No, it's really more of a clear example of hardware makers not testing or developing their hardware enough on Linux. Render acceleration on their drivers really should be both stable and enabled by default, like it is with pretty much every other video driver ever.
Once you beat the bottlenecks, it's very snappy.
on
GNOME 2.8 Released
·
· Score: 4, Informative
Right now, there are a two main reasons that GNOME feels so slow in comparison to lighter-weight desktop environments like IceWM and Fluxbox.
Many users on nVidia graphics cards install the proprietary nVidia drivers without setting
Option "RenderAccel" "true"
to enable Render acceleration, which greatly speeds up font rendering, alpha blending, and other tasks by offloading them to the graphics card; GTK+ depends upon this ability greatly. Additionally, the support for this is fairly flaky in nVidia's proprietary drivers and doesn't seem to work without working AGP and AGP Fast Writes. Try opening a large menu without and then with Render acceleration enabled. Go ahead.
Pango, the GTK+ font layout library, has much better Unicode support than Windows' GUI libraries. The downside to this is that it's not optimized for a Latin code path (yet), and the generic code path is somewhat slow. However, on a fast system (2 GHz+), you escape the bottleneck and GNOME is much snappier than Windows XP. I'm not saying "look, it's awesome on fast machines so it's really better and you should just upgrade," but it's important to note that GNOME currently has one single bottleneck killing its performance, and once that's optimized, it will be much better. It's not like the whole environment is much too weighty and slow.
Novell has expressed extreme interest in making Ximian Desktop the default desktop environment in their "unified desktop platform." Whether this will affect SuSE or become a separate Novell Linux distribution remains to be seen, but GNOME's hardly stagnant in this regard.
This isn't going to happen as long as educational curricula are based upon textbook teachings. As Diane Ravitch chronicled in her poignant bestseller The Language Police: How Pressure Groups Restrict What Students Learn, there are many lobby forces at work that keep textbook publishers from making sales to school districts if they don't fit the group's agenda. This includes references to multiculturalism from the left, and patriotic propaganda from the right, both of which are not only prevalent but pervasive in American education. There will be no end.
You're using an old version of GTK+. The issues you're talking about have been fixed for some time. Showing hidden files and folders is available via a right-click context menu, and type-ahead find eliminates the need for tab completion.
Looking to the open source community for applications that serve the same function as closed source solutions may cause vendors to be more flexible with pricing and licensing structures.
Basically, it boils down to "where applicable, use it as a bargaining chip for proprietary software instead," huh guys? Good thinking.
If all of Seagate's technology is protected by patents anyway, where's the problem? If he uses any of their super-secret hard drive technology, they can file patent infringement suits. That's what the patent system is for.
Slashdot Mirror
At 110 kilograms, how far will it fly when it gets T-boned by a Hummer?
With all the hype surrounding Daikatana for years prior to its release, I don't understand how anyone could accuse it of being a game with bad advertising.
Guess what? noexec doesn't do jack shit on the majority of Linux systems, and does not prevent anybody from running a. You know why? /lib/ld-linux.so.2. (On x86_64, there's also /lib64/ld-linux-x86-64.so.2.)
This little file is in the ELF header of basically every single ELF-format Linux binary, under a field called INTERP (you can see this by dumping a binary with readelf). Yes, even though the executable is a binary, it calls an interpreter to handle all of the run-time module loading. By a really obnoxious design decision in Linux that laughs in the face of security, this library, despite its .so extension, is executable by design and by necessity on every single Linux system in the world. And by passing it the path to a program as its arguments, you can run any binary your little heart desires, whether the filesystem is mounted noexec or not. You can't possibly turn this behavior off unless you have a system with no dynamically linked binaries.
I don't see why this binary couldn't have added a check to see whether or not the program it's passed is mounted on a noexec filesystem, but to this day, it doesn't care.
It's also one of the reasons Solaris guys didn't take the idea of "Linux security" seriously for a very, very, very long time.
Not all is lost, though. SELinux can prevent the system from invoking this directly, outside the context of a freshly-executed process. It just relies on SELinux being properly set up on your systems.
This still doesn't completely fix the problem. On many (most?) systems, a user can still get around this by abusing LD_PRELOAD to preload a library with the same name and same symbols as one being loaded by some arbitrary program they're executing. Then, instead of compiling an executable binary, they're stuffing their code into a library instead and abusing the system's module loader to execute it. (This was the source of Oracle's SA10043 advisory, among others. It's the application's responsibility to validate LD_PRELOAD, especially where privilege escalation can occur.)
It's safest just to assume that if the user can run any arbitrary program the administrator put there, they can also run any arbitrary program the user put there.
It's basically a customization of Red Hat Enterprise Linux.
In 1989, Westwood released a little-known game called "Battletech: The Crescent Hawk's Revenge." This game developed a lot of the ideas that would later be polished in Dune 2 and, in my opinion, deserves more credit for really kicking off the genre than Dune 2 does: Dune 2 really just took the same ideas and refined them into a more successful game.
http://en.wikipedia.org/wiki/BattleTech:_The_Crescent_Hawk's_Revenge
Of course it's not a perfect system. If there was a perfect system, everybody would be using it and nobody would be developing stuff like the SecurID. The point of these things is that they're:
If you don't think a window of opportunity of several minutes is preferable to a nearly unlimited window of opportunity, you've either got a severe ideological bias towards the nonexistent utopian solution, or you're a broken robot incapable of tears.
If this is true, and that hasn't been shown to be the case yet (and I certainly doubt that be the case for the majority of widgets, which are basically just prettying up XML web service calls), what's the difference between running a widget which may be malicious and any other program full of untrusted code that runs natively instead of through a widget scripting engine? What makes a bunch of images and Javascript on the desktop any worse than a C++ Qt/KDE application that does the same thing?
Can you explain to me, from an accomplished software engineer's perspective, what's so bad about modular components that can be reused in multiple applications?
The problem with Internet Explorer was never that it was coupled too deeply into the file manager and it was therefore buggy and insecure, and only someone with no clue whatsoever would tell you that. Internet Explorer is problematic because it has multiple zones with different security settings, and as history has shown, it's very, very easy to trick Internet Explorer into thinking that a script executing from the Internet zone is actually in the Local Computer zone, and thereby able to overwrite files, instantiate arbitrary ActiveX/COM components, and do all manners of naughty things that it shouldn't be able to.
This is true, of course, but it does not in any way change the fact that KDE is steadily improving performance-wise regardless.
While they've still got a long way to go, each successive release of KDE is substantially improved in terms of required CPU power and memory usage. KDE 3 ran a great deal faster than KDE 2 despite all sorts of added functionality, and KDE 3.4 RC1 is the fastest yet by a pretty big margin. The upcoming Qt 4 has a whole slew of performance improvements which should reduce requirements further.
http://www.straightdope.com/mailbag/mgenteindios.h tml
Shotguns cannot be used in war. Sorry.
I can't fathom why this idea even exists. All these USB devices show up as USB Mass Storage Devices, right? So why not just add a feature to the OS to allow USB Mass Storage Devices to be installed by administrators only, or not at all, that can be set via a Group Policy template? There's no problem here that requires a hardware solution.
Did you manage to somehow completely miss the next sentence or what?
No, it's really more of a clear example of hardware makers not testing or developing their hardware enough on Linux. Render acceleration on their drivers really should be both stable and enabled by default, like it is with pretty much every other video driver ever.
Novell has expressed extreme interest in making Ximian Desktop the default desktop environment in their "unified desktop platform." Whether this will affect SuSE or become a separate Novell Linux distribution remains to be seen, but GNOME's hardly stagnant in this regard.
This isn't going to happen as long as educational curricula are based upon textbook teachings. As Diane Ravitch chronicled in her poignant bestseller The Language Police: How Pressure Groups Restrict What Students Learn, there are many lobby forces at work that keep textbook publishers from making sales to school districts if they don't fit the group's agenda. This includes references to multiculturalism from the left, and patriotic propaganda from the right, both of which are not only prevalent but pervasive in American education. There will be no end.
Yeah, seriously, compared to ClearType on Windows it's really terrible. :rolleyes:
You're using an old version of GTK+. The issues you're talking about have been fixed for some time. Showing hidden files and folders is available via a right-click context menu, and type-ahead find eliminates the need for tab completion.
Oh, the "Linux IA32" page in nVidia's download area where you download a distribution-agnostic .run script must be mislabeled then.
Basically, it boils down to "where applicable, use it as a bargaining chip for proprietary software instead," huh guys? Good thinking.
If all of Seagate's technology is protected by patents anyway, where's the problem? If he uses any of their super-secret hard drive technology, they can file patent infringement suits. That's what the patent system is for.