Hardening grsec chroot lxc

Pause Café
#1

Bonjours à tous :slight_smile:

Voilà quelques mois que je tourne sous kernel 4.9 + GRsecurity et chercher a pousser un peu plus l hardening, l’audit et la compréhension de ces méchanisme complexe .

J’arrive au moment le plus crucial: bien scinder les groups et users
et là j’avous que je séches un peu malgrès de très très nombreuses lectures.

le patch Grsecurity est gérer par paxctl , l’utilitaire RBCA gradm et bien entendu PAM.

afin de maximiser un peu plus la sécurité oui oui viciiieux :smirk:
je m’imaginer le shéma utilisateur suivant:

                       sudo                             su
 USER1       -------------->   USER-AUDIT  ----------> ROOT
privilèges minimum |           chrooté avec
utilisateur x11    |           très peu de droit
chroot $home       |                ------->      USER-Gardien
                                                  {droit sudo}

USER1 est donc mon user courant dont jaimerai reduire les commandes au max mais comment chrooter un utilisateur graphique simplement? (sans faire un chroot debootstrap debian sinon je virtualize en kvm a ce train là)

jaimerai également que pour se connecter en root il faille passé obligatoirement par l’USER-AUDIT qui lui n’aura aucun droit sauf lire les log (ici chroot et /bin/ls + sudo et point barre)
Et enfin passé a l’user suivant qui sera soit ROOT soir USER-GARDIEN qui lui aura les droit sudo!! (le but étant ici de se connecter le plus rarement a root quand le pc est installer)

là ou j’ai le plus de mal acomprendre c’est le debat sur le fait que chroot ne soit pas très fiables.
(en temps normal puisque sous grsec chroot est renforcé mais bref)

ma question est comment peut on sortir d’un chroot par exemple USER-AUDIT où seul les binaires ls cat serait ajouter (aucun outils de modif en somme !!) ???

pour les services là aussi j’hésites lxc ou chroot lequel des deux serait le plus judicieux pour mes services;
chrooter chacun et gérer les droits au petit oignons
ou bien rassembler les services par “types” dans des containers lxc
exemple: |unbound+dnscrypt| |fail2ban portsenty| |snort-prelude-audit|

voilà j’avous que je sèches un peu sur la démarche la plus efficiente pour isoler processus et users
je précise tout de meme mon utilisation: bureautique, internet mail. unbound et dnscrypt en résolver dns et j’utilise pour le moment firejails et firetools en sandbox pour les applications.
quelqu’un connait il se soft et en saurait un peu plus quand a sa fiabilité??:slight_smile:

Voilà c’est avant tous un retour d’expériences sur l’isolation et leur efficacités ainsi qu’un regards aguérie de votre part queje viens chercher ici du coup je poste dans “Pause Café”:yum:

1 J'aime
#2

Sujet vaste …

En premier lieu j’aurai pas créer un sous utilisateur de plus, moins il y a d’étapes à contrôler, moins il y a de risques d’erreurs.

Un petit peu de lecture sur le durcissement d’une Debian :

https://wiki.debian.org/Hardening
https://wiki.debian.org/HardeningWalkthrough

Je ne durci plus mes Os car je préfère gérer la sécurité au niveau d’une passerelle, et le peux de portes d’entrées sont isolés à l’aide de virtualisation ou de containérisations.

