jeudi 27 avril 2017 (1 post)
Since the question popped here and there, I'll post a short blog post about the issue right now so there's a reference somewhere.
As you may know, Brad Spengler (spender) and the Pax Team recently announced that the grsecurity test patches won't be released publicly anymore. The stable patches were already restricted to enterprise, paying customers, this is now also the case for the test patches.
Obviously that means the end of the current situation in Debian since I used those test patches for the linux-grsec packages, but I'm not exactly sure what comes next and I need to think a bit about this before doing anything.
The “passing the baton” post mention a handover to the community (though the FAQ mention it needs to stop using the term “grsecurity”) so maybe there's some coordination possible with other users like Gentoo Hardened and Alpine, but it's not clear what would be possible with the tools we have.
I'm actually quite busy right now so I don't have much time to think about all this, but expect a new blog post when things have settled a bit and I've made up my mind.
Yves-Alexis@13:18:57 (Debian)
mercredi 21 décembre 2016 (1 post)
Aujourd'hui les jours rallongent \o/
Corsac@12:03:55 (Roadbook)
samedi 26 novembre 2016 (1 post)
Corsac@12:03:31 (Roadbook)
mercredi 04 mai 2016 (1 post)
Following discussion in #810506 and the ACK by the backports team, I've uploaded linux-grsec package (version 4.4.7-1+grsec201604152208+1~bpo8+1) to jessie-backports, and it has been ACCEPTED this morning (along with linux-grsec-base support package). So if you have a Jessie install with backports enabled, linux-grsec should be one apt call away:
apt install -t jessie-backports linux-image-grsec-amd64
4.4.8 should follow soon
.
Yves-Alexis@10:45:35 (Debian)
samedi 09 janvier 2016 (1 post)
As some of you might have already noticed, linux-grsec entered Debian unstable earlier this week, following linux-grsec-base a bit earlier.
So that means, if you're running sid, you can just run:
# apt install linux-image-4.3.0-1-grsec-amd64
There's no metapackage (version-less) for now, but I might add one at one point, if people need it.
After installing the kernel and the linux-grsec-base support package, you should check the /etc/sysctl.d/grsec.conf file and review the various tunables there, which might or might not suit your needs. The settings are mostly all enabled in the package (in order to get a “secure by default” state), but there a few bits you might need to disable.
For example, on my main laptop, where I do most of my stuff, including Debian work, I've disabled:
kernel.grsecurity.deny_new_usb = 0
kernel.grsecurity.audit_chdir = 0
kernel.grsecurity.chroot_deny_chmod = 0
kernel.grsecurity.chroot_deny_mknod = 0
kernel.pax.softmode = 0
The deny_new_usb because a laptop is not really usable without USB, audit_chdir because it's really to noisy (I like to keep exec_logging though, because it's only for the root gid so it's somehow interesting and not too noisy).
Both chroot settings are disabled because I'm building packages in pbuilder, which uses chroot. By the way, if you're doing that you'll need to add the pbuilder (uid 1234) user to the grsec-tpe (gid 64040) group inside the chroot so it has permissions to execute stuff.
softmode is disabled but it's a default setting (“secure by default”). You can use it if needed to see what PaX /would/ deny and adjust things (using paxctl or setting file extended attributes).
On the same laptop, I need to set PaX 'm' attributes (allow W|X memory maps) on the following binaries:
setfattr -n user.pax.flags -v m /usr/bin/evolution
setfattr -n user.pax.flags -v m /usr/bin/python
setfattr -n user.pax.flags -v m /usr/lib/chromium/chromium
It's a bit unfortunate (especially evolution and chromium are quite exposed to untrusted code, and python is really too generic), but to keep a working box I don't have much choice.
Plans regarding stable are a bit more fuzzy. As indicated on the initial bug, the current upstream release model doesn't really fit with the “Debian stable” one: only the test patch, against the latest major Linux kernel version, is available free of charge. I don't think the release team would be really happy to see a new Linux version uploaded to stable every two months.
Although having linux-grsec on unstable is already a great victory, I still think most users are likely to want it on stable (for example on server boxes), so I'm considering plans for that. Right now, I'm still uploading jessie packages to my repository, but also investigating wether backports are suitable. The default answer is no, obviously, because backports are only supposed to hosts packages which will be in the next stable release, but maybe there will be something possible. Stay tuned, in any way.
Don't hesitate to try the packages. There might be some roughs edges, it's expected. If you have issues, please read the documentation available on grsecurity and PaX, because security is a process, and installing the package won't just magically make you secure if you don't know what it does. Don't hesitate to report bugs, but try to investigate a bit before (with the src:linux package, and with vanilla+grsec packages).
Finally, many thanks to Brad Spengler and the PaX team, this is their work, I'm merely the packager here.
Yves-Alexis@10:14:37 (Debian)
mardi 22 décembre 2015 (1 post)
Aujourd'hui les jours rallongent \o/
Corsac@20:33:55 (Roadbook)
jeudi 26 novembre 2015 (1 post)
Corsac@17:57:34 (Roadbook)
samedi 21 novembre 2015 (1 post)
Tout d'abord, un grand grand merci. Un grand merci à Caravan Palace, pour avoir
joué hier soir, un grand merci au public pour avoir été si
bon.
Lorsque <|°_°|> (oui je ne sais pas non plus comment le
prononcer) est sorti, et que j'ai vu qu'il y avait un concert
prévu à Paris, je me suis tout de suite dit que ça se tentait.
Mais j'avais un peu zappé le truc, jusqu'à la sortie du concert
d'Archive, où on s'est dit que quand même le live, c'était
chouette. Malheureusement, à ce moment là, il n'y avait plus de
places, et les places d'occasion s'arrachaient comme des petits
pains, j'avais pratiquement renoncé à pouvoir y aller.
Fast-forward à la semaine dernière et les attentats du 13
novembre. Comme tout le monde, ça nous a bien secoué, et ça
continue. On ne sait toujours pas trop comment vivre avec ça,
comment avancer. Mais une des conséquences de ça, c'est que pas
mal de gens ont commencé à revendre des places pour le concert.
Sans trop réflechir, j'en ai récupéré deux. Pas par
militantisme, pas par héroïsme mal placé, et avec tout de même
un peu d'appréhension, soyons honnête.
Mais justement, sans verser dans le militantisme, s'il y a bien
une chose qui semble importante, c'est justement de ne rien
changer. Ni dans un sens, ni dans l'autre. Continuer, non pas comme
si de rien n'était, on ne pourra pas oublier ce qu'il s'est
passé, mais ne pas se laisser dicter ses réactions, ses actions,
son mode de vie.
Alors voilà, hier soir, devant l'Olympia, on ne savait pas
encore trop ce qui nous attendait, on était je pense tous un peu
mi-figue, mi-raisin. En ayant tout de même conscience que ce soir,
c'était spécial.
Première partie sympathique (Souleance), même si l'aspect
live est un peu déconvertant (musique uniquement
électronique, y compris les paroles, donc la présence scénique
se résume un peu à une table avec deux laptops et deux geeks
derrière). Puis arrive le moment attendu, et l'entrée en scène
de Caravan Palace (après que l'Olympia nous offre
gracieusement un entracte de vingt minutes, qui en dure
plutôt trente).
Et là, c'est la folie, dès le début. J'ai perdu le fil de la
setlist dès le début (j'essayerai de la retrouver à l'occasion),
mais ça a commencé très très fort. Le publique a commencé à
sautiller, à danser. Et ça a duré une bonne heure et demie, avec
à peine le temps de se reposer. Ça rockait, ça swingait, sans
s'arrêter.
Beaucoup d'émotion aussi. On sentait Zoé Colotis (la
chanteuse) au bord des larmes, quand elle a dit bonjour au nom du
groupe. Et à 21h20, une semaine pile après le début de l'attaque
au Bataclan, moment spécial : elle nous demande un cri, un
hurlement : pour ne pas oublier, pour montrer qu'on est là, pour
repousser la haine, pour crier, tout simplement. Et toute la salle
répond, hurle, se libère de ses démons.
Et ensuite c'est reparti, ça saute dans tous les sens. J'ai
rarement ressenti une telle rage de vivre et de jouer de la part
d'un groupe, et de son public. J'ai encore du mal à mettre des
mots sur autant d'émotion, j'avoue.
Alors encore une fois merci à vous, j'ai passé une soirée
merveilleuse, et je crois qu'on en avait tous besoin.
Corsac@15:13:27 (Echoes)
mercredi 04 novembre 2015 (1 post)
Thanks to Mehdi Dogguy, here's a nice hook to generate a source
change file at build time (with pbuilder), so one can upload
source-only packages to the archive and have buildds rebuild for
all the architectures. Put it in .pbuilder/hooks/B10_source-build
so it gets called once the builds succeeds
#! /bin/sh
generate_change_file()
{
local version=$(dpkg-parsechangelog -Sversion)
local package=$(dpkg-parsechangelog -Ssource)
echo "Generating source changes file"
dpkg-genchanges -S > ../${package}_${version}_source.changes
}
cd /tmp/buildd/*/debian/..
generate_change_file
Next time you build a package, you should find, alongside the
<package>_<version>_<arch>.changes file, a
<package>_<version>_source.changes which you can use
with usual tools (lintian, debsign, dput…) to upload it to the
Debian archive.
Note that if you do that, you have to make sure that your
debian/rules support building separately the arch-dependent and
arch-independant packages. To check that, you can call pdebuild
like this:
pdebuild --debbuildopts -A # binary-only build, limited to arch-independant packages
pdebuild --debbuildopts -B # binary-only build, limited to arch-dependant packages
Yves-Alexis@20:53:55 (Debian)
dimanche 01 novembre 2015 (1 post)
Suite à un cadeau d'anniversaire (merci !), hier c'était
soirée concert. Archive, une nouvelle fois, pour
le Restriction tour 2015. La dernière foi c'était en
2012 (pour la tournée de With us until you're dead), et
finalement ça passe vite. Depuis ils ont sorti Axiom
et Restriction, qui faisaient donc assez logiquement la
plus grosse part du concert.
Malheureusement (et comme en 2012, en fait), j'ai moyennement
apprécié le rendu live des chansons interprétées par
Holly Martin (la « nouvelle » chanteuse, arrivée au moment
de With us until you're dead). Autant j'adore les
versions studio (en particulier de Violently), autant
j'accroche pas les arrangements live. Holly Martin était
la seule chanteuse de ce concert (pas de Maria Q ce coup-ci), et en
plus des chansons de Restrictions (un peu décevantes
pour moi, donc) elle a chanté You make me feel
(de Take my head), qu'elle a pour le coup
merveilleusement réussi.
De façon générale, d'ailleurs, hormis la
séquence Violently - Kid korner, j'ai
vraiment adoré les interprétations live.
Y'avait du punch, ça bougeait bien quand il fallait, c'était doux
quand il fallait, c'était mélodieux quand il fallait. Bref, du
bonheur. Un peu fort (on a fini par se reculer, d'ailleurs), mais
pas horrible (à la Massive Attack) non plus. Et j'ai
beaucoup aimé la lumière aussi.
La setlist, donc :
- Feel It
- Fuck U
- Dangervisit
- Finding It So Hard
- Crushed
- Conflict
- Violently
- Black and Blue
- End of Our Days
- Kid Corner
- You Make Me Feel
- Bullets
- Distorted Angels
- Baptism
- Ladders
- Numb
- Encore: Lights
Une grosse mention spéciale
à Dangervisit, Finding it so hard (que
j'apprécie moyennement en studio, pour le coup, mais qui a
dépoté en live) et le Lights du rappel, qu'ils ont bien
fait durer.
Dans l'ensemble, un très bon moment, une très bonne soirée
<3
Corsac@15:56:45 (Roadbook)
mercredi 30 septembre 2015 (1 post)
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.
Yves-Alexis@18:00:09 (Debian)
dimanche 09 août 2015 (1 post)
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:
update_config=1
- Start wpa_supplicant in the foreground with your stub config file:
wpa_supplicant -iwlan0 -c wpa_supplicant.conf
- Start wpa_cli
Inside wpa_cli:
- Scan the network:
scan
- Get the results:
scan_results
and identity the bssid of the Livebox
- Press the WPS button on the Livebox
- Run
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)
- Run
save_config
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.
Yves-Alexis@21:44:32 (Debian)
jeudi 21 mai 2015 (1 post)
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.
Yves-Alexis@22:36:11 (Debian)
samedi 09 mai 2015 (1 post)
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.
Yves-Alexis@21:05:55 (Debian)
lundi 30 mars 2015 (1 post)
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.
Yves-Alexis@22:27:21 (Debian)
mercredi 25 mars 2015 (1 post)
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[1033]: pam_loginuid(login:session): Cannot open /proc/self/loginuid: Read-only file system
Mar 25 22:10:13 lxc-sync login[1033]: pam_loginuid(login:session): set_loginuid failed
Mar 25 22:10:13 lxc-sync login[1033]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Mar 25 22:10:13 lxc-sync login[1033]: 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.
Yes, there are a lot of errors, but they seem to be handled
just fine.
Yves-Alexis@22:26:04 (Debian)
samedi 14 mars 2015 (1 post)
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.
Yves-Alexis@16:59:22 (Debian)
samedi 03 janvier 2015 (1 post)
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.
Corsac@21:52:56 (Roadbook)
lundi 22 décembre 2014 (1 post)
Aujourd'hui les jours rallongent \o/
Corsac@00:03:00 (Roadbook)
mercredi 26 novembre 2014 (1 post)
Corsac@23:13:02 (Roadbook)