On 2012-03-21 01:30, Jérôme Benoit wrote:
On Tue, 20 Mar 2012 23:47:49 +0100
e-t172<[email protected]> wrote:
On 2012-03-20 20:25, Jérôme Benoit wrote:
C'est sur, c'est pas la faute de l'OS qui ne sépare pas les
privilèges,
Depuis Windows Vista, si. Tout utilisateur (même admin) est par
défaut sur une session à droits restreints et doit explicitement
autoriser une application à s'élever pour toucher au système. Et
c'est conçu de telle sorte que même les vieilles applis fonctionnent
avec des droits restreints, grâce à une astucieuse redirection
automatique des appels système.
http://en.wikipedia.org/wiki/User_Account_Control
Cette bonne blague :)
Et tu oses appeler çà de la séparation de privilèges ?
man 7 capabilities sous Linux par exemple mais des mécanismes
similaires existent sous tous les *nix des années avant 2008, l'année
ou MS a tout juste commencé à comprendre les idées sous-jacentes du
principe (mais pas entièrement vu le résultat :))
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx
Ça existe depuis XP, sorti en 2001.
qui ne randomize pas la pile d'allocation mémoire
Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows
Ahahahahah, même OS X l'implémente mieux depuis la 10.7, je te donne 10
min pour trouver un bout de code en C qui listent les zones qui ne le
sont pas et elles sont tellement nombreuses :)
Il faut spécifier que le code est compatible ASLR à la compilation pour
que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des…
« développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on
randomise leurs espaces d'adressage.
qui ne fourni
pas de base une seule politique de type MAC
Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control
Tu cherches à te ridiculiser en public ?
1) c'est pas actif à la livraison dans trop de OEM
Va falloir citer des sources, parce que pour l'instant, un Vista/7 qui
n'a pas la notion d'intégrité, j'en ai encore jamais vu. Et quand bien
même ce serait vrai, c'est la faute à l'OEM, pas l'OS.
2) c'est l'application qui choisit et de ne pas le faire dans 98% des
cas (hénaurme)
Encore une fois, si une application tierce choisit d'être une passoire,
c'est son problème. Microsoft privilégie parfois la compatibilité avec
les anciennes applications à la sécurité quand ils sont forcés de
choisir. Après c'est clair que permettre aux gens de travailler c'est
vraiment pas important (sarcasm inside).
Ceci dit, les applications présentant une surface d'attaque importante
telles que les navigateurs utilisent souvent ces fonctionnalités.
j'ose à peine parler pas
de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour
être fait sans énorme hack)
Google Chrome met chaque thread correspondant à un onglet dans une
sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack »
pour le faire. Il faut aussi signaler le mode protégé des threads
d'IE qui s'en rapproche pas mal.
Un rapide sous d’œil à
http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/
me fait très largement dire le contraire :)
Hum, oui. Au temps pour moi, j'avais pas pris le temps de vérifier. Il
est clair que réimplémenter tous les appels système n'est exactement la
solution la plus simple qui soit.
Tu confonds deux choses qui n'ont aucun rapport :
- La conception d'un système d'exploitation avec des mécanismes de
sécurité qui tiennent la route;
- L'intégration d'un tel système qui oublient juste
d'implémenter lesdits mécanismes.
Je suis conscient de cette distinction. Je dénonce justement le fait que
la distribution Linux la plus grand public (Ubuntu), malgré le fait
qu'elle soit basée sur un OS offrant des principes de sécurité solides,
envoie tout ça par la fenêtre dès lors qu'elle permet l'utilisation de
su/sudo.
Les corrections sont simples
pour corriger des choix d'intégration.
Tu peux expliquer ces corrections ? Plus précisément, si tu peux me
fournir un équivalent d'UAC sous Linux qui ne soit pas une passoire, je
suis tout ouïe. Et à ergonomie équivalente, hein, sinon c'est trop
facile (UAC c'est juste cliquer sur un bouton pour autoriser l'élévation).
Windows est dans le cas ou çà a été oublié à la conception et le
cheminement inverse pour palier les errances en sécurité à la
conception est juste largement plus complexe et ... en cours de
cheminement ... (pour rester poli) depuis 4 ans sans apporter pour
le moment des réponses concrètes et efficientes (une parti du pb
étant d'avoir mal habitué des palanqués de programmeurs a des APIs
qui n’intègre aucunes notions de sécurité).
C'est pas faux, mais tu ne peux pas nier le fait que depuis quelques
années Microsoft met les bouchées doubles pour tenter de rattraper son
retard.
--
Etienne Dechamps / e-t172 - AKE Group
Phone: +33 6 23 42 24 82
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
