I just realized that I've never linked to an article I wrote with Sebastian Rohr for Linux Technical Review earlier this year. Our article was selected to be part of the free issue preview - click here to get it (the site and the article are both in german).

One of our customers wanted to integrate their Confluence-Wiki with their Sharepoint environment. However, the sharepoint connector for confluence is (in my view) not really suited for enterprise installations because there are conflicting requirements: the confluence plugin for sharepoint (the one that is loaded into sharepoint as a plugin) only works with anonymous access (for the URI used for its XML communications with confluence: /rpc/xmlrpc) while all other URIs must be authenticated through IIS - this is a common requirement for enterprise environments, even for wikis. Anyhow, none of the authentications scenarios suggested by Atlassian are viable:

• Microsoft SSO: this is a big no-go as it stores the passwords of all wiki users in a central database (it would otherwise work, though)
• IIS Authentication: doesn't work because /rpc/xmlrpc must be accessible without HTTP authentication
• Confluence authentication: in this scenario confluence authenticates users, but this causes for "protected" resources (like images) to unloadable from the sharepoint webpart (because no authentication exists for these loaded resources)

We've come up with another solution:

• hardwire the confluence hostname to 127.0.0.1 on the sharepoint server which also runs the confluence installation
• create an IIS website for confluence (using the tomcat connector), which is bound to 127.0.0.1 and accepts requests for the confluence hostname without any HTTP authentication
• create another IIS website for confluence (using the tomcat connector), which is bound to the server's interface-IP and accepts requests for the confluence hostname while requiring HTTP authentication for all requests

Please note that this solution only works with IIS7, our attempt with IIS6 resulted in all requests being routed to the website requiring authentication.

Update: Atlassian is working on the connector to faciliate such requirements: http://developer.atlassian.com/jira/browse/CSI-449

My presentation proposal about Single-Sign-On for Full-Disk-Encryption on Linux has been accepted for FrOSCon 2009. I'll add more details once FrOSCon announced their programm.

I just installed Ubuntu 9.04 on my LifeBook P7230. I wanted a fresh install because my previous 8.10 installation was modified quite a bit as a result of my experiments and customizations.

I've become quite fond of a specific setup: encrypt the entire disk using LUKS/dmcrypt and auto-login my user into GNOME. This setup ensures that my system and its data is safe when its powered down but also gives me the same usability benefits during system startup that Windows users of Full-Disk-Encryption solutions have enjoyed for years: convenient single-sign-on after providing the correct credentials to the Pre-Boot-Authentication environment. Unfortunately, this setup works only as desired on single-user systems since LUKS is not bound to user credentials (I've previously described this here) - I am planning to release a workable solution for this scenario later this year.

Anyhow, back to my Ubuntu installation: activating the auto-login for GNOME by using gdmsetup doesn't work - the auto-login gdm instance crashes and a recovery instance (without auto-login) is started. After some analysis I've discovered a workaround: activating the auto-login by manually editing /etc/gdm/gdm.conf and restoring /etc/gdm/gdm.conf-custom to its original state (my comment on an existing issue on Launchpad).

Nope, this entry won't describe what the "Frozen Cache" concept is - it's more of an outing: I am the author of said blog & concept. The pseudonym "ACME Security" was initially chosen for no particular reason - it just sounded cool. However, as it turns out it's actually quite a fitting acronym:

ACME Security => Akkaya Consulting Makes Everything Security (Wikipedia explains the "real" ACME acronym)

What's "interesting" is that only 300 of the 13.000 visitors of the Frozen Cache blog stayed more than 60 seconds on the blog (and thus had even a theoretical chance to read a bit of what has been written there). About 12.300 left the site after less than 10 seconds. I just don't get it.

What I do understand is this: some people helped me develop this concept. Thank you guys (Pit, Jens, Philippe & Thorsten). But most of the credit should go to Peter Stuge: his mentioning of coreboot's Cache-as-RAM concept/implementation during his workshop at 25C3 sparked the whole idea.

I bought myself two Yoggie PICO Open Firewalls over the holidays. Unfortunately, these thingies don't have enough muscle to run a X desktop (assuming one desires reasonable application-performance).

I already bricked one of them by trying to optimized its boot scripts: the USB RNDIS interface won't load anymore. This leaves me with a fully functioning Linux system, to which I can't connect to. I've looked at the debug board documentation and it seems like accessing the pins for JTAG'ing the original filesystem back onto the device is straightforward - we'll see...

I've been playing with the Linux USB Gadget API on Ubuntu Hardy (2.6.24-22-generic) lately and encountered an issue with the serial gadget (g_serial). It all works nicely if the virtual USB gadget is connected locally. However, connecting the USB serial gadget to a system running inside a VMware or VirtualBox session leads to the following issue: data can be sent from the USB serial gadget device to the USB host (the Windows or Linux instance running inside VMware or VirtualBox), but data coming from the USB host will not get sent to the USB serial gadget. Other USB gadgets (g_file_storage, g_ether) work flawlessly in the same setup (data going in both directions).

I've first suspected that the issue was VMware specific, but I experienced the same issue with VirtualBox. Next, I attempted another kernel:2.6.27-9-generic from Intrepid: loading the g_serial kernel module causes this kernel to freeze immediately.

