The blog is dead, long live he blog.
This blog has moved. It’s new place is: www.cleeus.de/w/blog/ or for the rss feed: www.cleeus.de/w/feeds/blog.xml
This blog has moved. It’s new place is: www.cleeus.de/w/blog/ or for the rss feed: www.cleeus.de/w/feeds/blog.xml
I just tagged and released wiki2beamer 0.9.2 which is a maintenance/bugfix release for the new features val and julius introduced with 0.9. I also added a new example presentation (did the old ones even work?). So if you need to prepare slides, make sure to get the latest wiki2beamer version from sourceforge.
Ah, and we also have a shiny new website
oldschool, huh? ;)
As I’ve got a new laptop (a tiny EeePC) I used the chance to try gentoo hardened on the desktop. For those who don’t know: Gentoo hardened is a Gentoo Linux flavour where all packages are compiled with stack smashing protection (SSP) and address space layout randomization (ASLR) support. This makes the system a pretty hostile environment for attackers. So far everything went good and I have a fine gnome desktop running. The only major glitch is that python C extensions (ctypes) don’t work because the python runtime uses a bad mmap which would violate the general W^X policy enforced by the PaX kernel patches. But that bug is reported upstream and can and will be fixed.
Another security measure hardened takes is the so called relro linking. Usually when you link your executable binary against a shared library (.so) the dynamic linker loads symbols as they are needed (lazy). For this and the general dynamic linking process to work, references to dynamically exported symbols have to go through an indirection process. One part of this indirection mechanism on IA32 and AMD64 is the GOT, the global offset table. Think of it as a table where you can look up the addresses of symbols (not quite correct though). When the dynamic linker works in lazy mode, it fills out entries in the GOT as needed. Therefore the GOT must be writeable memory.
Now if an attacker manages to insert code into a running process and then tries to transfer control to this code one convenient way to achieve this would be to write into the GOT and manipulate an address there. Therefore we don’t really want the GOT to be writeable. But for this to work, lazy binding has to be disabled. That’s done with the ldd linker flags -z now
and -z relro
. -z now
advises the linker to resolve symbols on load time and not to use lazy binding. -z relro
makes the linker mark the GOT read-only.
Now while this is a cool defensive feature for security, it’s terrible for desktop performance. Every program loads all of it’s libraries on load time which slows down load times. I didn’t do any measurements but my HDD got pretty busy when I started heavy GUI programs. Combined with a slow laptop HDD this is no fun.
But there is a device in this little laptop that is unused most of the time anyway and could help: the SD-card reader. Given a good controller attached to the USB2.0 port and a fast SDHC card, it could somehow serve as a cache for /usr
90% of the systems libraries. So I bought a fine class 10 16GB SDHC card and put it into the slot. dd reported 20MB/s write speed. Combined with excellent random-access behaviour, this should be enough to improve the situation.
Now the idea is to somehow redirect access to /usr onto the SD card. There already are solutions out there. Google for mcachefs. Mcachefs is a fuse filesystem written in C that buffers accessed files on another filesystem that may be a solid state disk. But mcachefs is alpha-sate software and has known bugs. So I needed to go for something simpler. Writing my own python fuse filesystem seemed like a lot of work and the extra fuse overhead is something I’d like to avoid if possible anyway.
So I went for something more simple: I just copied /usr over to the SD card and mounted it over /usr in ro mode. The problem is, you will never be able to unmount this and access your real /usr (e.g. to install new packages) as long as there are processes running in the background with open files from /usr. So this was no option either. To be able to switch back and forth between the read-only /usr cache and the real read-write /usr both must be mounted and we need something to decide what to use. Symlink anyone? :)
That’s the solution where I’m now: Move your /usr to /usr.real/ and create a symlink named /usr that pointers either to /usr.real/ or /fscache/usr/. To make things more comfortable I created a nice gentoo init script.
/etc/init.d/fscache start #set up the mount and symlinks
/etc/init.d/fscache stop #switch the symlink back to /usr.real/
/etc/init.d/fscache sync #run an rsync that syncs /usr.real/ into /fscache/usr/
To use it, you have to setup your SD card, rename /usr to /usr.real and create and initial symlink /usr -> /usr.real/ (it won’t do anything if /usr is a directory).
Here is the code: http://pastebin.com/zw10p6TR
As I really need to get accustomed with GNU autotools, I was looking for some introduction docs. There is a free book from G. Vaughan et.al. (”The goat book“) but it’s a bit outdated and also quite comprehensive.
I just needed something to understand how it all works. Now what I stumbled uppon, is this fine online-book: “Autotools: a practitioner’s guide to Autoconf, Automake and Libtool” by John Calcote. It’s available at the usual bookstores as hardcover or e-book for some bucks.
And it’s also available in an unrevised, unfinished, work-in-progress HTML version here. That’s good enough for me, if there wasn’t that ugly HTML. Now theoretically, one could write a script that generates LaTeX code which would give a fine printable PDF. Such a script may even download everything it needs on the fly. And guess what, such a script already exists. You’re just not allowed to use it, ofcourse.
Solved what’s probably everbodys most neglected problem: backups (or better their absence).
It definitly was a very relaxing moment when I finished the first backup. Rsnapshot is certainly the tool to use for such home backup purposes. It allows you to have multiple virtual full snapshots of the system while only needing the space of the first full backup plus all your changes (it uses hardlinks for unchanged files). One thing I noticed: As I’m a bit of a paranoid, I set the disc encryption algorithm to AES256 in contrast to dmcrypts default AES128 setting. Now it seems like that takes up a considerable amount of CPU cycles more then AES128 (no real measurement, just quick observation). The result is that on my Atom 330 board, the encryption process runs at 100% CPU usage, eating up a full core and I only get 15MB/s writing speed (as opposed to 30MB/s on a Core2Duo 1.6GHz — maxing out the USB port). It’s still OK, it’s just that I don’t even have to bother using the eSATA port with the system. The good thing is, that on the next weekly backup, the disk speed will not matter very much as only the diff will get rsynced :)
Now … my nights will be much better, I think :)
And if you don’t have home backups yet, I hope your nights will be very restless!
and a personal update: after some struggling, I will go to work at 9:00 today. Finally. :)
Gentoo users compile their stuff on their own. This is a fun thing to do and provides you with a lot of flexibility. Every gentoo system is unique. Sadly this sometimes is exposed to the internet. For example Firefox contains the compile-date in it’s useragent string. Goodbye privacy.
Then again, we can easily fix this. Take a common useragent from useragentstring.com and paste it into the “general.useragent.override” option in the about:config settings editor of firefox. (If the setting does not exist, create it.) Done.
You can check your uniqueness on the EFF Panopticlick site. I reach a level of “one in 13,247 browsers have the same fingerprint as yours” (which is pretty good already). This is with a Windows-Firefox 3.6.3 useragent string and javascript disabled.
This is more or less a reblog from Joel on Software:
Kathy Sierra at Business of Software 2009
She explains how businesses get successful. Nothing more, nothing less. And I think she is right.