Forum on Civic Information No. 2 (UCLondon 2006-11-28 18:45) "will focus on open 'civic' information. Civic information is material produced by government or other groups which is relevant to political activity by citizens." I had some experience tracking this down through the Walks Action Group and I really should write up my notes on the Freedom of Information Act (FoIA or fire) and the Access to Environmental Information Regulations (AEIR, or air) before I forget it all.

One issue that is rarely considered is how to deal with office break-ins for the purpose of espionage. I believe that this issue has been solved reasonably well for military systems, but many of the military solutions do not apply well to civilian systems - particularly the use of scary dudes with guns. Also most office environments don't have the budget for any serious security, so we want to improve things a bit without extra cost. Finally the police aren't interested in crimes where an office is burgled for small amounts of cash and items of minor value, it gets lost in the noise of junky burglaries, so prevention is the only option.

Having heard more information about such break-ins than I can report, I'll note a few things that can be done to improve the situation - some of which I've implemented in production.

The most obvious threat model is theft of hard drives. The solution to this is to encrypt all data on the drives. The first level of this is to simply encrypt the partitions used for data, support for this is available in Fedora Core 6 and has been in Debian for some time. The more difficult feature is encrypting the root filesystem, encrypting root means that important system files such as /etc/shadow are encrypted. Also if the root filesystem is encrypted then an attacker can't trivially subvert the system by replacing binaries. An unencrypted root filesystem on a machine that is left turned off overnight (or for which an unexpected reboot won't be treated seriously) allows an attacker to remove the drive, replace important system files and then re-install it. If the machine is booted from removable media (EG USB key) which contains the kernel and the key for decrypting the root filesystem then such attacks are not possible. Debian/unstable supports an encrypted root filesystem, but last time I tried the installer there did not appear to be any good support for booting from USB (but given the flexibility of the installer I think it's within the range of the available configuration options). I have run Fedora systems with an encrypted root filesystem for a few years, but I had to do some gross hacks that were not of a quality that would be accepted. With the recent addition of support for encrypted filesystems in Fedora it seems likely that some such patches could be accepted - I would be happy to share my work with anyone who wants to do the extra work to make it acceptable for Fedora.

Once the data is encrypted on disk the next thing you want to do is to make the machines as secure as possible. This means keeping up to date with security patches even on internal networks. I think that a viable attack method is to install a small VIA based system in the switch cabinet (no-one looks for new equipment appearing without explanation) that sniffs an internal (and therefore trusted) network and proxies it to a public network. This isn't just an issue of securing applications, it also means avoiding insecure protocols such as NFS and AoE for data that is important for your secrecy or system integrity.

An option for using NFS is to encrypt it with IPSEC or similar technology. AoE can be encrypted with cryptsetup in the same way as you encrypt hard drive partitions, it doesn't use IP so IPSEC won't work but it is a regular block device so anything that encrypts block devices will work. I have been wondering about how well replay attacks might work on an encrypted AoE or iSCSI device.

Security technologies such as SE Linux are good to have as well. An attacker who knows that a server has encrypted hard drives might try cracking it instead. A thief who has stolen a laptop and knows that it has an encrypted drive can keep it running until future vulnerabilities are discovered in any daemons that accept data from the network (of course if you have enough technology you could sniff the necessary data from the system bus and from RAM while it's running - but most attackers won't have such resources). I have considered running a program on my laptop that would shut it down if for a period of 48 hours I didn't login or un-blank the screen, that would mean that if it was stolen then the thief would have 48 hours to try and crack it.

Prevent access to some hardware that you don't need. If you allow the system to load all USB drivers then maybe a bug in such a driver could be exploited to crack it. Remember that in a default configuration USB drivers will be loaded when a device is inserted (which is under control of an attacker) and the device will use data from the attacker's hardware (data of low integrity being accessed by code that has ultimate privilege). Turning off all USB access is an option that I have implemented in the past. I have not figured out a convenient way of disabling all USB modules other than the few that I need, I have considered writing a shell script to delete the unwanted modules that I can run after upgrading my kernel package.

Once these things have been done the next issue is securing hardware. Devices to monitor keyboard presses have been used to steal passwords. The only solution I can imagine for this is to use laptops on people's desks and then store them in a safe overnight, unfortunately laptops are still quite a bit more expensive than desktop machines and consequently they are mostly used as status symbols in offices. Please let me know if you have a better idea for solving the key-logging problem.

For servers there is also a problem with keyboard sniffing. Maybe storing the server's keyboard in a safe would be a good idea.

Security monitoring systems are a good idea, unfortunately they can be extremely expensive. There has already been at least one recorded case of a webcam being used to catch a burglar. I believe that this has a lot of potential. Get a webcam server setup with some USB hubs and cameras and you can monitor a small office from all angles. When the office is empty you can have it GPG encrypt pictures and send them off-site for review in the case of burglary. You could also brick the server into a wall (or make it extremely physically secure in other ways) so that the full photo record would be available in the case of damaged phone lines, and to give more pictures than the upload bandwidth of an ADSL link would allow (512Kb/s doesn't allow uploading many pictures - no-where near the capacity of a few high-resolution web-cams).

This is just a few random thoughts, some things I've done, some things I plan to do, and some that just sound like fun. I expect comments telling me that I have missed some things. I may end up writing a series of articles on this topic.

PS I've uploaded day 32 of the beard (which was taken yesterday). Last night at a LUV meeting I was asked to stand in front of the audience to show them my beard. I had imagined that they might have seen it enough through my blog, but apparently not.

Yahoo quietly released the del.icio.us Bookmarks Firefox extension the other day, which does something I’ve been wanting del.icio.us to do for a very long time, namely fully integrate with Firefox bookmarks. Like a lot of people, I gave up long ago on using bookmarks to keep track of interesting sites (del.icio.us fills that role quite nicely for me now). Still, the process of bookmarking something in del.icio.us had always been a bit tedious. The old del.icio.us extension helped a little (it would prefill the Notes field with whatever text was currently selected), but it was still missing some pretty important functionality (the popup didn’t display your existing bookmarks like the bookmarklet did). And even with del.icio.us, I still used browser bookmarks for quick access to the sites I frequent most via the bookmarks toolbar. The new extension integrates with browser bookmarks almost perfectly—with a few big exceptions. It’s easy to import your existing bookmarks (the extension even offers to give them a special tag and mark them “private” so as not to clutter your existing bookmarks, as well as mines existing tags to try to categorize what’s imported automatically). The tag button is much more functional now and offers to show your existing tags, my big complaint about the previous extension. And the new extension nicely replaces the bookmarks toolbar and allows you to specify and even order your favorite tags, effectively replacing the last useful vestiges of browser bookmarks with a del.icio.us backed equivalent that also allows you to give other tags to those bookmarks. That said, there are some pretty significant problems with the new extension, the biggest in my view being that there’s no way to change the sort order of the bookmarks within your favorite tags. Essentially, this makes the bookmarks toolbar far less useful—selecting “apps”, which used to contain a manually sorted list of web applications I frequently use, now contains a list of bookmarks in seemingly random order (it’s actually reverse chronological, but that’s not particularly useful for the bookmarks toolbar). The tags submenu under bookmarks doesn’t have any hierarchy to it—all tags are at the top level, making getting to a tag later in the alphabet quite tedious (I’d rather see a “tags starting with a”, “tags starting with b”, etc. structure). And, at least in my early experimentation, synchronization doesn’t always work as expected—changes to my local bookmarks seem to propagate back to del.icio.us, but the reverse doesn’t always seem to be true. Still, it’s a promising start, and I’m going to keep using it. If they don’t fix the sort problem soon, though, I’ll likely revert to Google Browser Sync. (Interestingly, Google Browser Sync is listed as incompatible and is disabled on installation of the del.icio.us extension, even though it technically does other things, like synchronize cookies and passwords. This would seem to be a smart move on Yahoo’s part—challenge Google’s foothold in the browser and create a foothold of its own.) A few parting thoughts: I’ve only installed this extension on my laptop thus far, and it’ll be interesting to see how well synchronization of my bookmarks works across machines (will it synchronize my favorite tags etc., allowing me to maintain a consistent browser toolbar? etc.). Finally, I’d like to see the “tag” function better integrated with the browser, perhaps the way Flock does it (a Google like star next to the address bar that reflects the current site’s del.icio.us state).

We are fortunate in Massachusetts to have fairly simple paper ballot voting machines (rather than electronic touch-screen voting machines, see, e.g. Ed Felten’s comprehensive critiques of electronic voting). When I voted this morning, however, the machines were not feeding the ballots. Instead, the poll workers were piling the ballots up on top of the machines, apparently to be fed into the machines when they figured out how to get them to work. When I left (about 90 minutes after the polls opened), they had gotten to the point of triple-checking whether the machine was plugged in. I felt a bit uneasy leaving my secret ballot in a big open pile. It was somewhat reassuring that a police officer seemed to be in charge of watching the ballots, but I still will always have a slight reservation as to whether or not my vote was actually counted. Don’t they get to work early to test the machines? Perhaps do a few dry runs, kick the tires, etc.? Other industries seem to have figured out most of these problems a long time ago — for example, I can’t remember a single instance in my entire life of encountering a paper jam (cash or receipt) with an ATM. (I’m sure it does happen, just rarely enough that it’s never effected me). If a system is mission critical, it should be possible to get the failure rate down to something more acceptable.

As a matter of principle, I try to avoid any conflict of interest between my release manager and alpha porter hats, by e.g. deferring to my co-RM when there's a question of whether a particular compromise should be made to benefit alpha's releasability. Where Dunc Tank is concerned, that means some changes in priorities for bugs to work on, since I'm being paid to try to get etch out in a timely manner, not to keep the alpha port afloat. OTOH, alpha is not the only arch that produces RC bugs needing release team attention, and Dunc Tank only dictates how I spend 40-50 hours of my week -- which means another 20-30 hours a week of Debian work that I can set my own priorities for, right? So the theme ingredient over the weekend was: problems on the alpha port.

• NMUed qdbm with a workaround for the long-standing build failure, helpfully filed by Aur lien G r me as bug #394626; this in theory makes it possible to get the fix for bug #367374 into testing by the normal route, but now hyperestraier and qdbm both have a very strange build failure on alpha and mips...
• It took quite a bit of time to track down RC bug #378346 in gail, what with all the libraries that needed to be rebuilt from experimental. Turns out to be a garbage collection issue fixed upstream. Who knows why this only showed up on alpha?
• I also poked a bit at the kernel for alpha, for the possibility of supporting installation on TITAN and TSUNAMI class systems. It looks promising to have this in for etch, which would be nice because these are higher-end alphas that could extend the lifetime of the alpha port overall if we can manage to turn that support into something like a new porter machine...
• Then I spent some more time poking at the kernel thanks to 397139, which showed that the fixes to get the kernel building under gcc-4.1 on alpha didn't quite do the trick.

I'll give myself 4/5 points for presentation, 5/5 points for use of the theme ingredient, and 6/10 points for taste (this plastic computer case needs more salt). And of course, waiting for Debian kernel packages to compile on an LX164 alpha gives one time to do other things too, like following through on the RC bugs that the BTS has wrong version-tracking information for, and preparing an NMU here and there. Less than 200 RC bugs left now, and dropping daily!

After the ambiguous MS-Novell deal (Received a lot of bad press, but I'm still not so sure in the long term. It might be bad for Novell and SuSE, but it might be good for Free Software as a whole), here's a piece of news that is hopefully less beset with snares: Flash becomes more open: Adobe donates some code to the Mozilla foundation. Now the only part that bothers me is that this likely means the Mozilla license will be used, which is AFAIK GPL-incompatible, which means that Konqueror will not get native flash in the foreseeable future now. Especially because I think that this move will cause work on the free flash player front (Gnash, and I believe there were others) to slow down. Update: MJ Ray corrects me, thanks - Mozilla code is multi-licensed MPL, GPL, LGPL. So integrating in Konqueror is, in theory, no license problem.

In front of the City Hall, there is this piece of art. A bus driver who often drives me from work commented recently that the shirts are probably dry by now. Similar comments have been seen in the regional newspaper letters to the editor.

I just got back from 4S, which happens to be one of my favorite of the large professional association conferences. Ok, 15 minutes to deliver talk is the equivalent of being treated as canned sardines, and thus totally unpleasant, but I feel like I can go to most any talk and find it relevant or interesting to my own work. I t is certainly more manageable too in terms of size than something like the AAAs which also gives you a paltry 15 minutes to present and worse, the association has been treading in some ethically problematic territory lately, so much so, I would rather throw my money to the other AAA. While in Vancover, my Internet access was near to nothing (I was staying with a friend who I have not seen since the summer of 2002, but alas, thanks to chatting we have been in pretty consistent contact). When I came back I came across some discouraging but not so surprising new news on the AAA and their cowardly decision to fight the FRPAA that would mandate open access for articles derived from federally funded research… The cherry on top of the cake was they dissolved the AnthrSource Steering Committee formed precisely to figure out how to open up access, no less! Alex Golub, a Savage Minds blogger, and a now ex-member of AnthroSource committee has written an excellent roundup of the story (link above) and Peter Suber, also has two very nice summaries, including links to the appropriate documentation. This year since I am curtailing my time on the conference circuit, I decided not to go to the AAA conference because frankly I am totally annoyed with the professional organization. I am usually quite proud to be or at least amused after I tell folks that I am am anthropologists (most react as if I had decided to embark on some real courageous path) but I am quite embarrassed about the association that is supposed to represent my interests and the profession at large. The links on SM point to and flesh out the problems with AAA’s refusal to jump on an exciting opportunity to free up some knowledge but I want to just emphasize three of the most problematic parts of their decision: 1.The most offensive part is that in reality the proposed bill is quite conservative in so far as it only asks for what should already be (a) given. That is, if the government is using tax dollars to fund research, it has every right to demand the fruits of such scholarship is made available to tax payers. Right? Given the neoliberal moment we are in, in which the government is retrehcnhing on all sorts of supports, this bill is admirable and I am afraid that if it does not pass it can be easily used by conservatives to justify future cuts of such funds. And given the very uncontroversial nature of the bill, it is not surprising that so many of the social science and humanities associations did not protest the bill… Anthropology sticks out as a sore sore thumb in fact. 2. The AAAs deployed FUD tactics to justify their position saying that open access would jeopardize peer review… Sigh. That is just so off the mark and the AnthroSource steering committee letter addressed this point well. 3. Many anthropologist know first-hand how appalling access outside of Europe, US, Australia, Japan etc, can be, even for academics and thus, AAA’s lack of support for this is also implicitly sanctions the North South Division that have plagued the field and all of academia so long. And for a field that has often been very thoughtful about these power/knowledge dynamics, it is doubly even more stinging… Is there really such a strong disconnect between the association and discplinary ethical currents?

I'd like to get a Bluetooth keyboard for my MythTV machine. It'd be more convenient to drive it from the couch instead of crouching down in front of the TV on the existing USB keyboard. Thing is, I'm paranoid about typing passwords over the air. Most of the wireless keyboards at Fry's are either IR (I'd be happy with this apart from the line-of-sight requirement) or running on some 27Mhz frequency I've never heard of, and so am rather wary of. I'm assuming Bluetooth will be a little more secure given that it supposedly encrypts the communication, but I'm trying to determine how flawed or not that encryption is. This article was an interesting read, but didn't really address any of the cryptography involved. It suggests that if I don't leave everything discoverable (which I wouldn't) and attackers aren't able to narrow their search space by knowing what sort of keyboard I have (which I'm guessing they could sniff anyway) that just sequentially searching the Bluetooth MAC address space would take over 1000 days. So I'm assuming that if the keyboard is in use, then its MAC address is going to be known, so the question comes back around to the strength of the encryption... Apple's website says it's 128-bit. I guess I could get the gear and do some investigating myself, but I'm hardly a l33t h4x0r, so my self-penetration test would hardly be as comprehensive as being under attack from someone who was.

I recently started to be aware of a problem in our family. Ever since we configured Mythgame to run Xmame games, we started to ignore native Linux games. This is a shame, because often the quality of such games is much higher, and besides, they are open source, which I strongly believe in. I looked around for help configuring Mythgame to run Linux games, and was unable to find a way to make a game player that would play any Linux game. So I devised the following solution: Step 1: Set up directories for pseudo-roms, command switches and snapshots

mkdir /usr/share/games/roms
mkdir /usr/share/games/switches
mkdir /usr/share/games/snaps

Step 2: Define a player in Mythgame

Player name: Linux
Type: OTHER
Command: %s  cat \ dirname %s\ /../switches/\ basename %s\ 
Rom Path: /usr/share/games/roms
ScreenShots: /usr/share/games/snaps

Step 3: Populate the directories with data

cd /usr/share/games/roms
ln -s /usr/games/oolite
ln -s /usr/games/starvoyager
cd /usr/share/games/snaps
cp ~synrg/snaps/oolite.png .
cp ~synrg/snaps/starvoyager.png .
cd /usr/share/games/switches
touch oolite
echo "-f" >starvoyager

Step 4: In Mythgame, “Scan for Games” Step 5: Play!

I've been after a python library to mess with lucene indexes for a bit, we use/write a fair few things that use lucene at the backend at work, and just occasionally it would be very useful to be able to fiddle in them (read: search from the command line) without having to do the "write java, compile, test, recompile because you got something wrong, retest, and again" type loop for simple things. Using X11 Forwarding over ssh over a shared with the rest of the office 2M line to use Luke on the indexes is just not fun at all! So, now that I've got pylucene compiled and know the right options (ish), and it compiles on Debian Sarge (both i386 and amd64 variants), I might just build me a package for installing on our servers so that there's an "easy" option for us sysadmin types that just need stuff that we can use, quickly, without messing about! Semi-planning writing a luke-alike using PyLucene and the ncurses library to make it easier to diagnose/look in to the indexes on remote servers, but that's not going to happen this week! Quite impressed with the speed though - looks *fast* - but then, I suppose if you compile the Java using gcj to get native code, then you can expect it to be a *bit* quicker than running in the vm, right? At least, that's what I'm attributing it to at the moment, well, that and python startup time is likely to be a little bit quicker than java startup time. Also, in my travels, I found Divmod Xapwrap, which is a python library round Xapian which seems to be another (interesting) full text indexing engine. Haven't played with that yet - but could be worth a look in the future. Core library written in C++ so should be reasonably quick. The bit that I like the looks of though is """Xapian can search across several databases as easily as searching across a single one. Simply call Xapian::Database::add_database() for each database that you wish to search through.""" which sounds very useful if you start thinking about distributing indexes across a number of machines. I've not read enough Lucene documentation to know wether you can do a similar thing there. Right - enough of that - time to put things back together in the office and go home (again!). Hopefully tomorrow morning I won't be rudely awoken at 5.30am by someone asking a question that could have been better asked via e-mail (where "better asked" means "wouldn't have woken me up and annoyed the hell out of me because I couldn't get back to sleep", though - I did then play with some things and watched American Pie: The Wedding before heading in to the office the first time round...).

Today I had problems trying to fix the versioning information of bug #343593. Neither the correct command notfound 343593 4.2.26-2 nor an unversioned reopen made the bts forget the wrong "found in 4.2.26-2". Jeroen told me of a heavier boot to kick the bts with: reassigning somewhere else and back again. This worked nicely. Documented here, so I will be able to look it up later.

I had an exhausting and stressing weekend. We had a long long holiday this week in Mexico. Some people had the week until Tuesday and had from Wednesday to Sunday off, because of the Day of the Dead celebration (being Nov 1st and 2nd, and taking Friday 3rd also). I didn’t have any classes, but the Superior Algebra teacher made us attend an exam on Friday and Saturday (9 am and 8 am, respectively). Some of my friends were high and drunk from Tuesday afternoon and will remain that way until tomorrow, while I had to stay at home and work stressing for my poor understanding on the class, trying to study with tons of things on my head, etc. This so much sucks. Anyway, last week, Raquel, Tato, Javier and a friend of Tato managed to go to Yeah Yeah Yeahs‘ concert, which was fucking amazing. I love Karen O, her sex appeal and the way she does to put people in the mood is great and lovely. Unfortunately, Rach hasn’t put the pics (we got her digital camera inside the building but was discovered by the staff and forced to put it on a stuff hold table, fuckers) yet, I hope she does soon The best moment of the concert: Date with the Night. Next weekend, the Corona Music Fest will take place in the Azteca stadium, which has me anxious. I can’t wait to watch The Mars Volta on stage. Other nice bands I’m expecting to watch are NOFX, Clap Your Hands Say Yeah, Resorte, La Gusana Ciega and the Nortec Collective. Here’s the flyer: