Echoes - Echoes camshot
jeudi 21 décembre 2017 (1 post)
  • Hiver

Aujourd'hui les jours rallongent \o/

Corsac@08:18:07 (Echoes)

dimanche 26 novembre 2017 (1 post)
  • Parce que sinon elle râle !

Bonne fête Delphine !

Corsac@08:16:54 (Roadbook)

lundi 16 octobre 2017 (1 post)
  • OpenPGP smartcard transition (part 1.5)

Following the news about the ROCA vulnerability (weak key generation in Infineon-based smartcards, more info here and here) I can confirm that the Almex smartcard I mentionned on my last post (which are Infineon based) are indeed vulnerable.

I've contacted Almex to have more details, but if you were interested in buying that smartcard, you might want to refrain for now.

It does *not* affect keys generated off-card and later injected (the process I use myself).


Yves-Alexis@17:32:01 (Debian)

mardi 10 octobre 2017 (1 post)
  • OpenPGP smartcard transition (part 1)

A long time ago, I switched my GnuPG setup to a smartcard based one. I kept using the same master key, but:

  • copied the rsa4096 master key to a “master” smartcard, for when I need to sign (certify) other keys;
  • created rsa2048 subkeys (for signature, encryption and authentication) and moved them to an OpenPGP smartcard for daily usage.

I've been working with that setup for a few years now and it is working perfectly fine. The signature counter on the OpenPGP basic card is a bit north of 5000 which is large but not that huge, all considered (and not counting authentication and decryption key usage).

One very nice feature of using a smartcard is that my laptop (or other machines I work on) never manipulates the private key directly but only sends request to the card, which is a really huge improvement, in my opinion. But it's also not the perfect solution for me: the OpenPGP card uses a proprietary platform from ZeitControl, named BasicCard. We have very few information on the smartcard, besides the fact that Werner Koch trust ZeistControl to not mess up. One caveat for me is that the card does not use a certified secure microcontroler like you would find in smartcard chips found in debit card or electronic IDs. That means it's not really been audited by a competent hardware lab, and thus can't be considered secure against physical attacks. The cardOS software and the application implementing the OpenPGP specification are not public either and have not been audited either, to the best of my knowledge.

At one point I was interested in the Yubikey Neo, especially since the architecture Yubico used was common: a (supposedly) certified platform (secure microcontroler, card OS) and a GlobalPlatform / JavaCard virtual machine. The applet used in the Yubikey Neo is open-source, too, so you could take a look at it and identify any issue.

Unfortunately, Yubico transitioned to a less common and more proprietary infrastructure for Yubikey 4: it's not longer Javacard based, and they don't provide the applet source anymore. This was not really seen as a good move by a lot of people, including Konstantin Ryabitsev ( administrator). Also, it wasn't possible  even for the Yubico Neo to actually build the applet yourself and inject it on the card: when the Yubikey leaves the facility, the applet is already installed and the smartcard is locked (for obvious security reason). I've tried asking about getting naked/empty Yubikey with developers keys to load the applet myself, but it' was apparently not possible or would have required signing an NDA with NXP (the chip maker), which is not really possible as an individual (not that I really want to anyway).

In the meantime, a coworker actually wrote an OpenPGP javacard applet, with the intention to support latest version of the OpenPGP specification, and especially elliptic curve cryptography. The applet is called SmartPGP and has been released on ANSSI github repository. I investigated a bit, and found a smartcard with correct specification: certified (in France or Germany), and supporting Javacard 3.0.4 (required for ECC). The card can do RSA2048 (unfortunately not RSA4096) and EC with NIST (secp256r1, secp384r1, secp521r1) and Brainpool (P256, P384, P512) curves.

I've ordered some cards, and when they arrived started playing. I've built the SmartPGP applet and pushed it to a smartcard, then generated some keys and tried with GnuPG. I'm right now in the process of migrating to a new smartcard based on that setup, which seems to work just fine after few days.

Part two of this serie will describe how to build the applet and inject it in the smartcard. The process is already documented here and there, but there are few things not to forget, like how to lock the card after provisionning, so I guess having the complete process somewhere might be useful in case some people want to reproduce it.

Yves-Alexis@22:44:37 (Debian)

jeudi 27 avril 2017 (1 post)
  • Debian, grsecurity and passing the baton

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)
  • Hiver

Aujourd'hui les jours rallongent \o/

Corsac@12:03:55 (Roadbook)

samedi 26 novembre 2016 (1 post)
  • Parce que sinon elle râle !

Bonne fête Delphine !

Corsac@12:03:31 (Roadbook)

mercredi 04 mai 2016 (1 post)
  • linux-grsec now in jessie-backports

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)
  • linux-grsec in unstable

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)
  • Hiver

Aujourd'hui les jours rallongent \o/

Corsac@20:33:55 (Roadbook)

jeudi 26 novembre 2015 (1 post)
  • Parce que sinon elle râle !

Bonne fête Delphine !

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)
  • Uploading source-only packages built with pbuilder

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

  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/..

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)
  • Archive - Restriction tour 2015 - Zenith Paris

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 ViolentlyKid 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 à DangervisitFinding 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)
  • Kernel recipes 2015: Hardened kernels for everyone

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)
  • 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.

  1. Disconnect NetworkManager from the network, disable the wireless link, stop it; just make sure wpa_supplicant is not running;
  2. Put a stub wpa_supplicant.conf file with only the following content:
  3. Start wpa_supplicant in the foreground with your stub config file: 
    wpa_supplicant -iwlan0 -c wpa_supplicant.conf
  4. Start wpa_cli
Inside wpa_cli:
  1. Scan the network:
  2. Get the results:
    and identity the bssid of the Livebox
  3. Press the WPS button on the Livebox
  4. 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)
  5. Run

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)
  • 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:

  •, 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;
  • 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 clone git://
mkdir build
cd linux-stable
../debian-grsec-config/bin/ stable2 # for 3.14 branch
../debian-grsec-config/bin/ ../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)
  • 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.

Yves-Alexis@21:05:55 (Debian)

lundi 30 mars 2015 (1 post)
  • 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 ( 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)
  • 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[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!
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
[ 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.
[ ok ] Cleaning up temporary files....
[FAIL] startpar: service(s) returned failure: 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)

  • 1508 posts
  • 5760 jours
  • 0.26 posts/jour
  • IRC