dénommé MicroBSD il serait un fork d'OpenBSD (Cf leur FAQ).
Cet OS apporte tout ce qu'OpenBSD n'implémente pas (ACL, TPE, détection d'intrusion dans l'install par défaut,etc..).
A noter:
pas encore d'accès aux sources, et beaucoup de choses ont l'air loin d'être avancées...
Il reste qu'au niveau cryptage il va falloir sérieusement se battre contre les lois (En prime: une clé de cryptage de 1024 bits serait cassable)
![[en]](../images/en.png)
MicroBSD (831 hits)-
OpenBSD (302 hits)
![[fr]](../images/fr.png)
Journal du net - clé 1024 cassable (1156 hits)
> Lire la dépêche (50 commentaires, moyenne: 8,3).
Vous avez demandé le commentaire #115738.
Run by 
Cette page a été générée par Templeet en 0.0711s (dont 0.0073 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
TPE ?
C'est quoi TPE ? Sur la page de microBSD, je vois que TPE == Trusted Path Execution, mais voila, ca ne m'aide pas beaucoup. Quelqu'un pourrait il m'expliquer ?
[^]Re: TPE ?
En gros il ajoute de la securité sur le path des binaires.
seul le 'root' a le droit d'exec ca , wheel ca , toto ca ..
un truc du genre .
amoins que ca soit dans l'autre sens ..
[^]Re: TPE ?
Non, c'est pas ca. TPE, ca interdit l'éxécution en dehors de path définis à l'avance.
Par exemple, un utilisateur ne peut éxécuter que ce qu'il y a dans /bin et /usr/bin. L'intérêt ? Empêcher un hacker de faire cc exploit.c && ./a.out
[^]Re: TPE ?
Le TPE permet de n'executer que les binaires étant dans des répertoires dont root est le propriétaire et qui ne sont pas ouverts en écriture à tout le monde.
C-a-d n'autoriser les executions de binaires que dans /usr/bin /sbin etc.
Ca complique les exploits pour des utilisateurs locaux ...
[^]Re: TPE ?
apparement (je viens de lire les liens que j'ai posté en dessous), TPE fait ce que tu dis effectivement. De plus il garde une liste de user qui ont le droit d'executer des binaires et a chaque lancement l'UID est cherché dans la liste.
Je ferai remarquer qu'a moindre cout, tous les unix peuvent etre installés de facon a limiter la casse si /home, /tmp et /var sont montés en mode "noexec" et "nodev".
[^]Re: TPE ?
Non, noexec ne sert à rien du point de vue de la sécurité. Pour un script shell, on peut faire :
/bin/sh /tmp/vilain_script.sh
Pour un binaire :
/lib/ld-linux.so.2 /tmp/vilain_binaire
[+] [^]Re: TPE ?
oups mea culpa, j'avais oublié cette astuce ...
[^]Re: TPE ?
Mais non !
La meilleure solution pour éviter la casse est de monter /home /tmp et /var en READONLY.
:-))
[^]Re: TPE ?
TPE est apporté sur OBSD par les patch "stephanie" décrits ici: http://c0ke.kaizo.org/mirrors/stephanie/(...)
la technique TPE a été décrite dans Phrack numero 54 ( http://www.phrack.org/phrack/54/P54-06(...) ) et repris par la nsa ( http://www.nsa.gov/selinux/inevit-abs.html(...) )
reste a lire tout cet anglais :-)
[^]j'en ai oublié un
trustedbsd ...
http://www.trustedbsd.org/(...)
le plus inquiétant c'est le cassage possible
du cryptage 1024 bits.
tout etant encore souvent basé sur la simple clé 128 bits (commerce, etc..)
[^]Re: j'en ai oublié un - cassage de clés
Attention à ne pas faire des amalgames entre des algorithme de chiffrement de type différents. L'article parle de clés pour des algorithmes asymétriques. Le commerce électronique est basé à la fois sur des algorithmes asymétriques (échange de clés utilisées pour créer un canal sûr) et symétriques (transfert des donées). Une fois le canal sûr créé, les deux parties l'utilisent pour s'échanger une clé de session (qui sera la clé pour le chiffrement symétrique) et n'utilisent plus qu'un algorithme symétrique pour s'échanger les informations. La raison de ceci est qu'un chiffrement symétrique est nettement, très nettement, plus rapide qu'un chiffrement asymétrique. En plus, on peut plus facilement implémenter au niveau matériel un chiffrement symétrique.
En ce qui concerne la longueur des clés, lorsqu'on parle de chiffrement pour le "e-commerce" avec des clés à 128 bits, il s'agit de la longueur de la clé utilisée dans l'algorithme symétrique. La longueur des clés utilisées pour la partie asymétrique est souvent de 1024 bits. Et n'oublions pas qu'à longueur de clé égale (bien que cela n'ait absolument aucun sens de prendre une clé symétrique de 1024 bits ou une clé asymétrique de 128 bits), un algorithme symétrique est nettement plus difficile à casser qu'un algorithme asymétrique. C'est pourquoi on trouve des longueurs de clés allant sans problème jusqu'à 4096 bits pour des clés GPG, alors que l'on a toujours du 128 bits pour le "e-commerce".
Je ne me souviens malheureusement plus quel est le facteur de correspondance sur la longueur des clés pour les deux types d'algorithme afin d'avoir le même niveau de sécurité. Peut-être quelqu'un d'autre a-t-il cela sous la main ?
Bonne journée.
[^]Re: j'en ai oublié un - cassage de clés
Bon, puisque personne ne l'a fait et que je viens de retrouver l'information, je vais me répondre à moi-même (car je n'aime pas laisser des questions en suspens).
Dans le hors-série numéro 36 de Pour la Science (date : juillet/octobre 2002), consacré à la cryptographie, il est indiqué en page 34 qu'il faut 10^27 MIPS.an[1] pour casser une clé symétrique de 128 bits par recherche exhaustive et "seulement" 7x10^19 MIPS.an pour casser une clé publique RSA de 2048 bits par factorisation. D'après la loi de Moore, ils estiment une date limite de résistance de ces clés à environ l'an 2100 pour les clés symétriques de 128 bits et environ l'an 2080 pour les clés RSA de 2048 bits (3x10^9 pour les clés à 1024 bits, cassable en environ l'an 2030).
Par contre, les clés symétriques de 256 bits (respectivement 4096 bits pour le RSA) resteront "à jamais" incassable car toute l'énergie du soleil ne suffirait pas à effectuer le nombre nécessaire d'opérations en supposant qu'une opération ne demande pas plus d'énergie que le changement d'orbite d'un électron autour d'un atome. Bien entendu, le terme "à jamais" est soumis à la condition qu'il n'y ait pas une découverte scientifique majeure qui change radicalement notre méthode de recherche de ces clés.
Conclusion : une "bonne" clé symétrique à 128 bits est encore plus sure qu'une clé publique à 2048 bits... donc l'utilisation de "seulement" 128 bits pour le chiffrage de "l'e-commerce" n'est pas du tout problématique.
Bonne journée.
[1] 1 MIPS.an correspond à 2^45 opérations élémentaires.
[^]Re: j'en ai oublié un
Attention aux amalgames !
Les clefs 128 bits utilisées pour les transactions CB par exemple sont des clefs symétriques (la même clef est utilisé pour le chiffrage que pour le déchiffrage), avec des algorithmes du genre DES qui consitent en gros à faire plein de XOR entre la clef et les données; les clefs dont le cassage des versions 1024 bits serait posssible sont des clefs asymétriques (clef privée pour chiffrer, clef publique pour déchiffrer), reposant sur le fait qu'il est difficile (donc long) de factoriser le produit de deux grands nombres premiers.
Ces deux types de clefs n'ont donc strictement rien à voir !
[+] [^]Re: j'en ai oublié un
Merci
je l'avais sans doute déja lue reste a s'en rappeler ;)
[^]Re: j'en ai oublié un
Raaaaaah faut arrêter de voir des forks partout !
FreeBSD et NetBSD était les BSD issuent de la fermeture du CSRG développant BSD. FreeBSD étant légèrement plus ancien puisque dérivé directement de 386BSD. Ensuite, OpenBSD est un fork de NetBSD orienté sécurité. MicroBSD est un fork (qui a dit vaporware ?) basé sur OpenBSD et lui ajoutant quelques fonctionnalités.
Qui, d'ailleurs ressemblent en partie au travail effectué par TrustedBSD (qui n'est pas un fork) dont le but est de faire passer à FreeBSD les Common Criteria for Information Technology Security Evaluation (reconnus en France, en Allemagne, aux USA, au Royaume-Uni, au Canada et au Pays-Bas) aussi connu sous le nom d'Orange Book. Et justement il demande entre autre des acl, des discretionnary access control (mac avec plusieurs politiques dont notamment un portage de SELinux appelé SEBSD, capabilities...). En passant, TrustedBSD n'est qu'une des nombreuses initiatives du projet CBOSS soutenu par NAI Labs et la DARPA. C'est notamment grâce à CBOSS qu'on a vu le remplacement du PRNG par Yarrow, l'arrivée des syncookies/syncache et bientôt l'arrivée d'UFS2 optimisé pour les Extended Attributes (utilisés pour les ACL et autres) ou l'extension de jail.
Bref, renseignez vous un peu.
http://opensource.nailabs.com/initiatives/cboss/(...)
(future news : CBOSS un fork (bomb) BSD !)
vjm
[^]Re: j'en ai oublié un
tiens et pendant que j'y suis, je tiens à signaler que bien que peu connu, FreeBSD possède depuis déjà quelques temps son propre projet de source auditing.
http://www.freebsd.org/auditors.html(...)
vjm