Sous BSD je durcissais l’OS principales et gérer effectivement les services critiques à l’aide de jail (du chroot au hormones).
Sous Debian j’aurai tendance à Dockeriser les applications sensibles et à permettre un isolement via les cgroup.
Le kernel ‘gresec’ est une plaie à maintenir sur un poste (compilation à chaque fois, du coup à moins que tu ai ta forge à paquet et la possibilité de mettre à disposition un dépôt personnel tu ne pourra pas automatiser la mise à jour de ton kernel.

Concernant les exploits, il est régulier de voir apparaître des patchs pour corriger des failles permettant une élévation de privilège.

Le plus simple pour durcir un système et de rendre immuable le plus de choses possible, passage en lecture seule (un ‘remonunt’ en rw sera nécessaire pour les maintenances).
Une isolation au plus sûr des services sensibles, il y a pléthore d’article sur le web sur le sujet.
Une bonne compréhension et gestion des correctifs de sécurité du système.

#3

Je m’injecte dans le sujet sans pouvoir aider mais plutot avec des questions.

En premier lieu, est-ce que des applis comme Firefox, Thunderbird, etc peuvent être considérées aujourd’hui comme sensibles et serait-il préférable des les containeriser?

Et deuxième chose, plutôt que de se tourner vers GRsec, qui est pénible pour la maintenance, est-ce qu’il ne serait pas judicieux de mettre en pratique la politique SELinux plutot?

#4

Tu y a déjà touché ou à Apparmor ?
C’est bien complexe à gérer finement et réclame pas mal de temps pour trouver le bon réglage sur un poste client remplit d’application parfois très gourmande en droit élevé.

Oui c’est exactement sur quoi travail de vieux projet comme Qubes OS

Mais à quel prix, c’est lourd et compliqué à maintenir, un PC on doit avant tout l’utiliser avant de le maintenir …

#5

J’ai installé Fedora en parallèle de ma Sid, comme je suis en btrfs je m’emploie à exploiter les sous-volumes… :smiley:
Et à ma grande surprise (j’ai lu aucune doc avant, à la base je voulais juste découvrir le monde RedHat et ses commandes, rpm, …) eh bien j’ai découvert que sur Fedora SELinux est installé par défaut, ainsi que firewalld…
Alors comme j’ai quelques containers sous systemd-nspawn (DNS Bind, …) que je partage entre les deux distrib’s sous systemd, grâce à btrfs et ses sous-volumes, eh ben je te raconte pas la m**de que c’est à configurer c’est vrai, c’est très pénible…
Donc pour répondre à ta question, je m’y suis mis doucement, mais c’est effectivement très compliqué. Par contre ça a l’air d’être assez costaud en matière d’enforcement.

Pareil pour Apparmor et PAM, pour l’instant j’évite d’y toucher parce que c’est du charabia encore pour moi :smiley:

En cherchant de la doc sur la containerisation et systemd-nspawn j’étais tombé sur une page qui présente un OS similaire : https://coreos.com/
Mais c’est vrai que ça devient vite pénible à maintenir.

#6

CoreOS est encore un poil différent c’est un OS plus que minimal pour gérer du container, les outils de debug sont ultra minimaux et sincèrement je préfère de loin gérer une Debian avec l’engine Docker dessus.
Par contre c’est un outils formidable pour qui souhaite gérer par dizaine ou plus des machines dans des clusters.

#7

Aucune idée j’ai cité ça à titre d’exemple, mais j’ai survolé la page en vitesse.

j’ai préféré systemd-nspawn que j’ai découvert par hasard en recherchant de la doc sur LXC et Docker, et que je trouve aussi un peu lourds à configurer au final…

#8

:innocent: chacun ses goûts je dirais

1 J'aime
#9

Hop! Salut à tous,

une passerelle Hardened pour gerer l’ensemble du parc, cest le Top

Mais bougeant pas mal avec un voir deux pc portables, j’ai décidé de m’interesser a grsec dans un contexte de station de travail “classic”

Bien entendu un plan de partitionnement fstab est au programme, avec un gestion draconienne des droits de lectures ecritures et separation de /var /tmp /home /root etc.:slight_smile:

Freebsd et hardened-gentoo gère apparement les jail chroot bien mieux que d’autres linux mais grsec apporte justement de très bonnes option pour durcir les jails.
et également une gestion plus accrus des comptes avec l’option TPE (pour trier les groupes de confiance ou non) et un groupes pour l’audit.

Pour l’USER1 je commence a comprendre, je me prend trop la tête en faite,
à partir du moment ou mes droit en lecture ecriture de chaque groupes et user sont bien définies mon user principale ne pourrait ni accéder a des commandes ou toucher au dossier;
rajouter a cela un chroot dans son $HOME qu’il ne puissent accéder pas a l’arborescence /
et point barre.