As part of my ongoing effort to provide grsecurity patched kernels for Debian, I gave a talk this morning at Kernel Recipes 2015. Slides and video should be available at one point, but you can find the former here in the meantime. I'm making some progresses on #605090 which I should be able to push soon.
Kernel recipes 2015: Hardened kernels for everyone
WPS and Network Manager
So, everybody knows that WPS (Wi-Fi Protected Setup) is broken. But sometimes, you don't own the access point, and you'd just want the wireless to work. That happens for example when you're a guest in some place using an Orange Livebox and you don't have the WPA passphrase (usually because it's written somewhere you don't have access too, or because someone forgot to tell you).
Liveboxes WPS is the “press button” thing: you press a button on the front for one second, then any device can connect in the next two minutes. That works fine with Android devices, for example, but it didn't work with my laptop and NetworkManager, which doesn't support WPS at all.
Fortunately, the underlying piece of software (wpa_supplicant) does support WPS, and even the “push button” style. And you can nicely ask it to reveal the passphrase to you with the following trick.
- Disconnect NetworkManager from the network, disable the wireless link, stop it; just make sure wpa_supplicant is not running;
- Put a stub wpa_supplicant.conf file with only the following content:
- Start wpa_supplicant in the foreground with your stub config file:
wpa_supplicant -iwlan0 -c wpa_supplicant.conf
- Start wpa_cli
- Scan the network:
- Get the results:
scan_resultsand identity the bssid of the Livebox
- Press the WPS button on the Livebox
wps_pbc <bssid>; some text should appear in the wpa_cli window, and it should eventually connect successfully (at that point you can even run a dhclient on wlan0)
The last command will update your stub configuration file, adding a new network block with the passphrase in the clear. You can then use that passphrase inside Network Manager if it's more convenient for you.
There might be something easier, but at least it worked just fine for me during the holidays.
Followup on Debian grsec kernels for Jessie
So, following the previous post, I've indeed updated the way I'm making my grsec kernels.
I wanted to upgrade my server to Jessie, and didn't want to keep the 3.2 kernel indefinitely, so I had to update to at least 3.14, and find something to make my life (and maybe some others) easier.
In the end, like planned, I've switched to the make deb-pkg way, using some scripts here and there to simplify stuff.
The scripts and configs can be found in my debian-grsec-config repository. The repository layout is pretty much self-explaining:
The bin/ folder contains two scripts:
- get-grsec.sh, which will pick the latest grsec patch (for each branch) and applies it to the correct Linux branch. This script should be run from a git clone of the linux-stable git repository;
- kconfig.py is taken from the src:linux Debian package, and can be used to merge multiple KConfig files
The configs/ folder contains the various configuration bits:
- config-* files are the Debian configuration files, taken from the linux-image binary packages (for amd64 and i386);
- grsec* are the grsecurity specifics bits (obviously);
- hardening* contain non-grsec stuff still useful for hardened kernels, for example KASLR (cargo-culting nonwidthstanding) or strong SSP (available since I'm building the kernels on a sid box, YMMV).
I'm currently building amd64 kernels for Jessie and i386 kernels will follow soon, using config-3.14 + hardening + grsec. I'm hosting them on my apt repository. You're obviously free to use them, but considering how easy it is to rebuild a kernel, you might want to use a personal configuration (instead of mine) and rebuild the kernel yourself, so you don't have to trust my binary packages.
Here's a very quick howto (adapt it to your needs):
mkdir linux-grsec && cd linux-grsec git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git clone git://anonscm.debian.org/users/corsac/grsec/debian-grsec-config.git mkdir build cd linux-stable ../debian-grsec-config/bin/get-grsec.sh stable2 # for 3.14 branch ../debian-grsec-config/bin/kconfig.py ../build/.config ../debian-grsec-config/configs/config-3.14-2-amd64 ../debian-grsec-config/configs/hardening ../debian-grsec-config/configs/grsec make KBUILD_OUTPUT=../build -j4 oldconfig make KBUILD_OUTPUT=../build -j4 deb-pkg
Then you can use the generated Debian binary packages. If you use the Debian config, it'll need a lot of disk space for compilation and generate a huge linux-image debug package, so you might want to unset CONFIG_DEBUG_INFO locally if you're not interested. Right now only the deb files are generated but I've submitted a patch to have a .changes file which can be then used to manipulate them more easily (for example for uploading them a local Debian repository).
Note that, obviously, this is not targeted for inclusion to the official Debian archive. This is still not possible for various reasons explained here and there, and I still don't have a solution for that.
I hope this (either the scripts and config or the generated binary packages) can be useful. Don't hesitate to drop me a mail if needed.
Xfce 4.12 in Debian sid
So, following the Jessie release, and after a quick approval by the release team for the 4.12 transition, we've uploaded Xfce 4.12 to sid and have asked the RT to schedule the relevant binNMUs for the libxfce4util and xfce4-panel reverse dependencies.
It went apparently well (besides some hickups here and there, lilke some lag on sparc, and some build-failulres on hurd). So Xfce 4.12 is now in sid, and should migrate to Stretch in the following weeks, provided nothing release critical is found.
3.2.68 Debian/grsec kernel and update on the process
It's been a long time since I updated my repository with a recent kernel version, sorry for that. This is now done, the kernel (sources, i386 and amd64) is based on the (yet unreleased) 3.2.68-1 Debian kernel, patched with grsecurity 3.1-3.2.68-201503251805, and has the version 3.2.68-1~grsec1.
It works fine here, but as always, no warranty. If any problem occurs, try to reproduce using vanilla 3.2.68 + grsec patch before reporting here.
And now that Jessie release approaches, the question of what to do with those Debian/grsec kernel still arrise: the Jessie kernel is based on the 3.16 branch, which is not a (kernel.org) long term branch. Actually, the support already ended some times ago, and the (long term) maintainance is now assured by the Canonical Kernel Team (thus the -ckt suffix) with some help from the Debian kernel maintainers. So there's no Grsecurity patch following 3.16, and there's no easy way to forward-port the 3.14 patches.
At that point, and considering the support I got the last few years on this initiative, I don't think it's really worth it to continue providing those kernels.
One initiative which might be interesting, though, is the Mempo kernels. The Mempo team works on kernel reproducible builds, but they also include the grsecurity patch. Unfortunately, it seems that building the kernel their way involves calling a bash script which calls another one, and another one. A quick look at the various repositories is only enough to confuse me about how actually they build the kernel, in the end, so I'm unsure it's the perfect fit for a supposedly secure kernel. Not that the Debian way of building the kernel doesn't involves calling a lot of scripts (either bash or python), but still. After digging a bit, it seems that they're using make-kpkg (from the kernel-package package), which is not the recommended way anymore. Also, they're currently targeting Wheezy, so the 3.2 kernel, and I have no idea what they'll chose for Jessie.
In the end, for myself, I might just do a quick script which takes a git repository at the right version, pick the latest grsec patch for that branch, applies it, then run make deb-pkg and be done with it. That still leaves the problem of which branch to follow:
- run a 3.14 kernel instead of the 3.16 (I'm unsure how much I'd lose / not gain from going to 3.2 to 3.14 instead of 3.16);
- run a 3.19 kernel, then upgrade when it's time, until a new LTS branch appears.
There's also the config file question, but if I'm just using the kernels for myself and not sharing them, it's also easier, although if some people are actually interested it's not hard to publish them.
LXCs upgrade to Jessie
So I started migrating some of my LXCs to Jessie, to test the migration in advance. The upgrade itself was easy (the LXC is mostly empty and only runs radicale), but after the upgrade I couldn't login anymore (using lxc-console since I don't have lxc-attach, the host is on Wheezy). So this is mostly a note to self.
auth.log was showing:
Mar 25 22:10:13 lxc-sync login: pam_loginuid(login:session): Cannot open /proc/self/loginuid: Read-only file system Mar 25 22:10:13 lxc-sync login: pam_loginuid(login:session): set_loginuid failed Mar 25 22:10:13 lxc-sync login: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Mar 25 22:10:13 lxc-sync login: Cannot make/remove an entry for the specified session
The last message isn't too useful, but the first one gave the answer. Since LXC isn't really ready for security stuff, I have some hardening on top of that, and one measure is to not have rw access to /proc. I don't really need pam_loginuid there, so I just disabled that. I just need to remember to do that after each LXC upgrade.
Other than that, I have to boot using SystemV init, since apparently systemd doesn't cope too well with the various restrictions I enforce on my LXCs:
lxc-start -n sync Failed to mount sysfs at /sys: Operation not permitted
(which is expected, since I drop CAP_SYS_ADMIN from my LXCs). I didn't yet investigate how to stop systemd doing that, so for now I'm falling back to SystemV init until I find the correct customization:
lxc-start -n sync /lib/sysvinit/init INIT: version 2.88 booting [info] Using makefile-style concurrent boot in runlevel S. hostname: you must be root to change the host name mount: permission denied mount: permission denied [FAIL] udev requires a mounted sysfs, not started ... failed! failed! mount: permission denied [info] Setting the system clock. hwclock: Cannot access the Hardware Clock via any known method. hwclock: Use the --debug option to see the details of our search for an access method. [warn] Unable to set System Clock to: Wed Mar 25 21:21:43 UTC 2015 ... (warning). [ ok ] Activating swap...done. mount: permission denied mount: permission denied mount: permission denied mount: permission denied [ ok ] Activating lvm and md swap...done. [....] Checking file systems...fsck from util-linux 2.25.2 done. [ ok ] Cleaning up temporary files... /tmp. [ ok ] Mounting local filesystems...done. [ ok ] Activating swapfile swap...done. mount: permission denied mount: permission denied [ ok ] Cleaning up temporary files.... [ ok ] Setting kernel variables ...done. [....] Configuring network interfaces...RTNETLINK answers: Operation not permitted Failed to bring up lo. done. [ ok ] Cleaning up temporary files.... [FAIL] startpar: service(s) returned failure: hostname.sh udev ... failed! INIT: Entering runlevel: 2 [info] Using makefile-style concurrent boot in runlevel 2. dmesg: read kernel buffer failed: Operation not permitted [ ok ] Starting Radicale CalDAV server : radicale.
So, I also got myself a new toy. My current ThinkPad is a bit ancient, but still sturdy. It's an X201s from 2010 (brought refurbished), and it's still working pretty fine, but eh, I couldn't resist.
The X230 was nice, but didn't have a large resolution screen (1366×768). The X240 brought a full HD (1920×1080) IPS screen, but lost the hardware trackpoint buttons. Finally, the X250 brings back the buttons, still have a nice screen (not qHD or some other trendy resolutions, but still FHD and IPS). And on top of that, it comes with Broadwell, so that means I get smap.
Debian, Xfce, policykit and permissions
So, it seems that for a lot of people using unstable, hardware-related permissions (shutdown/reboot, suspend/hibernate, devices mount/umount etc.) have been broken since some times.
That's usually the case for people using GNOME with lightdm display manager, Xfce with either gdm or lightdm.
It seems that recently, policykit (which is used by GNOME and Xfce) switched from consolekit backend to logind backend (yeah, systemd-logind). So applications using policykit needs to handle that correctly, and that means beeing sure a logind session is correctly setup, which is done by installing the package libpam-systemd.
For now, it's still possible to not switch to systemd as init system, by installing the systemd-shim package before libpam-systemd. Be aware that (at least with the current state of affairs), this is only true with logind before 204. When systemd maintainers start transitionning to a later version, only systemd-sysv (so, systemd as init system) will work.
For people reluctant to switch to systemd, they can use systemd-shim for now. Then when systemd 205+ enters the archive, either lose those hardware permissions, or try to improve systemd-shim to handle that situation.
There's not much we (Xfce/LightDM maintainers) can do about that.
CVE-2014-0160 / heartbleed
- yes we're affected;
- we're currently working on it;
- we didn't have an early warning so we're doing as fast as we can.
DSA should be in your INBOX in a few moments, and the updates on the mirror a moment later.
[UPDATE Tue, 08 Apr 2014 01:06:42 +0200]
- DSA 2896-1 released;
- Wheezy packages are already on the security mirrors;
- Sid packages are waiting in incoming and should be accepted soon (and migrate right away to Jessie).
After the upgrade, you really need to restart all TLS application using libssl1.0.0 to get the fix. Usual suspects are webservers, mailservers etc. Don't forget to restart clients too. Easiest way is to completely reboot the sever, but in case that's not a solution, you can check the process still using the old library with the following snippet:
grep -l 'libssl.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u
Some people seem to indicate that the 64kB leak can enable an attacker to get pretty much anything from the process memory space, including the certificate private key. While we weren't able to confirm that yet, that's not really impossible, so you might also want to regenerate those private keys, although that's not something you should do in a rush either.
Expiration extension on PGP subkeys
So, last year I've switched to an OpenPGP smartcard setup for my whole personal/Debian PGP usage. When doing so, I've also switched to subkeys, since it's pretty natural when using a smartcard. I initially set up an expiration of one year for the subkeys, and everything seems to be running just fine for now.
The expiration date was set to october 27th, and I though it'd be a good idea to renew them quite in advance, considering there's my signing key in there, which is (for example) used to sign packages. If the Debian archive considers my signature subkey expired, that means I can't upload packages anymore, which is a bit of a problem (although I think I could still upload packages signed by the main key). dak (Debian Archive Kit, the software managing the Debian archive) uses keys from the keyring provided by Debian admins, which is usually updated every month or so from the keyring.debian.org public key server, so pushing the expiration date two months before the due date seemed like a good idea.
I've just did that, and it was pretty easy, actually. For those who followed my setup last year, here's how I did it:
First, I needed my main smartcard (the one storing the main key), since it's the only one able to do operations on the subkeys. So I plug it, and then:
corsac@scapa: gpg --edit-key 71ef0ba8 gpg (GnuPG) 1.4.14; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 4096R/71EF0BA8 created: 2009-05-06 expires: never usage: SC trust: ultimate validity: ultimate sub 4096g/36E31BD8 created: 2009-05-06 expires: never usage: E sub 2048R/CC0E273D created: 2012-10-17 expires: 2013-10-27 usage: A sub 2048R/A675C0A5 created: 2012-10-27 expires: 2013-10-27 usage: S sub 2048R/D98D0D9F created: 2012-10-27 expires: 2013-10-27 usage: E [ultimate] (1). Yves-Alexis Perez <email@example.com> [ultimate] (2) Yves-Alexis Perez (Debian) <firstname.lastname@example.org> gpg&> key 2 pub 4096R/71EF0BA8 created: 2009-05-06 expires: never usage: SC trust: ultimate validity: ultimate sub 4096g/36E31BD8 created: 2009-05-06 expires: never usage: E sub* 2048R/CC0E273D created: 2012-10-17 expires: 2013-10-27 usage: A sub 2048R/A675C0A5 created: 2012-10-27 expires: 2013-10-27 usage: S sub 2048R/D98D0D9F created: 2012-10-27 expires: 2013-10-27 usage: E [ultimate] (1). Yves-Alexis Perez <email@example.com> [ultimate] (2) Yves-Alexis Perez (Debian) <firstname.lastname@example.org> gpg> expire Changing expiration time for a subkey. Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 429d Key expires at mar. 28 oct. 2014 12:43:35 CET Is this correct? (y/N) y
At that point, a pinentry dialog should ask you the PIN, and the smartcard will sign the subkey. Repear for all the subkeys (in my case, 3 and 4). If you ask for PIN confirmation at every signature, the pinentry dialog should reappear each time.
When you're done, check that everything is ok, and save:
gpg> save corsac@scapa: gpg --list-keys 71ef0ba8 gpg: checking the trustdb gpg: public key of ultimately trusted key AF2195C9 not found gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 4 signed: 5 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 5 signed: 53 trust: 5-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2013-12-28 pub 4096R/71EF0BA8 2009-05-06 uid Yves-Alexis Perez <email@example.com> uid Yves-Alexis Perez (Debian) <firstname.lastname@example.org> sub 4096g/36E31BD8 2009-05-06 [expires: 2014-10-28] sub 2048R/CC0E273D 2012-10-17 [expires: 2014-10-28] sub 2048R/A675C0A5 2012-10-27 [expires: 2014-10-28] sub 2048R/D98D0D9F 2012-10-27 [expires: 2014-10-28]
Now that we have the new subkeys definition locally, we need to push it to the keyservers so other people get it too. In my case, I also need to push it to Debian keyring keyserver so it gets picked at the next update:
corsac@scapa: gpg --send-keys 71ef0ba8 gpg: sending key 71EF0BA8 to hkp server subkeys.pgp.net corsac@scapa: gpg --keyserver keyring.debian.org --send-keys 71ef0ba8 gpg: sending key 71EF0BA8 to hkp server keyring.debian.org
Main smartcard now back in safe place. As far as I can tell, there's no operation needed on the daily smartcard (which only holds the subkeys), but you will need to refresh your public key on any machine you use it on before it gets the updated expiration date.
Xfce 4.10, final part
Someone recently asked me about the Debian Xfce 4.10 status, as apparently I forgot to update this post series.
So, as you might have noticed, the full Xfce 4.10 desktop environment is currently in Debian Jessie (current name for testing). All in all, the transition went well and smooth.
One of the most regular question I get about Xfce 4.10 is the panel behavior when it comes to the “task bar” expansion. In xfce4-panel 4.8, when people wanted to have a full side panel with a task bar plugin inside, they added a “Windows buttons” plugin and configured the panel to 100% length. Then the “Windows buttons” would expand to occupy all the free space on the panel. It was a special case plugins, as usually other plugins only used a fixed space. Now, in 4.10, this is not the case anymore. “Windows button” uses a fixed size. And the plugins are left-aligned, which means usually people end up with some space at the far right of the panel. To restore the previous behavior back (which is actually the pre-4.8 behavior, 4.8 was an exception by itself), one needs to add a “Separator” plugin, then configure it to expand (and optionnally select a transparent handle). Then move it next right to the “Windows buttons” plugin.
Another thing which might be a bit surprising for upgrading users is the change in the “Action buttons” plugin, which people usually use to logout. In 4.8, by default, it's set to run the logout dialog. In 4.10, by default, it's set to logout directly (but with a confirmation dialog). If you prefer the previous behavior, you can just configure the “Action buttons” plugin and select the “Log out…” item instead of the “Log out” one (I know, it's a bit confusing).
If you have any question, don't hesitate to reach us by mail or on irc (#debian-xfce on Freenode). Other than that remember that Xfce really needs you help, both in Debian and upstream (and at that point, I'd say *especially* upstream). There's a lot of unmaintained project under the Xfce umbrella, some of them part of the core (like xfce4-power-manager), so if you have some spare time and some C/GTK+ knowledge, feel free to contact the Xfce team on the mailing list.
Hiding encrypted disks in Thunar with udisks2
udisks2 was uploaded recently to Debian sid. With this, people might have seen hidden encrypted disks reappear in Thunar. Hiding disks in udisks was previously done by setting an udev propery. For example, I did this using /etc/udev/rules.d/99-hide-disks.rules:
This is not valid anymore in udisks2, but only the property name has changed. You can simply replace by:
Xfce 4.10, part 2
This is an update on the Xfce 4.10 transition to unstable. Most desktop components have been uploaded, built and installed to the archive.
We're now currently building and uploading the various goodies, and especially panel plugins. There's a lot of them so it takes some time.
Once we'll have finished to build and upload all the goodies, we'll ask for binNMUs on the packages which don't need a sourceful upload but need to be rebuilt against libxfce4util or xfce4-panel 4.10.
You can follow the transition status using the release team page.
In any case, please be patient while we upload all the packages. Again, no need to report installability issues in unstable for now, we are aware of it and don't need more warnings. We'll fix the fallouts in due time.
Xfce 4.10, part 1
Thanks to the release team ACK, I've started uploading Xfce 4.10 to unstable yesterday. For now, I've only pushed Xfce 4.10.1 desktop components, which means people using xfce4 + xfce4-goodies in unstable won't be able to upload at once.
That's because panel plugins have a quite hard dependency on the running xfce4-panel, and the communication protocol has changed between Xfce 4.8 and 4.10. So all panel plugins need to be rebuild against the new xfce4-panel. I'll start uploading new releases or packages revisions this evening, and binNMUs will be scheduled for the rest, but it'll take some days.
In the meantime, you can safely wait before upgrading xfce4. If you don't use external panel plugins, then you can accept to remove xfce4-goodies and the various xfce4-*-plugins and upgrade to xfce4 4.10.
There's no need to report a bug about that situation, we're already aware of it and it's somehow intended, things will settle in a few days.
Update on OpenPGPv2 smartcards
After some feedback from other people, I have an important update to make on my last post. As I said, what decided me to eventually buy an OpenPGP smartcard was that it supported 4096 bit keys, so it would fit my 4096R/71EF0BA8 key.
In the end, it seems it's a little more complicated than that. 4096R keys are indeed supported, as far as signing and authentication are concerned. But encryption keys seem limited to 3072 bits (or maybe more, I didn't test toroughly). When trying to decrypt some stuff encrypted for a 4096R key on the smartcard, gpg fails with some “general error”. It has already been reported here, but no news since.
In my case, it's not that bad, I decided to go for 2048R for all subkeys. But if you desperately need 4096 bit encryption key, OpenPGPv2 smartcards might not be the right solution for you. I have no idea if the problem lies in GnuPG or in the smartcard, and I can't really find much information on this.
Switching to OpenPGP smartcard
A friend of mine recently reminded me of the OpenPGP smartcard v2, and told me that it was perfectly able to handle 4096 bit RSA keys (provided you have GnuPG v2.0.18+). I had the opportunity to play with one a little, and notice it was super easy to use it for ssh authentication, especially since I already use gpg-agent as my ssh-agent (it should be easy to use a purely software authentication key as ssh key with GnuPG 2.1). So I decided to buy two of them and try to switch my main key (0x71ef0ba8) to it.
The cards arrived this weekend, and I was able to play with it a little. I didn't log every command I typed, but it was pretty easy, in the end. What I decided to do was to use one smartcard for every day usage, and one only for key signing. So basically, I would generate three (signing, encryption, authentication) subkeys, put them on smartcard 1, then put the primary key on smartcard 2. Then erase the private parts, and only keep them on smartcards.
In case it interests people, here the somehow detailed steps. Note that everywhere 'gpg' means 'gpg2' on Debian, we really need GnuPG v2 for correct smartcard handling. You'd better use gpg-agent too, although it doesn't seem mandatory.
- make a backup! As we're gonna play with private parts (!), it's
always a good idea to have backups. And it'll be useful to have one
later, in case there's a problem with the smartcards. You can do a
copy of your complete ~/.gnupg folder, but I simply did:
corsac@scapa: umask 066 corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
- Add three subkeys. Skip this is you already have subkeys (you
usually already have an encryption subkey, but I wanted to switch
to a new one too) --expert is needed in order to chose
corsac@scapa: gpg --expert --edit-key 71ef0ba8 gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? 8 Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? Q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 1y Key expires at dim. 27 oct. 2013 20:38:44 CET Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.Repeat this for encryption and authentication subkeys. Then save and send the key to keyservers
gpg> save corsac@scapa: gpg --send-keys 71ef0ba8
- Next, we'll switch to the smartcard part. I use a Gemalto
PC ExpressCard reader which is perfectly recognized under
Debian. You just need few tools:
root@scapa: ~# apt-get install pcscd scdaemonPlug the reader, insert the card, make sure it's detected:
corsac@scapa: gpg --card-status Application ID ...: D2760001240102000005000016A10000 Version ..........: 2.0 Manufacturer .....: ZeitControl ...You can edit various parameter (name etc.) and change the PINs using gpg:
corsac@scapa: gpg --change-pin corsac@scapa: gpg --card-edit
- Then we'll put the subkeys in the first smartcard. It might be
a good idea to export again the private keys for backups.
corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
- We'll now use the keytocard gpg command to move the
private parts on the smartcard:
corsac@scapa: gpg --edit-key 71ef0ba8 gpg> key 1 # select encryption subkey gpg> keytocard gpg> key 2 # select signature subkey gpg> keytocard gpg> key 3 # select authentication subkey gpg> keytocard gpg> saveA quick check on the card now reveals that it's populated:
corsac@scapa: gpg --card-status Application ID ...: D2760001240102000005000016A10000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 000016A1 Name of cardholder: Yves-Alexis Perez Language prefs ...: fr Sex ..............: unspecified URL of public key : http://www.corsac.net/71ef0ba8.asc Login data .......: corsac Signature PIN ....: forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 3 3 Signature counter : 7 Signature key ....: 9745 B022 7323 81FE 9E7E AFF5 6DDB 53F2 A675 C0A5 created ....: 2012-10-27 11:24:07 Encryption key....: F7E0 078F EA1A 5F23 92E0 20B3 A83A D136 D98D 0D9F created ....: 2012-10-27 11:27:01 Authentication key: 8CFD D478 AB4A 16F8 F0EC CD33 24E2 3B5C CC0E 273D created ....: 2012-10-17 14:29:18 General key info..: pub 2048R/A675C0A5 2012-10-27 Yves-Alexis Perez sec> 4096R/71EF0BA8 created: 2009-05-06 expires: never card-no: 0005 000016A2 ssb 4096g/36E31BD8 created: 2009-05-06 expires: never ssb> 2048R/CC0E273D created: 2012-10-17 expires: 2013-10-27 card-no: 0005 000016A1 ssb> 2048R/A675C0A5 created: 2012-10-27 expires: 2013-10-27 card-no: 0005 000016A1 ssb> 2048R/D98D0D9F created: 2012-10-27 expires: 2013-10-27 card-no: 0005 000016A1
At that point, the private part is replaced by a stub in the secret keyring, so when you export them, you only export stubs which you can then use anywhere without actually giving your private key. So now is a good idea to export the subkeys so you can import them on other boxes:
corsac@scapa: gpg -o 71ef0ba8-subkeys.gpg --export-secret-subkeys 71ef0ba8
Note that only the subkeys private parts have been moved to the card, not the primary one, so you're still able to sign keys. Here, you have multiple choices. You can simply erase the private key (and later re-import the stubs) and use the offline copy made above when you need to sign another key.
- What I did is something else. I've put the primary key on my
second OpenPGP smartcard. That way, I won't lose it, it'll be kept
safely in my house, but still be on a hardware token where it won't
The procedure for doing is so is exactly the same as above. First take a backup (in case you didn't do it first, do it now since after the keytocard command you won't have a backup of your primary key and there'll be no way to extract it from the smartcard. Then put the new smartcard in the reader, edit the key (don't select a subkey) and run the keytocard command.
After that, running gpg --export-secret-keys will export the stub and not the private part of your primary key.
In the end, it seems that everything is running fine. Only issue is that scdaemon is sometime not behaving nicely (especially after a card change or or suspend/resume cycle). I didn't yet report a bug but you might want to kill it in case it's stuck.
You can also use the authentication subkey for ssh logins. When the card is inserted, the authentication subkey appears automatically (through the magic of gpg-agent):
corsac@scapa: ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EA... cardno:0005000016A1
And now you can add it to your various authorized_keys and use the smartcard for SSH.
Debian, Xfce 4.10 and Xfce 4.11
It's been six months since Xfce 4.10 has been released. And it's been four months since Wheezy is frozen. Due to this timing (and the fact Squeeze has 4.6 and doing a 4.6 → 4.10 upgrade needed some tuning in various packages), it was decided to not try to push 4.10 into Wheezy that late in the release cycle.
So Xfce 4.10 was uploaded to experimental instead, and as it needs a full rebuild of all panel plugins against 4.10 panel (another reason for not trying to push it to Wheezy), those have not been uploaded. You can try Xfce 4.10 using experimental, but you'll need to remove the xfce4-goodies metapackage and the various depending plugin (since they'll just crash if you try to load them on 4.10 panel).
Multiple people asked me (either on IRC, by private or public mail) when 4.10 will be uploaded to unstable and transition to testing. Like last time, the answer is : not before Wheezy is released. Right now, we're more interested in stabilizing Wheezy and squashing the bugs there than adding new ones in unstable.
So, if you want to have Xfce 4.10 in Debian sid/testing sooner, then the easiest and fastest way is to fix some release critical bugs so we can release sooner, and then start breaking sid by uploading a whole lot of new stuff there.
Note that this is true also for other software like GNOME, KDE stack (I have no idea how to call it these days), the Linux kernel, strongswan or whatever.
About development releases of Xfce 4.11 (like the recently released exo 0.9 and Thunar 1.5), well, since we already use experimental for 4.10, there's not much chance they get uploaded anytime soon. We could try to package them and let people build it themselves, or I could host it somewhere on my server for people to try. But as I already said, we're more interested in fixing bug in Wheezy right now, and people interested in finding bugs in Xfce development releases (so they are fixed for the final one) should build it themselves and report everything they find on the Xfce bugzilla.
TL;DR: if you care about new, shiny stuff, please help fixing RC bugs in Wheezy.
Advocating people for hardware sponsoring
Our Dear Project Leader, Stefano Zacchiroli, regularly mentions the fact that there's an amount of Debian money available for hardware sponsoring of Debian developers, but it seems that not much people benefit from it.
Each time I saw one of this reminder, I wonder if I should apply, and the anser is usually no. The fact is that I don't think any new laptop or desktop to do my Debian stuff, and the last time I bought a box (my x201s last summer) it was not really specifically for Debian tasks so I didn't dare to ask (not to mention the fact I bought it because I did have the money to do so).
And I think this is mostly the problem. I might be wrong, but I think that most people which could benefit from this just don't dare asking or don't estimate themselves eligible for it.
When I saw Ben Hutchings post, where the first thing he says is about how hardware is expensive, I thought « hey, he should get some Debian money for buying new hardware: building kernel is really time consuming and having multiple powerful cores, more ram and fast disks/SSDs really helps ». Turns out that Ben just didn't really want to spend too much money there, but the case still stands. We also see from time to time people saying they'll be offline for a while because of broken laptop or something like that. Once again, maybe those people wouldn't mind some help from the Debian project, and maybe they just don't think about asking, or they don't dare.
So thinking about it a bit more, I think I wouldn't dare asking money for myself, but maybe I could dare asking money for other people (this is a bit like the flattr posts by Raphaël Hertzog, where he incited people to give money to projects he liked). If I'm not alone in this case, maybe those Debian developers who think some of their peers would benefit some hardware could drop them a mail with leader@ on copy, to propose just that. No need for huge publicity on that (in order to not embarass people), though the transparency rules still apply when it comes to Debian money.
Debian grsec kernels
I received recently a mail about my attempt to provide Grsecurity kernels in Debian. The sender found the bug by accident, and asked me why I didn't do some more publicity here. So here we are.
I won't go into details on what grsecurity is, it's fairly complex. But it's basically a hardening patch for the Linux kernel, with three main components:
- the PaX patch, which purpose is to harden the memory layout of the Linux kernel and improve existing options: enforcing of non-executable memory pages (userland and in kernel), W^X (no page marked as writable and executable), ASLR, prevention of invalid userland pointers dereference, copies between userland and kernel memory…
- RBAC (Role Based Access Control), an implementation of Mandatory Access Control
- various hardening features: /proc restrictions, chroot restrictions, kernel symbols hiding etc.
A lot of this touches low level stuff in the kernel, especially memory management. Ideally this patch would be pushed upstream, but Brad Spengler (grsecurity main developper) already said he wasn't interested in upstreaming it and upstream already said the patch was too huge and invasive to include it like that (especially since the original authors aren't interested in maintaining it upstream). There's an ongoing effort to split the patch and merge things little by little, but in the meanwhile having a mid-term solution would be nice.
I know Debian users rebuilding grsecurity-patched kernels themselves, and I know some of them would appreciate having them included in the Debian kernel. Fortunately, the linux-2.6 source package has a nice feature which is called featureset. Basically it's a way to build some (binary) packages using a different set of patches and a different config. For example this was used to provide xen/openvz/vserver patchsets, and is now used to provide rt kernels.
So I though it'd be nice to provide a grsec featureset, and starting doing the work. I have a working setup for producing those kernels, so I've opened a wishlist bug against the kernel (#605090) to have this merged.
Those packages follow the sid kernel. There's an ongoing work for Squeeze, but it's a bit harder there because both the grsecurity patchset and the Debian kernel ship a whole lot of backports to the Linux kernel, meaning the grsecurity patch doesn't apply directly to the Debian source package. Basically I need to remove some of the hunks (since they are already applied to the source) and port some others (since there are some backported code not present in the vanilla 2.6.32, for example the drm code).
Until the patches are merged and the bug is closed, I host some of the built packages at:
deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/
The repository is signed by my key which you can add to your apt setup using apt-key add. If you want to rebuild the packages yourself, here's the method:
svn checkout svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6
git clone git://anonscm.debian.org/users/corsac/grsec-patches.git
gpg --verify linux-3.0.tar.bz2
apt-get build-dep linux-2.6
quilt push -a
python debian/bin/genorig.py ../linux-3.0.tar.bz2
fakeroot debian/rules source
fakeroot make -f debian/rules.gen binary-arch_amd64_grsec_amd64
You could also do dpkg-buildpackage, pdebuild or whatever. Kernel handbook is a nice reading too if you want more information on how to rebuild Debian kernels. The quilt push -a may fail if you checkout an svn version more recent than mine. I try to keep patches up to date but I usually have some delay.
Note that installing the kernel will require installing linux-grsec-base package. Binary is not yet available on my mirror but you can easily build it. Source can be found on git.debian.org.
If you're interested by this, don't hesitate to mail me or the bug.
Fun with network cards
This morning (while I was running late for an appointement) I had a very weird stuff happening on my Thinkpad T61 laptop. Since I recently offered myself a shiny Thinkpad x201s, I have to admit I don't use much my T61 anymore. But this morning I had to print a page (for this appointement) and, as I didn't yet configured my printer on the x201s, I went to the T61. But I noticed that the network was down. I've tried quickly on wireless but, bad luck, my current wifi setup selects the channel automatically and it prefers choosing channels which aren't available in the US. Guess what, my T61 comes from the US and has those channels completely disabled, so no wireless available either.
I first tried to
modprobe -r e1000e
to see if it fixed the problem, but it didn't. Worse, the interface disappeared and never reappeared. I tried to reboot but it didn't fix the problem, the link was still down. Running really late, I put the file on a usb key and printed it from the powerbook and postponed the fix for later.
Now, this evening, I tried to investigate a bit more. Symptoms weren't only that the nic wasn't working, but there was a high load on the system (1-2 at idle), unresponsiveness every second or so, and watching top I could see spikes of high cpu usage for the kworker kernel thread. Typing that on google you can find a lot of people running on this issue, usually starting around kernel 2.6.36 or 2.6.37. Now, I might have upgraded the kernel recently to 3.0.0-4, but that didn't look related since the problem first appeared when the laptop was up and running. And I tried to reboot under 2.6.39, 2.6.38 and even 2.6.32 and the problem was still present. Each time, unloading the module would fix the problem, but loading it again wouldn't make the interface reappear. People advised to boot with pcie_ports=compat but that didn't do anything. I tried to boot without intel_iommu=force (disable Intel Vt-d) and pcie_aspm (Active State Power Management) but nothing either.
Considering a userland issue, I've tried to boot a grml live distro (always keep a grml.iso in your /boot, extlinux-update will even put it in your menu automatically), and the problem was still present. So not a Debian kernel issue, not a userland issue, only thing left was the laptop. I didn't update the Bios recently, so I wondered exactly what could be the problem. I started to feel a little bad, since I still really like that laptop, and that I already decided to lend it to my sister since her own T61 is sitting with a dead system board in my shelf. I know she might have some negative waves, but she was not even landed when the problem first appear.
Then I had a flash. It's not mystery that I'm used to break network cards, and I had the bright idea to shutdown the laptop, disconnect AC and battery, then let it idle a bit. I even tried the secret Thinkpad power button code but I think it's unrelated. Then I re-plugged the battery, booted to grml and the issue was gone. I rebooted on the standard Debian and the link was up, network was working.
So what happenned?
The (tentative) explanation
My guess is that, somehow, the network card firmware has an issue and choked on something (a network frame or an attack exactly like the one we demonstrated on ASF firmware). In fact, no, I don't think it's the e1000e firmware. My T61 comes with Intel vPro, which includes AMT (Active Management Technology), a remote management solution a bit like ASF but more advanced. As far as I know, AMT firmware always runs, even when it's disabled, it's just completely idle. Idle, but in this case I think it choked on something, and a reboot isn't enough to restart the AMT firmware. But a real hard reset without any power seems to do the trick.
Well, a part of me is pretty scared, but another is just bored. I mean, we know about that, that's exactly the kind of issue we are warning people of. I have no idea what exactly happened, and there's no way I'll be able to reproduce that, but I'm pretty sure it's something lying at a pretty low level in the platform, and which can severely disable your workstation. Now if it happens again I won't lose too much time on this.
TL;DR: helping other people
In case you came here because you searched on google terms like “kworker cpu usage”, e1000e, interrupts, it might be a good idea to first reboot on a live CD to eliminate installation issues, then shutdown the laptop, remove the battery and let it few seconds idle. This might be enough to reset “something” inside and fix the situation.