Gentoo Logo

Guide Gentoo Grsecurity version 2

Table des matières :

1.  À propos de Grsecurity

Le projet Grsecurity

Le projet grsecurity, hébergé sur le site http://www.grsecurity.org, propose un certain nombre de correctifs pour le noyau Linux pour améliorer la sécurité de l'ensemble de votre système. Dans le chapitre suivant nous présenteront l'ensemble des fonctionnalités apportées par grsecurity. Une liste complète est maintenue à jour sur la page des fonctionnalités de grsecurity.

Dans la mesure où la plupart des fonctionnalités apportées par grsecurity sont liées au noyau, une grande partie de ce document présente en détail certaines fonctionnalités du noyau et leurs opérations « sysctl » (dans la mesure du possible).

Intégration au projet Gentoo Hardened

Le projet Gentoo Hardened maintient les améliorations liées à la sécurité sous Gentoo. Ce qui inclut, mais n'est pas limité à grsecurity.

Configuration du noyau

Tout au long de ce document nous allons parler de la configuration du noyau en utilisant des noms de variables comme CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. Ce sont des variables que le noyau utilise lors de la construction pour déterminer quelles fonctionnalités doivent être compilées ou non.

Quand vous configurez votre noyau avec la commande make menuconfig (ou similaire) vous disposez d'une interface utilisateur dans laquelle on vous propose de choisir un certain nombre d'options du noyau. Si vous sélectionnez le bouton Help pour une fonctionnalité donnée, vous pourrez voir que les options correspondent en fait à ces mêmes variables du noyau.

Vous pouvez donc toujours configurer votre noyau comme vous le souhaitez, en faisant bien sûr attention à ce que vous choisissez. Et si vous n'arrivez pas à trouver une option spécifique, vous pouvez toujours éditer le fichier/usr/src/linux/.config à la main.

Évidemment, pour pouvoir choisir parmi les options de noyau grsecurity vous devez activer le support de grsecurity dans votre noyau :

Exemple de code 1.1 : Activer grsecurity

CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CUSTOM=y

2.  PaX

Combattre l'exploitation des bogues logiciels

PaX introduit un certain nombre de mécanismes de sécurité qui rendent encore plus difficile l'exploitation de bogues logiciels par les attaquants lorsqu'elles concernent des corruptions de mémoire (ne croyez donc pas que PaX vous protégera contre toutes les attaques possibles de bogues logiciels). Le document d'introduction de PaX parle de trois techniques d'attaque possibles :

  1. Introduction et exécution de code arbitraire ;
  2. Exécution d'un code existant en dehors du cadre d'exécution normal du programme ;
  3. Exécution d'un code existant dans le cadre normal d'exécution de celui-ci, mais avec des données arbitraires.

Une méthode de prévention est d'interdire aux codes exécutables de se stocker dans une mémoire en écriture. Lors de l'exécution d'un processus, celui-ci aura besoin de cinq zones mémoires différentes :

  1. une zone de données qui contient des données allouées de manière statique ou globale ;
  2. Une zone BSS (Block Started by Symbol, pour bloc commençant par un symbole) qui contient des informations à propos des données du processus initialisées à zéro ;
  3. Une zone de code, aussi appelée le segment texte, qui contient des instructions exécutables ;
  4. Un tas (« heap ») qui contient la mémoire allouée dynamiquement ;
  5. Une pile (« stack ») qui contient les variables locales.

La première méthode de prévention utilisée par PaX appelée NOEXEC a pour but de permettre le contrôle de la génération du code d'exécution. Elle marque les pages mémoires qui ne contiennent pas de code exécutable comme étant des zones non-exécutables. Cela signifie que le tas et la pile qui ne contiennent que des données et ne devraient pas contenir de code exécutable seront marqués comme non-exécutables. Les attaques qui mettent du code à exécuter dans ces zones avec l'intention de les exécuter échoueront.

