Documentation : Introduction à Grsecurity

Date de publication : 11.3.2005
Date de modification : 9.11.2005

Sommaire

• Introduction

• Grsecurity kernel auditing

• Grsecurity Filesystem Protections

• Grsecurity Network Protections

Grsecurity est un patch kernel Linux 2.4.x et 2.6.x sous licence GPL. Ce patch offre les possibilités suivantes pour sécuriser votre serveur linux :

• Système RBAC (Role-Based Access Control).

• Renforcement de la sécurité au niveau des chroot

• Prévention des "/tmp race condition"

• Monitoring renforcé du système

• Prévention contre des exploits basés sur les débordements mémoire (PaX)

• Stack TCP/IP aléatoire

• Restriction de la visualisation des processus d'un utilisateur à lui-même (Sauf root)

La liste de toutes les fonctionnalités de ce patch kernel sont présentées sur le site grsecurity

Nous allons étudier ci-dessous quelques unes des possibilités du patch grsecurity. Nous n'aborderons pas dans cette documentation toutes les options relatives à RBAC et PaX. Le patch grsecurity étudié est de deuxième génération et pour les kernel de génération 2.4

Remerciement : solar du projet Gentoo Hardened pour les scripts de regression

Grsecurity kernel auditing

Une des options de Grsecurity donne la possibilité de "loger" différentes actions des utilisateurs ou d'un groupe d'utilisateur en particulier, ou encore des "loger" toutes les actions du système. Nous décidons de ne "loger" que les actions du groupe d'utilisateur "untrusted" que nous considérons comme groupe non sûre. Il nous faut au préalable créer le groupe "untrusted" dont nous allons forcer le GID à 2000.

groupadd -g 2000 untrusted

Ajoutons maintenant un utilisateur "client" dont nous voulons monitorer toutes les actions effectuées sur le serveur. Nous allons bien sûr donner un mot de passe à cet utilisateur.

useradd -s /bin/bash -d /home/client -g untrusted -m client
passwd client

Rentrons maintenant dans le sujet des fonctionnalités présentes dans Grsecurity Kernel Auditing

• CONFIG_GRKERNSEC_AUDIT_GROUP :
  
  Si cette option est sélectionnée, les monitoring exec, chdir, mount, unmount et ipc ne seront effectués que pour le groupe spécifié. Cette option est recommandée si vous désirez monitorer certains utilisateurs présents dans un groupe commun, plutôt que de monitorer le système entier. Si l'option sysctl est activée, il est possible d'activer cette option par audit_group = 1
  
  Nous allons nous intéresser uniquement au groupe "untrusted" créé précédement, donc nous sélectionnons cette option.

  
  

• CONFIG_GRKERNSEC_AUDIT_GID :
  
  Ici peut être entré le GID qui sera la cible du monitoring kernel. Ne pas oublier de rajouter les utilisateurs que vous désirez monitorer au GID spécifié. Si l'option sysctl est activée, la configuration du gid par sysctl se fera par le biais de audit_gid = 2000.

  
  

• CONFIG_GRKERNSEC_EXECLOG :
  
  Si cette option est sélectionnée, tous les appels execve() seront monitorer. Cette fonctionnalité est intéressante pour un serveur ayant des comptes shell utilisateurs. Par exemple, ls, uname, netstat, vi, df, etc. Presque toutes les commandes unix sont ainsi "loger". Si l'option sysctl est activée, il est possible d'activer cette option par exec_logging = 1

  Exemple de log grsec pour EXECLOG : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ ls -la Mar 11 14:09:51 sysadmin kernel: grsec: From 192.168.1.25: exec of /bin/ls (ls --color=auto -la ) by /bin/bash[bash:2981] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:2964] uid/euid:1000/1000 gid/egid:2000/2000

  Cette option peut produire beaucoup de logs, à utiliser avec précaution.

  
  

• CONFIG_GRKERNSEC_RESLOG :
  
  Si cette option est sélectionnée, toutes les tentatives de dépassement de limites de ressources seront monitorées, avec le nom de la ressource, la taille demandée et la limite courante. Il est recommandé d'activer cette option.

  Exemple de log RESLOG : Plantage de gkrellm2 Mar 11 14:20:51 sysadmin kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (gkrellm2:19326) UID(1000) EUID(1000), parent (fluxbox:30547) UID(1000) EUID(1000)

  
  

• CONFIG_GRKERNSEC_CHROOT_EXECLOG :
  
  Si cette option est sélectionnée, toutes les commandes exécutée dans un jail chroot seront monitorées. Si l'option sysctl est activée, il est possible d'activer cette option par exec_logging = 1

  Exemple 1 de log grsec CHROOT_EXECLOG : Utilisateur root, commande ls Mar 11 15:03:02 sysadmin kernel: grsec: From 192.168.1.25: exec of /var/chroot/bin/ls within chroot by process /var/chroot/bin/bash[bash:2617] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2590] uid/euid:0/0 gid/egid:0/0

  Exemple 2 de log grsec CHROOT_EXECLOG : Utilisateur chrootclient membre du groupe untrusted, commande ls Mar 11 16:44:30 sysadmin kernel: grsec: From 192.168.1.25: exec of /home/chrootclient/bin/ls (ls ) by /home/chrootclient/bin/bash[bash:19772] uid/euid:1001/1001 gid/egid:2000/2000, parent /home/chrootclient/bin/bash[bash:19771] uid/euid:1001/1001 gid/egid:2000/2000

  
  

