The BFC Computing Weblog

Anti-Virus on Voting Machines

Bill McGonigle — Mon, 25 Aug 2008 21:10:00 -0400

There’s been much made of the revelation that Diebold voting machines run an install of McAfee Anti-Virus, and that it’s caused trouble with the voting software.

The arguments against it typically boil down to:

Your voting machines shouldn’t be use for anything else
Your voting machines should be secured against anybody installing software on it
You can’t verify the operation of MAV so it could possibly tamper with votes
You should be running an operating system which is not so easily infected

Those arguments all have merit, but skip the fundamentals - the software image on a voting machine should not be running on read/write media, that is hard drives. If that basic criteria isn’t met, AV software might actually be a good idea, but missing the fundamentals is no excuse for dirty hacks.

I build my first appliance computer that could run from a CD in a CD-ROM drive in 2002. It’s neither new nor a difficult concept. When you need things to be secure, in that case under HIPAA regs, in this case for votes, you mount your media device (hard drive, flash memory, etc) with the ‘noexec’ flag, and then no software installed on the read/write media can be run from that media. Since you can’t write to the CD, software can’t be run from there either. You provide a stripped down OS image to make doing any more than the minimum very difficult, certainly requiring physical access to the machine.

This isn’t to say your machine shouldn’t be kept secure - of course it should, and the BIOS needs to be correctly configured (many of you know the security problems with certain BIOS configurations) - but read-only media and a good Q/A process obviates the need for anti-virus software. Certainly some software selection choices can make this difficult, but any good architecture starts with the requirements and works towards software selection, not the other way around. Assuming good security is a requirement.

FCC Rules on Conflict of Interest at Comcast

Bill McGonigle — Fri, 22 Aug 2008 01:53:00 -0400

Following up on my March 2007 article Conflict of Interest at Comcast, in excerpt:

Odds are those high-traffic users are downloading video. … This is directly in competition with Comcast’s other, main, business, providing video services. The amount of traffic they’re killing at (~250GB/mo) is probably just about what you need to replace a Comcast video service.

the FCC yesterday ruled:

Comcast had an “anticompetitive motive” because it delayed and blocked peer-to-peer files through applications such as BitTorrent. Such files often are high-quality video that might otherwise be watched and paid for on cable television.

and ordered Comcast to behave. As I noted earlier, this mirrors a previous decision about DSL companies monkeying with VOIP traffic.

Sun Java for CentOS 5

Bill McGonigle — Mon, 11 Aug 2008 23:03:00 -0400

Unfortunately the GNU java in CentOS 5 is too old to run modern Java code. So, you need to install the Sun version in many cases, and the jpackage method is typically the best way to do that. Two problems, though:

They don’t have an RPM that represents the current Sun version
Their version doesn’t work well on CentOS due to CentOS RPM bugs

If you don’t have them already installed, you need the RPM development tools. Something like:

yum -y install rpm-build rpmdevtools

should be sufficient. (note: I’m assuming you’re root. Most of this can also be done with a local RPM build tree and sudo, but is beyond the scope of this article).

As of this writing the current security release of the Java JDK is 1.6u7, which you can get here. Pick 32-bit linux (the only type I tested) get the linux non-RPM version, and put the downloaded ‘.bin’ file in /usr/src/redhat/SOURCES.

Now, download my updated spec file and put it in /usr/src/redhat/SPEC. If you’re on a Fedora platform or CentOS fixes their version of rpm you might want this non-CentOS spec instead. This latter one builds everything just fine on CentOS but there are UnixODBC link errors due to the rpm bug.

Now, build Java with:

cd /usr/src/redhat
rpmbuild -ba SPEC/java-1.6.0-sun-centos-5.spec

This will take a while. You should wind up with a bunch of RPM files in RPMS/i586/, like this:

-rw-r--r-- 1 root root 43085836 Aug 11 22:48 java-1.6.0-sun-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root    35903 Aug 11 22:48 java-1.6.0-sun-alsa-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root 10473773 Aug 11 22:48 java-1.6.0-sun-demo-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root 21709383 Aug 11 22:48 java-1.6.0-sun-devel-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root  1259794 Aug 11 22:48 java-1.6.0-sun-fonts-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root    26057 Aug 11 22:48 java-1.6.0-sun-jdbc-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root   807126 Aug 11 22:48 java-1.6.0-sun-plugin-1.6.0.7-1jpp.i586.rpm
-rw-r--r-- 1 root root 17692845 Aug 11 22:48 java-1.6.0-sun-src-1.6.0.7-1jpp.i586.rpm

Use yum to install them like this:

cd RPMS/i586
yum --nogpgcheck localinstall java-1.6.0-sun-*.rpm

