On 2012-03-22 00:06, Jérôme Benoit wrote:
On Wed, 21 Mar 2012 09:45:33 +0100
e-t172<e-t...@akegroup.org> wrote:
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.
Personne ne les utilise puisque c'est pas obligatoire. Le principe
étant que si il n'a pas d'impératif fonctionnel sécuritaire lors de la
concrétisation d'un soft, le programmeur s'en tamponne le coquillard :)
C'est donc au client de se retourner contre le fournisseur du logiciel
vérolé. Je ne vois pas le rapport avec l'OS. (oui je sais, bisounours,
toussa, m'enfin si plus de monde le faisait et tenait les développeurs
pour responsables, on se retrouverait peut-être pas dans ce genre de
situation)
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.
C'est la faute à l'OS dans le sens où l'utilisation d'ASLR est rendu
optionnel. Ça ferait sans doute chier un paquet d'éditeur mais sans
l'obligation, c'est juste faire du marketing sécuritaire de ASLR.
Faut vérifier mais je pense que l'ASLR est activé par défaut lors de la
création de nouveau code, le fait qu'il ne soit pas activé pour de
l'ancien code est pour des questions de rétrocompatibilité.
LSM est ton ami lors de la phase d'intégration, c'est là que tu définis
quel paquet à le droit de faire quoi en fonction de critère très fin
en fonction du modèle choisi (TE, RSBAC, MLS).
C'est long ?
Vi, très long et fastidieux mais quand tu as fini le boulot, je met au
défi un cracker de passer outre.
C'est user-frienly ?
Vi, si ta politique est bien conçue. Même pas un prompt pour
l'élévation de privilège, pas besoin (ce qui entre parenthèse est une
hérésie, on ne demande pas à l'utilisateur de faire une
élévation ...).
Dans un autre mail tu cites un exemple de changement d'un alias pour
pointer vers du code malicieux. C'est inexploitable avec LSM, le code
n'aura pas les droits (pour faire court, c'est dans les extend
attributes d'un fichier qui ne sont pas modifiables, ni par root, ni par
l'utilisateur, seul dieu et le responsable le peut :))
Ton raisonnement s'applique à un gros parc d'entreprise avec des gens
payés à plein temps pour bosser sur ce genre de trucs (ce qui est déjà
pas gagné) et configurer au micropoil les politiques de sécurité. Je te
parle de la machine chez Madame Michu. Peux-tu me citer une distribution
user-friendly type Ubuntu qui implémente « hors de la boîte » ce genre
de mesures de sécurité ? (c'est une vraie question)
Plus sérieusement, MS doit passer maintenant à la phase : tu veux
tourner sur Windows 8 ? Tu le fais en suivant mes règles de sécurité
qui ne sont pas là pour te faire chier ou pour empêcher les gens de
travailler, elles sont là pour blah blah
J'ai l'impression que c'est ce qu'ils ont l'intention de faire pour
Windows 8 ARM, où ils n'ont pas à ce soucier de la compatibilité puisque
c'est une nouvelle plate-forme. Mais il est vrai que sur certains points
la philosophie de Windows 8 ARM ressemble tellement à celle d'Android ou
iOS que je me demande si on parle encore d'OS pour PC à ce stade…
MS est suffisamment gros pour le faire dans le monde de
l'informatique propriétaire, on se demande pourquoi çà a pris autant
de temps et autant de dommage collatéraux (enfin, j'ai une idée du
pourquoi du comment, mais çà fera l'objet d'un autre troll :))
Ce qui les ralentit c'est surtout leur philosophie de la
rétrocompatibilité à tout prix. Suffit de lire The Old New Thing pour se
rendre compte que c'est une idée fixe là-bas.
--
Etienne Dechamps / e-t172 - AKE Group
Phone: +33 6 23 42 24 82
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