• CONFIG_GRKERNSEC_AUDIT_CHDIR :
  
  Si cette option est sélectionnée, toutes les commandes chdir() seront monitorées. Si l'option sysctl est activée, il est possible d'activer cette option par audit_chdir = 1

  Exemple de log grsec AUDIT_CHDIR : Utilisateur client, commande cd test/ Mar 11 17:08:06 sysadmin kernel: grsec: From 192.168.1.25: chdir to /home/client/test by /bin/bash[bash:2532] uid/euid:1000/1000 gid/egid:2000/2000, parent /usr/sbin/sshd[sshd:2531] uid/euid:1000/1000 gid/egid:2000/2000

  
  

• CONFIG_GRKERNSEC_AUDIT_MOUNT :
  
  Si cette option est sélectionnée, tous les montages (mount) et démontages (unmount) seront monitorés. Si l'option sysctl est activée, il est possible d'activer cette option par audit_mount = 1

  Exemple de log grsec AUDIT_MOUNT : Utiilsateur root, commande mount -o loop fichier.iso /mnt/loop Mar 11 17:36:09 sysadmin kernel: grsec: From 192.168.1.25: mount /dev/loop0 to /mnt/loop by /bin/mount[mount:3976] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:2505] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_AUDIT_IPC :
  
  Si cette option est sélectionnée, l'ajout ou la suppression de files de messages, de semaphores, de mémoire partagée seront monitorés. Si l'option sysctl est activée, il est possible d'activer cette option par audit_ipc = 1

  Exemple de log grsec AUDIT_IPC : Mar 22 11:25:29 sysadmin kernel: grsec: From 192.168.1.25: shared memory of size 1024 created by /home/client/testshm.php[testshm.php:17904] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:17888] uid/euid:1000/1000 gid/egid:2000/2000 Mar 22 11:25:37 sysadmin kernel: grsec: From 192.168.1.25: semaphore created by /home/client/testshm.php[testshm.php:17904] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:17888] uid/euid:1000/1000 gid/egid:2000/2000 Mar 22 11:25:37 sysadmin kernel: grsec: From 192.168.1.25: shared memory of size 1024 created by /home/client/testshm.php[testshm.php:17904] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:17888] uid/euid:1000/1000 gid/egid:2000/2000 Mar 22 11:25:37 sysadmin kernel: grsec: From 192.168.1.25: shared memory of uid:1000 euid:1000 removed by /home/client/testshm.php[testshm.php:17904] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:17888] uid/euid:1000/1000 gid/egid:2000/2000 Mar 22 11:25:37 sysadmin kernel: grsec: From 192.168.1.25: semaphore of uid:1000 euid:1000 removed by /home/client/testshm.php[testshm.php:17904] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:17888] uid/euid:1000/1000 gid/egid:2000/2000

  
  

• CONFIG_GRKERNSEC_SIGNAL :
  
  Si cette option est sélectionnée, certain signaux importants seront monitorés, tels que les signaux du type SIGSEGV, qui vous avertis si une erreur dans un programme a eu lieu, ce qui pourrait sous-entendre dans certains cas qu'une tentative d'exploit a eu lieu. Si l'option sysctl est activée, il est possible d'activer cette option par signal_logging = 1

  Exemple de log grsec SIGNAL : Mar 14 14:53:30 sysadmin kernel: grsec: From 192.168.1.25: signal 11 sent to /usr/nagios/bin/nagios[nagios:7325] uid/euid:102/102 gid/egid:409/409, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_FORKFAIL :
  
  Si cette option est sélectionnée, tous les fork() ayant échoués seront monitorés. Ces messages peuvent suggérer une attaque du type "fork bomb", ou qu'un utilisateur essaye de dépasser ses limites de processus. Si l'option sysctl est activée, il est possible d'activer cette option par forkfail_logging = 1

  Exemple de log grsec FORKFAIL : Mar 15 16:14:35 sysadmin kernel: grsec: From 192.168.1.25: failed fork with errno -11 by /root/test/fork-bomb[fork-bomb:4362] uid/euid:0/0 gid/egid:0/0, parent /root/test/fork-bomb[fork-bomb:4009] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_TIME :
  
  Si cette option est sélectionnée, toutes les modifications de l'horloge système seront monitorés. Si l'option sysctl est activée, il est possible d'activer cette option par timechange_logging = 1

  Exemple de log grsec TIME : Mar 15 16:39:23 sysadmin kernel: grsec: time set by /sbin/hwclock[hwclock:1806] uid/euid:0/0 gid/egid:0/0, parent /sbin/rc[rc:1805] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_PROC_IPADDR :
  
  Si cette option est sélectionnée, une nouvelle entrée va être ajoutée dans chaque répertoire /proc/ contenant l'adresse IP de la personne utilisant ce processus. Cette information peut être utile pour des IDS afin de pouvoir effectuer des contre-mesures à une attaque locale. Cette entrée n'est lisible que par l'utilisateur du processus (et l'utilisateur root si celui-ci a "CAP_DAC_OVERRIDE", dont l'accès au root peut être supprimé par le système RBAC).

  Exemple : sysadmin root # ps faux ... root 2737 0.0 0.3 5872 1872 ? Ss 17:14 0:00 \_ sshd: root@pts/1 root 2741 0.6 0.3 2608 1696 pts/1 Ss 17:14 0:00 \_ -bash root 3910 0.0 0.1 2332 784 pts/1 R+ 17:15 0:00 \_ ps faux ... sysadmin root # cat /proc/2737/ipaddr 192.168.1.25

