Loading...Attention, cet article a plus d'une année d'ancienneté. Il est possible que les informations présentées ne soient plus à jour, spécialement dans le cadre d'un article technique.
Bonjour à tous,
Ça va faire plus d’une année que j’utilise des kernels GrSecurity sur mes serveurs web.
J’utilisais Mempo avant son arrêt brutal et j’ai ensuite décidé de faire mes propres kernels qui sont d’ailleurs disponibles en téléchargement sur The Abyss Project.
Quand j’en parle sur Twitter j’ai souvent la même remarque qui revient en boucle. GrSecurity ne serait pas compatible avec une utilisation de Debian (ou Linux plus généralement) en serveur web.
Une des grosses sécurités mise en place par le patch GrSecurity qui a contribuée à cette croyance, c’est la protection contre l’exécution de code en mémoire vive.
Deux modules particuliers font disjoncter la plupart des applications utilisées dans le web en provoquant des Segmentation Fault, à savoir SEGMEXEC et MPROTECT.
Ces modules font partie intégrante de PAX qui est intégré dans GrSecurity.
Il y’a aussi d’autres problèmes avec le monitoring, mais on en parlera dans un autre article.
L’idée aujourd’hui, c’est de faire le tour des choses qui m’ont le plus souvent étés remontées pour voir point par point que ce n’est pas une fatalité et que GrSecurity est parfaitement utilisable sur des serveurs webs.
Installation de paxctl :
Dans un premier temps on va installer paxctl qui nous permettra de contrôler les attributs PAX d’un exécutable pour activer ou désactiver des protections mises en place par PAX.
Lancez simplement la commande suivante :
apt-get install paxctl -y
Régler les problèmes avec Let’s Encrypt (Python) :
Let’s Encrypt, c’est quand même sympa pour générer ses certificats SSL gratos et on en parle beaucoup sur ce blog.
Léger problème, GrSec n’aime pas trop l’environnement virtuel de Python2 utilisé par Let’s Encrypt lors de la génération des certificats et il part en segmentation fault directement :
root@debian:/etc/letsencrypt# ./letsencrypt-auto --config /etc/letsencrypt/configs/www.segfault.com.conf certonly Segmentation fault
En allant dans le syslog (/var/log/syslog) on constate que GrSec a tué le processus Let’s Encrypt dans l’œuf :
Jul 4 14:08:36 debian kernel: [ 2497.666343] grsec: From 10.26.79.5: denied RWX mmap of <anonymous mapping> by /root/.local/share/letsencrypt/bin/letsencrypt[letsencrypt:7521] uid/euid:0/0 gid/egid:0/0, parent /etc/letsencrypt/letsencrypt-auto[letsencrypt-aut:7510] uid/euid:0/0 gid/egid:0/0 Jul 4 14:08:36 debian kernel: [ 2497.671280] letsencrypt[7521]: segfault at 0 ip 00000312e554899b sp 0000038b6e65f268 error 6 in libffi.so.6.0.2[312e5543000+7000] Jul 4 14:08:36 debian kernel: [ 2497.671300] grsec: From 10.26.79.5: Segmentation fault occurred at (nil) in /root/.local/share/letsencrypt/bin/letsencrypt[letsencrypt:7521] uid/euid:0/0 gid/egid:0/0, parent /etc/letsencrypt/letsencrypt-auto[letsencrypt-aut:7510] uid/euid:0/0 gid/egid:0/0 Jul 4 14:08:36 debian kernel: [ 2497.676647] grsec: From 10.26.79.5: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /root/.local/share/letsencrypt/bin/letsencrypt[letsencrypt:7521] uid/euid:0/0 gid/egid:0/0, parent /etc/letsencrypt/letsencrypt-auto[letsencrypt-aut:7510] uid/euid:0/0 gid/egid:0/0
Pour régler ce problème, lancez simplement la commande suivante :
paxctl -cm /root/.local/share/letsencrypt/bin/python2.7
Vous devriez avoir cette sortie :
file /root/.local/share/letsencrypt/bin/python2.7 had a PT_GNU_STACK program header, converted
Cette commande convertit le header PT_GNU_STACK en header PT_PAX_FLAGS et désactive la protection MPROTECT.
Fini les problèmes avec Let’s Encrypt.
Régler les problèmes avec NodeJS :
Je ne veux pas faire mon troll, mais, avec du JavaScript serveur-side vous cherchez déjà les ennuis. Bon on va pas se mentir, j’ai utilisé Ghost pour mon site alors j’ai eu des problèmes avec GrSec.
On veut simplement lancer npm et la c’est le drame :
root@debian:~# npm Erreur de segmentation
Bon, la c’est pas une historie de dépendance comme chez Let’s Encrypt, on connait directement le fautif, NodeJS.
Même histoire que pour le composant Python de Let’s Encrypt, on converti les headers et on désactive la protection MPROTECT.
paxctl -cm /usr/bin/nodejs
Avec pour résultat :
root@debian:~# paxctl -cm /usr/bin/nodejs file /usr/bin/nodejs had a PT_GNU_STACK program header, converted root@debian:~# npm Usage: npm <command> where <command> is one of: access, add-user, adduser, apihelp, author, bin, bugs, c, cache, completion, config, ddp, dedupe, deprecate, dist-tag, dist-tags, docs, edit, explore, faq, find, find-dupes, get, help, help-search, home, i, info, init, install, issues, la, link, list, ll, ln, login, logout, ls, outdated, owner, pack, ping, prefix, prune, publish, r, rb, rebuild, remove, repo, restart, rm, root, run-script, s, se, search, set, show, shrinkwrap, star, stars, start, stop, t, tag, team, test, tst, un, uninstall, unlink, unpublish, unstar, up, update, upgrade, v, version, view, whoami npm <cmd> -h quick help on <cmd> npm -l display full usage info npm faq commonly asked questions npm help <term> search for help on <term> npm help npm involved overview Specify configs in the ini-formatted file: /root/.npmrc or on the command line via: npm <command> --key value Config info can be viewed via: npm help config npm@2.15.8 /usr/lib/node_modules/npm root@debian:~#
Régler les problèmes avec HHVM :
Alors le cas HHVM est un peu spécial.
Beaucoup de monde, moi compris, a cru que HHVM était complètement incompatible avec GrSec.
Toutefois, ce n’est actuellement pas le cas et je n’ai pas réussi à retrouver des traces de cela sur Internet, étrange donc.
Hormis ça, c’est toujours le même problème d’exécution en mémoire qui est présent avec la même résolution.
Si on lance HHVM on se retrouve avec cette erreur :
root@debian:~# hhvm -m server -p 80 Uncaught exception: Operation not permitted Core dumped: Aborted Stack trace in /tmp/stacktrace.10483.log Abandon
Même histoire que pour NodeJS, le coupable est connu, on lance donc la commande suivante :
paxctl -cm /usr/bin/hhvm
En sortie :
root@debian:/var/www# paxctl -cm /usr/bin/hhvm file /usr/bin/hhvm had a PT_GNU_STACK program header, converted root@debian:/var/www# service hhvm start
Et avec un petit phpinfo ou l’on voit bien le kernel GrSecurity et HHVM en cohabitation pacifique :
Pour d’autres applications :
Je n’ai jamais eu d’autres problèmes avec NGINX, MariaDB et PHP-FPM, mais des ressources sont disponibles sur le wiki de WikiBooks en cas de problèmes.
Une petite aide supplémentaire sur le fonctionnement et la gestion de PAX.