Pour dire vrai, NOEXEC va plus loin et les lecteurs intéressés devraient lire la documentation de NOEXEC pour PaX.

La seconde méthode de prévention employée par PaX s'appelle ASLR (Address Space Layout Randomization, pour Allocation aléatoire de l'espace adressé). Elle rend le processus d'allocation de la mémoire aléatoire pour chaque demande de mémoire. Si auparavant la mémoire était assignée de manière contiguë (ce qui signifie que les exploitations permettent de savoir où sont situées les zones mémoire de chaque tâche), ASLR rend aléatoire cette assignation, ce qui rend inutile l'utilisation de techniques utilisant ce type d'information.

Pour plus d'informations sur ASLR lisez la documentation de ASLR pour PaX.

Activer PaX

Les configurations noyau recommandées pour l'usage de PaX sont :

Exemple de code 2.1 : Configuration recommandée du noyau pour PaX

#
# PaX Control
#
# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set
CONFIG_GRKERNSEC_PAX_EI_PAX=y
CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set

#
# Address Space Protection
#
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y
# CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_HIDESYM=y

Si vous utilisez un système non-x86, vous n'aurez pas la variable CONFIG_GRKERNSEC_PAX_NOEXEC. À la place vous devez sélectionner la variable CONFIG_GRKERNSEC_PAX_PAGEEXEC qui est la seule implémentation de méthode de type non-exécution disponible.

Contrôler PaX

Toutes les applications ne s'accordent pas bien avec les restrictions de sécurité de PaX. Par exemple, xorg-x11, java, mplayer, xmms n'aiment pas PaX. Si vous voulez pouvoir les utiliser vous pouvez augmenter leur protection en utilisant les paquets chpax et paxctl.

Exemple de code 2.2 : Installer les outils chpax et paxctl

# emerge app-admin/chpax
# emerge app-admin/paxctl

chpax fournit un script d'initialisation qui gère la plupart des configurations d'applications connues pour vous :

Exemple de code 2.3 : Ajouter le script chpax au niveau de lancement par défaut

# rc-update add chpax default

pax-utils est une petite boîte à outils qui inclut des applications très pratiques pour administrer un serveur utilisant PaX.

Exemple de code 2.4 : Installer pax-utils

# emerge pax-utils

Les outils les plus intéressants sont scanelf et pspax :

  • Avec scanelf, vous pouvez passer en revue les répertoires de binaires et de bibliothèques pour lister les différents droits d'exécution et les types de binaires ELF qui continueront de fonctionner dans une configuration idéale utilisant pax/grsec ;
  • Avec pspax, vous pouvez afficher les paramètres/capacités/xattr de PaX du point de vue du noyau.

Vérifier la configuration de PaX

Peter Busser a écrit une suite de tests de régression nommée paxtest. Cet outil vérifiera plusieurs cas de vecteurs d'attaques possibles et vous informera des résultats. Lorsque vous l'exécutez, il laisse un fichier de jounalisation nommé paxtest.log dans le répertoire de travail courant.

Exemple de code 2.5 : Installation et exécution de paxtest

# emerge paxtest

# paxtest
Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 16 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 25 bits (guessed)
Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
Main executable randomisation (ET_DYN)   : 17 bits (guessed)
Shared library randomisation test        : 16 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : No randomisation
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Dans l'exemple précédent, vous remarquerez que :

  • strcpy et memcpy sont indiqués comme vulnérables. On s'y attendait et c'est normal, cela indique que vous avez besoin d'une technologie comme ProPolice/SSP ;
  • Il n'y a pas de processus aléatoire pour PAGEEXEC. C'est normal dans la mesure où la configuration du noyau x86 recommandée ne sélectionne pas la variable PAGEEXEC. Cependant, sur les architecture qui disposent du support d'un vrai bit NX (Non-eXécutable) (la plupart le supportent et notamment x86_64), PAGEXEC est la seule méthode disponible pour NOEXEC et n'aura pas de problème sur ce point.

3.  RBAC