Grsecurity inclus de nombreux patch qui interdisent à des utilisateurs d'obtenir des informations non nécessaires sur le système. Cela inclus des restriction sur la récupération d'informations sur /proc, des restrictions sur les actions possibles dans un chroot, des restrictions sur l'utilisation de liens symboliques, de l'utilisation des commandes FIFO.

• CONFIG_GRKERNSEC_PROC :
  
  Si cette option est sélectionnée, les permissions sur le système de fichier /proc sera modifié pour lui fournir plus de sécurité. Il faut au moins choisir si on utilise un restriction uniquement utilisateur ou si on utilise un restriction utilisateur et groupe. Suivant l'option choisie, vous pouvez restreindre des utilisateurs à ne voir que leurs processus, ou choisir un groupe qui peut voir tous les processus et tous les fichiers dont l'accès est normallement restreints à l'utilisateur root.
  

• CONFIG_GRKERNSEC_PROC_USER :
  
  Si cette option est sélectionnée, les utilisateurs non root pourront voir uniquement leurs propres processus, l'accès aux informations réseaux seront restreintes, ainsi que les symboles du kernel et les informations sur les modules.

  Exemple sans PROC_USER : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ netstat -taue Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode tcp 0 0 *:ssh *:* LISTEN root 2618 tcp 0 0 192.168.1.49:ssh 192.168.1.25:37681 ESTABLISHED root 2837 tcp 0 144 192.168.1.49:ssh 192.168.1.25:53793 ESTABLISHED root 2884 udp 18876 0 *:bootpc *:* root 2528 client@sysadmin client $ ps faux ... root 2213 0.0 0.1 1420 604 ? Ss 11:21 0:00 /usr/sbin/syslogd -m 0 root 2228 0.0 0.0 1376 440 ? Ss 11:21 0:00 /usr/sbin/klogd -c 3 -2 root 2335 0.0 0.0 1388 448 ? Ss 11:21 0:00 /sbin/dhcpcd eth0 root 2439 0.0 0.2 3060 1428 ? Ss 11:21 0:00 /usr/sbin/sshd ... client@sysadmin client $ lsmod Module Size Used by Not tainted pdcraid 12064 8 ataraid 6596 8 [pdcraid] usb-ohci 17480 0 (unused) usbcore 59084 1 [usb-ohci]

  Exemple avec PROC_USER : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ netstat -taue Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode /proc/net/tcp: Permission denied client@sysadmin client $ ps faux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND client 2741 0.0 0.3 5872 1880 ? S 12:58 0:00 sshd: client@pts/1 client 2742 0.1 0.3 2476 1676 pts/1 Ss 12:58 0:00 \_ -bash client 3908 0.0 0.1 2332 756 pts/1 R+ 13:00 0:00 \_ ps faux client@sysadmin client $ lsmod Module Size Used by Not tainted /proc/modules: Permission denied

  
  

• CONFIG_GRKERNSEC_PROC_ADD :
  
  

  Si cette option est sélectionnée, des restrictions supplémentaires seront ajoutées sur /proc pour interdire à un utilisateur normal de voir les informations CPU et sur les informations matériels.

  Exemple sans PROC_ADD : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ cat /proc/cpuinfo ... model name : Pentium III (Coppermine) stepping : 10 cpu MHz : 866.304 cache size : 256 KB ...

  Exemple avec PROC_ADD : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ cat /proc/cpuinfo cat: /proc/cpuinfo: Permission denied

  
  

• CONFIG_GRKERNSEC_PROC_USERGROUP :
  
  

  Si cette option est sélectionnée, il vous sera possible de sélectionner un groupe qui aura le droit de voir tous les processus, les informations relatives au réseau, au kernel et modules.
  
  Pour nos exemples nous allons créer un groupe trusted et un utilisateur sysadmin qui sera dans le groupe sysadmin.
  
  sysadmin root # groupadd -g 2001 trusted
  sysadmin root # useradd -s /bin/bash -d /home/sysadmin -g trusted -m sysadmin
  
  Ajoutons le groupe 2001 à l'option CONFIG_GRKERNSEC_PROC_USERGROUP

  Exemple sans PROC_USERGROUP : sysadmin@sysadmin sysadmin $ id uid=1002(sysadmin) gid=2001(trusted) groups=2001(trusted) sysadmin@sysadmin sysadmin $ ps faux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND sysadmin 8790 0.2 0.3 5872 1872 ? S 14:14 0:00 sshd: sysadmin@pts/2 sysadmin 8791 5.2 0.3 2476 1672 pts/2 Ss 14:14 0:00 \_ -bash sysadmin 8826 0.0 0.1 2332 756 pts/2 R+ 14:14 0:00 \_ ps faux sysadmin@sysadmin sysadmin $ netstat -taue Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode /proc/net/tcp: Permission denied

  Bien sur l'utilisateur client a aussi access a toutes ces informations.

  Exemple avec PROC_USERGROUP : sysadmin@sysadmin sysadmin $ id uid=1002(sysadmin) gid=2001(trusted) groups=2001(trusted) sysadmin@sysadmin sysadmin $ ps faux ... root 2213 0.0 0.1 1420 604 ? Ss 14:23 0:00 /usr/sbin/syslogd -m 0 root 2228 0.0 0.0 1376 440 ? Ss 14:23 0:00 /usr/sbin/klogd -c 3 -2 root 2335 0.0 0.0 1388 448 ? Ss 14:23 0:00 /sbin/dhcpcd eth0 ... client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ ps faux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND client 2527 0.0 0.3 5872 1872 ? S 14:26 0:00 sshd: client@pts/1 client 2528 0.2 0.3 2476 1676 pts/1 Ss 14:26 0:00 \_ -bash client 2545 0.0 0.1 2332 756 pts/1 R+ 14:28 0:00 \_ ps faux

  
  

