going so far as to point out that you could be ticketed for unsafe driving (or impeding traffic) if you were driving the speed limit (e.g. 60mph on the freeway) but the rest of traffic was going 90.
Yeah I don't think so. Otherwise, there would be no way to drive on that road at all without breaking the law. I think that would violate due process. Also common sense.
Your driving instructor isn't wrong about safety, though.
Yes, people talking about suicide want "attention". But this usually isn't the same kind of attention spoiled children want. People talking about suicide often mean it, or at least think they do, and talking about suicide is one of their last attempts to grasp at whatever straws they think might support them as they fall.
Don't trivialize the pain that can and does make people end their own lives.
...have to defend their license at a license board hearing...
To all Slashdotters, take note: - Never support licensing for programmers. - NEVER support licensing for programmers. - NEVER SUPPORT LICENSING FOR PROGRAMMERS!
If there's anything that can make you a raving libertarian, it's professional licensing. Did you know the US state bars can refuse to license a lawyer who passed all tests and has no criminal record because (paraphrasing) "he's a jerk"? Seriously. Not an exaggeration. I can't find the case right now (slow Internet), but that has happened. Look up how broad the requirement of "good moral character" can be. Don't want that bull feces in YOUR profession? Oppose licensure. Always.
In OO language, we don't want any friends and we want to make sure that no data is exposed and all functions that provide functionality (get, set, do_something, whatever) are checked properly.
Friends are irrelevant. In C and C++, you have the ability to set pointers to arbitrary values, cast them to whatever you want, and then use them to overwrite arbitrary memory. Friends matter for minimizing code complexity, but, as Stroustrup said, C++'s object model is intended to prevent accidents, not fraud. If you have evil code with access to an object, whether or not the code is friends with the object's class is entirely irrelevant.
It's an impressive idea, although it depends on the TPM which is not designed to be safe against physical attacks. There's no reason the implementation of that should only work with QubesOS, either, although the developers appear to be the same.
Please read the link again, and/or work on your reading comprehension skills. The part you talk about is referring to not showing up to court when summoned, not failing to pay a monetary judgment.
Generally, once you have a judgment, it's up to you as a creditor to enforce it. You can do this in a number of ways, including enlisting a sheriff to help you (for a fee). But the debtor doesn't end up in prison for not paying a judgment.
Do you see how "not showing up to court" != "not paying a judgment"? Like I said earlier, the only way you can end up in jail for not paying a debt is if it's child support or a fine. These exceptions are perpetually controversial because they're basically debtors' prison, although supposedly inability to pay is a defense to the contempt charge.
In any case, I've thoroughly skewered your stupid "send me an email saying you'll pay me $10000" or whatever hypothetical. Unsecured creditors have no ability to force you into jail. Just make your court appearances, stupid.
It's generally not contempt of court not to pay a judgment. There are special cases where it sometimes can be with child support, but, as a general rule, you're just wrong on this. Even with child support, if you show up in court and prove you can't pay the debt, it's not contempt of court.
Trolling? There's no harm in running a mixed-mode system. It makes your kernel slightly larger and means 32-bit shared libraries will be loaded when and only when you're actually using 32-bit programs. You still get the speedup for software compiled in long mode. Given that the CPU designers baked the support logic into your CPU anyway, there's really no downside ot using that support when it makes sense.
It took four months for my relatively unknown server.
This smells funny. How specifically did your server get hacked? If I put out a server running nothing but Apache serving static HTML and SSH with a good password, I would expect it to be hacked approximately never or until the next sshnuke exploit. Which, again, would be approximately never. What were you running where you got hacked in four months?
Except that privilege escalation attacks against these multi-decade-old systems appear year after year. A well-funded state attacker (OP is about activists, after all) would certainly have some at their disposal.
All code has bugs. Xen has bugs. Qubes has bugs. And yes, OSes have bugs, although Linux local privilege escalation bugs are not an everyday occurrence, and OpenBSD bugs are very rare. You can't handwave a 0-day privilege escalation vulnerability into existence and claim that there are no 0-day privilege escalation vulnerabilities in Xen.
Re: CD-R, lets assume I use an optical disk to move a quantity of email messages from a networked/untrusted machine to an airgapped one (both conventional architecture). If I export as.eml files, I have to archive them before burning them. So, over and above the risk from nasty email attachments, there is the risk the untrusted machine could use malformed email or archive format to perform an exploit. If you think that's far-fetched, consider how much more complex email and archive formats are compared to the.lnk files that were recently discovered as an NSA exploit.
tar is pretty solid, actually, but, if you don't like it, make up your own trivial archive format (it's not hard), or don't use it and follow a one-disk-per-message protocol. And don't use a filesystem. dd if=email.eml of=/dev/cdrw (approximately), then dd if=/dev/cdrom of=email.eml
Even so, the untrusted networked system could take a chance that you have automounting enabled or that you will inadvertently do something to mount a volume... it could write a malformed filesystem to the disc anyway.
User error could happen with any system. You're really stretching here.
Once an air-gapped system is compromised, it can alter the hard drive firmware to store passwords and keys in a format/cipher readable by the attacker who can later break-in to the premises and steal/confiscate the computer. In a Qubes non-networked vm, there is no out-of-band way to communicate or store info, and a compromised vm wouldn't have access to the disc encryption password in any case.
Where did I ever say any of these computers had hard discs? And of course there's an out-of-band way to store info. Just use a magical vulnerability in Xen I made up to write it to another VM's permanent storage.
What you described #s 1-5 sounds much more complicated than using email in Qubes. And presumably this covers only email for one type of role (work, personal, etc); Covering all the roles means using many additional computers and burning many discs, and each role needs its own disc encryption passphrase.
I have no idea where you're getting that disc encryption has anything to do with anything here, and, no, you could definitely use the same three computers for all your emails. If you find burning discs to be too cumbersome, use floppy disc drivers or Zip drives or something, but it's really not that bad, especially if you don't bother to fixate.
This whole notion you have that "the operating system is insecure so let's put another layer on top of it" is just silly. If you make Xen your operating system, then Xen is your operating system. If you want a secure operating system with no privilege escalation, then that's what you need. Using a hypervisor doesn't magically make security vulnerabilities go away. There have and will be attacks against Xen, against Qubes, and against any other complex pieces of software you create. You want a secure OS, then you need a dead-simple OS written with security in mind. True security comes from simplicity, not complexity.
The one thing I think you're right about is that modern OSes are too complex to provide extreme levels of security. OpenBSD is the best, but even it is a quite complex piece of software. A braindead-simple POSIX-like OS kernel prizing secur
I'm not saying it's impossible to customize a USB device. I'm saying rooting a machine to the point that it can customize an arbitrary USB key plugged in by the legitimate operator of the machine is impractical. You're also invoking speculative, unknown attacks against the USB host driver and firmware, which I will see you with my previously invoked unknown, speculative attacks against Xen. Also, you completely ignored my suggestion of using an optical disk if you are concerned about USB.
Safest way I can think of using airgapped machines right now for encrypted email:
1. Copy received email from networked machine C to write-once optical disk. 2. Decrypt received email on airgapped machine A. 3. Compose reply on different airgapped machine B, encrypt reply. 4. Copy encrypted reply to write-once optical disk. 5. Send encrypted reply from networked machine.
This involves three physical computers, but none has to be recent or expensive. Airgapped machine A has no ability to send information to C or B, and airgapped machine B is never touched by any devices from the outside world, and also never needs to know any secret keys, since all you need to encrypt an email message is the recipient's public key. Theoretically you could type such a key in by hand, but in any case it's a once-per-recipient transfer.
I would argue using USB sticks in this scenario gives only a very slight reduction in security, but write-many optical disks would be a practical approach if you're scared of USB. I will say that compiling out obscure and unused USB kernel drivers is a good move, as is disabling USB kernel module autoloading.
In any case, BadUSB would require reprogramming the actual device, so I still don't think it is a practical attack vector in this scenario. Moreover, if you're really paranoid, you can use write-once CD-Rs instead of USB devices.
QubesOS is an interesting idea, but it's more complicated and therefore more likely to have bugs than airgapping a machine. You're assuming there are no bugs in Xen, for instance.
As for filesystem bugs, this code has been around for 20 years or more. There are bugs everywhere, but I think especially popular Linux filesystem drivers are likely pretty solid. But go ahead and just dd the file to the optical disk directly and don't use a filesystem if it makes you feel better.
Bugs in the filesystem driver, yes, but those are probably pretty rare I'd think. BadUSB, not really. That attack works by emulating a keyboard/mouse HID controller. If you plug your USB drive in and all of a sudden your computer starts typing things and moving the mouse on its own, you would notice immediately. Also it typically requires special hardware; a rooted box couldn't just take a real USB drive and turn it into a HID controller.
- It is technically possible to air-gap the machine you use to access your email, by copying the email over from an insecure computer to the air-gapped machine. - TAILS is great, but they probably at least try to break it since it's popular. Will they succeed? Maybe. So use an OpenBSD live CD, it's more secure anyway. Or get creative: use Whonix. The FBI's pedestrian attempt at drive-by malware would have fallen flat on its face with an adversary using Whonix. - Firejail. Google it. Won't protect you against local kernel privilege escalation attacks, though.
Yes, contingency planning is good. Yes, single points of failure are bad. But you can get very, very good communication security if you really try.
The lessons of Liberal Arts last for a lifetime, compared to technology which is largely short lived knowledge. I'm sure you were proud of your Commodore64 knowledge like I was at the time, but that stuff all vanished. As did DOS, SunOS 2, HP-UX 9, and all of these other technologies that people said were "essential" to know. The latest application is not important when a large portion of the population can't afford it.
If you learned SunOS 2 or HP-UX 9, most of that knowledge is applicable to Solaris and modern Linux distributions today.
My undergrad curriculum had a class where we designed a pipelined processor, though we didn't actually build it. It was an interesting and educational experience for me, and I'm glad to have done it.
And he died more than a year after the end of his "treatment".
This. There is a good chance that Turing actually didn't commit suicide, but rather died of accidental cyanide inhalation. He had set up a chemical lab in his living space and wasn't exactly using OSHA-approved storage protocols for dangerous chemicals. His mother, at the time, said she didn't think he'd killed himself, and contemporary accounts were that he was doing pretty okay. The supposedly cyanide-poisoned apple was not tested for cyanide. None of this is conclusive.
IMO, any modern report on Turing should account for the possibility he didn't kill himself. The suicide angle makes a great story for gay rights activists, but it does a disservice to the memory of this great man to reduce him to a political talking point. The forced hormone treatment was abominable, whether or not it drove him to suicide. There's a chance it did, and a chance it did not.
Slashdot Mirror
going so far as to point out that you could be ticketed for unsafe driving (or impeding traffic) if you were driving the speed limit (e.g. 60mph on the freeway) but the rest of traffic was going 90.
Yeah I don't think so. Otherwise, there would be no way to drive on that road at all without breaking the law. I think that would violate due process. Also common sense.
Your driving instructor isn't wrong about safety, though.
Yes, people talking about suicide want "attention". But this usually isn't the same kind of attention spoiled children want. People talking about suicide often mean it, or at least think they do, and talking about suicide is one of their last attempts to grasp at whatever straws they think might support them as they fall.
Don't trivialize the pain that can and does make people end their own lives.
...have to defend their license at a license board hearing...
To all Slashdotters, take note:
- Never support licensing for programmers.
- NEVER support licensing for programmers.
- NEVER SUPPORT LICENSING FOR PROGRAMMERS!
If there's anything that can make you a raving libertarian, it's professional licensing. Did you know the US state bars can refuse to license a lawyer who passed all tests and has no criminal record because (paraphrasing) "he's a jerk"? Seriously. Not an exaggeration. I can't find the case right now (slow Internet), but that has happened. Look up how broad the requirement of "good moral character" can be. Don't want that bull feces in YOUR profession? Oppose licensure. Always.
In OO language, we don't want any friends and we want to make sure that no data is exposed and all functions that provide functionality (get, set, do_something, whatever) are checked properly.
Friends are irrelevant. In C and C++, you have the ability to set pointers to arbitrary values, cast them to whatever you want, and then use them to overwrite arbitrary memory. Friends matter for minimizing code complexity, but, as Stroustrup said, C++'s object model is intended to prevent accidents, not fraud. If you have evil code with access to an object, whether or not the code is friends with the object's class is entirely irrelevant.
Christ ...we meet again. Are you like a Qubes developer or something because it's either that or you're REALLY a fanboy.
Is this what you're talking about: http://blog.invisiblethings.or...
It's an impressive idea, although it depends on the TPM which is not designed to be safe against physical attacks. There's no reason the implementation of that should only work with QubesOS, either, although the developers appear to be the same.
Please read the link again, and/or work on your reading comprehension skills. The part you talk about is referring to not showing up to court when summoned, not failing to pay a monetary judgment.
Generally, once you have a judgment, it's up to you as a creditor to enforce it. You can do this in a number of ways, including enlisting a sheriff to help you (for a fee). But the debtor doesn't end up in prison for not paying a judgment.
Do you see how "not showing up to court" != "not paying a judgment"? Like I said earlier, the only way you can end up in jail for not paying a debt is if it's child support or a fine. These exceptions are perpetually controversial because they're basically debtors' prison, although supposedly inability to pay is a defense to the contempt charge.
In any case, I've thoroughly skewered your stupid "send me an email saying you'll pay me $10000" or whatever hypothetical. Unsecured creditors have no ability to force you into jail. Just make your court appearances, stupid.
Yes, protocol on Slashdot with alleged bullshit things is that burden of proof is on the bullshitter. Since, you know, you made the original claim?
But I'll throw you a bone. I won't even use insult you with lmgtfy.com. Aren't I a nice guy?
http://www.nolo.com/legal-ency...
Bullshit.
It's generally not contempt of court not to pay a judgment. There are special cases where it sometimes can be with child support, but, as a general rule, you're just wrong on this. Even with child support, if you show up in court and prove you can't pay the debt, it's not contempt of court.
Trolling? There's no harm in running a mixed-mode system. It makes your kernel slightly larger and means 32-bit shared libraries will be loaded when and only when you're actually using 32-bit programs. You still get the speedup for software compiled in long mode. Given that the CPU designers baked the support logic into your CPU anyway, there's really no downside ot using that support when it makes sense.
Or the claim is entirely bullsh.
Right. Like those silly people who think Candlejack will come to ta.
It took four months for my relatively unknown server.
This smells funny. How specifically did your server get hacked? If I put out a server running nothing but Apache serving static HTML and SSH with a good password, I would expect it to be hacked approximately never or until the next sshnuke exploit. Which, again, would be approximately never. What were you running where you got hacked in four months?
Correct. Not the first time that acronym has been confusing.
Thanks for bringing this up. Minor correction is he was charged but not convicted.
Your explanation isn't correct. The entire situation is unsettled law.
Except that privilege escalation attacks against these multi-decade-old systems appear year after year. A well-funded state attacker (OP is about activists, after all) would certainly have some at their disposal.
All code has bugs. Xen has bugs. Qubes has bugs. And yes, OSes have bugs, although Linux local privilege escalation bugs are not an everyday occurrence, and OpenBSD bugs are very rare. You can't handwave a 0-day privilege escalation vulnerability into existence and claim that there are no 0-day privilege escalation vulnerabilities in Xen.
Re: CD-R, lets assume I use an optical disk to move a quantity of email messages from a networked/untrusted machine to an airgapped one (both conventional architecture). If I export as .eml files, I have to archive them before burning them. So, over and above the risk from nasty email attachments, there is the risk the untrusted machine could use malformed email or archive format to perform an exploit. If you think that's far-fetched, consider how much more complex email and archive formats are compared to the .lnk files that were recently discovered as an NSA exploit.
tar is pretty solid, actually, but, if you don't like it, make up your own trivial archive format (it's not hard), or don't use it and follow a one-disk-per-message protocol. And don't use a filesystem. dd if=email.eml of=/dev/cdrw (approximately), then dd if=/dev/cdrom of=email.eml
Even so, the untrusted networked system could take a chance that you have automounting enabled or that you will inadvertently do something to mount a volume... it could write a malformed filesystem to the disc anyway.
User error could happen with any system. You're really stretching here.
Once an air-gapped system is compromised, it can alter the hard drive firmware to store passwords and keys in a format/cipher readable by the attacker who can later break-in to the premises and steal/confiscate the computer. In a Qubes non-networked vm, there is no out-of-band way to communicate or store info, and a compromised vm wouldn't have access to the disc encryption password in any case.
Where did I ever say any of these computers had hard discs? And of course there's an out-of-band way to store info. Just use a magical vulnerability in Xen I made up to write it to another VM's permanent storage.
What you described #s 1-5 sounds much more complicated than using email in Qubes. And presumably this covers only email for one type of role (work, personal, etc); Covering all the roles means using many additional computers and burning many discs, and each role needs its own disc encryption passphrase.
I have no idea where you're getting that disc encryption has anything to do with anything here, and, no, you could definitely use the same three computers for all your emails. If you find burning discs to be too cumbersome, use floppy disc drivers or Zip drives or something, but it's really not that bad, especially if you don't bother to fixate.
This whole notion you have that "the operating system is insecure so let's put another layer on top of it" is just silly. If you make Xen your operating system, then Xen is your operating system. If you want a secure operating system with no privilege escalation, then that's what you need. Using a hypervisor doesn't magically make security vulnerabilities go away. There have and will be attacks against Xen, against Qubes, and against any other complex pieces of software you create. You want a secure OS, then you need a dead-simple OS written with security in mind. True security comes from simplicity, not complexity.
The one thing I think you're right about is that modern OSes are too complex to provide extreme levels of security. OpenBSD is the best, but even it is a quite complex piece of software. A braindead-simple POSIX-like OS kernel prizing secur
Burz,
I'm not saying it's impossible to customize a USB device. I'm saying rooting a machine to the point that it can customize an arbitrary USB key plugged in by the legitimate operator of the machine is impractical. You're also invoking speculative, unknown attacks against the USB host driver and firmware, which I will see you with my previously invoked unknown, speculative attacks against Xen. Also, you completely ignored my suggestion of using an optical disk if you are concerned about USB.
Safest way I can think of using airgapped machines right now for encrypted email:
1. Copy received email from networked machine C to write-once optical disk.
2. Decrypt received email on airgapped machine A.
3. Compose reply on different airgapped machine B, encrypt reply.
4. Copy encrypted reply to write-once optical disk.
5. Send encrypted reply from networked machine.
This involves three physical computers, but none has to be recent or expensive. Airgapped machine A has no ability to send information to C or B, and airgapped machine B is never touched by any devices from the outside world, and also never needs to know any secret keys, since all you need to encrypt an email message is the recipient's public key. Theoretically you could type such a key in by hand, but in any case it's a once-per-recipient transfer.
I would argue using USB sticks in this scenario gives only a very slight reduction in security, but write-many optical disks would be a practical approach if you're scared of USB. I will say that compiling out obscure and unused USB kernel drivers is a good move, as is disabling USB kernel module autoloading.
StackExchange says you're wrong about USB having DMA: http://security.stackexchange....
In any case, BadUSB would require reprogramming the actual device, so I still don't think it is a practical attack vector in this scenario. Moreover, if you're really paranoid, you can use write-once CD-Rs instead of USB devices.
QubesOS is an interesting idea, but it's more complicated and therefore more likely to have bugs than airgapping a machine. You're assuming there are no bugs in Xen, for instance.
As for filesystem bugs, this code has been around for 20 years or more. There are bugs everywhere, but I think especially popular Linux filesystem drivers are likely pretty solid. But go ahead and just dd the file to the optical disk directly and don't use a filesystem if it makes you feel better.
Bugs in the filesystem driver, yes, but those are probably pretty rare I'd think. BadUSB, not really. That attack works by emulating a keyboard/mouse HID controller. If you plug your USB drive in and all of a sudden your computer starts typing things and moving the mouse on its own, you would notice immediately. Also it typically requires special hardware; a rooted box couldn't just take a real USB drive and turn it into a HID controller.
I was thinking flash drive or possibly optical disk ... couldn't there theoretically be an exploitable buffer overflow in ZModem?
- It is technically possible to air-gap the machine you use to access your email, by copying the email over from an insecure computer to the air-gapped machine.
- TAILS is great, but they probably at least try to break it since it's popular. Will they succeed? Maybe. So use an OpenBSD live CD, it's more secure anyway. Or get creative: use Whonix. The FBI's pedestrian attempt at drive-by malware would have fallen flat on its face with an adversary using Whonix.
- Firejail. Google it. Won't protect you against local kernel privilege escalation attacks, though.
Yes, contingency planning is good. Yes, single points of failure are bad. But you can get very, very good communication security if you really try.
The lessons of Liberal Arts last for a lifetime, compared to technology which is largely short lived knowledge. I'm sure you were proud of your Commodore64 knowledge like I was at the time, but that stuff all vanished. As did DOS, SunOS 2, HP-UX 9, and all of these other technologies that people said were "essential" to know. The latest application is not important when a large portion of the population can't afford it.
If you learned SunOS 2 or HP-UX 9, most of that knowledge is applicable to Solaris and modern Linux distributions today.
Uh, maybe PRIVATE schools can have content-based speech restrictions...
http://en.wikipedia.org/wiki/T...
Oh, yeah? Well, I'll make my own porn site. With blackjack! And hookers! Actually, forget the porn site. And the blackjack...
My undergrad curriculum had a class where we designed a pipelined processor, though we didn't actually build it. It was an interesting and educational experience for me, and I'm glad to have done it.
And he died more than a year after the end of his "treatment".
This. There is a good chance that Turing actually didn't commit suicide, but rather died of accidental cyanide inhalation. He had set up a chemical lab in his living space and wasn't exactly using OSHA-approved storage protocols for dangerous chemicals. His mother, at the time, said she didn't think he'd killed himself, and contemporary accounts were that he was doing pretty okay. The supposedly cyanide-poisoned apple was not tested for cyanide. None of this is conclusive.
IMO, any modern report on Turing should account for the possibility he didn't kill himself. The suicide angle makes a great story for gay rights activists, but it does a disservice to the memory of this great man to reduce him to a political talking point. The forced hormone treatment was abominable, whether or not it drove him to suicide. There's a chance it did, and a chance it did not.