Putting security services in VMs has been done for years.
The particular service we're providing, ReVirt, is new to Virtual Machines (as far as we know). We don't log normal "security" information, like login attemps, etc. We log just enough information to be able to roll the virtual machine back to a previous state, and make it execute exactly the same way.
One of the (many) problems with security logs is that you frequently don't know everything that you really need to log until after the fact. With our system, you can go back and find out anything you want to know, because you have a live VM doing exactly what it did during the attack.
BTW, the technique we're using for ReVirt was described back in the late 80's, and implemented in the mid 90's for debugging purposes; we're the first ones, as far as we know, to put it in a (somewhat) general-purpose virtual machine, like UMLinux.
Did you restore a copy at some point (i.e., a checkpoint), or did you log all the input going into it, so that you could replay it, and generate exactly the same execution, race conditions and all?
If you have a reference, I'm sure the covirt group would appreciate it, so we can learn from it / acknowledge prior work more completely. =)
-George Dunlap (main ReVirt author)
Here's the problem we're trying to address. Say someone breaks into your system. At some time later you notice something strange, follow it up, and find that you've been hacked. You don't know:
How they broke in (what the exploit was)
When they broke in
What they saw (if they d/l'd any sensitive data: credit cards, company information, whatever), or
What they changed (if they installed any backdoors, trojaned binaries, etc).
Current techniques require a lot of time, a lot of expertise, a lot of Sherlock-holmes style educted guessing, and in the end you may just not know the answer. Apply some patches, restore from backup, hope you fixed the hole and didn't miss any trojans.
With our system, you will be able to go back and find out all of these things with complete confidence and accuracy (once we have the proper analysis tools in place, that is).
We'd gladly use VMWare, if they'd just GPL the source code. =)
Unfortunately, since that's not likely to happen, Plex86 isn't in good shape, and we didn't want to write our own full-fleged VM, we used UMLinux for a prototype and proof-of-concept that the ReVirt idea could work. Maybe someday VMWare or someone else will pick it up.
BTB, we do use UMLinux (now FAUmachine, I think), but we're looking into porting it to Jeff Dike's User-Mode-Linux soon.
I'm George Dunlap, the main author on the ReVirt paper. So, IIAP/R (programmer/researcher). =)
There is no way to know if there is a bug in the VM, just as there's no way to know if there's a bug in the operatin gsystem. BUT, the virtual machine montitor, which controls the VM, is a *lot* smaller piece of software than a kernel, with a much simpler interface to provide. Therefore, the hope is that there's less of a chance of an exploitable bug in the VM, than in an operating system.
You know, Eric Raymond's brief about the whole SCO thing says that there are quite a number of engineers who have access to the original Bell Labs UNIX source. Couldn't someone with access to the source do an independent analysis to see what kinds of things turn up, and try to find out where the sources look similar?
At any rate, it's clear that they don't have any actual good-faith desire to help people stop re-distributing "their" IP. If they really cared, they would have e-mailed Linus saying, "We have reason to believe the following lines of code have been added to the kernel in violation of our license with IBM" and listed them, so he could take them out and stop distribution.
SCO Sending a letter to a company saying "Linux violates our IP rights, you should stop using it" would be like Virgin Records sending a letter to a bunch of record stores saying, "EMI is distributing songs containing illegal samples of Virgin Records' songs. You should stop distributing any EMI record labels, or you could be liable" -- without saying exactly which CDs or tracks, and without contacting EMI with the specifics either.
(I just pulled these names out of a hat, so don't tell me Virgin is owned by EMI or anything crazy like that. *grin* )
Even the language I use to post this reply is a standard.
So you're speaking Esperonto, an artificial language designed by a committe? Maybe Loglan?
No, you seem to be speaking English.
OK, so which standards orginization do you adhere to? None? Because there is no standards organization, it evolves and adapts as people use it?
If you'll notice the header, the guy doesn't say standards are stifling innovation, just that standards orginizations, in particular those that try to create a standard from scratch (rather than describing what's already there), are stifling innovation.
First, it's not "geeky". Tons of "normal" guys are into tinkering with cars, and taking about engine mods and stuff, which makes it less of an esoteric thing.
Two, you probably have a car that's somewhat complicated, and worth something to you. I did lots of repairs on my first car, an old beat-up Renault, because (a) it was simple, and (b) it wasn't worth paying anyone else to do it; the whole car couldn't've been worth more than $100.
When I got another car, a Nissan Altima, the engine is just a lot harder to look at and say, "Oh, I just need to do this." You need better tools, more skills, and if you screw something up, it costs you a lot more. Better just let the professionals handle it. If you screw up your car, you have to find another ride; if you screw up your brew-making, just go buy some beer at the store.
Well, no... see, the additional code company X wrote is still copyrighted by company X. Just because they broke copyright law by illegally distributing copyrighted code (or copylefted, if you prefer) written by someone else without their permission, doesn't give you the right to break the law by illegally distributing company X's code without their permission.
The only way for company X to legally distribute the whole shebang is to (a) put their code under the GPL, thus gaining permission from the original authors, or (b) contacting each of the original authors of the code individual and asking their permission to distribute it (assuming they still own the copyright).
Since the remote computer is initiating everything, and all they're doing is answering requests, it would be pretty hard to charge them with unauthorized use of your machine.
Think of it this way:
1. The remote computer goes: "What do I do?"
2. The server goes: "Well, since you're asking, I think you should do this."
OK then, what about all those exploits in web pages -- URLs, malformed html, etc? If you put a poison html page that you *know* is going to cause a certain version of IE or Mozilla viewing it to do something the user never intended, do you really think you can hide behind the "All I was doing was answering requests!" defense?
Or what if you managed to get Microsoft's private key for WindowsUpdate, and intercepted people's requests for updates, giving them "updates" that allow you to 0wnz0r their machines. Hey, you didn't install it, you just answered requests! Yeah, see if a jury buys that one.
This is a clever technical solution to the problem; however, it's very dangerous -- they haven't tested this update on a wide variety of systems, and it may cause a lot of damage and data loss. It's not their place to make that kind of a decision.
A legal solution would be to look what IP is connecting to this URL, put it on a temporary blackout list, and contact the ISP or company responsible for that IP and advise them to take action.
Baloney. A man is allowed to memorize as many openings as he wants, just as the computer has "memorized" them.
Sure, but there's a difference between a man memorizing openings, and pulling out his "Encyclopedia of Chess Openings" during the game. The point is that human's memories are limited and suffer bit-rot; the computer's doesn't. If humans, during the match, were allowed access to the vast compendiums of lore as quickly and accurately as the computer, humans would never lose.
As for "blunders": there's a qualitative difference between a "good game" of chess, where both players play strongly and one forces the other to lose anyway, and a "bad game" of chess, where one guy just has a whole bunch of "trick moves" and traps that depend on the other person "not seeing" the trap.
The author looks down on humans who play this way("cheaters" who play chess for money in parks, etc): even though they may win a lot of games, they're not playing "real" chess. They only know their own traps, and if anyone knows their tricks, or sets up the board in a way that they've never seen before, they're completely helpless. For real players, it's not really satisfying to win this way, or even to win because your opponent makes an obvious blunder.
So what he's saying is that the games of the humans against computers do not have the qualitative feel that games between two grandmasters do: they have the feel of games played by those "cheaters", and he analyzes why.
Yeah, but, look, a band like Talking Heads recorded their album "Fear of Music" in their attic, in 1979, using the Record Plant's mobile unit, and shoving the cables through the window. They did the basic layout in 2 days.
I don't know the details of their layout, but if their attic is anything like MY attic, it probably had better acoustics, as far as recording is concerned, than most normal rooms:
The triangular shape, from the roof, means few parallel surfaces -- only at the ends of the house. Less chance for echos and standing waves.
Insulation to stop / muffle high- and midrange reflection, and muffle sounds from outside but
Wood in non-parallel surfaces to get a nice ambiance (i.e., not completely dead)
No ventilation duct, which means no low hum picked up by the mics
So yeah, I can believe they sounded halfway decent in their attic. Hmm...maybe I should try that... =)
What Protools, Sound Forge, Audio Mulch and other pieces of software are brilliant at is making the new music that has nothing to do with "air" or performances by real people. This music (sometimes called "Glitchwerks") was not possible before fast cheap computers, sound cards and the software to mess it all up, but generally speaking, the public does not yet consider these works to be music at all. Hmmm this atually means that Protools is good for modern music!
You're right there. It's actually really cool to listen to an all-electronic piece and NOT hear the same beat repeated for 95 bars, but to see care and craftsmanship demonstrated in every track of the piece.
Compare the two attitudes:
The bad folks (including guy who wrote the article):
"Wow, I can make music that sounds somewhat like the stuff I already know with hardly *any* effort, talent, or musical creativity! Thanks ProTools!"
The good folks: "Wow, think of all the new kinds of music we can write with this stuff, new kinds of music never heard before. Thanks, ProTools!"
Geh...
Re:ProTools is a large reason modern music sucks
on
Cheap Audio Production
·
· Score: 5, Insightful
Amen, mod that parent up. It may sound impressive at first, but if you listen you can definitely tell the lame music done the way described in the article from the good stuff.
What's more, the article talks as though the studio is now obsolete -- as though the mixing decks and equipment were the only importnat part of the studio. One of the major reasons for going to a studio at all is the sound. No matter how good your mic is, if you record it in a square room you get standing waves and all kinds of acoustic crap, making it sound like you did your recording in a bathroom; furthermore, if you're not isolated, you pick up the ventilation system, the whir of the computer fans, and trucks (or ghetto blasters) driving by outside. There's only so much Pro Tools can do to compensate for a crappy input (I know, I've tried).
Studios put a lot of work into making a room tha has good acoustic qualities and is isolated from all nasty bits of noise; designing, building, and maintaining such a room is still an expensive venture, and still necessary for a decent recording.
How about, it's simply a fact that, in general, women have a harder time navigating with small screens than men do. If you are running an AutoCad shop and using 15" screens you are, in fact, discriminating against women, making it harder for them to work there.
It would be like designing the workplace so that you had to be 6 foot to use anything (women are generally shorter) or do some heavy lifting (women are generally less muscular). If heavy lifting is part of the job, fine; but if it's not necessary, get rid of it!
The difference between the genders are valuable. Having a workplace with 50% women, who are able to work to their maximum potential, is simply better (in most cases) than having 100% men, or 90% men and 10% women (especially if those 10% are inhibited unnecessarily). If you want such a workplace, though, you'll need to design it so that women do not have a harder time than men. That means, among other things, large displays for 3D navigation, so that women can, in fact, work as effectively as men.
That being said, "general tendencies" is no excuse for prejudice. I don't like Ayn Rand in general, but she made a good point about racism (as well as sexism, etc) which I'll try to paraphrase here: "Even if it could be shown that in general, one particular group tends to be better in some area (smarter / stronger / whatever) than some other group, that doesn't mean that this particular individual in the first group is better than that particular individual in the second group: you still have to judge them on their merits." (Something like that, anyway.)
So, would you spend five years in jail (or whatever it was) to get a better job? Was that actually Kevin Mitnick's plan, to get caught and thrown in jail so he could make it big later? If it was, he was pretty dumb.
I understand that most felons don't have that opportunity; but I wish it were the case that having a felony weren't a lifelong sentence.
Because when you're fast-forwarding through something, you have to pay attention so you know when the commercials are over. For normal TV, you can just wander around and not pay attention to the commercials. It only takes you a second to realize the commercials are over and to start paying attention again. But you don't want to skip the first 30 seconds of the show by accident, so you actually *watch* the ads to find when they're over.
It's sort of like those guys who say, "I drive better when I'm drunk, because I really have to focus on what I'm doing..." Yeah.
Not to mention, he still shows up at academic conferences and asks tough questions, not infrequently. I don't know what kind of research he's doing now, but he definitely knows his stuff -- not the kind of guy you want to have to answer on-the-fly in front of 400 other researchers.
Actually, this is a good point... people usually assume that 'evolution' is progressing inexorably towards what we consider better -- smarter, faster, stronger, taller, thinner, better looking. Evolution in fact doesn't care about those things -- only what will survive to pass on its genes. If conditions ever change on Earth, so that the luxury of having a big brain can't compensate for the extra costs, it will remorselessly cut the big brain out. We may, in fact, evolve back down to chimps, or even back to single-celled organisms, if that's what it takes to survive.
I can't mod you up, but I'll expand on that theme: the book by honeynet.org, "Know Your Enemy" has a lot of good practical experience to share. Some things to think about:
Having the attacker on your internal network, or even with one of your ip addresses is a security threat. Best to have the entire 'fake' honeynet walled off with its own router and firewall.
There's a chance that if someone breaks into your honeypot, and then uses it to break into someone else's computer, or in a DDOS, you may be liable. The book has a good rule of thumb on this point: Limit the number of outgoing connections to 10. That makes a 'usable' system (necessary for a honeypot) but limits the damage they can really do. Put an excuse in motd, like "The network is acting flaky, we're upgrading our router software" or something like that.
One of the advantages to honeypots is that it makes anomaly detection easy: any activity on the honeypot is suspicious by definition.
So yeah... "Know Your Enemy" is a good book for practical tips, kudos to the Honeynet team.
Well, even in systems like LIDS which have controls even on root, there are still ways to gain privileges to do things... in other words, there is the need for a super-super-user. The basic problem is that people make mistakes, and things are buggy. What happens if a user accidentally takes away his own access to a file? What happens if the MAC or capabilities get screwed up somehow -- either because of end-user error, or some glitch in the system? Until we can guarantee this won't happen (i.e., probably never) you need the ability to come in and play 'God', so to speak, to set things right.
What's a kludge is giving some random process complete superuser access, when all it needs to do is just one thing -- i.e., modify/etc/passwd, or bind to port 80, or access/dev/tape to do a backup. That's what MAC and capabilities are for.
It all depends on exactly what you're doing! And don't forget, Perl is not the only scripting language, some of your arguments don't apply to others.
Yes, I agree! The system I'm working on now in fact uses about half C (for stuff in the kernel, and stuff that talks to the kernel) and half bash scripts. It's just a whole lot easier to make bash do some things than to write it in C (or even in perl, which is what my boss wants). I'm hoping my scripts are self-explanatory enough that anyone else using them can at least figure out what they're doing and hack them do do what they need, even if they're not fluent in bash.
I didn't mean to make it sound like I was bashing scripting (no pun intended). I use scripts extensively, and there are places where they really shine.
Certainly compiled languages have many things lacking, and many people use them in ways which completely negate any advantages they have.
But seriously, what's the biggest, most complicated program written in perl, compared to the biggest, most complicated program written in C/ C++ / Java? How maintainable is a large (>10,000 line) *well written* program in perl, compared to a *well written* program in Java? That was exactly what the original poster said:
Most programming languages are designed around keeping a codebase usable even at large sizes.
Most scripting languages are designed around letting small problems be implemented quickly.
People writing bad code, in perl or in Java/C++/etc, are beside the point. Per'aps we have different ideas of what "small" means...
There may still be a small amount of truth to what you said, however, modern scripting languages are every bit as maintainable as C, C++, or Java. In fact, an incompetent C programmer probably is the most likely to create unmaintainable code, as scripting languages require less total code, and therefore it's easier to absorb quickly.
What do you mean 'maintainable'? Sure, an incompetent programmer can screw up the best languages. But the programming languages aren't designed to help incompetent programmers -- they're designed to help competent ones. I remember reading about a study done in the 80's that suggested that experienced coders wrote as many bugs as inexperienced ones -- they just found more of them before the ship date.
With that in mind, there's a hierarchy of places that bugs exhibit themselves, going from good to bad. The best bugs don't get written; the next best are caught at compile time. After that, are bugs which cause the program to crash immediately (fail-stop) and the worst are bugs that cause random, non-evident behavior much later down the road. Anything you can do to push errors up the hierarchy will make programs easier to debug and maintain. Hence strong typing languages, OO, things like that.
Sure, all decent languages have comments, functions, ways to structure the code that make it somewhat easy to read. But last time I checked (which was a while, granted) Perl didn't have strong type checking to make sure you didn't pass the wrong kind of thing to a function. You have a handful of data types that do everything; it doesn't allow you to make assumptions about what other bits of code are/aren't doing, as you can with a properly-organized strongly-typed language. That's the next step in maintainability -- partitioning the thing into littler bits and making sure they work right, and moving errors up the hierarchy to compile-time errors.
It depends on what your goal is. If you're looking to collect new exploits, well, it's pretty easy to make things seem real on the outside. The earlier versions of honeyd (if I recall correctly from my conversations with Neils) didn't actually allow an attacker to get very far with an attack, because they didn't run any actual services, just a fake thing that mimicked a service. The purpose wasn't to actually entrap and convict hackers, or to observe their modes of operation and so on; but to collect information about new attacks (for signature detectors in firewalls) and to hide your real system in among a bunch of fakes.
If you're looking to actually observe crackers "in the wild", you have to make your system look reasonably real; while at the same time making sure the attackers can't do any real damage from your machine (else you may be implicated in their crimes). The Honeynet project has a lot of good tips and tricks on this sort of thing. For example, not allowing more than 10 outgoing connections (so that it can't be used to scan or launch a DDOS attack), and putting a message in motd saying, "The network is acting kind of flaky, we're working on it, blah blah blah."
In fact, making a realistic honeypot is essentially just social engineering... hmm...
Slashdot Mirror
The particular service we're providing, ReVirt, is new to Virtual Machines (as far as we know). We don't log normal "security" information, like login attemps, etc. We log just enough information to be able to roll the virtual machine back to a previous state, and make it execute exactly the same way.
One of the (many) problems with security logs is that you frequently don't know everything that you really need to log until after the fact. With our system, you can go back and find out anything you want to know, because you have a live VM doing exactly what it did during the attack.
BTW, the technique we're using for ReVirt was described back in the late 80's, and implemented in the mid 90's for debugging purposes; we're the first ones, as far as we know, to put it in a (somewhat) general-purpose virtual machine, like UMLinux.
If you have a reference, I'm sure the covirt group would appreciate it, so we can learn from it / acknowledge prior work more completely. =) -George Dunlap (main ReVirt author)
- How they broke in (what the exploit was)
- When they broke in
- What they saw (if they d/l'd any sensitive data: credit cards, company information, whatever), or
- What they changed (if they installed any backdoors, trojaned binaries, etc).
Current techniques require a lot of time, a lot of expertise, a lot of Sherlock-holmes style educted guessing, and in the end you may just not know the answer. Apply some patches, restore from backup, hope you fixed the hole and didn't miss any trojans.With our system, you will be able to go back and find out all of these things with complete confidence and accuracy (once we have the proper analysis tools in place, that is).
That's what a security camera is good for. =)
Unfortunately, since that's not likely to happen, Plex86 isn't in good shape, and we didn't want to write our own full-fleged VM, we used UMLinux for a prototype and proof-of-concept that the ReVirt idea could work. Maybe someday VMWare or someone else will pick it up.
BTB, we do use UMLinux (now FAUmachine, I think), but we're looking into porting it to Jeff Dike's User-Mode-Linux soon.
There is no way to know if there is a bug in the VM, just as there's no way to know if there's a bug in the operatin gsystem. BUT, the virtual machine montitor, which controls the VM, is a *lot* smaller piece of software than a kernel, with a much simpler interface to provide. Therefore, the hope is that there's less of a chance of an exploitable bug in the VM, than in an operating system.
I'm going home now...
At any rate, it's clear that they don't have any actual good-faith desire to help people stop re-distributing "their" IP. If they really cared, they would have e-mailed Linus saying, "We have reason to believe the following lines of code have been added to the kernel in violation of our license with IBM" and listed them, so he could take them out and stop distribution.
SCO Sending a letter to a company saying "Linux violates our IP rights, you should stop using it" would be like Virgin Records sending a letter to a bunch of record stores saying, "EMI is distributing songs containing illegal samples of Virgin Records' songs. You should stop distributing any EMI record labels, or you could be liable" -- without saying exactly which CDs or tracks, and without contacting EMI with the specifics either.
(I just pulled these names out of a hat, so don't tell me Virgin is owned by EMI or anything crazy like that. *grin* )
So you're speaking Esperonto, an artificial language designed by a committe? Maybe Loglan?
No, you seem to be speaking English. OK, so which standards orginization do you adhere to? None? Because there is no standards organization, it evolves and adapts as people use it?
If you'll notice the header, the guy doesn't say standards are stifling innovation, just that standards orginizations, in particular those that try to create a standard from scratch (rather than describing what's already there), are stifling innovation.
When I got another car, a Nissan Altima, the engine is just a lot harder to look at and say, "Oh, I just need to do this." You need better tools, more skills, and if you screw something up, it costs you a lot more. Better just let the professionals handle it. If you screw up your car, you have to find another ride; if you screw up your brew-making, just go buy some beer at the store.
The only way for company X to legally distribute the whole shebang is to (a) put their code under the GPL, thus gaining permission from the original authors, or (b) contacting each of the original authors of the code individual and asking their permission to distribute it (assuming they still own the copyright).
OK then, what about all those exploits in web pages -- URLs, malformed html, etc? If you put a poison html page that you *know* is going to cause a certain version of IE or Mozilla viewing it to do something the user never intended, do you really think you can hide behind the "All I was doing was answering requests!" defense?
Or what if you managed to get Microsoft's private key for WindowsUpdate, and intercepted people's requests for updates, giving them "updates" that allow you to 0wnz0r their machines. Hey, you didn't install it, you just answered requests! Yeah, see if a jury buys that one.
This is a clever technical solution to the problem; however, it's very dangerous -- they haven't tested this update on a wide variety of systems, and it may cause a lot of damage and data loss. It's not their place to make that kind of a decision.
A legal solution would be to look what IP is connecting to this URL, put it on a temporary blackout list, and contact the ISP or company responsible for that IP and advise them to take action.
Sure, but there's a difference between a man memorizing openings, and pulling out his "Encyclopedia of Chess Openings" during the game. The point is that human's memories are limited and suffer bit-rot; the computer's doesn't. If humans, during the match, were allowed access to the vast compendiums of lore as quickly and accurately as the computer, humans would never lose.
As for "blunders": there's a qualitative difference between a "good game" of chess, where both players play strongly and one forces the other to lose anyway, and a "bad game" of chess, where one guy just has a whole bunch of "trick moves" and traps that depend on the other person "not seeing" the trap. The author looks down on humans who play this way("cheaters" who play chess for money in parks, etc): even though they may win a lot of games, they're not playing "real" chess. They only know their own traps, and if anyone knows their tricks, or sets up the board in a way that they've never seen before, they're completely helpless. For real players, it's not really satisfying to win this way, or even to win because your opponent makes an obvious blunder.
So what he's saying is that the games of the humans against computers do not have the qualitative feel that games between two grandmasters do: they have the feel of games played by those "cheaters", and he analyzes why.
I don't know the details of their layout, but if their attic is anything like MY attic, it probably had better acoustics, as far as recording is concerned, than most normal rooms:
- The triangular shape, from the roof, means few parallel surfaces -- only at the ends of the house. Less chance for echos and standing waves.
- Insulation to stop / muffle high- and midrange reflection, and muffle sounds from outside but
- Wood in non-parallel surfaces to get a nice ambiance (i.e., not completely dead)
- No ventilation duct, which means no low hum picked up by the mics
So yeah, I can believe they sounded halfway decent in their attic. Hmm..You're right there. It's actually really cool to listen to an all-electronic piece and NOT hear the same beat repeated for 95 bars, but to see care and craftsmanship demonstrated in every track of the piece.
Compare the two attitudes:
- The bad folks (including guy who wrote the article):
"Wow, I can make music that sounds somewhat like the stuff I already know with hardly *any* effort, talent, or musical creativity! Thanks ProTools!"
- The good folks: "Wow, think of all the new kinds of music we can write with this stuff, new kinds of music never heard before. Thanks, ProTools!"
Geh...What's more, the article talks as though the studio is now obsolete -- as though the mixing decks and equipment were the only importnat part of the studio. One of the major reasons for going to a studio at all is the sound. No matter how good your mic is, if you record it in a square room you get standing waves and all kinds of acoustic crap, making it sound like you did your recording in a bathroom; furthermore, if you're not isolated, you pick up the ventilation system, the whir of the computer fans, and trucks (or ghetto blasters) driving by outside. There's only so much Pro Tools can do to compensate for a crappy input (I know, I've tried).
Studios put a lot of work into making a room tha has good acoustic qualities and is isolated from all nasty bits of noise; designing, building, and maintaining such a room is still an expensive venture, and still necessary for a decent recording.
It would be like designing the workplace so that you had to be 6 foot to use anything (women are generally shorter) or do some heavy lifting (women are generally less muscular). If heavy lifting is part of the job, fine; but if it's not necessary, get rid of it!
The difference between the genders are valuable. Having a workplace with 50% women, who are able to work to their maximum potential, is simply better (in most cases) than having 100% men, or 90% men and 10% women (especially if those 10% are inhibited unnecessarily). If you want such a workplace, though, you'll need to design it so that women do not have a harder time than men. That means, among other things, large displays for 3D navigation, so that women can, in fact, work as effectively as men.
That being said, "general tendencies" is no excuse for prejudice. I don't like Ayn Rand in general, but she made a good point about racism (as well as sexism, etc) which I'll try to paraphrase here: "Even if it could be shown that in general, one particular group tends to be better in some area (smarter / stronger / whatever) than some other group, that doesn't mean that this particular individual in the first group is better than that particular individual in the second group: you still have to judge them on their merits." (Something like that, anyway.)
I understand that most felons don't have that opportunity; but I wish it were the case that having a felony weren't a lifelong sentence.
It's sort of like those guys who say, "I drive better when I'm drunk, because I really have to focus on what I'm doing..." Yeah.
Not to mention, he still shows up at academic conferences and asks tough questions, not infrequently. I don't know what kind of research he's doing now, but he definitely knows his stuff -- not the kind of guy you want to have to answer on-the-fly in front of 400 other researchers.
Actually, this is a good point... people usually assume that 'evolution' is progressing inexorably towards what we consider better -- smarter, faster, stronger, taller, thinner, better looking. Evolution in fact doesn't care about those things -- only what will survive to pass on its genes. If conditions ever change on Earth, so that the luxury of having a big brain can't compensate for the extra costs, it will remorselessly cut the big brain out. We may, in fact, evolve back down to chimps, or even back to single-celled organisms, if that's what it takes to survive.
- Having the attacker on your internal network, or even with one of your ip addresses is a security threat. Best to have the entire 'fake' honeynet walled off with its own router and firewall.
- There's a chance that if someone breaks into your honeypot, and then uses it to break into someone else's computer, or in a DDOS, you may be liable. The book has a good rule of thumb on this point: Limit the number of outgoing connections to 10. That makes a 'usable' system (necessary for a honeypot) but limits the damage they can really do. Put an excuse in motd, like "The network is acting flaky, we're upgrading our router software" or something like that.
- One of the advantages to honeypots is that it makes anomaly detection easy: any activity on the honeypot is suspicious by definition.
So yeah... "Know Your Enemy" is a good book for practical tips, kudos to the Honeynet team.What's a kludge is giving some random process complete superuser access, when all it needs to do is just one thing -- i.e., modify /etc/passwd, or bind to port 80, or access /dev/tape to do a backup. That's what MAC and capabilities are for.
Yes, I agree! The system I'm working on now in fact uses about half C (for stuff in the kernel, and stuff that talks to the kernel) and half bash scripts. It's just a whole lot easier to make bash do some things than to write it in C (or even in perl, which is what my boss wants). I'm hoping my scripts are self-explanatory enough that anyone else using them can at least figure out what they're doing and hack them do do what they need, even if they're not fluent in bash.
I didn't mean to make it sound like I was bashing scripting (no pun intended). I use scripts extensively, and there are places where they really shine. Certainly compiled languages have many things lacking, and many people use them in ways which completely negate any advantages they have.
But seriously, what's the biggest, most complicated program written in perl, compared to the biggest, most complicated program written in C/ C++ / Java? How maintainable is a large (>10,000 line) *well written* program in perl, compared to a *well written* program in Java? That was exactly what the original poster said:
People writing bad code, in perl or in Java/C++/etc, are beside the point. Per'aps we have different ideas of what "small" means...
What do you mean 'maintainable'? Sure, an incompetent programmer can screw up the best languages. But the programming languages aren't designed to help incompetent programmers -- they're designed to help competent ones. I remember reading about a study done in the 80's that suggested that experienced coders wrote as many bugs as inexperienced ones -- they just found more of them before the ship date.
With that in mind, there's a hierarchy of places that bugs exhibit themselves, going from good to bad. The best bugs don't get written; the next best are caught at compile time. After that, are bugs which cause the program to crash immediately (fail-stop) and the worst are bugs that cause random, non-evident behavior much later down the road. Anything you can do to push errors up the hierarchy will make programs easier to debug and maintain. Hence strong typing languages, OO, things like that.
Sure, all decent languages have comments, functions, ways to structure the code that make it somewhat easy to read. But last time I checked (which was a while, granted) Perl didn't have strong type checking to make sure you didn't pass the wrong kind of thing to a function. You have a handful of data types that do everything; it doesn't allow you to make assumptions about what other bits of code are/aren't doing, as you can with a properly-organized strongly-typed language. That's the next step in maintainability -- partitioning the thing into littler bits and making sure they work right, and moving errors up the hierarchy to compile-time errors.
If you're looking to actually observe crackers "in the wild", you have to make your system look reasonably real; while at the same time making sure the attackers can't do any real damage from your machine (else you may be implicated in their crimes). The Honeynet project has a lot of good tips and tricks on this sort of thing. For example, not allowing more than 10 outgoing connections (so that it can't be used to scan or launch a DDOS attack), and putting a message in motd saying, "The network is acting kind of flaky, we're working on it, blah blah blah."
In fact, making a realistic honeypot is essentially just social engineering... hmm...