It should find dependencies, something like this:

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 java-1.6.0-sun-alsa     i586       1.6.0.7-1jpp     java-1.6.0-sun-alsa-1.6.0.7-1jpp.i586.rpm   79 k
 java-1.6.0-sun-demo     i586       1.6.0.7-1jpp     java-1.6.0-sun-demo-1.6.0.7-1jpp.i586.rpm   15 M
 java-1.6.0-sun-devel    i586       1.6.0.7-1jpp     java-1.6.0-sun-devel-1.6.0.7-1jpp.i586.rpm   36 M
 java-1.6.0-sun-fonts    i586       1.6.0.7-1jpp     java-1.6.0-sun-fonts-1.6.0.7-1jpp.i586.rpm  2.0 M
 java-1.6.0-sun-jdbc     i586       1.6.0.7-1jpp     java-1.6.0-sun-jdbc-1.6.0.7-1jpp.i586.rpm   69 k
 java-1.6.0-sun-plugin   i586       1.6.0.7-1jpp     java-1.6.0-sun-plugin-1.6.0.7-1jpp.i586.rpm  1.6 M
 java-1.6.0-sun-src      i586       1.6.0.7-1jpp     java-1.6.0-sun-src-1.6.0.7-1jpp.i586.rpm   18 M
Installing for dependencies:
 java-1.6.0-sun          i586       1.6.0.7-1jpp     java-1.6.0-sun-1.6.0.7-1jpp.i586.rpm   68 M
 libXp                   i386       1.0.0-8.1.el5    base               23 k
 unixODBC-devel          i386       2.2.11-7.1       base              739 k
 unixODBC                i386       2.2.11-7.1       base              832 k

And yum should download and complete without errors.

Now, make sure that this new version of Java is set to be the default with:

/usr/sbin/alternatives --config java

and enjoy current java. Hopefully it won’t be long before Sun gets its code freed so next time you can just ‘yum -y install sun-java’.

First Open Source iPhone App Killed?

Bill McGonigle — Mon, 04 Aug 2008 16:49:00 -0400

Apple has pulled the popular iPhone application BoxOffice from its store without informing the author or responding to his queries.

Some have speculated that it might be at the behest of the data provider (Fandango) but the author clarified, “i’m in talks with fandango right now, and they’re thrilled with my app”.

Another possibility is that the terms of the iPhone SDK were violated by the publication of the source code for BoxOffice, which necessarily discloses parts of the iPhone API to third parties.

For those wondering if Apple was actually going to enforce the non-open-source aspect of its NDA, this may be the test case that will decide the issue.

Ideal Time Machine Hard Drive

Bill McGonigle — Wed, 23 Jul 2008 18:47:23 -0400

After coming close to losing a few years' worth of the kids’ digital photos (I had a backup, thank you, rsnapshot, but when I only have one copy it’s close to being lost) I decided to find a good full-time backup hard drive for the wife’s computer. Hers is a Mac Mini running Leopard, and it has the Time Machine backup system (think exactly like rsnapshot, but with directory-level hard links as well). So, I wanted to find a drive that would be:

Small
Quiet
Easy
Big enough to handle backup of an 80GB drive
Reliable
Cost-effective

Now, there are several drives out there that have the capacity. Most are pretty big (physically), and many of them require an AC wall wart and have fans in them. That I didn’t want.

I usually just head over to Newegg and find a case and a drive and screw something together, but they didn’t have any that met the requirements. By this time I had decided that a Firewire bus-powered drive with a 2.5” 160GB drive would be perfect, and I finally found one at MacSales/OtherWorld Computing. These guys sponsor the open source project XPostFacto which lets you run OSX on hardware Apple has abandoned (so that you can connect to the Internet without being pwned). So, good guys, and they have the 160GB OWC Mercury On-The-Go Oxford911 FireWire 2.5” 5400RPM 8MB Cache Portable Storage Solution, which, while a mouthful, is just the right drive for Time Machine backups. I didn't think I'd buy another PATA drive, but the Oxford 911 chipset is really quite well-proven, a nice feature for a backup drive. The drive comes with a cable and a pleather case:

and a CD that contains some software for something I don't need (it would be a nice green move to be able to leave out pleather cases and CD's if they're just headed to the trash heap). I plugged the drive in, the Mac asked me if I wanted to use it for Time Machine, and a few clicks later the backups started running. Nicer interface than rsnapshot, for normal mortals anyway. Now after all that, there are two complaints. First, it's in a very nice lucite case. But the case doesn't have much in the way of markings on it. There's a 3-position switch on the back, and you have to refer to the user's manual pamphlet to figure out what it does. It's a switch for Bus Power/Off/AC Power. I made a label on my label maker so I could recycle the instructions. The second point isn't about the product but the marketing. The box exclaims, "Fits in your shirt pocket!". Here's how well that works:

This particular oxford (not 911) shirt of mine has bigger pockets than any others, and it just fits. When I hear a claim like that, I think of another 2.5" drive I have:

that can almost fit reasonably in a pocket. This isn't a shirt pocket drive - maybe cargo pants. Better to just call it a really nice drive.

Complete Deniability

Bill McGonigle — Thu, 10 Jul 2008 19:51:00 -0400

I’ve written before about the limited usefulness of plausible deniability, especially in relation to software like TrueCrypt, a hard drive encryption program.

The gist of plausible deniability with TrueCrypt is this: You have multiple encrypted hard drive partitions. When your enemy forces you to reveal your keys, you reveal the low-cost key, and the enemy sees some data that he doesn’t care about and sends you on your merry way. The ‘real’ stuff you want to hide is still hidden.

This works if two conditions are true:

The enemy doesn’t know you employ a product with plausible deniability
The enemy can merely detain you

If those conditions aren’t true, you’re in big trouble. Say a violent group gets you and your data. They know TrueCrypt has plausible deniability, and they really want your data. You’re going to be tortured until they get what they want, it’s that simple, and ugly.

Now, the worst possible scenario is that you can’t give up ‘your data’ because it doesn’t exist. But only you know that. The bad guys think you have it and they know you have plausible deniability. You’re completely screwed.

For this reason I’ve been against plausible deniability systems for defending against all threats (yes, TrueCrypt would still be fine from hiding that porn you have stashed away on your home PC).

This changed when Cal Harding introduced the concept of Complete Deniability. That is, you can prove that you have no more plausible deniability.

Here’s how it can work: With TrueCrypt, you could have a utility that, once inside a locked data set, could be given a set of keys and ensure that those keys account for all readable data and all blocks of the storage device. Because TrueCrypt is open source, the bad guys can trust this utility to verify that you’re no longer hiding anything. They can review the source and compile it themselves, if they wish.

But, good news for you, you get to go home. Because even bad guys don’t like to waste their time and you’re not otherwise terribly interesting. Odds are you’re not getting your laptop back once the bad guys find your porn bank, though.

Twittervision

Bill McGonigle — Thu, 10 Jul 2008 11:19:00 -0400

Twittervision is combines Tweets and geo coding to show a realtime display of what people are Twittering. It’s quite a beautiful thing to watch, especially the 3D view.

I guess I wasn’t aware that Twitter fed all updates to third parties, so that’s something important to be aware of - it’s not just your followers who are seeing your updates.

I’m not sure it’s actually useful, but it certainly is neat, so probably it is useful to somebody.

I wonder if Twitter will be coming up with a trademark licensing program to allow apps like this to live peacefully.

Mac OS X 10.5.4 Issues

Bill McGonigle — Wed, 09 Jul 2008 11:28:00 -0400

I was hopeful that Mac OS X 10.5.4 would address previous versions’ data corruption issues, but it appears they still exist.

According to MacFixit, issues still exist with saving files to servers via at least AFP (are NFS or SMB affected?), system logging issues, firewall problems, and apparently Software Update is still buggy at applying binary deltas.

So, unfortunately I’m still not recommending 10.5 (Leopard) Client for folks who need to use network filesystems. If you’re using local disks only and don’t mind downloading the ‘Combo’ OS updates and applying them by hand, you’re likely to be fine and feature-wise Leopard has plenty to offer.

Hopefully 10.5.5 will finally quash the network filesystems problems, and nearly a year from release the OS will become widely useful.

PICT Abandoned by Apple

Bill McGonigle — Mon, 07 Jul 2008 19:30:00 -0400

I was cleaning up my hard drive today and found some screenshots I took of websites on 9/11, in Apple PICT format. Less than 7 years later, those PICT’s aren’t viewable on OSX in the Preview application (the standard image viewer). Seeing as this OS came out in 2005, it was likely abandoned then. At the time I was running the latest version of Mac OS 9, judging by the screenshots.

So, less than 4 years of support for that presumably very common file format.

I’ve converted the pictures to PNG (Using Photoshop 7, which can parse them), which as an industry standard open format ought to be recoverable for some time to come.

This has been reason #687 to avoid proprietary file formats.

Dan Grover - Speedy Recovery!

Bill McGonigle — Fri, 04 Jul 2008 02:12:00 -0400

Our friend and sometimes subcontractor Dan Grover had surgery today, and we wish him a speedy recovery.

Dan posted a pre-surgery photo today, and finally it makes sense how he’s so efficient at his work:

All the best, Dan.