Contrôle d'accès basé sur des rôles

Deux types de base de mécanismes de contrôle d'accès sont utilisés pour empêcher l'accès non autorisé aux fichiers (et de manière plus générale à toute information) : DAC (Discretionary Access Control, pour contrôle d'accès arbitraire) et MAC (Mandatory Access Control, pour contrôle d'accès obligatoire). Par défaut, Linux utilise un mécanisme DAC : le créateur du fichier peut définir qui a accès à ce fichier. Un système MAC en revanche oblige tous les utilisateurs à suivre des règles dictées par l'administrateur.

Le support grsecurity pour l'implémentation de MAC est nommée RBAC (Role Based Access Control). RBAC associé des rôles à chaque utilisateur. Chaque rôle définit quelles opérations peuvent être effectuées sur certains objets. Une fois que vous aurez un ensemble de rôles et d'opérations bien écrits, vos utilisateurs seront limités uniquement aux tâches que vous leur aurez données. Le rôle par défaut « deny-all » interdit aux utilisateurs d'effectuer une action à laquelle vous n'auriez pas pensé.

Configuration du noyau

La configuration du noyau recommandée pour le support de RBAC est :

Exemple de code 3.1 : Configuration du noyau recommandée pour RBAC

#
# Options RBAC
#
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

Utilisation de gradm

gradm est un outil qui vous permet d'administrer et de maintenir une politique pour votre système. Vous pouvez activer ou désactiver le système RBAC, recharger les rôles RBAC, configurer un mot de passe pour le mode administrateur, etc.

À l'installation de gradm, une politique par défaut sera installée dans /etc/grsec/policy :

Exemple de code 3.2 : Installation de gradm

# emerge gradm

Les politiques RBAC par défaut ne sont pas activées. C'est à l'administrateur système de choisir si le système utilisera des politiques RBAC et non celles de Gentoo. Avant d'activer le système RBAC, vous devez configurer un mot de passe administrateur.

Exemple de code 3.3 : Activation du système RBAC

# gradm -P admin
Setting up grsecurity RBAC password
Password: (Entrez un mot de passe bien choisi)
Re-enter Password: (Confirmez-le)
Password written in /etc/grsec/pw
# gradm -E

Pour désactiver le système RBAC exécutez gradm -D. Si vous n'y êtes pas autorisé, vous devez auparavant vous approprier les rôles administrateur :

Exemple de code 3.4 : Désactivation du système RBAC

# gradm -a admin
Password: (Entrez votre mot de passe administrateur pour les rôles)
# gradm -D

Si vous souhaitez abandonner le rôle administrateur, exécutez la commande gradm -u admin :

Exemple de code 3.5 : Abandon du rôle administrateur

# gradm -u admin

Génération d'une politique