One last note: in order to use the USB Gadget API on Ubuntu one has to first recompile the USB Gadget API to use the dummy HCD USB controller (CONFIG_USB_GADGET_DUMMY_HCD=y):

	apt-get install linux-headers-2.6.24-22
	apt-get source linux-image-2.6.24-22-generic
	dpkg -x linux_2.6.24-22.45.dsc
	cd linux-2.6.24
	ln -s /usr/src/linux-headers-2.6.24-22-generic/Module.symvers
	make oldconfig
	make menuconfig # Device Drivers->USB Support->USB Gadget Support->USB Peripheral Controller=Dummy HCD
	make # CTRL-C after build of internal tools
	make M=drivers/usb/gadget/
	insmod ./drivers/usb/gadget/dummy_hcd.ko
	insmod ./drivers/usb/gadget/g_serial.ko use_acm=1

I once again lost a just completed and fairly lengthy blog entry after hitting submit due to an expired session. Arrgh. I'll write about my USB Gagdet API issues another time. I've now decided to give this plugin a chance.

I got somewhat mixed feedback about my presentation, just as I expected. There were some people who found my talk to be too shallow. I attribute this mostly to differences in expectations: It was meant to be a comprehensive introduction to the topic, nothing more or less. Still, the overall feedback is positive and I think most people learned a few new things about Full-Disk-Encryption.

On another note: Peter Stuge's presentation and workshop about CoreBoot (formerly known as LinuxBIOS) was really interesting. There's also something else that I took away from his workshop: an idea how to counter cold-boot attacks (yes, that would be really really BIG). I'll be working on a proof-of-concept implementation for dm-crypt on Linux over the next weeks.

Here it is:

Update 1: Yes, the audio and video is out-of-sync after some minutes.
Update 2: A high-resolution version is available here (audio and video are OK)

On some of my systems I'm running Ubuntu 8.04 with the root-filesystem on an encrypted LVM. Due to some USB Gadget API experiments I wanted to upgrade a system to 2.6.27, this turned out to be a bit more involved than expected.

I got the 2.6.27 kernel from a Ubuntu PPA and the following reboot stopped right after the password LVM password input, switching to TTY1 yielded an indication about the problem:

	cryptsetup: failed to setup lvm device

Since a mistyped password was out of the question as the cause of the problem after a second attempt I proceeded to investigate the init-ramdisk scripts and concluded that it's not an issue related to the encrypted device. Instead, it turned out that the LVM kernel api has changed from version 4.12.0 to 4.14.0 between kernel versions 2.6.24 and 2.6.27. As a result, I had to download the libdevmapper and lvm2 packages for Intrepid (which uses 2.6.27), extract /sbin/lvm and /lib/libdevmapper.so.1.02.1 and manually update the initrd file:

	mkdir /tmp/initrd
	cd /tmp/initrd
	zcat /boot/initrd.img-2.6.27-9-generic | cpio -id
	# copy aforementioned files from DEB packages
	find . | cpio -o -H newc | gzip -9 > /boot/initrd.img-2.6.27-9-generic initrd.gz

Et voila, problem solved. Now back to the USB Gadget API...

I ran across this gizmodo post today. The idea is simple: target computer novices with a single package that allows for a worry-free computing experience. Their offering includes the computer(, any peripherals/components if desired) and internet service.

I came up with a similar business idea: provide customers with a complete package, so they don't have to worry about actually getting up-and-running with a computer. In contrast to the above offering I was looking into a solution that would be based upon thin-client technology instead of a a full-blown computer running at the customer's end. The idea is to minimize the cost for the hardware below a certain price-level in order to make such a package financially attractive.

I set up a proof-of-concept environment consisting of:

• a TFT monitor (100 Euro - bought elsewhere)
• some thin client systems
• 2 GB compact-flash card (already had this one)
• Keyboard, Mouse (already had those too)

As it turns out, the setup is quite usable for most common computer usage scenarios (which is what I expect computer novices would mostly do): E-Mail, Web-Browsing, word processing, ...

NX is my thin-client technology of choice and as I've already said: performance was quite good. The only time a delay was noticable was when scrolling web-pages that included animations (flash, images, ...). However, getting to this point wasn't easy - the 500 MHz VIA CPU of the thin-client system had enough to do with an unoptimized X11 server setup. Therefore I adopted the standard Ubuntu installation a bit:

• Kernel Mode Linux
• X11 tweaking
• some SSH performance tweaks (not blogged)

Anyhow, we dropped this idea due to several reasons (I will not detail those here). With this blog post I want to complete the picture, as to in what context the aforementioned blog posts were written -- I also figured it was time for a new blog entry again.

• Paper finished: CHECK (it is already published on the 25C3 site)
• Slides finished: CHECK
• Flight booked: CHECK
• Hotel booked: CHECK

I've just about completed the paper for my talk about "Full-Disk-Encryption Crash-Course" at the 25C3.

In other news: I've been extremely busy and haven't had time to work on DiskCryptor at all...

Go over there and get more information about DiskCryptor: http://www.diskcryptor.de/.