Avant la conférence Kernel Recipes et la rédaction d'un article pour Linux Mag, j'aimerais lancer les questions suivantes : utilisez-vous un mécanisme de contrôle d'accès avec vos systèmes d'exploitation ? Si oui lequel ?
merci. Samir
-
SElinux :
103(11.6 %)
-
AppArmor :
79(8.9 %)
-
SMACK :
0(0.0 %)
-
tomoyo :
3(0.3 %)
-
yama :
4(0.4 %)
-
capabilities :
8(0.9 %)
-
grsecurity :
13(1.5 %)
-
chroot :
38(4.3 %)
-
aucun (ou le parefeu OpenOffice.org) :
451(50.7 %)
-
geste de la main plus « ce n'est pas cet accès que vous cherchez » :
155(17.4 %)
-
autre (en commentaire ) :
35(3.9 %)
Total : 889 votes
# Aucun, et, à quoi ça sert
Posté par Adrien.D . Évalué à 4.
Je n'en utilise pas sur ma distrib (ou pas à ma connaissance).
Sur Fedora, je désactive systématiquement SELinux.
Je ne sais pas ce que ça peut apporter en plus, pour un ordinateur personnel.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Sufflope (site web personnel) . Évalué à 4.
Pareil et en plus je passe tout le disque en chmod 777 parce que je vois pas pourquoi j'aurais de problème, je sais ce que je fais.
Et sinon en vrai sur ma Fedora je laisse SELinux et je fais les quelques réglages simples pour que ça tourne avec les services (vu que je m'autohéberge) que j'ai pourtant installés à des endroits parfois bizarres.
[^] # Re: Aucun, et, à quoi ça sert
Posté par esdeem . Évalué à 2.
J'avais fais pareil, mais ensuite, je n'étais aperçu de mon erreur.
Heureusement, un petit
# chmod -R -x /*a tout remis d'aplomb…0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Aucun, et, à quoi ça sert
Posté par claudex . Évalué à 6.
Si c'est bien configuré, ça évite les comportements suspects. Par exemple, un mail forgé pour profiter d'un buffer overflow et lire tes cookies dlfp pour pouvoir poster sous ton nom peut être éviter. (ou ajouter un PATH=~/.malwaredir/:$PATH dans le bahrc).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Aucun, et, à quoi ça sert
Posté par Adrien.D . Évalué à 0.
Non, je ne mets pas de chmod 777; il ne faut pas être mazo non plus.
Néanmoins, tout fonctionne sans soucis et les permissions de base sont suffisantes pour un PC (je ne parle pas de serveur)
[^] # Re: Aucun, et, à quoi ça sert
Posté par Anonyme . Évalué à 6. Dernière modification le 21 septembre 2014 à 21:41.
Ben, franchement, j’ai rien non plus mais je commence à me demander sérieusement si ce n’est pas une erreur de ne rien mettre. Et à plus forte raison sur des serveurs (bon alors mon problème supplémentaire est qu’en utilisant des conteneurs, c’est un poil plus compliqué et je n’ai pas le temps d’arracher ce poil… donc…).
Je ne sais pas si c’est possible (a priori ça devrait l’être, sinon quel intérêt…) mais j’aimerais beaucoup que personne sauf Firefox ne puisse lire la base de ses propres mots de passes, qu’aucune autre extension ne puisse s’installer ni se modifier, par exemple, ou les cookies.
Pareil pour mes clefs SSH, pour le $PATH, pour les clefs GPG et j’en passe et des meilleurs.
Les permissions UNIX de base, c’est bien, mais je ne crois vraiment pas que cela suffise, en aucun contexte : le nombre d’applications externes pouvant être installées (et je met NoScript dans le lot, hein) est trop important pour laisser ça au hasard.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Sufflope (site web personnel) . Évalué à 7.
Et bien cette idée que "tout fonctionne sans souci" est quasiment parfaitement applicable à SELinux (surtout sur un ordi non serveur).
Ca fait quand même des années que les politiques par défaut SELinux ont été raffinées (notamment par Fedora) et tant que tu restes sur les installations standard (même pour des services "serveur") tout est configuré comme il faut. Si comme moi tu installes par exemple postgresql en le configurant pour mettre sa BDD sur un point de montage sur mon raid au lieu de l'emplacement par défaut… bah c'est une ligne de config SELinux pour mettre le label qu'il faut sur le nouvel emplacement. Assez surmontable.
Et pour répondre à Leryan c'est précisement à ça (entre autres sans doute ; je ne suis qu'un newbie SELinux) que ça sert : en gros tu mets sur ~/mozilla un label spécial, auquel tu ne donnes l'accès qu'au binaire firefox qui aura le même label, et même un malware sur lequel tu doubles-cliques ne pourra pas y accéder.
[^] # Re: Aucun, et, à quoi ça sert
Posté par freem . Évalué à 3. Dernière modification le 23 septembre 2014 à 16:08.
Et qu'est-ce qui empêche un malware sur lequel tu doubles-clickes de s'ajouter ce label? (c'est une vraie question, j'avoue ne m'être jamais intéressé à ce genre de trucs…)
[^] # Re: Aucun, et, à quoi ça sert
Posté par Renault (site web personnel) . Évalué à 4.
Normalement il n'a aps le label permettant d'effectuer une telle action, et il faut également les droits root.
Après si tu lui donnes tous les pouvoirs pour qu'il contourne la protection, à ce niveau là on ne peut plus y faire grande chose.
[^] # Re: Aucun, et, à quoi ça sert
Posté par freem . Évalué à 2.
Donc, quand d'habitude on fait un simple
chmod +x foo.sh, avec SELinux, il y à d'autres actions à faire, sans quoi rien ne peut se lancer?Ou est-ce que, par défaut, un certain niveau de "partage" est activé? Parce que sinon pour le dev/scripting ça doit être assez pénible… non?
[^] # Re: Aucun, et, à quoi ça sert
Posté par Renault (site web personnel) . Évalué à 3.
Non, c'est juste que certains processus seulement ont l'autorisation de modifier les labels de SELinux. Donc le binaire téléchargé sur warez.com pourra par défaut faire des choses basiques mais s'il a besoin de ressources protégées par SELinux là il va falloir lui donner une politique adéquat. Et en l'occurence, il ne pourra pas dire à SELinux "coucou, je suis sûr, je te demande expressément de modifier mes labels pour pouvoir te contourner".
[^] # Re: Aucun, et, à quoi ça sert
Posté par freem . Évalué à 2.
Ok je vois. Donc on ne ferme l'accès qu'à des ressources précisées explicitement. Me reste à comprendre comment ça marche mais pour ça je ne connais qu'une solution… va falloir que je teste :)
[^] # Re: Aucun, et, à quoi ça sert
Posté par Anonyme . Évalué à 3.
Generalement, l'utilisateur classique tourne dans le contexte "unconfined", ce qui lui donne à peu près toutes les permissions (comme si selinux n'était pas la), et il n'y a que les services qui sont limités par selinux.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Misc (site web personnel) . Évalué à 10.
Sur RHEL 7/Centos 7 et fedora je sais pas combien, les plugins firefox sont restreint via SELinux. Donc si jamais quelqu'un arrive à trouver une faille dans flash et la distribue via un réseau de pub, comme ça arrive souvent, ta clé ssh se fera pas faucher, sauf à contourner SElinux.
( tu peux aussi remplacer "clé ssh" par "fichier de mot de passe firefox" ).
Il me semble aussi qu'il y a eu des choses sur les outils qui font des vignettes, au cas ou tu trouves une clé usb avec un fichier vérolé qui fait planter l'outil de vignette.
Cf https://danwalsh.livejournal.com/54092.html
Je pense aussi que SElinux permet de s'assurer que le compte guest ( paquet xguest ) est vraiment limité, ce qui sert sur un kiosque.
Il permet également de limiter docker, qui est un outil assez à la mode en ce moment pour les devs ( donc sur un pc personnel ), et je suppose que selinux serviras aussi pour limiter les applications tierces pour ce que Gnome veut faire avec les histoires de sandbox.
[^] # Re: Aucun, et, à quoi ça sert
Posté par cluxter . Évalué à 8.
Ca peut permettre d'éviter que Skype n'aille regarder ton historique de Firefox, par exemple. Et ne l'envoie sous forme chiffrée à Microsoft.
Une piste à suivre : http://www.debian-fr.org/securiser-skype-t41130.html
Après vous en faites ce que vous voulez…
Les contrôles d'accès permettent de s'assurer qu'un processus (donc un logiciel) n'accède pas à une information à laquelle il ne devrait normalement jamais accéder. Autrement dit, ça peut permettre d'éviter les attaques 0-day, les buffer overflows, ce genre de choses. Si demain Linux remplace Windows en parts de marché, les virus deviendront légion et les solutions de contrôle d'accès seront absolument indispensables.
Ceci étant dit, j'ai recensé environ 1000 attaques sur le port SSH de mon serveur par jour (80 % en provenance de Chine). Pourtant il ne s'agit que d'une machine très banale, je n'ose pas imaginer sur un serveur critique. Donc je pense que n'importe quelle machine connectée à l'Internet devrait impérativement avoir une solution de contrôle d'accès.
J'illustre à quoi ça peut servir concrètement : imagine qu'on découvre une faille jusque là totalement inconnue dans un logiciel de suivi d'activité de ton PC (faille 0-day) et que cette faille permet de récupérer tout tes fichiers perso. En l'occurrence, ce logiciel n'est pas censé accéder à tes fichiers perso puisqu'il n'en a pas besoin. Il a juste besoin d'accéder aux fichiers de suivi de température, au taux de charge de ta batterie, etc. Avec une solution de contrôle d'accès, tu écris une règle qui dit que ce logiciel ne devra jamais accéder à autre chose qu'aux fichiers système pour le suivi de la température et la charge de ta batterie. S'il essaie d'accéder à tes fichiers perso, il se fait jeter. Et donc la faille sera inefficace. Alors que sans contrôle d'accès, la faille devient utilisable et peut avoir des conséquences catastrophiques.
Un contrôle d'accès permet même de restreindre les droits de root. Pensez-y, ça peut être très intéressant, car je ne vois pas pourquoi je dois accorder les pleins pouvoirs à Microsoft lorsque j'installe Skype sur mon ordi. Je veux juste installer Skype, pas formater mon disque dur, donc je ne vois pas trop pourquoi je donne le même niveau de droits à Microsoft qu'à moi-même. En réalité, root ne devrait quasiment jamais être utilisé, ou en tout cas pas à l'état pur. C'est un niveau de privilèges bien trop important pour ce qu'on souhaite généralement faire.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Pseudo007 . Évalué à 2.
Heu, sais-tu ce que ça t'apporte de le désactiver ?
J'ai Fedora (ou RHEL) depuis de nombreuses années, avec SELinux, il est très très rare que j'ai à m'occuper de SELinux.
[^] # Re: Aucun, et, à quoi ça sert
Posté par Adrien.D . Évalué à 1.
Et bien, j'ai un LAMP pour faire 3 bricoles, et un petit samba pour partager des fichiers avec mon réseau local, et bien souvent, SELinux m'embête :)
[^] # Re: Aucun, et, à quoi ça sert
Posté par DerekSagan . Évalué à 4.
Réponse courte:
- du temps en plus pour faire des choses utiles,
- des insatisfactions en moins.
Réponse longue:
Ça m'évite de passer des heures à pas comprendre pourquoi tel programme ne fonctionne pas et ne produit aucun message d'erreur clair sur le problème qu'il rencontre. Ce qui arrive souvent quand SELinux est activé et qu'on utilise autre chose que juste les packages Fedora/RHEL fournis avec la distrib et configuré comme testé par la distrib…
[^] # Re: Aucun, et, à quoi ça sert
Posté par Sufflope (site web personnel) . Évalué à 3.
Faut pas déconner, depuis des années y a une notification graphique en cas de refus d'accès par SELinux, avec le détail et les infos sur quoi faire si on veut autoriser cet accès. Et si tu n'utilises pas d'environnement graphique, y a une alerte dans le fichier principal de log /var/log/messages avec également la marche à suivre pour rendre cet accès légal (et le détail brut dans /var/log/audit/audit.log au cas où). Alors bon moi aussi je peux démarrer un service sans rien lire ni avant (docs) ni après (logs), voir que ça marche pas comme je veux, et chier sur l'outil…
[^] # Re: Aucun, et, à quoi ça sert
Posté par DerekSagan . Évalué à 1.
Bah quand je code un programme qui se comporte comme s'il était buggué, je suis peut-être trop humble, mais je peux passer une heure à chercher le bug avant d'aller regarder dans /var/log/messages en me disant que c'est pas un bug mais cette merde infâme de SELinux.
Donc je vais continuer à le désactiver et à chier dessus.
Et à être incompris par les gens comme toi qui pensent qu'on ne fait que démarrer des services mais jamais les développer…
Bisous.
# Les permissions Unix
Posté par rewind (Mastodon) . Évalué à 10.
Ça suffit bien !
# Virtualisation/isolation?
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Et la virtualisation kvm ou isolation comme lxc?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Virtualisation/isolation?
Posté par Anonyme . Évalué à 1.
Et si tes VM et conteneurs sont poutraves ? Tu fais quoi ?
[^] # Re: Virtualisation/isolation?
Posté par Tonton Benoit . Évalué à 4.
Pour LXC tu peux voter 'capabilities'.
# choix par défaut
Posté par daeavelwyn . Évalué à 5.
bah j'utilise apparmor par flemme de mettre autre chose sur ubuntu et que SELinux est une vrai usine à gaz…Mais bon, c'est pas pour ça que j'suis fan…
# Le mot de passe du BIOS
Posté par Oliver (site web personnel) . Évalué à 1.
J'utilise le mot de passe du BIOS comme mécanisme de contrôle d'accès pour ma distribution Linux. Et le reste en auto-login, ni de mot de passe de sortie de veille :-)
Deux avantages :
* En cas de vol, il y a de fortes chances que le voleur ne s'y connaisse pas suffisamment pour utiliser/revendre mon ordi
* Le démarrage et l'utilisation est agréable avec un seul mot de passe depuis le démarrage
Ah ! On me dit que arkhe parlait d'autre chose…
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Re: Le mot de passe du BIOS
Posté par 2PetitsVerres . Évalué à 1.
Je ne vois pas en quoi c'est un avantage pour toi. Tu n'as plus ton PC, et il va finir à la poubelle, ce qui est a un coût écologique pour l'ensemble de la société. Si on me vole mon PC, je préfère que le voleur n'ait pas accès à mes données mais qu'il soit quand même capable de réutiliser mon PC.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Le mot de passe du BIOS
Posté par voxmundix . Évalué à 1.
Le must étant de pousser le dit voleur a re-connecter la machine a internet afin qu'on puisse le retrouver/recontrôler (via l'installation d'un logiciel espion/contrôle a distance).
[^] # Re: Le mot de passe du BIOS
Posté par sebas . Évalué à 2. Dernière modification le 22 septembre 2014 à 11:52.
non, le must serait qu'il y ait une grosse icône sur le bureau "Je viens de voler cet ordi, je rends ses fichiers à l'ex-proprio et je garde l'ordi (anonymat garanti, cliquer ici pour voir notre charte de respect de la vie privée)" qui fasse le transfert des fichiers essentiels et pas encore sauvegardés (!) vers un serveur pré-configuré.
[^] # Re: Le mot de passe du BIOS
Posté par voxmundix . Évalué à 2.
ça n'a d’intérêt que si tu es membres de la mafia mdr
http://www.20minutes.fr/insolite/1254319-20131125-20131125-chine-vole-iphone-renvoie-liste-contacts-recopies-a-main
[^] # Re: Le mot de passe du BIOS
Posté par kowalsky . Évalué à 3.
Oui mais du coup, cela "incite" au vol.
Alors que si tout les PC était inutilisable une fois volés (à la android/ios), les voleurs voleraient moins et ne seraient même plus des voleurs ,du coup !
[^] # Re: Le mot de passe du BIOS
Posté par voxmundix . Évalué à 1.
Est-ce réellement faisable?
Android et IOS ne sont pas protégé fasse au vol, il existe de nombreux outils pour flasher la rom (les mêmes outils pour rooter) et des outils pour changer les codes (IMEI etc), sans compter la flopée d'outils des services secrets.
Je suis d'accord ces outils ne sont pas utilisable par le premier débile venu, se qui peut décourager les débiles de pratiquer le vol occasionnel, mais les réseaux organisé ne souffrent pas de ces problèmes. (d'après les docu les smartphones/pc sont envoyé en europe de l'Est où des ptits crack s'occupent de les dé-loocker).
# OpenBSD
Posté par TeXitoi (site web personnel) . Évalué à 3.
Sur mon serveur sous OpenBSD, j'ai rien à faire, et tout est chrooté :)
[^] # Re: OpenBSD
Posté par Njibhu . Évalué à 5.
Chroot ne peux être considéré comme réel moyen d'isolation, il faut savoir que ce n'est pas du tout son rôle (qui est de pouvoir installer différents paquets/applications qui si elles étaient installées sur le même système rentrerais en conflit de dépendances..)
Si un utilisateur malicieux arrive a obtenir un accès root a l’intérieur de la chroot, il lui suffit de créer une nouvelle chroot pour en sortir tout en gardant les privilèges root !
C'est une très très grave erreur de considérer le chroot en tant que solution de sécurité, encore plus sur un serveur.
[^] # Re: OpenBSD
Posté par jyes . Évalué à 4.
Ce que tu écris est vrai, sauf la conclusion, parce-que
ça fait quand-même un gros « si ». Un chroot réduit quand-même considérablement la surface d’attaque, parce-que trouver une faille dans un programme c’est une chose, mais l’exploiter ensuite pour trouver une faille dans le système qui permet de passer « root », ça fait une grosse marche supplémentaire. Et ça ce jeu là, on pourrait rajouter, exploiter une faille qui fait planter SELinux pour le même prix parce-que tous les mécanismes de contrôle contiennent des bugs, ça reste des logiciels.
Donc chroot n’est pas la panacée, il faut savoir ce de quoi ça protège, mais c’est loin d’être nul comme en apport en matière de sécurité.
[^] # Re: OpenBSD
Posté par David Carlier . Évalué à 1.
Pas mal ! Sous FreeBSD nous avons les jails :-P
# Ubuntu
Posté par patrick_g (site web personnel) . Évalué à 5.
Le score d'apparmor me semble très faible dans le sondage. Sachant qu'Ubuntu est extrêmement utilisé et qu'apparmor est activé par défaut pour pleins de trucs sur cette distro, son score devrait être plus haut.
Ou alors les utilisateurs d'Ubuntu désactivent apparmor ? Je n'y crois pas.
[^] # Re: Ubuntu
Posté par voxmundix . Évalué à 1.
Anecdote avec AppArmor:
J'ai voulu testé une installation de MySQL dans un container chiffré par truecrypt (ouvrable uniquement manuellement après démarrage du pc), AppArmor m'en a empêché :( (môsieur Armor ne comprenait rien au fait que le "disque" n'existe pas avant que je le monte avec truecrypt).
Ptête que ça à changé, ou que c'est moi le noob (se qui est fort probable aussi ^ ^ ), mais c'était désagréable
[^] # Re: Ubuntu
Posté par Donk . Évalué à 10.
Ou alors, ils ne savent pas qu'ils utilisent apparmor
[^] # Re: Ubuntu
Posté par patrick_g (site web personnel) . Évalué à 5.
Possible. Probable même.
[^] # Re: Ubuntu
Posté par Antoine . Évalué à 3.
En effet, c'est mon cas.
[^] # Re: Ubuntu
Posté par 2PetitsVerres . Évalué à 7.
Ou alors ils ne répondent pas aux sondages.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Ubuntu
Posté par voxmundix . Évalué à 3. Dernière modification le 22 septembre 2014 à 13:44.
Ou ils font comme moi, dans le doute il clique sur "aucun" ^ ^
Avant de lancer le sondage, ça aurait été bien de faire un petit résumé du fonctionnement de ces outils :) (perso je n'aurais pas tenté le truc avec SQL je n'aurais probablement jamais entendu parler d'AppArmor).
Les linuxiens sont curieux, mais linux est vaste, très vaste, énormément vaste ^ ^
# Divers...
Posté par David Carlier . Évalué à 2.
Tournant surtout sous Ubuntu, c'est plutot du AppArmor, sinon quand il m'arrive de toucher a Gentoo, c'est du grsecurity mais ca prend 2/3 millions d'annees a configurer tout aux petits oignons (RBAC et co surtout…). En dernier lieu, pour le boulot, SELinux mais j'ai du mal a m'y faire …
# Une larteuse
Posté par Tonton Th (Mastodon) . Évalué à 8.
[^] # Re: Une larteuse
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
'Larteuse' de Luser Attitude Readjustment Tool ?
C'est fou que t'ai gardé cet esprit maquisard… ;)
[^] # Re: Une larteuse
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
« C’est marrant que t’aies gardé ce côté maquisard, t’es pas en âge d’arrêter tes momeries ? » (de Pascal à Bastien, pas de Raoul à un Tonton :).
# grsecurity
Posté par MadWatch . Évalué à 10.
Récemment j'ai ressenti le besoin de sécuriser un peu mon PC (et surtout l'envie d’expérimenter les divers solutions de sécurité existantes). Je ne suis pas du tout un expert dans le domaine, mais si ça intéresse quelqu'un voici ce que j'ai appris :
SELinux, AppArmor, SMAK, Tomoyo
Insuffisants. Ces solutions permettent de restreindre finement les droits des processus (plus finement qu'il n'est possible de le faire avec les permissions UNIX de base). Par exemple, comme mentionné dans un précédent commentaire, il est possible de les utiliser pour empêcher tout processus autre que firefox d’accéder aux données de ce dernier. Un malware s'exécutant sur la machine ne pourra donc pas récupérer les mots de passes stockés.
C'est bien, mais ça ne suffit pas à assurer la protection d'une machine. Le problème c'est qu'un attaquant peut essayer de contourner ces protections en attaquant directement les processus ou le noyau (SELinux, AppArmor, SMAK et Tomoyo ne font absolument rien pour empêcher ça). Les failles dans le noyau ce n'est pas si rare que ça. Si un attaquant arrive à compromettre le noyau lui même alors c'est game over, il aura absolument tout pouvoir sur la machine.
chroot
Assez compliqué à mettre en place et pas très efficace. Encore une fois, même enfermé dans un chroot, un attaquant peut toujours s'en prendre directement au noyau. Mais même sans aller jusque là, suivant les droits dont il dispose, il peut faire pas mal de bêtises. Par exemple monter un système de fichier dans le chroot, créer des devices, s'attaquer aux IPC des autres applications. Et puis, depuis le chroot il a accès à l'interface réseau localhost aussi. Ça laisse pas mal de possibilités.
Il y a des solutions plus poussées que le chroot pour isoler des processus. Je ne les ai pas testées alors je ne vais pas en parler. Mais d'après ce que j'ai pu lire à droite à gauche, il semblerait que le must de l'isolation reste la virtualisation avec Xen. Un jour il faudra que j'essaye.
grsecurity
La seule solution qui m'a convaincu jusqu'à maintenant. Grsecurity est en fait une colletions de plusieurs mécanismes de sécurité, chacun destiné à résoudre un problème précis. Il adresse le problème de la sécurité de façon plus globale que les solutions mentionnées ci-dessus.
GRSecurity inclut un certain nombre de mécanismes pour protéger le noyau lui même. Ce n'est pas absolut, mais ça rend certaines failles non exploitables (ou plus difficiles à exploiter).
GRSecurity fournit aussi RBAC, un équivalent de SELinux, AppArmor, SMAK et Tomoyo. Ce n'es qu'une opinion personnelle mais je le trouve beaucoup plus simple à utiliser. Par contre je n'ai pas obtenu de bon résultats avec le "mode apprentissage", j'ai dû faire toute ma config à la main, c'est un vrai jeu de patience. Après, rien n'empêche de désactiver RBAC et d'utiliser GRSecurity avec SELinux, AppArmor, SMAK ou Tomoyo à la place.
Enfin GRSecurity fournit PAX, une solution destinée à empêcher l'exploitation des failles de type corruption de mémoire (buffer oveflow et autres) dans les processus fonctionnant sur la machine. PAX fonctionne en rendant aléatoire la disposition des données en mémoire et en rendant certaines zone mémoire non exécutables. Le noyau Linux de base fournit déjà des mécanismes similaires, PAX ne fait que les renforcer et les compléter. De même que RBAC, PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable). Encore un jeu de patience. Il faut aussi savoir que, pour qu'un processus puisse pleinement profiter de la protection offerte par le placement aléatoire des zones mémoire, il faut qu'il est été compilé en PIE (Position Independent Executables) ce qui est loin d'être le cas de la majorité des exécutables sur la plupart des distribution (mais heureusement c'est le cas pour les plus sensibles).
Le PC depuis lequel j'écris ce post fonctionne sur une Mint 17 à laquelle j'ai ajouté GRSecurity (dans un but purement expérimental). Lors de la compilation du noyau (parce que oui pour profiter de GRSecurity il faut commencer par recompiler son noyau) j'ai pu activer presque toutes les options de sécurité. Les exceptions étant :
* GRKERNSEC_IO qui empêche X de fonctionner.
* SYSFS_RESTRICT qui fait planter le driver graphique Intel.
Il faut aussi savoir que utiliser GRSecurity signifie dire adieu à polkit (le truc graphique qui vous demande votre mot de passe lorsque vous lancez synaptic par exemple). Maintenant pour administrer ma machine je dois d'abord ouvrir un shell root puis passer en mode admin. Ça me fait trois mot de passe à retenir (utilisateur, root et admin).
En dehors de ça GRSecurity ne pose pas de problème pour une utilisation quotidienne (web, mail, chat, compilation, musique,
pornvidéo, youtube, flash…). Plus tard je prévois de le tester sur une autre machine sur laquelle j'utilise les drivers proprio NVidia et Steam. Il faudra surement faire quelques ajustements pour que ça marche.Et pour finir, il ne faut pas oublier que sous X, n'importe quel processus, peu importe les droits dont il dispose, peut voir absolument tout ce que vous tapez au clavier, et donc récupérer vos mots de passe sans soucis. Il n'existe, à ma connaissance, aucune protection contre ça. Il semble que la sécurité de Linux ai encore beaucoup ce chemin à faire.
[^] # Re: grsecurity
Posté par freem . Évalué à 2.
Serait-ce lié au fait que tous les outils dont tu parles interprètent (et donc compilent en JIT) un fichier? Firefox interprète JS, python les .py, mono les je-ne-sais-quoi (.exe?)… avec java, ça donne quoi, même combat?
Lancer un serveur X par application :D Je déconne, mais en fait, il y à wayland qui, en théorie, est protégé contre ce problème (c'est un de leurs arguments massue en fait, mais je parle de théorie parce que je n'ai pas vérifié…).
En tout cas, merci pour ce message informatif.
[^] # Re: grsecurity
Posté par Kerro . Évalué à 2.
C'est un peu le principe de l'exploit via le noyau hein.
À part avoir un système de lecture-seule non désactivable, un noyau est forcément vulnérable en cas de… vulnérabilité.
Et là forcément tout devient possible, vu que le noyau est tout puissant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.