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.

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.

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.

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.

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.

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:

(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:

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.

It runs mostly fine out of the box on Debian sid, but for full
support some tuning is needed. I've setup a page
with more information on the laptop, and some images can be found
over there.

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.

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:

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.

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:

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.

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:

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.

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.