Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Best idea is not to hide. (Score 1) 123

The problem is that zombies either bite and infect or bite and kill/eat. From watching the various movies and TV shows, the bite and infect starts for the first few generations of the disease but turns to bite and kill once there's a sufficient number of infected. Thus the number of people that are infected are lower and the number of people that are infected and mobile (still have legs/arms) is probably lower still. The WWZ movie makes the infection almost instantaneous which allows you to boost the number of bite and infect, but almost nobody else (even the book) shows the disease infecting that quickly.

Comment: Mr. Moynihan should have read on the (Score 1) 310

by aussersterne (#49162227) Attached to: Google Wants To Rank Websites Based On Facts Not Links

problems of epistemology, including in science.

Note that there are no shortage of facts whose veracity depends on nuanced facets of context and condition, some of which are disputed.

For example, fact or not: "Linux is a difficult operating system to use, and is a better choice for geeks and hackers than for regular users."

Or how about:

"Android is an operating system written by Google."

Or how about:

"The Bermuda Triangle region has seen an unusually high number of ship and plane disappearances over the years, and may be a particularly dangerous place to travel."

Because unless Google's algorithms are very, very nuanced in their approach, each of these is going to be seen as carrying high levels of factuality based on the preponderance of content out there, particularity in high-authority sources.

Of course, statements like the first and third are too complex for Google's rankings to evaluate and rank, and it can only work with very simple assertions on the order of "Milk is white," or "Obama is a Democrat," the it's going to do practically nothing (good or bad) at all for the rankings, since facts with this level of consensus are generally undisputed, even by those that promote falsehoods.

Comment: This shifts the weakness in Google's rankings (Score 3, Interesting) 310

by aussersterne (#49160739) Attached to: Google Wants To Rank Websites Based On Facts Not Links

from gameability (in short, SPAM) to politics. Rather than punish above-board or non-predatory websites, it will punish both subversive and innovative thought that runs well ahead of social consensus. Sure, it will also eliminate willful misinformation, but it turns Google into an inherently conservative, rather than socially innovative, force.

Can't say I think it's better. Probably not any worse, but certainly not panacea.

Comment: Re:Some Real Advice (Score 1) 88

by linuxrocks123 (#49160625) Attached to: OPSEC For Activists, Because Encryption Is No Guarantee

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 security above all other values may have its uses. It could use generic hardware drivers for the hard disk and display adapter (VESA). Ethernet would be a problem but maybe there's a standard for USB Ethernet adapters? Wayland for the graphics API instead of X, braindead-simple written-from-scratch TCP stack, you get the idea. I'll have to make that when I have time. It shouldn't be too hard.

Comment: Re:Some Real Advice (Score 1) 88

by linuxrocks123 (#49157315) Attached to: OPSEC For Activists, Because Encryption Is No Guarantee


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.

Comment: Re:Some Real Advice (Score 1) 88

by linuxrocks123 (#49156625) Attached to: OPSEC For Activists, Because Encryption Is No Guarantee

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.

Comment: Re:OpenMeetings (Score 2) 162

by i.r.id10t (#49154703) Attached to: Ask Slashdot: Whiteboard Substitutes For Distributed Teams?

Similar is Big Blue Button (a google summer of code project) - whiteboard functionality, upload files and do the "john madden football commentator thing" to them, voice and cam sharing, ability to mute, etc. And can be set up to record meetings/conferences/etc. Tested it a while back stand-along on a linode that would be $10/mo now (it was a $20/mo plan then), and it was enough to support 15 users at once as long as they all weren't connected via the same wireless link to the LAN to get out to the World

If it's not in the computer, it doesn't exist.