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.
Alors c'est testé et validé : le Blues Bar-b-q, dans le 11ème (M. Bréguet Sabin). Petit restau texan, tenu par une texane (du coup il parait nettement plus naturel de parler anglais).
Les usual suspects de la cuisine sud états-uniennes : cornbread, bbq beef brisket, ribs, plus quelques découvertes (les Outlaw Chili Cheese Fries). Une sauce barbecue qui déchire, un beef brisket hyper tendre. Sans oublier les desserts : leur cheesecake est le plus dense que je connaisse (à part peut être celui de Marie) et la southern pecan pie déchire bien aussi.
Enfin du personnel adorable, de la tenancière au cuistot en passant par la serveuse (dont c'était le premier jour). Et de la musique du coin aussi, histoire d'accompagner. Bref, que du bon, allez-y.
Aujourd'hui les jours rallongent \o/
Parce que sinon elle râle !
Bonne fête Delphine !
So, sometimes, you had a somehow rough day, it's raining and you're tired.
And then, in your mailbox, out of the blue, there's a “thank you” mail.
That really enlightens the day…
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.
Avec les semaines pourries qu'on s'est tapé ces derniers temps, ça fait quand même plaisir :
La cuvée 2013, donc, comme d'habitude en début d'année suivante. Une année pas très prolifique (17 films) mais bon. À noter une forte concentration au début de l'année (il fallait écluser les congés 2012 avant la fin mars) ainsi que fin octobre (suite à mon marathon).
- Django Unchained : 22 janvier 2013, MK2 Beaubourg
- Zero Dark Thirty : 7 février 2013, UGC Ciné Cité les Halles
- Gangster squad : 13 février 2013, UGC Ciné Cité les Halles
- Die Hard 5 : 1er mars 2013, UGC Montparnasse
- No : 22 mars 2013, MK2 Quai de Seine
- Cloud Atlas : 25 mars 2013, MK2 Quai de Loire
- Mariage à l'anglaise : 12 avril 2013, MK2 Quai de Loire
- Iron Man 3 : 19 mai 2013, UGC Ciné Cité Bercy
- Prisoners : 26 octobre 2013, UGC Montparnasse
- Sheriff Jackson : 26 octobre 2013, UGC Ciné Cité Les Halles
- Malavita : 27 octobre 2013, UGC Ciné Cité Les Halles
- Omar : 27 octobre 2013, UGC Ciné Cité Les Halles
- La vie d'Adèle : 27 octobre 2013, UGC Ciné Cité Les Halles
- Jeune & jolie : 28 octobre 2013, MK2 Parnasse
- Blue Jasmine : 29 octobre 2013, UGC Ciné Cité Les Halles
- Gravity : 30 octobre 2013, UGC Maillot
- The lunchbox : 30 décembre 2013, UGC Ciné Cité Les Halles
Dans l'ensemble, là encore, un plutôt bon cru. Faut dire que quand on va moins souvent au cinéma, on sélectionne aussi plus, évidemment. Quelques petites déceptions (plus ou moins attendues, disons), mais aussi quelques pétites. J'ai déjà parlé de de la série Prisoners, Malavita, Omar, La vie d'Adèle et Gravity, mais j'ai aussi vraiment beaucoup apprécié The lunchbox, et évidemment Django Unchained.
On the road
Aujourd'hui, sur l'autoroute, trois voitures sur la file de gauche, derrière moi, m'ont gentiment cédé le passage alors que j'étais sur la file de droite, afin de me permettre de faire un dépassement.
J'en reviens toujours pas. C'est Noël ?!
Je suis pas raide dingue de la Tour Eiffel, mais à force de la voir tous les jours, voire à passer devant, on finit quand même par l'apprécier.
Et comme j'aime bien le principe des photos du jour, j'ai profité l'été dernier d'aller/retour sur le champ de mars pour en prendre, et monter ça en petite vidéo pour rigoler.
Évidemment il aurait fallu que ça dure un peu plus longtemps, mais ça rend pas si mal que ça…
Parce que sinon elle râle !
Ne soustrayons pas à la tradition.
Bonne fête Delphine !
C'est le moins qu'on puisse dire que notre fréquentation des salles obscures a nettement baissé depuis trois ans. Quasiment nulle la première année, on a réussi à augmenter quand même un peu la fréquentation les années suivantes (merci les RTTs d'ailleurs).
Ce coup ci, merci les vacances de la Toussaint. Profitant de quelques jours d'absence des miss, puis du centre de loisir, je me suis dit que j'allais me faire « quelques » toiles. N'ayant pas fait les choses à moitié, voilà le résultat :
Dans l'ensemble, je suis vraiment content du lot, hormis Sheriff Jackson, un peu moins bien et Blue Jasmine (vraie déception pour le coup). Dans la grande majorité des cas (en fait tout sauf La vie d'Adèle et Gravity) je n'avais pas la moindre information sur le film, et j'ai donc choisi à l'horaire (c'est en fait pas si évident que ça de caler trois films dont un de trois heure dans la même journée).
Une mention spéciale à Prisoners et Malavita, ainsi que La vie d'Adèle.