Kernel GrSecurity et serveur Web

//Kernel GrSecurity et serveur Web
1/52/53/54/55/5 (1 votes, moyenne: 5,00 sur 5)
Loading...

Kernel GrSecurity et serveur Web

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 :

hhvm-grsec

 

 

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.

 

By |2016-07-21T09:43:37+00:0021 juillet 2016|GNU/Linux|0 Comments

About the Author:

Diplômé d'un BTS SIO SISR et travaillant actuellement en Suisse, je suis passionné par tout ce qui touche à l'informatique et la musique hard rock et métal depuis ma plus tendre enfance. Je suis le créateur et l'unique rédacteur d'Abyss Project, ce blog qui me sert de bloc-notes public en quelque sorte.

Poster un Commentaire

avatar

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.