• CONFIG_GRKERNSEC_LINK :
  
  

  Si cette option est sélectionnée, les utilisateurs ne sont plus capable de suivre des liens symboliques d'autres utilisateurs dans un répertoire écrivable par tous et avec un sticky bit +t (/tmp par exemple), à moins que le propriétaire du lien symbolique soit le propriétaire du répertoire. Les utilisateurs ne seront aussi plus capable de faire des liens (non symboliques) sur des fichiers dont ils ne sont pas les propriétaires. Si l'option sysctl est activée, il est possible d'activer cette option par linking_restrictions = 1

  Exemple sans LINK : sysadmin@sysadmin sysadmin $ id uid=1002(sysadmin) gid=2001(trusted) groups=2001(trusted) sysadmin@sysadmin sysadmin $ touch file sysadmin@sysadmin sysadmin $ ls -la file -rw-r--r-- 1 sysadmin trusted 0 Mar 18 15:13 file client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ ln /home/sysadmin/file hardlink client@sysadmin client $ ls -la hardlink -rw-r--r-- 2 sysadmin trusted 0 Mar 18 15:13 hardlink

  Exemple avec LINK : sysadmin@sysadmin sysadmin $ id uid=1002(sysadmin) gid=2001(trusted) groups=2001(trusted) sysadmin@sysadmin sysadmin $ touch file sysadmin@sysadmin sysadmin $ ls -la file -rw-r--r-- 1 sysadmin trusted 0 Mar 18 15:13 file client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) client@sysadmin client $ ln /home/sysadmin/file hardlink ln: creating hard link `hardlink' to `/home/sysadmin/file': Operation not permitted Mar 21 13:05:48 sysadmin kernel: grsec: From 192.168.1.25: denied hardlink of /home/sysadmin/file (owned by 1002.2001) to hardlink for /bin/ln[ln:2608] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:2593] uid/euid:1000/1000 gid/egid:2000/2000

  
  

• CONFIG_GRKERNSEC_FIFO :
  
  

  Si cette option est sélectionnée, les utilisateurs ne sont plus capables de lire les FIFO dont ils ne sont pas les propriétaires dans un répertoire écrivable par tous et qui possède un sticky bit +i (/tmp par exemple), à moins que le propriétaire du FIFO ne soit le propriétaire du répertoire. Si l'option sysctl est activée, il est possible d'activer cette option par fifo_restrictions = 1.
  

• CONFIG_GRKERNSEC_CHROOT :
  
  Si cette option est sélectionnée, vous aurez la possibilité de choisir différentes options qui rendront le cassage de chroot plus difficile.
  