Le système RBAC propose unr fonctionnalité intéressante nommée « learning mode » (mode d'apprentissage). Le mode d'apprentissage peut générer une politique d'anticipation de privilèges pour votre système. Cela permet d'économiser temps et argent en déployant rapidement de nombreux serveurs sécurisés.

Pour utiliser le mode d'apprentissage vous devez l'activer en utilisant gradm :

Exemple de code 3.6 : Activation du mode d'apprendissage RBAC

# gradm -F -L /etc/grsec/learning.log

Maintenant, utilisez votre système, faites ce que vous feriez normalement. Essayez d'éviter de faire une synchronisation rsync, d'utiliser locate ou toute autre opération impliquant une manipulation lourde de fichiers. En effet, cela peut ralentir énormément votre système.

Quand vous pensez avoir utilisé votre système suffisamment pour obtenir une bonne politique, indiquez à gradm qu'il peut commencer l'apprentissage et proposer des rôles dans le fichier /etc/grsec/learning.roles :

Exemple de code 3.7 : Effectuer l'apprentissage en utilisant le journal d'actions

# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles

Vérifiez le fichier /etc/grsec/learning.roles et sauvegardez-le dans le fichier /etc/grsec/policy (avec les permissions 0600) une fois que vous avez fini.

Exemple de code 3.8 : Sauvegarder les politiques

# mv /etc/grsec/learning.roles /etc/grsec/policy
# chmod 0600 /etc/grsec/policy

Vous devriez maintenant pouvoir activer le système RBAC en utilisant la politique nouvellement apprise.

Peaufiner votre politique

Une fonctionnalité intéressante de grsecurity2 est le Set Operation Support (Support de la mise en place d'opérations) pour le fichier de configuration. Actuellement il supporte les unions, les intersections et les différences de sets (ou objets dans notre cas).

Exemple de code 3.9 : Exemple de sets

define setobj1 {
/root/titi rw
/root/toto2 r
/root/toto3 x
}

define unnom2 {
/root/test1 rw
/root/toto2 rw
/root/bars3 h
}

Voici un exemple d'utilisation et les objets résultant seront ajoutés à votre sujet :

Exemple de code 3.10 : Exemple de l'opérateur &

subject /unbinaire o
$setobj1 & $unnom2

Ce qui est équivalent à :

Exemple de code 3.11 : Configuration résultante

subject /unbinaire o
/root/toto2 r

C'est le résultat de l'opérateur & qui récupère les deux sets et retourne la liste des fichiers qui sont présents dans les deux sets et les permissions de ces fichiers présentes dans les deux sets.

Exemple de code 3.12 : Exemple de l'opérateur |

subject /unbinaire o
$setobj1 | $unnom2

Cet exemple est équivalent à :

Exemple de code 3.13 : Configuration résultante

subject /unbinaire o
/root/titi rw
/root/toto2 rw
/root/toto3 x
/root/test1 rw
/root/bars3 h

C'est le résultat de l'opérateur | qui récupère les deux sets et retourne les fichiers qui existent dans les deux. Si un fichier est dans les deux sets il récupère les permissions qui existent dans l'un ou l'autre des deux sets.

Exemple de code 3.14 : Exemple de l'opérateur -

subject /unbinaire o
$setobj1 - $unnom2

Cet exemple est équivalent à :

Exemple de code 3.15 : Configuration résultante

subject /unbinaire o
/root/titi rw
/root/toto2 h
/root/toto3 x

C'est le résultat de l'opérateur - qui prend les deux sets et retourne les fichiers existant dans le set de gauche mais pas dans le set de droite. Si un fichier est présent dans les deux (ou bien un répertoire parent existe dans le set de droite) il sera retourné et les permissions sur le fichier seront celles du fichier de gauche auxquelles on aura retiré les permissions données dans le second set.

Dans un pseudo langage, vous pourriez l'interpréter ainsi :

Exemple de code 3.16 : Explication avec un pseudo langage

si ( ($setobj1 contient /tmp/toto rw) et
     ($setobj2 contient /tmp/toto r) )
alors
  $setobj1 - $setobj2 doit contenir /tmp/toto w

si ( ($setobj1 contient /tmp/toto rw) et
     ($setobj2 contient / rwx) )
alors 
  $setobj1 - $setobj2 doit contenir /tmp/toto h

L'ordre de priorité, de la plus forte à la plus faible, est le suivant : -, & |.

Si vous ne voulez pas vous encombrer l'esprit avec les priorités d'opérations, le support des parenthèses est également fourni. Vous pouvez donc écrire, par exemple :

Exemple de code 3.17 : Exemple d'utilisation des parenthèses

(($set1 - $set2) | $set3) & $set4

4.  Protection des systèmes de fichiers

Lutter contre le chroot et l'abus dans les systèmes de fichiers

Grsecurity2 dispose de nombreux correctifs qui empêchent les utilisateurs d'obtenir une connaissance inutile à propos du système. Cela inclut notamment des restrictions sur l'utilisation de /proc, du chroot, l'utilisation de liens symboliques, etc.

Configuration du noyau

Nous vous recommandons la configuration de la protection des systèmes de fichiers suivante :

Exemple de code 4.1 : Activatiion de la protection des systèmes de fichiers

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=10
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y

Activation du mécanisme de sécurité

Lorsque vous utilisez un noyau compilé avec les options indiquées plus haut (ou des options similaires), vous pouvez activer ou désactiver plusieurs de ces options en utilisant le système de fichiers /proc ou en utilisant sysctl.

L'exemple ci-dessous montre un extrait classique du fichier /etc/sysctl.conf :

Exemple de code 4.2 : Exemple de paramètres dans /etc/sysctl.conf

kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_execlog = 0
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_shmat = 1

Vous pouvez activer ou non les options à volonté en utilisant la commande sysctl :

Exemple de code 4.3 : Activer des paramètres avec sysctl

(Activer la fonctionnalité exec_logging)
# sysctl -w kernel.grsecurity.exec_logging = 1
(Désactiver la fonctionnalité exec_logging)
# sysctl -w kernel.grsecurity.exec_logging = 0

Une option très importante de sysctl appartenant à grsecurity : kernel.grsecurity.grsec_lock. Quand elle est activée, vous ne pouvez plus changer aucune option.

Exemple de code 4.4 : Protéger l'interface sysctl

# sysctl -w kernel.grsecurity.grsec_lock = 1

5.  Auditer le noyau

Étendre votre possibilités de journalisation du système

grsecurity ajoute une fonctionnalité supplémentaire au noyau appartenant à la journalisation. Avec l'audit de noyau de grsecurity, le noyau vous informera quand les applications sont exécutées, les périphériques (dé)montés, etc.

Les différentes options d'audit du noyau

La section de configuration du noyau suivante peut être utilisée pour activer les options d'audit du noyau de grsecurity :

Exemple de code 5.1 : Activation de l'audit du noyau

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_AUDIT_IPC=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y

6.  Restrictions des processus

Protection des fichiers exécutables

Avec grsecurity vous pouvez restreindre les exécutables. Dans la mesure où la plupart des exploitations de failles fonctionnent à l'aide d'un ou plusieurs processus en exécution cette protection peut préserver la santé de votre système.

Protection du réseau

La pile TCP/IP de Linux est vulnérable aux attaques basées sur la prédiction. Grsecurity propose des correctifs utilisant des procédés aléatoires pour contrer ces attaques. En plus de cela, vous pouvez également activer des restrictions sur les sockets, interdisant l'accès au réseau à certains groupes.

Configuration du noyau

Les options du noyau présentées ci-dessous activent plusieurs protections sur les exécutables et le réseau :

Exemple de code 6.1 : Configuration du noyau

#
# Executable Protections
#
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
CONFIG_GRKERNSEC_TPE_GID=100

#
# Network Protections
#
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
# CONFIG_GRKERNSEC_SOCKET is not set

7.  L'ensemble d'outils « Hardened »

Même si ce n'est pas dans l'objectif de ce document, nous mentionnons l'utilisation de l'ensemble des outils « hardened » qui complète le modèle grsec/PaX du côté de l'espace utilisateur. Pour commencer rapidement, vous pouvez exécuter les commandes suivantes :

Exemple de code 7.1 : Utiliser les outils proposés par le projet hardened

# cd /etc
# rm make.profile
# ln -s ../usr/portage/profiles/hardened/x86 make.profile
# emerge -e world

Si vous n'avez pas envie d'utiliser ce profil ajoutez les paramètres USE hardened pic pie à votre variable USE dans le fichier /etc/make.conf.

8.  Ressources



Imprimer

Dernière mise à jour le 6 octobre 2004

Résumé : Ce document propose un certain nombre de correctifs de sécurité grsecurity2, des options de configuration supportées par le noyau et des outils mis à disposition par le projet grsecurity pour améliorer la sécurité de votre système.

solar
Auteur

Sven Vermeulen
Auteur

Clément Varaldi
Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.