All of those things related to accessing the user's files can be accomplished by running those programs as separate user -- this is why modern systems automatically update X cookies when the user successfully authenticates with su. This is a sufficiently isolated sandbox to run untrusted things.
With the network I don't think, there is anything that should be done except disallowing some users to use the network (or talk to anything other than a predefined list of hosts) _before_ some programs will be run under their userids. And netfilter already can do this.
Things like ZoneAlarm are in most of the situation a kind of a cure that is far worse than a disease that it is supposed to cure. There are many programs that have absolutely legitimate reasons to talk to the network, and most of them are not interactive. I don't think, a user will be happy to see hundreds of "fetchmail called from cron called from init is trying to ACCESS THE INTERNET -- allow (Y/N)?" when he wakes up after scheduling mail download every ten minutes and leaving it running for the night. Games, browser plugins, etc. mostly are designed to talk over the network, so just allowing/denying them something would be pointless. And, of course, package management should not be mixed with this -- if the user runs something that modifies executables that he runs, he has a larger problem on his hands than some unrecognized network connection.
What user should do is to avoid installing untrusted things in a way that they can access something that he does not want to be accessed by others. File permissions and users exist for a reason, and network connections from unprivileged ports and without authentication are not supposed to be trusted within the network in the first place.
One can justify tools that restrict network connections/packets made by certain "unprivileged" users (and that is already supported by netfilter), and make wrappers that run some applications as different users, in chroot, etc. , but those things should be configured once at the time of installation, and should not require manual intervention just to pass a packet. There is absolutely no reason to imitate the behavior of consumer-grade software, made to mitigate the existing abysmal security design of systems where such things are used.
It's not as much the problem that there are a lot of insecure desktops as that those insecure boxes are trusted just because they are behind some firewall. If the trusted boxes are known to be insecure, the sysadmin has two choices -- replace them with something more secure, or make them untrusted. Trying to secure a Windows box running Outlook and with the user that can install software and doesn't know spyware or trojan from a legitimate software is a waste of time, and trying to mitigate the consequences of such a box being compromised is much more difficult than either replacing it (face it, Solitaire is not a work-related application, and users have no business exchanging Word documents with embedded macros), or establishing a draconian policy of what users should install. Regardless of this, there is absolutely no excuse for treating every Joe Schmoe desk jokey's box as trusted -- they potentially can be just as hostile as any other boxes at the other side of the firewall. There are plenty of ways to restrict access within the company's LAN and use reasonable access/password/encryption policies. Then firewall will become what it is really good for -- a tool used to prevent the waste of address space, and to provide an additional layer of security that in no way should be treated as absolute or reliable.
Also the sysadmin should not try to prevent users from INTENTIONALLY installing backdoors, compromising their own boxes or sending company's information outside -- when that happens he is guaranteed to lose because the only way to stop that is by never letting the employees to leave their offices until the rest of their lives. As long as some packets are allowed to leave the network, they can be used for backdoors. If the company pulls the plug on its border router, same user will use his memory and scraps of paper as a "compromise mechanism", and both of those things are not supposed to be the responsibility of the sysadmin in the first place.
Instead of playing cat and mouse games with users sysadmin should spend the same time developing and implementing a reasonable security policy, or at least installing patches for known vulnerabilities. And CEO should think more about how to stop antagonizing employees to the extent that they sabotage their computers, intentionally install backdoors and send confidential information outside rather than how to waste few more tens of thousands on yet another firewall "solution".
1. What firewall software pretends to do (as opposed to what it actually accomplishes).
2. How to become a perfect target of DoS attack through paranoia (imitation of any intrusion-like activity will make the supposed origin unable to access you).
3. How to defend yourself when you have already lost, and are for all practical purposes as good as dead.
Trolleys didn't go out of business because of the Interstates. This is not hard to figure out. Look at the closure dates for various trolleys.
Of course, trolleys couldn't compete -- no one improved/replaced them with better public transit, lagging behind pretty much every other industrialized country in the world in the area of public transportation. Say, NY subway, being a more or less usable system, remained without any trouble.
The point is, public transportation needed _improvement_, and only federal government was able to do it -- at the sorry state that it was, and even worse that it became soon after that, it barely performed its basic functions, and couldn't compete with anything at all except for the poorest of the consumers. Instead money were spent only on competing with it, at the cost to the public, so public had to pay twice -- first for the infrastructure (highways), then for transportation costs increase (cars, fuel, insurance, garages and/or repairs). Good job, federal pork-handlers.
Any ideas who might be the happy hacker that led the Wachowski brothers in the right path?
Most likely some guy from their special effects company -- they have more than enough programmers there, and considering that they used mostly FreeBSD for the first movie, it's likely that a lot of Unix programmers worked on this one, too. It's even possible that directors just asked for a realistic-looking screen with some exploit, and whoever made it, chosen nmap and then-just-published ssh bug.
1. Americans love to be able to go anywhere easily on vacation. With America's highly-efficient road system most of the USA is well within reach of 4-5 day's drive.
Yet for some reason people always choose planes. If there were trains in US (as opposed to the $DEITY-awful single line across the country operated by Amtrak), people would use them, too.
2. Truckers love it because it allows a massive amount of goods to be shipped anywhere in a matter of days. Why do you think Wal-Mart maintains such a huge fleet of trucks?
Because if there were freight trains in US, truckers would have to do something else, likely not as profitable. And Wal-Mart certainly would use trains because it always chooses the cheapest option.
3. The USA is a very large country for the Lower 48 states, with considerable distances between population centers especially west of the Mississippi River. Small wonder why road systems developed so rapidly, because they often went places beyond the reach of the railroads.
Horrendous waste of space is nothing to be proud of, however the the world with the exception of the ocean floor, US and Antarctica is covered by a dense network of railroads made precisely for the purpose of cheap and fast transportation between cities. In US, likely not without some participation from the car and oil industries, government built a huge highway system, yet did nothing to help the railroads, leaving them in the private hands.
People voluntarily switched to automobiles because (and this is the important part) they saved people time.
People "voluntarily" switched to automobiles after the federal government, without asking anyone (it was then too busy looking for communists among the citizens with any inclinations toward liberal views), thrown enormous amounts of money (taxes + national debt) into the highway system, yet made no public transit infrastructure to go along with it. Public transit remained mostly in the cities' and hands. I would like to see how people would "voluntarily" use cars if highways were toll roads, or had to be funded by local governments.
With stacks of cheap coldswap enclosed, Ghosted Windows image hard drives available, you can run a pretty large Customer Care system with excellent uptime. When someone has a software problem, you go to their computer, cold swap the drive, and when it comes up it just works. You can figure out what virus they got, or what other crap they did to it later. The fact that Linux Netboots are cheaper/better/cooler doen't make it the only solution.
I have no idea how any of the things that you have mentioned are relevant to what I am responding to.
You have already mentioned that a solution that works with Linux exists, and is cheaper. You have mentioned that the "problems" with Linux version are caused by the lack of the support people's skills or experience with it.
Now you are bringing all kinds of "religious" arguments, and giving an imaginary solution to the imaginary problem that is absolutely unrelated to the one (maybe imaginary one, too, maybe not) you have described in the previous message -- it's obvious that if the users can be satisfied with replacement of their drives every time they have problems, they don't need a support person at all, leave alone ten of them.
The fact that your previous hiring needs were based solely on a strong Windows skill set doesn't mean your people are incompetent, any more than hiring mono-lingual people implies that they are all stupid.
"Strong Windows skills" is the same as "strong burger-flipping skills". Especially if the "just replace the hard drive with ghosted image" solution works. What usually does not because people have data, and if all data and settings are on the network, server is likely to be the first victim of any problem, so you need 1-2 skilled (and therefore not windows-only) sysadmins anyway.
So, it would seem to me, the idea that "the" solution is to go on a firing spree to get rid of eight formerly valuable employees because of your personal affinity for the FOSS solutions base, won't win you any awards for good management.
I merely mean that if you base your arguments entirely on your sad accident of having a single person that can handle a solution other than what you have, you have no idea what are you talking about in the first place. You have described a problem, and I have given a solution that saves you installation and maintenance costs that you have described. If you are going to pile up more conditions that suit you, you certainly do not help your credibility. If you replace more people with less, more expensive solution with cheaper and at least as usable (and likely more reliable) one, it would be definitely an example of good management. Clinging to assets that are worth more to maintain than to replace, only because they are percieved as "valuable" is a common mistake.
Good manager does not assume that if his particular choice of employees ended up with a single support person capable of administering Linux, he has anything to say about Linux. In this particular situation the solution is to fire 9 Windows-only support people and hire 1-2 better ones that can support multiple systems (and pay them better, too). Instant improvement.
So basically it was an early version...
on
Nuke-Lobbing
·
· Score: 1
...that supports alternative interfaces in some consistent manner, but puh-leeze, don't pretend that this is the same as accessing _existing_ application. Everything that can fit into a simple user interface can run on a PDA already, and almost everything that is worth being accessed remotely has some piece of interface (CAD, for example) that definitely does not translate well, and user will still have to use the original interface (and then there is X, VNC, etc.)
XML is just a way to design data formats that are supposed to have data (and metadata) represented in a structured way. What that data may represent, how convoluted it is and what insane algorithms it can require to be parsed and used is still entirely the decision made for the developer.
XML _can_ produce readable formats however it has no facilities to ensure that XML-based formats will be readable -- just the opposite, XML itself is an example of a hopelessly over-complicated (though at least deterministic and documented) system made for a trivial purpose. The possibilities of using it as a wrapper for incredible amounts of convolutedness are endless.
(this is a copy of my comment that I have left for the article)
The recent security holes in Unis softare have ABSOLUTELY NOTHING TO DO WITH LOW-LEVEL LANGUAGES and everything with design bugs. Also the idea that languages must keep newbies from doing specific mistakes (in this case security bugs due to buffer overflows) is a load of complete and undiluted bullshit. If they won't make common mistakes, they will make uncommon ones. If it won't be a buffer overflow, it will be passing tainted data. If it won't be memory leak, it will be object leak. And in any case there will be some plain bad design.
The truth is, bad programmers write bad code no matter what, and newbies make mistakes no matter how the language creators, in their arrogance, tried to keep those newbies from doing this. The solution is to keep programmers that write bad code from programming, not to try to find a magic pixie dust that makes bad coder equal to a professional.
Zip has an index at the end of the file, so to extract anything one has to get the whole file first. This is good as a foolproofing measure to prevent people from extracting half-downloaded files over existing installations of some sotware and getting an unusable setup, but it's absolutely pointless for anything else.
OTOH, tar (gzipped or not) has no index, and files can be extracted as they are being downloaded.
...so you have to tell BIOS not to try to boot from the network. Why did it rewrite something, I have no idea, probably you had a server on your network that PXE found.
Solution: Add to the resume whatever a person thinks, he can learn. This will be many orders of magnitude less of a bullshit than keyword-scanning systems.
Everyone already uses libraries versioning that perfectly fits into existing filesystem and linking procedures, and only mental giants at Microsoft can't use such a simple solution and have to create an additional layer of hideous mess to accomplish the same thing.
gcc C++ implementation was limited, however exactly in ways that have no effect on a GUI toolkit. C was chosen to make the object-oriented nature of the GUI accessible to programs not written in an OO language. It makes sense because with Qt (and MFC) many programs that do not benefit from C++ had to use that language just to accommodate GUI.
Before GTK was released one could argue that this approach causes huge amount of convolitedness citing Motif as an example, however now we know that it has nothing to do with C and everything with Motif and Xt being giant messy pieces of code.
Slashdot Mirror
All of those things related to accessing the user's files can be accomplished by running those programs as separate user -- this is why modern systems automatically update X cookies when the user successfully authenticates with su. This is a sufficiently isolated sandbox to run untrusted things.
With the network I don't think, there is anything that should be done except disallowing some users to use the network (or talk to anything other than a predefined list of hosts) _before_ some programs will be run under their userids. And netfilter already can do this.
Things like ZoneAlarm are in most of the situation a kind of a cure that is far worse than a disease that it is supposed to cure. There are many programs that have absolutely legitimate reasons to talk to the network, and most of them are not interactive. I don't think, a user will be happy to see hundreds of "fetchmail called from cron called from init is trying to ACCESS THE INTERNET -- allow (Y/N)?" when he wakes up after scheduling mail download every ten minutes and leaving it running for the night. Games, browser plugins, etc. mostly are designed to talk over the network, so just allowing/denying them something would be pointless. And, of course, package management should not be mixed with this -- if the user runs something that modifies executables that he runs, he has a larger problem on his hands than some unrecognized network connection.
What user should do is to avoid installing untrusted things in a way that they can access something that he does not want to be accessed by others. File permissions and users exist for a reason, and network connections from unprivileged ports and without authentication are not supposed to be trusted within the network in the first place.
One can justify tools that restrict network connections/packets made by certain "unprivileged" users (and that is already supported by netfilter), and make wrappers that run some applications as different users, in chroot, etc. , but those things should be configured once at the time of installation, and should not require manual intervention just to pass a packet. There is absolutely no reason to imitate the behavior of consumer-grade software, made to mitigate the existing abysmal security design of systems where such things are used.
It's not as much the problem that there are a lot of insecure desktops as that those insecure boxes are trusted just because they are behind some firewall. If the trusted boxes are known to be insecure, the sysadmin has two choices -- replace them with something more secure, or make them untrusted. Trying to secure a Windows box running Outlook and with the user that can install software and doesn't know spyware or trojan from a legitimate software is a waste of time, and trying to mitigate the consequences of such a box being compromised is much more difficult than either replacing it (face it, Solitaire is not a work-related application, and users have no business exchanging Word documents with embedded macros), or establishing a draconian policy of what users should install. Regardless of this, there is absolutely no excuse for treating every Joe Schmoe desk jokey's box as trusted -- they potentially can be just as hostile as any other boxes at the other side of the firewall. There are plenty of ways to restrict access within the company's LAN and use reasonable access/password/encryption policies. Then firewall will become what it is really good for -- a tool used to prevent the waste of address space, and to provide an additional layer of security that in no way should be treated as absolute or reliable.
Also the sysadmin should not try to prevent users from INTENTIONALLY installing backdoors, compromising their own boxes or sending company's information outside -- when that happens he is guaranteed to lose because the only way to stop that is by never letting the employees to leave their offices until the rest of their lives. As long as some packets are allowed to leave the network, they can be used for backdoors. If the company pulls the plug on its border router, same user will use his memory and scraps of paper as a "compromise mechanism", and both of those things are not supposed to be the responsibility of the sysadmin in the first place.
Instead of playing cat and mouse games with users sysadmin should spend the same time developing and implementing a reasonable security policy, or at least installing patches for known vulnerabilities. And CEO should think more about how to stop antagonizing employees to the extent that they sabotage their computers, intentionally install backdoors and send confidential information outside rather than how to waste few more tens of thousands on yet another firewall "solution".
It will appear when the first spyware will be written for Linux. And will be used by people who install software that they can not trust.
Right now even the worst spyware offenders have clean Unix/Linux versions/equivalents, so it's pointless.
1. What firewall software pretends to do (as opposed to what it actually accomplishes).
2. How to become a perfect target of DoS attack through paranoia (imitation of any intrusion-like activity will make the supposed origin unable to access you).
3. How to defend yourself when you have already lost, and are for all practical purposes as good as dead.
Get it right, bani -- djb is the unit of assholeness.
Trolleys didn't go out of business because of the Interstates. This is not hard to figure out. Look at the closure dates for various trolleys.
Of course, trolleys couldn't compete -- no one improved/replaced them with better public transit, lagging behind pretty much every other industrialized country in the world in the area of public transportation. Say, NY subway, being a more or less usable system, remained without any trouble.
The point is, public transportation needed _improvement_, and only federal government was able to do it -- at the sorry state that it was, and even worse that it became soon after that, it barely performed its basic functions, and couldn't compete with anything at all except for the poorest of the consumers. Instead money were spent only on competing with it, at the cost to the public, so public had to pay twice -- first for the infrastructure (highways), then for transportation costs increase (cars, fuel, insurance, garages and/or repairs). Good job, federal pork-handlers.
Any ideas who might be the happy hacker that led the Wachowski brothers in the right path?
Most likely some guy from their special effects company -- they have more than enough programmers there, and considering that they used mostly FreeBSD for the first movie, it's likely that a lot of Unix programmers worked on this one, too. It's even possible that directors just asked for a realistic-looking screen with some exploit, and whoever made it, chosen nmap and then-just-published ssh bug.
1. Americans love to be able to go anywhere easily on vacation. With America's highly-efficient road system most of the USA is well within reach of 4-5 day's drive.
Yet for some reason people always choose planes. If there were trains in US (as opposed to the $DEITY-awful single line across the country operated by Amtrak), people would use them, too.
2. Truckers love it because it allows a massive amount of goods to be shipped anywhere in a matter of days. Why do you think Wal-Mart maintains such a huge fleet of trucks?
Because if there were freight trains in US, truckers would have to do something else, likely not as profitable. And Wal-Mart certainly would use trains because it always chooses the cheapest option.
3. The USA is a very large country for the Lower 48 states, with considerable distances between population centers especially west of the Mississippi River. Small wonder why road systems developed so rapidly, because they often went places beyond the reach of the railroads.
Horrendous waste of space is nothing to be proud of, however the the world with the exception of the ocean floor, US and Antarctica is covered by a dense network of railroads made precisely for the purpose of cheap and fast transportation between cities. In US, likely not without some participation from the car and oil industries, government built a huge highway system, yet did nothing to help the railroads, leaving them in the private hands.
People voluntarily switched to automobiles because (and this is the important part) they saved people time.
People "voluntarily" switched to automobiles after the federal government, without asking anyone (it was then too busy looking for communists among the citizens with any inclinations toward liberal views), thrown enormous amounts of money (taxes + national debt) into the highway system, yet made no public transit infrastructure to go along with it. Public transit remained mostly in the cities' and hands. I would like to see how people would "voluntarily" use cars if highways were toll roads, or had to be funded by local governments.
With stacks of cheap coldswap enclosed, Ghosted Windows image hard drives available, you can run a pretty large Customer Care system with excellent uptime. When someone has a software problem, you go to their computer, cold swap the drive, and when it comes up it just works. You can figure out what virus they got, or what other crap they did to it later. The fact that Linux Netboots are cheaper/better/cooler doen't make it the only solution.
I have no idea how any of the things that you have mentioned are relevant to what I am responding to.
You have already mentioned that a solution that works with Linux exists, and is cheaper. You have mentioned that the "problems" with Linux version are caused by the lack of the support people's skills or experience with it.
Now you are bringing all kinds of "religious" arguments, and giving an imaginary solution to the imaginary problem that is absolutely unrelated to the one (maybe imaginary one, too, maybe not) you have described in the previous message -- it's obvious that if the users can be satisfied with replacement of their drives every time they have problems, they don't need a support person at all, leave alone ten of them.
The fact that your previous hiring needs were based solely on a strong Windows skill set doesn't mean your people are incompetent, any more than hiring mono-lingual people implies that they are all stupid.
"Strong Windows skills" is the same as "strong burger-flipping skills". Especially if the "just replace the hard drive with ghosted image" solution works. What usually does not because people have data, and if all data and settings are on the network, server is likely to be the first victim of any problem, so you need 1-2 skilled (and therefore not windows-only) sysadmins anyway.
So, it would seem to me, the idea that "the" solution is to go on a firing spree to get rid of eight formerly valuable employees because of your personal affinity for the FOSS solutions base, won't win you any awards for good management.
I merely mean that if you base your arguments entirely on your sad accident of having a single person that can handle a solution other than what you have, you have no idea what are you talking about in the first place. You have described a problem, and I have given a solution that saves you installation and maintenance costs that you have described. If you are going to pile up more conditions that suit you, you certainly do not help your credibility. If you replace more people with less, more expensive solution with cheaper and at least as usable (and likely more reliable) one, it would be definitely an example of good management. Clinging to assets that are worth more to maintain than to replace, only because they are percieved as "valuable" is a common mistake.
Good manager does not assume that if his particular choice of employees ended up with a single support person capable of administering Linux, he has anything to say about Linux. In this particular situation the solution is to fire 9 Windows-only support people and hire 1-2 better ones that can support multiple systems (and pay them better, too). Instant improvement.
of a cruise missile minus navigation, plus pilot.
...that supports alternative interfaces in some consistent manner, but puh-leeze, don't pretend that this is the same as accessing _existing_ application. Everything that can fit into a simple user interface can run on a PDA already, and almost everything that is worth being accessed remotely has some piece of interface (CAD, for example) that definitely does not translate well, and user will still have to use the original interface (and then there is X, VNC, etc.)
Didn't you read the documentation? You are supposed to charge it before the first use. And don't you know what the second slot on Zaurus is for?
XML is just a way to design data formats that are supposed to have data (and metadata) represented in a structured way. What that data may represent, how convoluted it is and what insane algorithms it can require to be parsed and used is still entirely the decision made for the developer.
XML _can_ produce readable formats however it has no facilities to ensure that XML-based formats will be readable -- just the opposite, XML itself is an example of a hopelessly over-complicated (though at least deterministic and documented) system made for a trivial purpose. The possibilities of using it as a wrapper for incredible amounts of convolutedness are endless.
First rule of DoS-resistant network security: system must not change any of its behavior when attacks are present.
Including logging.
What means, never try to log the intrusion attempts, leave alone portscans, every connection, etc. unless for the purpose of studying them.
(this is a copy of my comment that I have left for the article)
The recent security holes in Unis softare have ABSOLUTELY NOTHING TO DO
WITH LOW-LEVEL LANGUAGES and everything with design bugs. Also the idea
that languages must keep newbies from doing specific mistakes (in this
case security bugs due to buffer overflows) is a load of complete and
undiluted bullshit. If they won't make common mistakes, they will make
uncommon ones. If it won't be a buffer overflow, it will be passing
tainted data. If it won't be memory leak, it will be object leak. And in
any case there will be some plain bad design.
The truth is, bad programmers write bad code no matter what, and newbies
make mistakes no matter how the language creators, in their arrogance,
tried to keep those newbies from doing this. The solution is to keep
programmers that write bad code from programming, not to try to find a
magic pixie dust that makes bad coder equal to a professional.
Zip has an index at the end of the file, so to extract anything one has to get the whole file first. This is good as a foolproofing measure to prevent people from extracting half-downloaded files over existing installations of some sotware and getting an unusable setup, but it's absolutely pointless for anything else.
OTOH, tar (gzipped or not) has no index, and files can be extracted as they are being downloaded.
...so you have to tell BIOS not to try to boot from the network. Why did it rewrite something, I have no idea, probably you had a server on your network that PXE found.
Solution: Add to the resume whatever a person thinks, he can learn. This will be many orders of magnitude less of a bullshit than keyword-scanning systems.
And imagine what kind of work environment is at the places that hire people this way.
Everyone already uses libraries versioning that perfectly fits into existing filesystem and linking procedures, and only mental giants at Microsoft can't use such a simple solution and have to create an additional layer of hideous mess to accomplish the same thing.
Bravo!
gcc C++ implementation was limited, however exactly in ways that have no effect on a GUI toolkit. C was chosen to make the object-oriented nature of the GUI accessible to programs not written in an OO language. It makes sense because with Qt (and MFC) many programs that do not benefit from C++ had to use that language just to accommodate GUI.
Before GTK was released one could argue that this approach causes huge amount of convolitedness citing Motif as an example, however now we know that it has nothing to do with C and everything with Motif and Xt being giant messy pieces of code.
Nadesico doesn't take itself seriously enough to be considered "giant robot series," methinks.
It takes itself so non-serious that it has a GIANT ROBOT ANIME AS AN IMPORTANT PART OF THE PLOT!