• CONFIG_GRKERNSEC_CHROOT_MOUNT :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot n'aura pas le droit de monter ou de demonter des systèmes de fichiers. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_mount = 1

  Exemple sans CHROOT_MOUNT : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin root # chroot /var/chroot/ /bin/bash sysadmin / # mount -o loop test.ext3 test/ sysadmin / # cd test/

  Exemple avec CHROOT_MOUNT : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin root # chroot /var/chroot/ /bin/bash sysadmin / # mount -o loop test.ext3 test/ mount: permission denied Mar 21 12:30:48 sysadmin kernel: grsec: From 192.168.1.25: denied attempt to mount test.ext3 as /var/chroot/test from chroot by /var/chroot/bin/mount[mount:2543] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2541] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_CHROOT_DOUBLE :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot n'auront plus le possibilité de se chroot en dehors du chroot. Cette méthode est utilisée largement pour casser le chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_chroot = 1
  
  Le script d'exemple de cassage de chroot est pris depuis http://www.bpfh.net/simes/computing/chroot-break.html
  
  Notre chroot est situé dans /var/chroot (#define TEMP_DIR "/var/chroot").

  Exemple sans CHROOT_DOUBLE : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin test # gcc -o chroot-break chroot-break.c sysadmin test # ./chroot-break sysadmin / # sysadmin / # ls -la /var/ ... drwxr-xr-x 4 root root 4096 Mar 11 12:20 cache drwxr-xr-x 19 root root 4096 Mar 21 11:01 chroot drwxr-xr-x 3 root root 4096 Oct 27 23:40 db ... Comme on peut le voir le chroot a été cassé.

  Exemple avec CHROOT_DOUBLE : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin test # gcc -o chroot-break chroot-break.c sysadmin test # ./chroot-break sysadmin / # Mar 21 16:47:15 sysadmin kernel: grsec: From 192.168.1.25: denied attempt to double chroot to / by /root/test/chroot-break[chroot-break:6310] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:2541] uid/euid:0/0 gid/egid:0/0 sysadmin / # ls -la /var/ ... drwxr-xr-x 4 root root 4096 Oct 27 22:19 cache drwxr-xr-x 3 root root 4096 Oct 27 21:40 db mais ;) effectuons ceci : sysadmin / # ls -la var/ ... drwxr-xr-x 4 root root 4096 Mar 11 12:20 cache drwxr-xr-x 19 root root 4096 Mar 21 11:01 chroot drwxr-xr-x 3 root root 4096 Oct 27 23:40 db ... Il est toujours possible de sortir du chroot

  
  

• CONFIG_GRKERNSEC_CHROOT_PIVOT :
  
  Si cette option est sélectionnée, les processus à l'intérieur d'un chroot n'auront pas le droit d'utiliser la fonction pivot_root() qui a été introduite dans le Linux Kernel 2.3.41. Cette fonction est identique à chroot. Cette fonction pourrait être utilisée dans un processus à l'intérieur d'un chroot pour tenter de casser le chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_pivot = 1

  Exemple avec CHROOT_PIVOT : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin root # chroot /var/chroot/ sysadmin / # pivot_root secondchroot/ . pivot_root: Operation not permitted Mar 22 11:53:14 sysadmin kernel: grsec: From 192.168.1.25: denied attempt to pivot_root from chroot by /var/chroot/sbin/pivot_root[pivot_root:2561] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2560] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_CHROOT_CHDIR :
  
  Si cette option est sélectionnée, le répertoire courant de toutes applications dans un chroot sera affecté au répertoire root du chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_enforce_chdir = 1

  Exemple sans CHROOT_CHDIR : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin root # chroot /var/chroot/ sysadmin / # ls -la var/ ... drwxr-xr-x 4 root root 4096 Mar 11 12:20 cache drwxr-xr-x 19 root root 4096 Mar 21 11:01 chroot drwxr-xr-x 3 root root 4096 Oct 27 23:40 db ... On peut voir les fichiers qui sont en dehors du chroot

  Exemple avec CHROOT_CHDIR : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin root # chroot /var/chroot/ sysadmin / # ls -la var/ ... drwxr-xr-x 4 root root 4096 Mar 11 12:20 cache drwxr-xr-x 3 root root 4096 Oct 27 23:40 db ...

  
  

• CONFIG_GRKERNSEC_CHROOT_CHMOD :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot ne pourrait plus changer les droits sur des fichiers pour leurs donner des bits suid ou sgid. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_chmod = 1

  Exemple avec CHROOT_CHMOD : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin root # chroot /var/chroot/ sysadmin / # touch test sysadmin / # chmod u+s test chmod: changing permissions of `test': Permission denied Mar 22 15:01:48 sysadmin kernel: grsec: From 192.168.1.25: denied attempt to chmod +s /var/chroot/test by /var/chroot/bin/chmod[chmod:2582] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2561] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_CHROOT_FCHDIR :
  
  Si cette option est sélectionnée, une méthode connu pour casser les chroot par le biais de la fonction fchdir(). Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_fchdir = 1

  Exemple avec CHROOT_FCHDIR : sysadmin var # id uid=0(root) gid=0(root) groups=0(root),... sysadmin test # ./chroot-break Failed to fchdir - Operation not permitted Mar 23 14:55:01 sysadmin kernel: grsec: From 192.168.1.25: attempted fchdir outside of chroot to /root/test by /root/test/chroot-break[chroot-break:5828] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:2515] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_CHROOT_MKNOD :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot ne pourrons plus effectuer de mknod. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_mknod = 1

  Exemple sans CHROOT_MKNOD : sysadmin root # chroot /var/chroot/ sysadmin / # mknod test c 4 64 sysadmin / # ls -la test crw-r--r-- 1 root root 4, 64 Mar 23 13:57 test

  Exemple avec CHROOT_MKNOD : sysadmin root # chroot /var/chroot/ sysadmin / # mknod test c 4 64 mknod: `test': Operation not permitted Mar 23 15:18:31 sysadmin kernel: grsec: From 192.168.1.25: refused attempt to mknod /var/chroot/test from chroot by /var/chroot/bin/mknod[mknod:2550] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2549] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_CHROOT_SHMAT :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot ne pourraont pas s'attacher aux segments de mémoire partagée créés en dehors du chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_shmat = 1
  

• CONFIG_GRKERNSEC_CHROOT_UNIX :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot ne pourra pas se connecter à des sockets domain abstraits Unix qui ont été lancé en dehors d'un chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_unix = 1
  

• CONFIG_GRKERNSEC_CHROOT_FINDTASK :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot ne seront pas capable d'effectuer un kill, d'envoyer des signaux via fcntl, ptrace, capget, setpgid, getpgid, getsid ou voir tous autre processus en dehors du chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_findtask = 1
  
  Les scripts d'exemples sont tirés de Linux Gazette

  Exemple sans CHROOT_FINDTASK : En dehors du chroot : (lecture des processus) sysadmin / # ps faux ... root 2345 0.0 0.0 1388 448 ? Ss Mar23 0:00 /sbin/dhcpcd eth0 root 2449 0.0 0.2 3060 1428 ? Ss Mar23 0:00 /usr/sbin/sshd ... Dans le chroot : (lecture des processus) sysadmin / # ps faux ... root 2345 0.0 0.0 1388 448 ? Ss Mar23 0:00 /sbin/dhcpcd eth0 root 2449 0.0 0.2 3060 1428 ? Ss Mar23 0:00 /usr/sbin/sshd ... En dehors du chroot nous lançons un script qui bouclera sur lui même : sysadmin test # ./loop je loop loop looje loop loop ........ Dans le chroot nous récupérons le pid du script loop et essayons de le tuer : sysadmin / # ps faux | grep loop | awk -F " " '{print $2}' | head -n 1 11712 sysadmin / # ./catch 11712 Mesg : trying to launch shellcode on process 11712 %eip : 0x4009fab5 %esp : 0xbffff744 Inserting shellcode into bffff544 Nous pouvons voir que notre loop c'est interrompu avec comme message d'erreur : loop loop looje loop l Oh, Caught Killed

  Exemple avec CHROOT_FINDTASK : En dehors du chroot : (lecture des processus) sysadmin / # ps faux ... root 2345 0.0 0.0 1388 448 ? Ss Mar23 0:00 /sbin/dhcpcd eth0 root 2449 0.0 0.2 3060 1428 ? Ss Mar23 0:00 /usr/sbin/sshd ... Dans le chroot : (lecture des processus) sysadmin / # ps faux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2611 0.5 0.2 2080 1176 ? S 14:56 0:00 /bin/bash -i root 2612 0.0 0.1 2332 760 ? R+ 14:56 0:00 \_ ps faux En dehors du chroot nous lançons un script qui bouclera sur lui même : sysadmin test # ./loop je loop loop looje loop loop ........ Dans le chroot nous récupérons le pid du script loop et essayons de le tuer : sysadmin / # ps faux | grep loop | awk -F " " '{print $2}' | head -n 1 Aucun processus n'est visble Imaginons que par un moyen ou un autre un utilisateur du chroot ait connaissance du pid d'un processus (ici le pid de loop en dehors du chroot) en dehors du chroot et qu'il essaye de le tuer. sysadmin / # ./catch 2613 Mesg : trying to launch shellcode on process 2613 Attach: No such process

  
  

• CONFIG_GRKERNSEC_CHROOT_NICE :
  
  Si cette option est sélectionnée, les processus au sein d'un chroot ne pourrait pas augmenter la priorité d'un processus dans un chroot ou modifier la priorité d'un processus en dehors du chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_restrict_nice = 1

  Exemple sans CHROOT_NICE : En dehors du chroot, nous lançons de nouveau notre script loop et récupérons son pid et nice sysadmin linux # ps -eo pid,user,args,ni --sort user | grep loop 2613 root ./loop 0 Dans le chroot, nous essayons de modifier le nice du processus loop sysadmin / # renice -10 -p 2613 2613: old priority 0, new priority -10 Maintenant en dehors du chroot nous verifions que nous avons bien modifier le nice du processus loop sysadmin linux # ps -eo pid,user,args,ni --sort user | grep loop 2613 root ./loop -10 Dans le chroot, nous lancons le script loop et changeons son nice. sysadmin / # ps -eo pid,user,args,ni --sort user | grep loop 4251 root ./loop 0 Dans le chroot, nous changeons le nice du processus loop en cours. sysadmin / # renice -10 -p 4251 4251: old priority 0, new priority -10

  Exemple avec CHROOT_NICE : En dehors du chroot, nous lançons de nouveau notre script loop et récupérons son pid et nice sysadmin linux # ps -eo pid,user,args,ni --sort user | grep loop 2576 root ./loop 0 Dans le chroot, nous essayons de modifier le nice du processus loop sysadmin / # renice -10 -p 2576 renice: 2576: setpriority: Permission denied Apr 22 16:03:12 sysadmin kernel: grsec: From 192.168.1.25: attempted priority change of process (loop:2576) by /var/chroot/usr/bin/renice[renice:2579] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2575] uid/euid:0/0 gid/egid:0/0 Dans le chroot, nous lancons le script loop et changeons son nice. sysadmin / # ps -eo pid,user,args,ni --sort user | grep loop 2588 root ./loop 0 Maintenant nous essayons de changer son nice sysadmin / # renice -10 -p 2588 renice: 2588: setpriority: Permission denied Apr 22 16:07:11 sysadmin kernel: grsec: From 192.168.1.25: attempted priority change of process (loop:2588) by /var/chroot/usr/bin/renice[renice:2607] uid/euid:0/0 gid/egid:0/0, parent /var/chroot/bin/bash[bash:2604] uid/euid:0/0 gid/egid:0/0

  
  

• CONFIG_GRKERNSEC_CHROOT_SYSCTL :
  
  Si cette option est sélectionnée, un utilisateur local malveillant n'aura pas la possibilité d'écrire dans sysctl, par le biais de sysctl(2) ou par le biais de /proc. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_deny_sysctl = 1

  Exemple sans CHROOT_SYSCTL : Dans le chroot sysadmin / # echo "/bin/sh" > /proc/sys/kernel/modprobe sysadmin / # sysctl -a | grep modprobe kernel.modprobe = /bin/sh

  Exemple avec CHROOT_SYSCTL : Dans le chroot sysadmin / # echo "/bin/sh" > /proc/sys/kernel/modprobe sysadmin / # sysctl -a | grep modprobe kernel.modprobe = /sbin/modprobe

  
  

• CONFIG_GRKERNSEC_CHROOT_CAPS :
  
  Si cette option est sélectionnée, les capacitées de tous les processus root au sein d'un chroot seront diminués afin d'interdire le chargement de modules, les tâches sur les entrées / sorties, les tâches système et réseaux, redémarrer le système, modifier des fichiers immuables, modifier l'IPC d'autres utilisateurs, et de changer l'horloge système. Cette option peut poser des problèmes pour certaines applications présentes dans un chroot. Si l'option sysctl est activée, il est possible d'activer cette option par chroot_caps = 1

  Exemple sans CHROOT_CAPS : Fichiers immuables : On rend un fichier du chroot immuable. sysadmin root # chattr +i /var/chroot/etc/make.conf Dans le chroot on essaye d'enlever l'attribut sur le fichier sysadmin / # chattr -i /etc/make.conf L'attribut a été supprimé Ajout et suppression de modules : Dans le chroot sysadmin / # insmod i2c-core.o sysadmin / # lsmod | grep i2c-core i2c-core 13028 0 (unused) Le module a été ajouté avec succès. Dans le chroot sysadmin / # lsmod | grep usb-ohci usb-ohci 17480 0 (unused) usbcore 59084 1 [usb-ohci] sysadmin / # rmmod usb-ohci sysadmin / # lsmod | grep usb-ohci Le module a été supprimé avec succès.

  Exemple sans CHROOT_CAPS : Fichiers immuables : On rend un fichier du chroot immuable. sysadmin root # chattr +i /var/chroot/etc/make.conf Dans le chroot on essaye d'enlever l'attribut sur le fichier sysadmin / # chattr -i /etc/make.conf chattr: Operation not permitted while setting flags on /etc/make.conf Ajout et suppression de modules : Dans le chroot sysadmin / # insmod i2c-core.o i2c-core.o: create_module: Operation not permitted Dans le chroot sysadmin / # lsmod | grep usb-ohci usb-ohci 17480 0 (unused) usbcore 59084 1 [usb-ohci] sysadmin / # rmmod usb-ohci usb-ohci: Operation not permitted

Grsecurity inclus de nombreux patch qui interdisent à des utilisateurs ou à un groupe d'utilisateur d'effectuer des connexions réseaux. Des sécurisations réseaux sont aussi ajoutées au niveau kernel pour rendre la prédiction d'IDs IP, de ports sources, de XIDS RPC, et de ICN TCP impossibles.

• CONFIG_GRKERNSEC_RANDNET :
  
  Si cette option est sélectionnée, les regroupements d'entropies utilisés pour différentes raisons par Linux et grsecurity sera doublé. Activer cette option modifiera /proc/sys/kernel/random/poolsize.

  Exemple sans RANDNET : sysadmin root # cat /proc/sys/kernel/random/poolsize 512

Exemple sans RANDNET : sysadmin root # cat /proc/sys/kernel/random/poolsize 1024




• CONFIG_GRKERNSEC_RANDISN :
  
  Si cette option est sélectionnée, la sélection par défault des ISN (TCP Initial Sequence Numbers) sera remplacé par celle de OpenBSD. Linux utilise un hash MD4 basé sur la connection additionné à une valeur de temps pour créer l'ISN, alors que la sélection sous OpenBSD est aléatoire. Si l'option sysctl est activée, il est possible d'activer cette option par rand_isns = 1

  Exemple sans RANDISN : Récupération de 1000 ISN sur une période de temps de 25 secondes. Le résultats ne comporte pas les pics pour des questions de lissage. Nous pouvons voir que les séquences ISN s'incrémentent progressivement ce qui donne la possibilité de deviner les valeurs futures des ISN.

Exemple avec RANDISN : Nous pouvons voir que les ISN sont générés de façon aléatoire ce qui rend impossible de deviner les valeurs futures des ISN.




• CONFIG_GRKERNSEC_RANDID :
  
  Si cette option est sélectionnée, tous les champs id de tous les paquets sortants seront aléatoires. Cette méthode permet de limiter les techniques de "OS fingerprints" et empeche votre machine d'être utilisée en tant que relais pour un scan de port non traçable. Les IDs sont utilsés pour les paquets fragmentés, les fragments faisant parti du même paquet ont le même id. Par défault linux incrémente la valeur id de chaque paquets envoyés à un hôte. Le patch utilisé est un portage du code d'ip id aléatoire de OpenBSD. Si l'option sysctl est activée, il est possible d'activer cette option par rand_ip_ids = 1

  Exemple sans RANDID : Analyse d'ID tiré de snort 04/26-14:59:24.353345 192.168.1.46:22 -> 192.168.1.25:34229 TCP TTL:64 TOS:0x10 ID:15345 IpLen:20 DgmLen:132 DF ***AP*** Seq: 0x9F9945A4 Ack: 0x46D0EC38 Win: 0x2580 TcpLen: 32 TCP Options (3) => NOP NOP TS: 214412 90399019 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 04/26-14:59:24.353418 192.168.1.46:22 -> 192.168.1.25:34229 TCP TTL:64 TOS:0x10 ID:15346 IpLen:20 DgmLen:116 DF ***AP*** Seq: 0x9F9945F4 Ack: 0x46D0EC38 Win: 0x2580 TcpLen: 32 TCP Options (3) => NOP NOP TS: 214412 90399019 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 04/26-14:59:24.392680 192.168.1.46:22 -> 192.168.1.25:34229 TCP TTL:64 TOS:0x10 ID:15347 IpLen:20 DgmLen:452 DF ***AP*** Seq: 0x9F994634 Ack: 0x46D0EC38 Win: 0x2580 TcpLen: 32 TCP Options (3) => NOP NOP TS: 214416 90399081 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On peut voir que les ID s'incremente de 1 à 1 (15345 - 15346 - 15347)

Exemple avec RANDID : Analyse d'ID tiré de snort 04/26-15:35:06.788415 192.168.1.46:22 -> 192.168.1.25:34387 TCP TTL:64 TOS:0x10 ID:43116 IpLen:20 DgmLen:132 DF ***AP*** Seq: 0x905F3285 Ack: 0x46FD227D Win: 0x2580 TcpLen: 32 TCP Options (3) => NOP NOP TS: 91555 92541559 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 04/26-15:35:06.788521 192.168.1.46:22 -> 192.168.1.25:34387 TCP TTL:64 TOS:0x10 ID:59718 IpLen:20 DgmLen:116 DF ***AP*** Seq: 0x905F32D5 Ack: 0x46FD227D Win: 0x2580 TcpLen: 32 TCP Options (3) => NOP NOP TS: 91556 92541559 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 04/26-15:35:06.800990 192.168.1.46:22 -> 192.168.1.25:34387 TCP TTL:64 TOS:0x10 ID:58997 IpLen:20 DgmLen:132 DF ***AP*** Seq: 0x905F3315 Ack: 0x46FD227D Win: 0x2580 TcpLen: 32 TCP Options (3) => NOP NOP TS: 91557 92541559 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On peut voir que les ID sont maintenant aléatoires.




• CONFIG_GRKERNSEC_RANDSRC :
  
  Si cette option est sélectionnée, les situations durant lesquelles le port source est généré à la volée pour le protocole TCP (avec connect() ) sera modifier pour générer le port source de façon aléatoire, plutôt que d'utiliser l'algorithme d'incrémentation. Si l'option sysctl est activée, il est possible d'activer cette option par rand_tcp_src_ports = 1

  Exemple sans RANDSRC : Des connexions SSH effectuées à la suite vers une machine externe depuis la machine sans RANDSRC tcp 0 0 192.168.1.46:32771 192.168.1.46:22 TIME_WAIT tcp 0 0 192.168.1.46:32769 192.168.1.25:22 TIME_WAIT tcp 0 0 192.168.1.46:32770 192.168.1.25:22 ESTABLISHED tcp 0 0 192.168.1.46:32772 192.168.1.25:22 ESTABLISHED On peut voir que les ports sources sont incrémentés de 1 à 1

Exemple avec RANDSRC : Des connexions SSH effectuées à la suite vers une machine externe depuis la machine sans RANDSRC tcp 0 0 192.168.1.46:60232 192.168.1.25:22 ESTABLISHED tcp 0 0 192.168.1.46:59930 192.168.1.25:22 TIME_WAIT tcp 0 0 192.168.1.46:36072 192.168.1.25:22 ESTABLISHED tcp 0 0 192.168.1.46:37802 192.168.1.25:22 ESTABLISHED On peut voir que les ports sources sont maintenant aléatoires.




• CONFIG_GRKERNSEC_RANDRPC :
  
  Si cette option est sélectionnée, la méthode pour déterminer les XIDs pour les requêtes RCP sera aléatoire, à la place d'utiliser la méthode par défault de linux qui est d'incrémenter les XID. Si l'option sysctl est activée, il est possible d'activer cette option par rand_rpc = 1
  

• CONFIG_GRKERNSEC_SOCKET :
  
  Si cette option est sélectionnée, différentes options vous seront proposées. Vous pouvez restreindre les capacitées réseau de différents groupes utilisateurs. Les restrictions possibles sont décrites ci-dessous.
  
  Pour les exemples ci-dessous nous utiliseront le GID 2000 de notre groupe unstrusted, dans lequel se trouve l'utilisateur client et chrootclient.
  

• CONFIG_GRKERNSEC_SOCKET_ALL :
  
  Si cette option est sélectionnée, il vous sera possible de choisir le groupe d'utilisateurs (GID) qui ne pourront pas se connecter sur d'autres hôtes depuis la machine ou de lancer un lancer des applications réseaux depuis la machine. Si l'option sysctl est activée, il est possible d'activer cette option par socket_all = 1

  Exemple sans SOCKET_ALL : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) lient@sysadmin client $ ping 192.168.1.25 PING 192.168.1.25 (192.168.1.25) 56(84) bytes of data. 64 bytes from 192.168.1.25: icmp_seq=1 ttl=64 time=0.193 ms client@sysadmin client $ ssh root@192.168.1.25 Password:

Exemple avec SOCKET_ALL : client@sysadmin client $ id uid=1000(client) gid=2000(untrusted) groups=2000(untrusted) lient@sysadmin client $ ping 192.168.1.25 socket: Permission denied Apr 29 13:11:46 sysadmin kernel: grsec: From 192.168.1.25: attempted socket(2,dgram,ip) by /bin/ping[ping:4204] uid/euid:1000/1000 gid/egid:2000/2000, parent /bin/bash[bash:2588] uid/euid:1000/1000 gid/egid:2000/2000 client@sysadmin client $ ssh root@192.168.1.25