Posts Tagged 'Security'

Ksplice Uptrack: a quick-test on Ubuntu 9.04 Live

I’ve been using Ubuntu 8.04 on my laptop for ages, and never had any reason to upgrade from there – “it just works, I’m done upgrading” is what I’d smugly tell people… Now, I’ve found a big reason to upgrade: Ksplice, which I mentioned the other day, put a new service up:

Ksplice Uptrack is a new service that lets you effortlessly keep your systems up to date and secure, without rebooting.

Once you’ve completed the easy installation process, your system will be set up to receive rebootless updates instead of traditional, disruptive updates.  […]

Ksplice, Inc. is proud to make this service freely available for the latest version of the world’s most popular desktop Linux distribution: Ubuntu 9.04 Jaunty Jackalope.

No more reboots, and still applying security patches as soon as they become available. That’s worth the dist-upgrade hassle.

For now, all I did was running a quick test. I had a USB stick with Ubuntu Netbook Remix 9.04 lying around, so I booted from that, hooked up the wifi (man, connecting is fast with NetworkManager 0.7-something – another reason to upgrade…), downloaded ksplice-uptrack.deb, and installed it on the Live system (you also need network connectivity to fetch some dependencies from the Ubuntu repository). This is what you get:

ksplice-uptrack updates window

There’s a little tray-icon (the one resembling a “K”…) informing you that kernel updates are available, and clicking it opens an update window. Nothing exciting to see here, actually.

ksplice-uptrack in action

Still not very exciting. The whole thing is very understated, almost disappointingly so – I mean, something this cool should look cool, shouldn’t it?

…. and everything still works after this. In fact, I’m typing this post from the Live system with the (supposedly) updated kernel. I tried shutting the lid on my D630, and it nicely went into ACPI suspend. And came back up.

Wicked.

(Small disappointment: it seems Firefox crashed between suspend and resume. Did it a second time, and again Firefox died. Third time: no problems. Not sure if this has anything to do with anything, so for now pretend I didn’t mention it.)

Cool stuff, seriously. This will be in 10.04 by default, I’ve no doubt. In case you’re looking, here’s one guy eager to work on that!

One more thing: in their FAQ they suggest a little test to demonstrate that the thing actually does something. I tried their suggestion and ran their test-thing a couple of times. But I’m off to bed now, so here’s the output, and I’ll leave calculating whether the difference before/after updates is statistically significant to you…

ubuntu@ubuntu:~$ wget -O demo.c http://www.ksplice.com/uptrack/2009-06-demo.c
ubuntu@ubuntu:~$ gcc demo.c -o demo
ubuntu@ubuntu:~$ sudo cpufreq-selector -c 0 -g performance
ubuntu@ubuntu:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
ubuntu@ubuntu:~$ sudo cpufreq-selector -c 1 -g performance
ubuntu@ubuntu:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     T8100  @ 2.10GHz
stepping        : 6
cpu MHz         : 2101.000
cache size      : 3072 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida tpr_shadow vnmi flexpriority
bogomips        : 4189.64
clflush size    : 64
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     T8100  @ 2.10GHz
stepping        : 6
cpu MHz         : 2101.000
cache size      : 3072 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida tpr_shadow vnmi flexpriority
bogomips        : 4189.57
clflush size    : 64
power management:

ubuntu@ubuntu:~$ ./demo
time to write 100 lines is 6(msec)
# ...hmmm, wait, this is a Live system...
ubuntu@ubuntu:~$ sudo mount /dev/sda3 /mnt
ubuntu@ubuntu:~$ cd /mnt/
ubuntu@ubuntu:/mnt$ sudo mkdir test
ubuntu@ubuntu:/mnt$ sudo chmod a+rwx test
ubuntu@ubuntu:/mnt$ cd test/
ubuntu@ubuntu:/mnt/test$ cp /home/ubuntu/demo .
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 49(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 54(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 64(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 60(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 75(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 72(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 62(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 65(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 80(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 52(msec)
ubuntu@ubuntu:/mnt/test$ sudo uptrack-remove --all -y
The following steps will be taken:
Remove [cdoprpi1] Performance regression in filesystem buffer code.
Remove [9xoc5qmo] Possible erroneous memory overcommit in program start.
Remove [ll9q1ymc] Multiple bugs in filesystem core.
Remove [ovniqwxh] CVE-2009-1192: Information leak in the agp subsystem.
Remove [hrxbvh0e] CVE-2009-1265: Integer overflow in the af_rose maximum user frame size.
Remove [uzolzfa2] CVE-2009-1337: kill the wrong capable(CAP_KILL) check.
Remove [xgqc9vy4] VGA console corrupts non-ASCII characters.
Remove [pdfrn6qa] Denial of service by evading CPU time limits.
Remove [c8ueseae] Symbolic link filenames under eCryptfs can produce alarming warnings in dmesg.
Removing [cdoprpi1] Performance regression in filesystem buffer code.
Removing [9xoc5qmo] Possible erroneous memory overcommit in program start.
Removing [ll9q1ymc] Multiple bugs in filesystem core.
Removing [ovniqwxh] CVE-2009-1192: Information leak in the agp subsystem.
Removing [hrxbvh0e] CVE-2009-1265: Integer overflow in the af_rose maximum user frame size.
Removing [uzolzfa2] CVE-2009-1337: kill the wrong capable(CAP_KILL) check.
Removing [xgqc9vy4] VGA console corrupts non-ASCII characters.
Removing [pdfrn6qa] Denial of service by evading CPU time limits.
Removing [c8ueseae] Symbolic link filenames under eCryptfs can produce alarming warnings in dmesg.
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 816(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 805(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 793(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 786(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 785(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 787(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 791(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 787(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 786(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 785(msec)
ubuntu@ubuntu:/mnt/test$ sudo uptrack-upgrade -y
The following steps will be taken:
Install [c8ueseae] Symbolic link filenames under eCryptfs can produce alarming warnings in dmesg.
Install [pdfrn6qa] Denial of service by evading CPU time limits.
Install [xgqc9vy4] VGA console corrupts non-ASCII characters.
Install [uzolzfa2] CVE-2009-1337: kill the wrong capable(CAP_KILL) check.
Install [hrxbvh0e] CVE-2009-1265: Integer overflow in the af_rose maximum user frame size.
Install [ovniqwxh] CVE-2009-1192: Information leak in the agp subsystem.
Install [ll9q1ymc] Multiple bugs in filesystem core.
Install [9xoc5qmo] Possible erroneous memory overcommit in program start.
Install [cdoprpi1] Performance regression in filesystem buffer code.
Installing [c8ueseae] Symbolic link filenames under eCryptfs can produce alarming warnings in dmesg.
Installing [pdfrn6qa] Denial of service by evading CPU time limits.
Installing [xgqc9vy4] VGA console corrupts non-ASCII characters.
Installing [uzolzfa2] CVE-2009-1337: kill the wrong capable(CAP_KILL) check.
Installing [hrxbvh0e] CVE-2009-1265: Integer overflow in the af_rose maximum user frame size.
Installing [ovniqwxh] CVE-2009-1192: Information leak in the agp subsystem.
Installing [ll9q1ymc] Multiple bugs in filesystem core.
Installing [9xoc5qmo] Possible erroneous memory overcommit in program start.
Installing [cdoprpi1] Performance regression in filesystem buffer code.
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 61(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 56(msec)
ubuntu@ubuntu:/mnt/test$ ./demo
time to write 100 lines is 47(msec)
ubuntu@ubuntu:/mnt/test$

Ksplice Trophée du Libre

I’ve repeatedly been whining here about how kernel-update reboots kill productivity, but I also think that delaying security updates is the worse alternative.  So I was very excited to learn about Ksplice, through the LWN announcement of the “Trophées du Libre”. Ksplice is the 2009 winner in the Security category.

A quick snippet from the project page:

Ksplice enables running systems to stay secure without the disruption of rebooting.  Specifically, Ksplice creates rebootless updates that are based on traditional source code patches.  These updates are as effective as traditional updates, but they can be applied seamlessly, with no downtime.

Ksplice currently supports updating the Linux kernel, but the core technology applies to any operating system or to user space applications.

A quick search tells me even ZDNet had already heard of this project over a year ago, so I’m half ashamed that it’s news to me, but I’m too excited to keep it to myself :)

The superiority of the distro

Shawn wrote a nice piece pointing out why developers (in particular for embedded systems) are better off running Linux than Windows. In summary, it’s all about the tools that ship with it. If we’re nitpicking then, what we’re actually talking about here is not Linux proper (the kernel), and not GNU/Linux (the operating system), but rather the distribution (whichever one that is). It’s the software stack as a whole that’s making the difference.

This is exactly what I usually tell people who ask why I’m running “this Linux thing”. It’s better suited to my needs on every level of the software stack. Of course, that’s usually way too vague to compel someone who had to ask to begin with. Examples please? My new favourite example is a security thing.

The other week I was catching up with a few long-overdue admin tasks on my parents’ PCs, mostly security updates. They’re (still) on MS Windows, and you should have seen the number of pop-ups when I logged on as admin: I don’t know how many apps, all reporting they’d like permission to fetch and install updates. Compare that to the elegance of the little warning star in the Gnome menu, or the output of a quick “aptitude upgrade”.

Big deal? I think so. I’m quite sure that that single interface to all software updates is not just more elegant, but that it’s also directly keeping systems more secure. Quoting from an old eWeek item:

For example, for the nine highest-profile Windows malicious code incidents as of March 2003, Microsofts patches predated major outbreaks by an average of 305 days, yet most firms hadnt applied the patches.

That is not a statement about Windows, or Linux. It’s a statement about human nature.

Here’s another item, from Ars:

Secunia cited data from Microsoft showing that third-party software vulnerabilities are the ones that are most frequently exploited, and said that its own data showed that users simply don’t update as frequently as they should.

Having a clear, simple, and non-crappy upgrade manager vastly diminishes these problems, because all people are lame, and the number of people that will not apply updates promptly will go up at least quadratically with the number of steps the update takes (and that’s a conservative estimate). That’s why distros will win from bare operating systems with apps dropped on top of them. It’s also why I’m going to press mom and dad to please let me replace their systems…

Is this benefit intrinsically tied to free software? In theory, no. I actually tried to pitch this idea to the Ideastorm crowd at some point. But maybe it would not work so well in practice: if MS would try to turn Windows into a distro, or would try to press other vendors into using their update manager, the anti-monopolistic regulators would be all over them in no time. So in practice, one might say this is a benefit of free software. Yay.

Eight tips for a robust Ubuntu Hardy installation

It’s been a while since I wrote stuff here – ironically I thought it was cool to get my own domain name, and then I ended up having too much fun on the GNU/Linux blog I also started. This should actually also go on the other blog, but I really wanted to write something here :)

Besides, the more Ubuntu buzz on blogs, the better, right? With the release of Ubuntu 8.04 this week, it couldn’t be a better time.

About these tips

If you’re new to the GNU/Linux operating system, this may not be for you. Nothing I’m mentioning here is complicated in any way, but it sort of assumes you’re reasonably comfortable finding your way around in Ubuntu. Instead, you may want to check out the Ubuntu website and, if you’re looking for help, the Ubuntu Forums.

The tips I’m listing here are a personal collection of things that I think might make your Ubuntu system that little bit more robust. That’s not only in a security or stability sense: I’m also thinking about protecting my system from my own tweaking and fiddling around (which you’ll inevitably do if you want to learn new things).

The tips here are most simple to act on at installation time, so I’ve sort of turned this into an installation advice list. Quite a few pointers here point back to my own writing of this week, for which I apologise. My middle name is not Narcissus, but those pieces needed a good overview to connect them, and this is it.

Preparations

1. Check hardware compatibility before you start – this is still a big problem for all free-software operating systems. By now, it’s no longer a problem the developers can really help: all hardware could be made compatible if some manufacturers weren’t so secretive about the devices they make. As a sad result, the Ubuntu Forums are full of reports on (mostly) hardware compatibility problems.

No general recommendations here, but you’ll want to be prepared. If your wifi chip vendor is an ***, it’s helpful to know which packages and other files you need to have at hand. A few pointers: HardwareSupport on the Ubuntu wiki pages, TuxMobil, UbuntuHCL.org.

2. Download a disc image using BitTorrent – it takes some persistence to find the page with the torrent links for Hardy if you start from the Ubuntu frontpage. I presume they don’t want to confuse new users. Of course, using the torrents takes some load off the main servers, helps some people, and (best of all) it’s likely faster too (especially now, just after the release date).

If you’re interested in the tips in the next section, you’ll want the alternate installer disc image.

Installation

Almost all choices you make during installation are revertible later on. I mean, you can always change your username, clock settings (local or UTC time?), which packages you want. One thing is a bit more tricky to change later, and that’s partitioning your disk(s). The alternate installer gives you some neat extra partitioning options which I want to highlight here.

3. Logical Volume Management - creating your file systems as LVM logical volumes gives you a lot more flexibility. The LVM HOWTO has a section “Benefits of Logical Volume Management on a Small System” which however doesn’t mention one of its cooler features: snapshots. LVM snapshots allow you to keep an image of your file system frozen at some point in time.

That will be useful for at least one thing: six months from now, you can take a snapshot of your root file system, upgrade to Ubuntu 8.10, and if it didn’t work well (proprietary video and wifi drivers seem to have regressions to no end), you still have a working 8.04 snapshot you can boot to use until you fixed the upgrade.

The other useful application for the home user: it’s easier to create consistent backups from a snapshot. Now, while you’re at it, I’d combine LVM with…

4. Disk encryption - reusing the rationale from this post: “if someone steals your laptop, you’ll worry a lot less about them getting access to your email and other important accounts (think browser cookies…). In case you’re wondering why the user login won’t protect you: anyone with physical access to the machine – like a thief – can just reboot and start in single-user mode, thereby getting root user privileges. Not so with an encrypted disk”.

Be sure to make frequent backups though – recovering data from an encrypted disk can be hard.

Post-installation

5. Set up version control on your configuration files - before you stroll off to your favourite geek forum and take advice from everyone and their dog to alter all kinds of stuff in configuration files under /etc, you might want to ensure that you can always get back what it said originally. Don’t get me wrong, I also try risky stuff people I’ve never met recommend to me, but I really like to keep track of those actions, too. So here you go: version control on /etc using Bazaar. As explained there, version control gives you some cool flexibility that a simple backup wouldn’t.

6. Installing additional packages: use aptitude – actually that’s not really what I want to recommend. There are quite a few APT front-ends and it’s worth checking out several, especially if you’ve never looked beyond Synaptic. So check out a few, and then decide that you like aptitude :)

Aptitude runs in a console, and has both a direct command line mode and an interactive mode. Its killer feature for me: it tracks which packages were only installed as dependencies of a package you really chose. So if you ever tell it to remove that package, it will remove its dependencies, too.

Here’s a more elaborate discussion of the tool’s merits.

7. Keep non-repo software under /usr/local – just one more quote of my own writing (promised!): “To ensure that the package manager doesn’t interfere with software you installed “manually” (i.e. not through dpkg, apt-get, aptitude, synaptic, …), there’s an article in the Filesystem Hierarchy Standard that says everything you install manually should go into /usr/local (or /opt, actually) and not directly into /usr.”

If you want to make it easier for yourself to enforce that policy, without reading every line of every install script you use, you might like to check out that post. It’s about installing software on /usr/local without full root privileges.

8. Secure your web browser – with properly set user permissions, should you now bother with such things as a firewall and a virus scanner on your desktop (laptop) machine? Probably not. (Although I wonder if everybody is sudoing all the time, won’t somebody exploit that at some point? How high are the chances that a malicious script that’s trying to use sudo hits you while a sudo session that you started is still open? Not sure how that would work, but then I’m not a seasoned malware designer).

A lot of executable code that you rake in as a normal user is stuff coming through your web browser: scripts on web pages, but also (Firefox) browser plug-ins. Malicious code in those can only destroy stuff that you have write permission for, and can only collect information that you have read permission for (which is typically most of other users’ data!), so decide if you think that’s still worrying. A good start for securing Firefox is this overview at Ubuntu Forums.

Wrap up

That’s all I could produce in my spare time this week… hope it’s useful. I’d love to hear if it is. Commenting here does not require you to leave any contact details (hint!). Thanks for reading.



Follow

Get every new post delivered to your Inbox.