C'est terrible, depuis le temps que je fréquente linuxfr, je ne devrais plus
espérer grand chose mais bon, on sait jamais...
Dans un message récent, je parlais d'une méthode bourrine pour sécuriser une
machine de bureau (https://linuxfr.org/forums/12/4850.html(...)). Comme je n'ai
rien d'autre à faire, je vais réexpliquer mon idée.
Je réfléchissant à le façon de sécuriser une machine desktop le plus possible sans géner trop les utilisateurs. Biensûr, il y a les trucs évidents comme ne pas
laisser l'utilisateur utiliser le compte administrateur, n'installer aucun serveur et
d'autres trucs. Placer un firewall est déjà plus délicat parce que l'utilisateur
peut vouloir utiliser des logiciels qui nécessitent que certains ports soient
ouverts (ftp ou d'autres). De plus, cet utilisateur n'étant pas technophile, il ne
va pas chercher à mettre à jour sa machine toutes les 15 secondes et il ne va
pas s'amuser à installer 10 programmes par jour non plus. D'ailleurs, si on peut
décourager les installations superflues, c'est pas plus mal, ça évite certaines
saloperies.
La technique OSX est pas mal mais je proposais d'aller plus loin. S'arranger
pour que tous les binaires soient sur une partition séparée sur laquelle le
noyau aurait perdu définitivement les droits d'écriture. De cette façon, il
deviendrait impossible d'installer un root-kit ou de compromettre les binaires.
Pour installer un paquet sur une debian (ce que je connais):
On récupère les paquets dans un endroit spécial (/var/cache/apt/archives) puis
on installe. Il est tout à fait possible d'imposer un reboot pour passer en mode
« install » (en single user mode ou quelque chose d'approchant). Une fois
l'installation faite, le système perd les droits en écriture sur la partition et finit
de booter.
Voilà mon idée. J'aimerai avoir vos idées sur la chose. Sachant que les réponses
du genre:« y a un reboot, c'est mal » ne m'intéressent pas. Qu'un serveur ait
un uptime de 1000 ans peut-être intéressant mais un machine de bureau...
Or, je n'ai eu aucune réponse plus argumentée.
Je suis d'accord que pour un administrateur qui gère 1000 machines, il faut des
aménagements comme autoriser un minimum de réseau pour qu'il puisse faire
l'installation sans avoir à se déplacer devant les 1000 machines mais
autrement, je ne vois pas de problèmes majeurs. Si vous en voyez, je suis
preneur.
Frédéric
Journal Espoir, quand tu nous tiens!
15
nov.
2004
# Cas d'utilisation
Posté par Pior . Évalué à 2.
Un poste personnel connecté à internet est il vulnérable ?
Dans ce cas pourquoi l'idée de forcer ou de proposer une mise à jour périodique n'est elle pas recevable ?
(Tu voulais des réponses c'est ça ?)
[^] # Re: Cas d'utilisation
Posté par fmaz fmaz . Évalué à 2.
Le terme rook-kit était mal choisi.
À priori, ce genre de technique empèche un spyware de s'installer sans l'accord
explicite de l'utilisateur. Il faut que le spyware ailles se copier dans la zone
d'installation, attendes le reboot et à ce moment, il faut que l'utilisateur accepte
d'installer un programme qu'il n'a pas demandé.
De plus, si le système n'accepte d'exécuter que des binaires venant de la
partition « binaires », cela empêche aussi le spyware de se placer dans le
/home et de modifier le .xsession (ou autre technique de ce genre).
Cela n'empêche pas les chevaux de troie ni les virus de macro et cela ne garantit
pas l'intégrité des données de /home mais c'est une protection beaucoup plus
importante.
Je ne dis pas que ma technique est l'arme ultime mais que c'est une façon pas
trop intrusive d'augmenter de façon importante la sécurité. De ce point de vue,
demander à l'utilisateur de faire des mises à jours toutes les semaines est plus
contraignant, même s'il vaut mieux le faire. De plus, certaines personnes n'ont
pas encore l'ADSL et sur un modem RTC, les mises à jours...
[^] # Re: Cas d'utilisation
Posté par botio2 . Évalué à 2.
si tu changes tout simplement les droits sur cette "zone d'installation" pour que seul root puisse y ecrire c'est pas plus simple?
[^] # Re: Cas d'utilisation
Posté par fmaz fmaz . Évalué à 2.
Heuuu...
Non.
La seule raison pour laquelle j'ai mentionné OSX est que c'est le premier
unix orienté desktop dont j'ai entendu parlé qui s'arrange pour « virer »
root. Et je trouve que c'est bien.
# de l'idée a la realisation
Posté par TheBreton . Évalué à 1.
Sachant que c'est le kernel qui autorise ou non l'ecriture sur le disk on ne peut pas dire que lui supprimer le droit d'ecriture du cette partition par un chmod par exemple servent a grand chose.Il faut dont deux kernel distinct(un complet et un modifié sans les operations d'ecriture disk).
Sachant qu'en amputant le kernel des routines d'ecritures il faudrait avoir deux type de peripherique distinct pour que ca marche (un disque ide avec le code complet ecriture/lecture(pour les fichiers des user) et un disk scsi sans la possibilité d'ecriture pour le stockage des binaires et de l'os) ca devrait pouvoir marché....
le plus simple pour essayer ton idée c'est une clef usb avec un verrouillage d'ecriture positionnée et tu auras l'occasion de voir l'ampleur de la tache de la configuration a prevoir pour que cela marche dans les moindres details.
[^] # Re: de l'idée a la realisation
Posté par Rin Jin (site web personnel) . Évalué à 1.
ro pour les partitions binaires
noexec sur les partitions home
pour un démarrage normal
rw pour la partion binaire lors d'une install, aprés reboot
Avec effectivement deux noyau, l'un permettant l'écriture et l'autre non, pour éviter tout changement intempestif (ce qui obligerait j'imagine à avoir /home et / sur deux fs distinct (ext3 pour l'un, reiserfs pour l'autre, par exemple))
[^] # Re: de l'idée a la realisation
Posté par ckyl . Évalué à 3.
Si tu choppes le root ou faille noyau ca sert a rien. On retourne a la case depart puisqu'il fallait deja le root pour modifier les binaires installés
> noexec sur les partitions home
noexec est une vaste blague sur les 2.4, sur les 2.6 ca a un peu changé et on peut enfin empecher l'execution de fichiers binaires (il reste toujours les interpreteurs)
> rw pour la partion binaire lors d'une install, aprés reboot
Donc il suffit d'attaquer a ce moment la. Donc il faut rendre impossible cela, donc ca devient ultra super lourdingue.
> Avec effectivement deux noyau
Ca sert a quoi concretement ? Si tu peux prendre la main sur l'un tu peux prendre la main sur l'autre...
[^] # Re: de l'idée a la realisation
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: de l'idée a la realisation
Posté par ckyl . Évalué à 2.
[^] # Re: de l'idée a la realisation
Posté par jeff110 . Évalué à 2.
Sans redemarrer:
mount -o remount,rw /usr
Resultat: si jamais une faille permet d'executter du code avec des droit root, c'est mort .
A momn avis, comme dit plus haut: soit ton peripherique gere le ro au niveau materiel, soit le noyau est compiler sans l'ecriture ...
[^] # Re: de l'idée a la realisation
Posté par fmaz fmaz . Évalué à 2.
(http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel&apropo(...))
En niveau 1, on peut placer un flag immutable sur des fichiers et la seule façon
de pouvoir à nouveau ecrire sur ces fichiers est de rebooter.
Je ne sais pas si linux permet ce genre de chose mais j'imagine qu'il existe des
patch pour faire des choses semblables.
# Bof
Posté par ckyl . Évalué à 0.
Le noyau ne peut pas perdre les droits d'ecritures. Si tu as le controle sur le noyau tu peux lui rajouter le code necessaire pour ce que tu veux.
Tu peux a la limite utiliser la technique des BSDs (ou grsec) pour augmenter la difficultee technique de la chose
1/ interdire /dev/mem et /dev/kmem (pas de bol X marche plus :-)
2/ interdire l'access brute aux disques
> impossible
En sécu impossible je connais pas désolé.
> je ne vois pas de problèmes majeurs. Si vous en voyez, je suis
preneur.
Moi ce que je vois c'est que tu balances une idée en l'air sans en comprendre les tenant et les aboutissant. Quand on propose une idée en sécu on a pour habitude de faire quelques trucs basiques comme.
1/ présenter le problème de manière générale
2/ Présenter notre solution
3/ Présenter techniquement en quoi notre solution resoud le problème (et les problèmes qu'elle peut apportée)
Présente au moins *un* cas précis de manière technique ou ta solution apporte quelque chose, hormis de grandes idées et ca aura peut etre un interet.
Au fait, il se passe quoi si l'archive telechargée est pas la bonne ? Ou puisque tu vas ecrire a un moment cette archive toute personne avec les droits suffisant pourra y ecrire aussi... Enfin y'a d'autres idees comme ca
[^] # Re: Bof
Posté par fmaz fmaz . Évalué à 1.
Je sais bien que la sécurité absolue, ça n'existe pas, je sais bien qu'il y aura
toujours des trous de sécurité. Je sais bien qu'on ne peut pas être sûr que les
mesures de sécurité mises en place ne seront pas détournée.
Ce que je cherche, ce n'est pas la sécurité absolue: la sécurité informatique
absolue, c'est de ne pas avoir d'ordinateur. Ce que je cherche, c'est comment
microsoft, apple ou redhat peut s'arranger pour rendre son système plus sûr
de façon notable sans faire chier le client. Car la sécurité, c'est avant tout
quelque chose de chiant et de pénible car c'est avant tout quelque chose qui
contrôle et qui interdit.
Je pars du constat qu'une machine windows non administrée se retrouve vite
bourrée de spywares, virii et autres. Si on excepte les virus de macro et les
chevaux de troye, ce genre de chose existe parce que du code à pu s'exécuter
sans que cela ait été voulu. Pour se protéger de ce genre de chose, il faut donc
éviter qu'un bug puisse conduire à l'execution arbitraire de code. Une première
approche consiste à empêcher cette exécution très tôt (W^X, malloc
randomisé, etc...). Maix comme tu le dis si bien, il se peut qu'un attaquant
arrive quand-même à faire exécuter son programme. Or l'une des premières
choses que l'attaquant va essayer de faire, c'est rendre cet exécution pérène.
Si un simple reboot permet de virer tous les spywares et tous les virus,
l'attaquant n'a pas gagné grand chose. Pour péréniser son attaque, il doit
pouvoir écrire sur le disque des informations. De plus, ces informations doivent
être exécutée de façon automatique. Ce que je propose a pour but de rendre
cette seconde étape plus difficile.
Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
noexec, c'est déjà un premier pas. Cependant, comme l'attaquant est fourbe,
il va trouver une faille de sécurité et arriver à devenir root. Dans ce cas, il
peut écrire dans /etc/rc2.d pour que son truc se lance au démarrage. Si
on s'arrange pour que root ne puisse pas écrire dans /bin /sbin /usr /lib...
et qu'un programme doive faire partir d'un de ces répertoires pour être lancé,
la tâche de l'attaquant devient plus dur: il doit trouver le moyen pour rendre
à root les droits d'écriture aux endroits ou il ne les a plus.
Evidemment, ce n'est pas complètement sûr mais ça complique la tâche de
l'attaquant.
[^] # Re: Bof
Posté par ckyl . Évalué à 2.
noexec, c'est déjà un premier pas.
Bha il ecrira son code en Perl :-)
> devenir root.
Dans une configuration ordinaire c'est perdu.
Autrement ce que tu cherches a faire c'est du SELinux, utiliser le module RBAC de grsec ou creer une police MAC pour FreeBSD. Tous permettent d'outre passer l'idée du root tout puissante d'UNIX et de limiter les actions des acteurs dans le système.
Et bien entendu en cas de faille noyau c'est game over dans tout les cas.
Le point critique de ton truc est "Comment je fais les mises a jour" ? Si on peut reproduire l'attaque pendant la mise a jour ca n'a que peu d'interet. Il est aussi a reflechir si le cout impliqué n'est pas superieur a avoir un master que l'on replique periodiquement ou quelque chose du genre (on parle de postes clients la non ?).
[^] # Re: Bof
Posté par fmaz fmaz . Évalué à 2.
:) Ça rejoint ce que je disais pour les virus de macro.
Si son fichier à les droits en exécution, c'est un exécutable et il est traité
comme tel. Sinon, il faut faire
# perl virus
et là, pour augmenter la sécurité, il faut changer l'utilisateur. Je suis bien
convaincu que le fishing et autres techniques de social engenering sont
applicable mais c'est autre chose.
Oui, ce que je veux, c'est du SELinux ou autre et oui encore, le
problème se pose quand on fait une mise à jour.
Si on arrive a mettre en place un système de clef, de sertificat ou autre, on peut
être à peut près sûr de faire une mise à jour depuis le bon site. Évidemment, si
le site est compromis, on est eu.
Au moment où on fait l'installation, la machine est plus vulnérable car on doit
authoriser certaines opérations dangereuses (écrire sur le disque). L'idée est
donc de passer temporairement dans un environnement beaucoup plus contraint
(sans réseau, sans serveur d'impréssion, éventuellement sans serveur
graphique). Une telle configuration n'est certe pas viable en utilisation courante
mais juste pour une installation de programmes, cela me paraît convenir.
Et je vois mal comment une attaque réseau peut être réalisée si
- le système est sain;
- les fichiers à installer sont authentifiés;
- aucune communication avec l'extérieur n'est possible.
Biensur il reste possible de modifier les fichiers de configuration qui se trouvent
dans /etc. Mais il y a rarement une option « installer une backdoor »
configurable dans /etc dans les programmes normaux.
[^] # Re: Bof
Posté par fmaz fmaz . Évalué à 2.
je continue à trouver ton premier commentaire un poil agressif mais ton second
me plait pas mal. Comme tu l'as noté, il y a un certain nombre de choses qui se
font pour sécuriser une machine Linux (SELinux, grsec, pax...)
Et la mise à jour d'un système reste une partie délicate.
Au final, ce que je propose n'est rien d'autre qu'une façon violente de gérer ce
problème de mise à jour.
Un utilisateur technophile a plus de chances d'avoir un comportement sain
vis-à-vis de la sécurité informatique (ne pas rester toujours en root, ne pas
ouvrir tous les mails bizarre...). Cependant, un certain nombre de distributions
visent directement un utilisateur moins « chevronné ». Celui-ci doit être éduqué
mais il me semble plus important d'avoir une politique plus volontaire concernant
la sécurité pour ces personnes. Il me semble que les outils de sécurité mentionné
peuvent être déployé sans trop géner l'utilisateur. Or, à ma connaissance, ils
restent confiné à des niches de spécialites.
Je trouve cela dommage car si pour le moment, Linux n'est pas une cible
importante pour les virus et autres spyware, il est en train de le devenir et si
les éditeurs ne font rien, les machines Linux vulnérables qui se baladent dans
la nature vont finir par devenir un problème.
[^] # Re: Bof
Posté par ckyl . Évalué à 2.
Le gros problème de la sécurité c'est qu'elle n'est pas vraiment transposable. Certaines choses peuvent etre deployables partout comme PaX (W^X, execshield etc.). Quand tu commences a taper dans les regles SELinux tu commences deja a specialiser la machine. Et si tu veux vraiment un truc efficasse tu as une solution adaptée a *une* problématique.
Hors le but des vendeurs est de vendre... Et c'est justement pour ca que fedora est passée d'une police strict (qui correspondrait a je bloque tout ce qui n'est pas autorisée du firewall) a une police targeted qui ne vise que des points particuliers. Bref l'etape actuelle est d'empecher la prise de privilege du a l'exploitation d'un serveur. A ma connaissance, hormis utiliser une politique qui empeche les gens de bosser, il n'y a pas de vraie reponse a la problematique des "PEBKAC" et c'est souvent plus simple d'eduquer les utilisateurs que de chercher des solutions purement techniques. Et activer trop de choses par defaut empeche de bosser, genre les securelevel ne sont applicable que si l'utilisation de la machine a ete prevue pour.
Un mec a presenté y'a pas longtemps un IDS (FreeBSD) basé sur le principe du filtre bayesien sur le comportement des process. Ca pourrait aussi être un deuxieme angle d'attaque meme si ca a des limitations qui sautent aux yeux.
[^] # Re: Bof
Posté par fmaz fmaz . Évalué à 2.
Je m'explique. Il y a des choses que l'on peut déployer partout facilement (W^X
et autres joyeusetés). Ensuite, une politique de sécurité passe par définir ce que
les personnes/processus doivent pouvoir faire (tout le reste étant interdit).
Je trouve que les distributions (dans leur grande majorité) ne semblent pas
s'impliquer activement dans ce genre de politique volontariste. W^X, execshield
et autres ne sont pas la norme. De plus, en ce qui concerne la sécurité, il y a
des gens qui développent des outils (SELinux, grsec...). À d'autres de les utiliser.
Il ne me semblerait pas abérant que /home soit monté par défaut en /noexec.
Pour une machine de bureau, soit l'utiliseur est root, soit il n'a pas à installer
de programmes. Dans le cas contraire, la machine est administrée et libre à
celui-ci de changer le ligne correspondante dans le fstab. Or, ce n'est pas le cas.
Apt-get (et j'imagine urpmi) n'authentifient pas par défaut les serveurs et les
paquets qu'ils installent. À la limite debian a un fonctionnement
ultra-conservateur ce qui peut expliquer cela mais redhat peut imposer ce
genre de choses. Et si c'est effectivement intégré aux outils, les gens l'auront
rien à faire de plus.
Une vraie politique forte de sécurité est forcément intrusive mais je pense qu'il
reste des choses à faire qui ne sont pas trop contraignantes pour améliorer
globale d'une distribution.
Frédéric
[^] # Re: Bof
Posté par ckyl . Évalué à 2.
Dans les distribs grand publique je n'ai vu que gentoo et fedora faire cet effort
> Il ne me semblerait pas abérant que /home soit monté par défaut en /noexec.
Et si quelqu'un veut compiler un programme dans son home ? Ou si c'est un poste de developpeur. Ca rajoute au moins une question a l'installation, et on arrive a un nombre de question < 30 au total. Tu imagines le nombre de question dans les forums a ce sujet ? Je comprend que les mecs puissent hesiter, d'ailleur ce que j'aime bien chez fedora c'est qu'ils osent imposer des choix même si ca casse "tout" pour le moment.
> mais je pense qu'il reste des choses à faire qui ne sont pas trop contraignantes pour améliorer globale d'une distribution.
Je pense qu'il y a a peu pres tout a faire :-)
Le problème est que la sécurité impose a tout les utilisateurs une compréhension minimale de la problématique. Et c'est toujours la que ca coince, l'utilisateur va geuler par ce que "ca marche pas". Les permisions unix sont comprehensibles avec un peu d'effort, les ACLs sous linux/bsd sont une plaies. C'est dingue qu'il n'existe pas d'interface graphique integré a gnome ou rox (quid de KDE ?) ! NFSv4 arrive tout juste avec ses ACLs dans les facs on en arrive a devoir mettre des projets en 660 pour pouvoir bosser et donc n'importe qui peut lire/modifier les projets !
Et la on parle de truc triviaux qui devraient être la base. Ce sont des choses qui ne perturbent pas le fonctionement. Le problème pour les distribs est qu'elles doivent convenir aussi bien au developpeur maison, qu'a l'entreprise et a celui qui tente d'installer linux chez lui. Et c'est trois scenarios sont totalement contradictoires on reintroduit donc une couche de complexité !
Allez pour finir dans une distribution que je ne citerais pas, le maintainer du gestionaire de paquet ne voulait pas de miroir car ce n'etait pas secure ! Apparement le principe meme de signature electronique n'est pas assimilé par des gens techniques. De même la sécurité est un concept dont énormement de devels n'ont jamais entendu parlé, la même personne ignorait les possibilités qu'offraient les symlinks par exemple...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.