3.1. Permissions sur les fichiers

Démarrons avec la limitation la plus faible que l'on puisse imposer : l'utilisation des permissions UNIX. En fait, cela est sûrement suffisant pour la plupart des environnements. Les permissions permettent de contrôler quels binaires les utilisateurs peuvent exécuter. Si tous les binaires ne sont pas executable pour tout le monde (permission +x sur les fichiers) et que les partitions /home et /tmp sont montées avec le flag noexec (voir man mount pour plus de détails), la sécurité est relativement fiable. L'option noexec est nécessaire pour prévenir au cas où des utilisateurs essaieraint de compiler leur propre binaire. Si un groupe d'utilisateurs ont besoin de plus de privilèges, un groupe spécial peut-être créé et les binaires seront modifiés pour être exécutable par ce groupe.

3.2. Les permissions via PAM

Un autre type de restriction peut-être accompli via les limitations du système Linux PAM. Ceci va prévenir le système d'utilisation de ressources trop importante par les utilisateurs (espace disque, CPU, RAM, etc...). Pour plus d'informations sur les restrictions via PAM, reportez-vous à l'article disponible sur le site.

3.3. Restriction des shells

Un autre degré de limitation est de restreindre le shell. Dans ce cas, nous allons modifier différentes choses pour empêcher les utilisateurs de modifier les variables d'environnement, de restreindre la redirection de sorties de programmes, lancer des commandes avec les chemins absolus, utiliser la commande exec et quelques autres actions. Les restrictions ne concernent pas les scripts shell. L'utilisation de rbash (bash -r en fait) (voir la page de manuel pour plus d'informations) en complément de la configuration des permissions UNIX va nous aider à augmenter la sécurité. L'utilisation de rbash est un choix viable si vous essayez de contenir vos utilisateurs. Ses fonctionnalités peuvent être facilement maîtrisées :

				# adduser test

				# ln -s /bin/bash /bin/rbash

				# echo "/bin/rbash" >> /etc/shells

				# chsh -s /bin/rbash test

				# cd ~test

				# su test

				$

				$ cd /
				rbash: cd: restricted
				

3.4. Shells basés sur des menus

Une autre solution serait d'utiliser une application sur mesure qui aurait accès qu'à certaines ressources système sélectionnés. Jetons un oeil aux applications de ce type disponible. pdmenu est une interface de type ncurse pour lancer certaines commandes sous Linux. Il peut être utiliser, par exemple, comme shell de connexion et permettre l'accès à certaines applications comme le mail ou le navigateur web. Il permet également de lancer des commandes et les présente à l'utilisateur. L'idéal est de configurer le programme afin que les utilisateurs ne puissent pas modifier le menu. Idéalement, le menu ne devrait permettre que des choix depuis une liste prédéfini pour l'utilisateur et ne pas lui permettre de taper quoi que ce soit. Cette application fonctionne pour les utilisateurs distant, connectés via SSH ou telnet et pour les utilisateurs locaux qui n'utilisent pas d'interface graphique comme X. Regardons un peu la sécurité que ce type de logiciel peut nous apporter. Si on l'utilise en tant que shell de connexion, cela limite l'utilisateur aux applications prédéfinis. C'est le cas, par exemple, pour les terminaux bancaires qui sont utilisés dans les agences par des personnes qui ne doivent pas utiliser le système à d'autres fins. Par contre, ce type de shell n'a aucun contrôle sur ce qui peut se passer une fois l'application défini lancé. Similaire à rbash ci-dessus, cette fonctionnalité est plus une protection contre les utilisateurs inexpérimentés qu'une réelle solution pour sécuriser son système.

3.5. Chroot

Une autre façon de restreindre les utilisateurs est de les enfermer dans une petite "prison". Cela fourni un degré de sécurité dans le cas où certaines conditions sont rencontrées. Je vous invite à lire la documentation disponible pour avoir un exemple concret de la commande chroot. En clair, s'il n'y a pas aucun moyen d'obtenir les privilèges root dans le répertoire "chrooté" alors chroot fourni une sécurité efficace. Pour éviter que les utilisateurs depuis l'environnement chrooté deviennent root, les applications présentes dans la prison doivent être soigneusement sélectionnées.

La combinaison des environnements chrootés avec la restriction des shells permet d'augmenter la sécurité de son système. Si un utilisateur arrive à se sortir du shell restreint et si l'environnement chrooté a bien été étudié, la seule chose qu'il pourra faire est de modifier des commandes dans les applications qui sont permises et cela est à peu près tout.

3.6. Les possibilités basés sur le noyau Linux

Voyons des mesures de sécurité plus sérieuses pour restreindre davantage les utilisateurs en se basant sur des spécificités du noyau Linux. Différents patchs de sécurité disponible pour le noyau Linux permettent d'implémenter des contrôles d'accès et différents rôles liés à la sécurité. En utilisant ces fonctionnalités, on s'empare de pratiquement tous les droits des utilisateurs. Par exemple, le patch noyau LIDS peut empêcher un utilisateur d'utiliser ou même de voir certains fichiers, devices ou processus, changer le propriétaire d'un fichier et d'autres fonctions UNIX.

Le patch noyau GRSecurity dispose également de fonctionnalités pour restreindre les actions des utilisateurs. L'option CONFIG_GRKERNSEC_TPE permet de créer un groupe pour les utilisateurs "non-sûrs" afin qu'ils ne puissent exécuter des binaires depuis des répertoires bien définis et appartenant à root.

Je vous accorde que la sécurisation au niveau du noyau n'est pas très fun à configurer à moins d'utiliser de multiples ACL ou pour tracer des appels systèmes autorisés par application. La configuration au niveau du noyau n'est pas une chose qui va fonctionner facilement car il y a énormément de configurations mais en contrepartie vous permettra de restreindre les accès des utilisateurs les plus avertis.