I don't disagree with what you're saying, I just think that given that this is a morally ambiguous position some care should be exercised to examine what your potential employer stands to gain. Are they looking for your knowledge of the subject or your knowledge of their competitor's product? In this case, it sounds to me like the focus is on the competing product, and that makes me very uncomfortable. Add to that the tenuous position of undermining the trust of friends and leaving a community of volunteers, and I suspect that the submitter has already sussed out that they shouldn't be doing what they are being asked to do.
If you push that too far, its called corporate espionage, and its not only unethical, its illegal. I believe we recently had a story about an AMD exec doing something very close to what you're talking about.
Are you suggesting that it is completely ethical to take a detailed knowledge of a company's future plans, as yet unreleased products, or sales leads with you to their competitor? That would make absolutely no sense!
I would be ashamed, although maybe not for the same reasons as the op.
To my mind, this would be the same as working for a vendor and then taking a job working on their competitor's product. It works, but is it ethical?
The original story has the man as Sir Winston Churchill, going something like this:
Churchill: Madam, would you sleep with me for five million pounds?
Socialite: My goodness, Mr. Churchill... Well, I suppose... we would have to discuss terms, of course...
Churchill: Would you sleep with me for five pounds?
Socialite: Mr. Churchill, what kind of woman do you think I am?!
Churchill: Madam, we've already established that. Now we are haggling about the price.
I'm perfectly serious. It's a useful app and a pretty easy problem. If you'll email me at CTO@Openmigration.net and let me know more about your specific requirements (number of remote hosts, total archive size, etc) I can start figuring out what the best way to do this is. Also, I'll need to know all of the platforms you're running on (will you need support on cell phones? Xbox?), the level of redundancy you're comfortable with, will you need a web interface, etc.
I'd be happy to write a script that will handle that concern, but somebody else would have to do the UI unless you want it looking like it escaped from Windows 95.
Break n' bake servers work out really well with Amazon's EC2. I've never had to use it for anything really critical but so long as you maintain a set of closely sync'd liveUSB and AMI images I don't see why you'd have a problem. Just make sure that your existing failover mechanisms automatically initiate the backup plan, notify you, and isolate your local system for forensics or repair, since a security breach that will take down your local system has a high likelihood of succeeding in the cloud.
Obsolescence is not the enemy; downtime is. The vulnerability-by-vulnerability, patch-by-patch turf warfare technique that secures joe blow's basement server is a firing offense on the kind of system we're talking about.
If you're looking into securing a shared hosting solution, you might look into libpcap. I mentioned it before, but it gets far less attention than it deserves, especially among admins. It has the capability to forbid forming new chroots, making modifications to your networking properties, the insertion of kernel modules, even escalations to root. Between libpcap, something like this, a well-constructed jail, a good vserver solution, and a very carefully secured network, you're going to be as secure as just about anything out there.
This is actually quite different from selinux, although they both hinge on controlling what syscalls a program can make. The major difference here is that this system automatically builds an equivalent to the selinux rules at compile time, and therefore avoids a lot of the problems caused by poorly written selinux rules. An associated advantage is the ability to track whether a chain of syscalls is legitimate. Such context analysis could be very powerful if used properly.
However, you've probably already spotted the major flaws with this approach: the first is that it only works on compiled programs, which strikes me as a serious problem when you're talking about webservers. The second is that it doesn't work on certain classes of programs whose execution pattern is extremely difficult to predict: self-modifying code, highly dynamic code (longjmp is not allowed), etc. Another limitation is that it only works on statically linked libraries. Finally, it is totally dependent on GCC and friends, which could be a problem for it moving forward, and in groups where the intel compiler is preferred.
As for false positives, the entire point of this is that inside of these admittedly limited confines, it has no possibility for false positives. This system is not statistical in nature. It depends entirely upon the program itself to determine correct syscall behavior.
All in all, while it is a long way from a practical security model, it does offer the promise of powerful, accurate protection from certain classes of attacks. When combined with selinux and pcap on a system with a slim attack profile it could help to narrow the gap between being a zero-day compromise and having full protection.
My God, you've figured out how to encrypt pixels! Genius! Let me know when you've got it working.
Seriously, though, I'm not sure why you think that plaintext can't be digital, but it is most certainly the case that so long as your user does not have an in-brain decryption mechanism, it will be the machine's job to render unto them movies, music, and TV in such a way that they can process it. If this is the case, then so long as you do not control the pipe between your system and them, they will always be able to capture it.
It is worth noting that this is not a first line of attack on this kind of system, but rather a last line. This presumes that *every other* relevant communication in the system is unquestionably unassailable. I don't need to tell you that given unlimited physical access to the hardware, of even a reasonable modicum of access to the software, that state of being will not endure.
My point is that even if you completely secure the machine, if the attacker and intended recipient are the same person, all you have done is make a very complicated system for delivering cleartext to your attacker. The intent of the system is irrelevant.
That's my point. DRM *is* designed to protect against plaintext theft. The use of cryptographic mechanisms to secure the data from point A to point B is irrelevant when your endpoint is untrusted.
The point about consumers not being endpoints is pretty much moot, however- whether it is on the network, in RAM, on the graphics hardware, or on the monitor, there is a point at which it will be in the machine and cleartext. At that point it will always be vulnerable.
The goal of cryptography is not to protect mechanisms, it is to protect information. An attacker, then, is anybody who you do not want to have the information you are trying to protect, while an intended recipient is anybody you do want to have that information. So, if the world is divided neatly into customers and pirates, cryptography has powerful mechanisms to protect your interests. But if even one individual can be a member of both groups, cryptographic mechanisms will fail to provide security of any provable strength.
You talk about authorized systems, tamperproof mechanisms, etc., but the problem runs much deeper than that. If it were just the misbehaving client problem we could fix the hole and move on with our lives. The issue is that the recipient has to have the information in the clear, and as long as you are willing to provide that you will run the risk of having that person spread that information. Even if you were able to 100% blackbox your machine, the end result would be the same- you would 100% securely retrieve the information, 100% securely process it, then 100% deliver it to a person who wants to spread it around the net.
Slashdot Mirror
I don't disagree with what you're saying, I just think that given that this is a morally ambiguous position some care should be exercised to examine what your potential employer stands to gain. Are they looking for your knowledge of the subject or your knowledge of their competitor's product? In this case, it sounds to me like the focus is on the competing product, and that makes me very uncomfortable. Add to that the tenuous position of undermining the trust of friends and leaving a community of volunteers, and I suspect that the submitter has already sussed out that they shouldn't be doing what they are being asked to do.
If you push that too far, its called corporate espionage, and its not only unethical, its illegal. I believe we recently had a story about an AMD exec doing something very close to what you're talking about.
Are you suggesting that it is completely ethical to take a detailed knowledge of a company's future plans, as yet unreleased products, or sales leads with you to their competitor? That would make absolutely no sense!
Exaggeration is a fine art, don't overdo it.
A good song indeed, by which I mean "a song which makes a point I agree with".
I would be ashamed, although maybe not for the same reasons as the op.
To my mind, this would be the same as working for a vendor and then taking a job working on their competitor's product. It works, but is it ethical?
The original story has the man as Sir Winston Churchill, going something like this:
Churchill: Madam, would you sleep with me for five million pounds?
Socialite: My goodness, Mr. Churchill... Well, I suppose... we would have to discuss terms, of course...
Churchill: Would you sleep with me for five pounds?
Socialite: Mr. Churchill, what kind of woman do you think I am?!
Churchill: Madam, we've already established that. Now we are haggling about the price.
Thank you, wikiquotes!
Thanks for the info, I'll have somebody fix that right away.
I'm perfectly serious. It's a useful app and a pretty easy problem. If you'll email me at CTO@Openmigration.net and let me know more about your specific requirements (number of remote hosts, total archive size, etc) I can start figuring out what the best way to do this is. Also, I'll need to know all of the platforms you're running on (will you need support on cell phones? Xbox?), the level of redundancy you're comfortable with, will you need a web interface, etc.
Not a bad idea, actually, using the p2p grids for backup. Wonder if that's possible.
I'd be happy to write a script that will handle that concern, but somebody else would have to do the UI unless you want it looking like it escaped from Windows 95.
I see what they're getting at but not how to achieve similar gains. Anybody out there feel like putting together a slightly more practical guide?
Break n' bake servers work out really well with Amazon's EC2. I've never had to use it for anything really critical but so long as you maintain a set of closely sync'd liveUSB and AMI images I don't see why you'd have a problem. Just make sure that your existing failover mechanisms automatically initiate the backup plan, notify you, and isolate your local system for forensics or repair, since a security breach that will take down your local system has a high likelihood of succeeding in the cloud.
Edit: I also screwed it up here. The correct library, as pointed out below, is not libpcap, but rather libcap. My bad.
Edit: spelling is my mortal adversary. The correct library is libcap.
Its funny you should mention that- I was.
Obsolescence is not the enemy; downtime is. The vulnerability-by-vulnerability, patch-by-patch turf warfare technique that secures joe blow's basement server is a firing offense on the kind of system we're talking about.
There always exists the analog hole. I don't dispute that. But that's not the problem that DRM was designed to solve, and nor can it.
Actually, it is .
If you're looking into securing a shared hosting solution, you might look into libpcap. I mentioned it before, but it gets far less attention than it deserves, especially among admins. It has the capability to forbid forming new chroots, making modifications to your networking properties, the insertion of kernel modules, even escalations to root. Between libpcap, something like this, a well-constructed jail, a good vserver solution, and a very carefully secured network, you're going to be as secure as just about anything out there.
Thank you; you've stated the case quite a bit more clearly than I could have.
This is actually quite different from selinux, although they both hinge on controlling what syscalls a program can make. The major difference here is that this system automatically builds an equivalent to the selinux rules at compile time, and therefore avoids a lot of the problems caused by poorly written selinux rules. An associated advantage is the ability to track whether a chain of syscalls is legitimate. Such context analysis could be very powerful if used properly.
However, you've probably already spotted the major flaws with this approach: the first is that it only works on compiled programs, which strikes me as a serious problem when you're talking about webservers. The second is that it doesn't work on certain classes of programs whose execution pattern is extremely difficult to predict: self-modifying code, highly dynamic code (longjmp is not allowed), etc. Another limitation is that it only works on statically linked libraries. Finally, it is totally dependent on GCC and friends, which could be a problem for it moving forward, and in groups where the intel compiler is preferred.
As for false positives, the entire point of this is that inside of these admittedly limited confines, it has no possibility for false positives. This system is not statistical in nature. It depends entirely upon the program itself to determine correct syscall behavior.
All in all, while it is a long way from a practical security model, it does offer the promise of powerful, accurate protection from certain classes of attacks. When combined with selinux and pcap on a system with a slim attack profile it could help to narrow the gap between being a zero-day compromise and having full protection.
My God, you've figured out how to encrypt pixels! Genius! Let me know when you've got it working.
Seriously, though, I'm not sure why you think that plaintext can't be digital, but it is most certainly the case that so long as your user does not have an in-brain decryption mechanism, it will be the machine's job to render unto them movies, music, and TV in such a way that they can process it. If this is the case, then so long as you do not control the pipe between your system and them, they will always be able to capture it.
It is worth noting that this is not a first line of attack on this kind of system, but rather a last line. This presumes that *every other* relevant communication in the system is unquestionably unassailable. I don't need to tell you that given unlimited physical access to the hardware, of even a reasonable modicum of access to the software, that state of being will not endure.
My point is that even if you completely secure the machine, if the attacker and intended recipient are the same person, all you have done is make a very complicated system for delivering cleartext to your attacker. The intent of the system is irrelevant.
That's my point. DRM *is* designed to protect against plaintext theft. The use of cryptographic mechanisms to secure the data from point A to point B is irrelevant when your endpoint is untrusted.
The point about consumers not being endpoints is pretty much moot, however- whether it is on the network, in RAM, on the graphics hardware, or on the monitor, there is a point at which it will be in the machine and cleartext. At that point it will always be vulnerable.
The goal of cryptography is not to protect mechanisms, it is to protect information. An attacker, then, is anybody who you do not want to have the information you are trying to protect, while an intended recipient is anybody you do want to have that information. So, if the world is divided neatly into customers and pirates, cryptography has powerful mechanisms to protect your interests. But if even one individual can be a member of both groups, cryptographic mechanisms will fail to provide security of any provable strength.
You talk about authorized systems, tamperproof mechanisms, etc., but the problem runs much deeper than that. If it were just the misbehaving client problem we could fix the hole and move on with our lives. The issue is that the recipient has to have the information in the clear, and as long as you are willing to provide that you will run the risk of having that person spread that information. Even if you were able to 100% blackbox your machine, the end result would be the same- you would 100% securely retrieve the information, 100% securely process it, then 100% deliver it to a person who wants to spread it around the net.
"There is no cryptographic solution to the problem in which the attacker and intended recipient are the same person"
When will they learn?