[F] iPad (Informatique et high-tech) - Page 352

Kevin Kofler (./10525) :
Pourrais-tu élaborer s'il te plaît?

Apple refuse de faire une version de leur OS qui pourrais mettre a mal la sécurité de leur utilisateurs, parce que si ils acceptent de le faire pour le FBI, il vont avoir tous les gouvernement (et le chinois en premier) qui va leur demander à avoir accès a cette version, voir pire tenter de les forcer a avoir cette version par défaut.

Apple n'est pas contre aider le FBI a récupérer des données pour une enquête, ils disent eux meme avoir envoyé des ingénieurs pour tenter de récupérer des infos du téléphone, ils sont contre répondre a une requête qui est d'une part douteuse (comme si le FBI cherchais a masquer une connerie et/ou cherche une excuse pour dire "regarder le cryptage c'est le mal", ca fait quelques années qu'ils veulent interdire et faire mettre des backdoors dans les systèmes de cryptages pour leur propre et unique usage bien sur, car tout le monde sais qu'on ne découvre jamais les backdoors, en tout cas publiquement.

Bref, non ca n'a absolument rien a voir avec des app tierces ou du signage, mais bel et bien avec la sécuritée.

ca commence

http://www.wsj.com/articles/justice-department-seeks-to-force-apple-to-extract-data-from-about-12-other-iphones-1456202213

Godzil (./10530) :
Tu peux lancer le recovery de "secours" mais il faut etre patient et un bonne connexion internet,

J'ai eu fait 2x; chez moi, ça met 47mins... mais je dois reconnaître que c'est bien foutu, ça marche dans tous les cas. ^^
Je devrais essayer du boulot, en fait!

Oui la patience est de mise, surtout que.. L'image qui est téléchargé n'est pas si grosse (mais après il faut aussi de la patience parce que installer de cette manière prends encore plus de temps...)

Par contre attention le recovery online n'est pas celui de la version installé, mais celui d'origine de la machine, donc une machine livré avec 10.6 (par exemple) meme si elle a été installé avec 10.11 lancera le recovery internet de 10.6

Ça ne varie pas avec les mises à jour du firmware ?

Non, parceque la machine est vendu avec la version X, les version X+y sont lié a ton compte, et non ta machine, donc si tu restaure depuis la c'est la version lié a la machine et non ton compte.

Sauf (mais je suis pas sur a 100% que la version internet le propose) si tu as moyen de rentrer ton Apple ID, la potentiellement

Hmm ouais, ça se tient. Mais les OS sont tous gratuits maintenant non ?

ca ne change pas le fait qu'il est lié a ton compte et non ton hardware (c'est le fonctionnement du Mac App Store)

Godzil (./10535) :
le recovery online n'est pas celui de la version installé, mais celui d'origine de la machine

Aaaah intéressant. Je crois effectivement que l'installeur était celui de Lion (que je n'ai JAMAIS installé )

https://github.com/SummitRoute/osxlockdown
pour sécuriser un peu son OS X 10.11

Il a oublié de désactiver le clavier. C'est un point d'entrée très critique !

Donc osx n'est pas secure, cqfd

C'est un peu l'équivalent Mac de SELinux.

Plutôt de Bastille Linux, d'après la trace terminal des modifs apportées. Sachant que Bastille Linux est tout sauf un projet vivant.

Aux chiottes le SELinux de la NSA, dont la vision de la sécurité est très restreinte (policy pour le user-space compliquée et lourde) et évite soigneusement les aspects de sécurité réelle qui emmerdent la NSA (anti-exploitation du kernel)...

Vu comment la vraie bastille s'est faite défoncer, c'est pas un super nom pour un machin de sécurité je trouve

D'un autre côté, NSA Linux... vous avez vraiment confiance dans un OS tripoté par le NSA ?

Non, donc la premiere chose a faire est de le désactiver

+1, SELinux = merde.

Alors que sans le SE = bien (tout comme Windows 98, ah quelle belle machine).

Kevin Kofler (./10549) :
+1, SELinux = merde.

Je sais que ça date, mais :

topics/102143-virus-linux#post-14
topics/108760-pourquoi-linux-cest-mal/4#post-107
topics/128625-f-ipad-informatique-et-high-tech/67#post-2008

Tron (./10551) :
topics/102143-virus-linux#post-14
topics/108760-pourquoi-linux-cest-mal/4#post-107
topics/128625-f-ipad-informatique-et-high-tech/67#post-2008

La première et la troisième citation sont en fait des critiques de SELinux, je dis que ça pourrait être intéressant en théorie, mais ne sert strictement à rien en pratique. La deuxième, c'est un cas d'utilisation très particulier où ça pourrait servir (et là aussi, seulement si on se casse la tête à coder une configuration personnalisée, ce qui est très compliqué), ce n'est pas le cas courant. J'ai toujours été contre SELinux.

SELinux est conçu pour faire exactement une chose: bloquer. Donc forcément ça ne fait que casser des choses qui fonctionnent quand on le désactive.

le vrai problème n'est pas que ca bloque puisque c'est fait pour.

le problème est que c'est uber-chiant a configurer pour que ca marche dans une utilisation normale (générale) d'un PC.

Sur une config serveur qui bouge peu, genre un serveur web potentiellement attaquable, ca peut aider a éviter des exploits qui auraient été possibles autrement (enfin, j'imagine que c'est le cas)

(et d'une origine douteuse, mais c'est secondaire)

Par exemple, si un processus qui n'a aucune raison d'utiliser des sockets réseau se met à essayer de le faire, ça peut être un symptôme d'exécution de code arbitraire, auquel cas tuer l'application est une bonne chose à faire pour protéger l'intégrité, la confidentialité, la disponibilité du code et des données de l'ordinateur, et donc des utilisateurs. A une époque (Vista ou 7 ?), Microsoft avait mentionné le même genre de capacités pour Windows, même si je ne suis pas au courant que beaucoup utilisent de telles capacités, à supposer qu'elles aient été mises en place.

Le problème, c'est qu'outre la création et l'évolution compliquées des policies SELinux, SELinux est facile à contourner et désactiver par les nombreux exploits qui s'attaquent au faible kernel standard, grâce auquel plusieurs fois par an pour chaque type de vulnérabilité, des gens font élever les privilèges (voir le bordel actuel avec la terrible passoire que sont les user namespaces, dont le mainteneur refuse la création d'une option permettant de les désactiver autrement que par le fait de ne pas les compiler), ou tranquillement déférencer des structures de données puis exécuter du code arbitraire situé en user-space (sur la quasi-totalité des processeurs existants)...
Même avec une couche soi-disant "Security-Enhanced", une passoire ne protégeant pas contre les techniques d'exploitation connues depuis plus d'une décennie, pour quelques pourcents de performance en plus, reste une passoire.

Des travaux d'incorporation de quelques features de PaX/grsecurity ont récemment commencé, de façon plus sérieuse qu'avant parce que les mainteneurs principaux du kernel prennent lentement conscience que le retard considérable du Linux standard s'aggrave avec le temps, et Linux (tel que presque tout le monde l'utilise) usurpe de plus en plus sa réputation de sécurité. Cependant, vu que Linus refuse les plus efficaces (UDEREF et KERNEXEC), leur préférant les capacités pourtant inférieures de processeurs rares, et n'est toujours pas chaud pour les plugins GCC, qui sont pourtant à la base des deux autres membres du quatuor de base (RANDSTRUCT et CONSTIFY), ça n'ira pas loin...
Je ne demande qu'à avoir tort, mais la seule vraie solution reste - et restera - l'utilisation d'un kernel grsec, tant qu'il existe. D'ailleurs, les distros qui proposent des intégrations plus ou moins avancées du kernel grsec sont de plus en plus nombreuses, et c'est une bonne chose. Debian sid a récemment ajouté un kernel grsec, et même si celui-ci n'arrivera jamais dans testing et donc dans une release stable, ça finira quand même par porter ses fruits.

>processeurs rares
quésaco ?

* les processeurs Intel gérant SMEP (à partir d'Ivy Bridge, Core i* de 3ème génération), et encore davantage les processeurs Intel gérant SMAP (annoncé depuis des années, mais disponible seulement à partir de Broadwell, Core i* 5ème génération, et si je me souviens bien pas sur tous les modèles) sont une goutte d'eau par rapport à la base de CPUs Intel et compatibles sur laquelle PaX/grsecurity propose respectivement KERNEXEC et UDEREF, qui sont tous les deux des sur-ensembles stricts de SMEP et SMAP, depuis plus de 10 ans. Aussi, PaX/grsecurity tire partie du PCID des Sandy Bridge (Core i* de 2ème génération) pour optimiser UDEREF, et mainline pourrait bénéficier de PCID pour optimiser sans la sécurité augmentée, mais ne le faisait toujours pas il y a quelques mois...
EDIT 2+h plus tard: et en plus, l'utilisation de SMAP par le kernel mainline est foireuse depuis qu'il gère le SMAP: http://seclists.org/oss-sec/2016/q1/446 "That patch fixes a bug that exposed a fairly large kernel code surface to a straightforward SMAP bypass." / "This bug is present in all kernels from 3.10 on AFAICT.".

* certains processeurs ARM disposent de PXN et PAN, mais encore faut-il les utiliser, ce qui est loin d'être le cas par défaut sur nombre d'entre eux, notamment les Android utilisant des kernels lourdement obsolètes et trafiqués... Là aussi, PaX/grsecurity était en avance.

* PaX/grsecurity gère UDEREF et/ou KERNEXEC sur d'autres ISAs.

Linus se plaint toujours du security theater, mais en attendant, son kernel reste une passoire n'implémentant pas des protections efficaces connues pour certaines depuis plus de 10 ans, et c'est largement à cause de son état d'esprit, partagé hélas par beaucoup de devs core. Android va finir par être en avance (mais sur des kernels obsolètes, c'est malin...) grâce notamment à Copperhead, géré par des chercheurs en sécurité et bons connaisseurs de PaX/grsec comme Daniel Micay, qui sont en train d'augmenter le niveau de sécurité de userspace + kernel Android.


Les BSDs sont hors course pour la sécurité, n'ayant par exemple implémenté des choses aussi faibles qu'ASLR qu'avec des années de retard sur Windows et Linux (ça, c'était pour OpenBSD; FreeBSD ne l'a toujours pas dans la souche principale, ou si ça a été enfin mergé, ça date au plus de quelques mois), avoir mal copié MPROTECT avec le W^X OpenBSD Not Invented Here, etc.

UDEREF est une émulation logicielle de SMAP qui a un impact de performance non-négligeable (même si inférieur à celui d'un vrai split 4G4G).

Cela dit, on commence à s'éloigner du sujet…

UDEREF est une émulation logicielle de SMAP

PaXTeam écrit régulièrement que c'est un sur-ensemble de ce qu'Intel a fini par implémenter comme SMAP.
Parmi les conneries récemment implémentées par Intel, signalons les Memory Protection eXtensions, peu efficaces, lourdes, nécessitant des changements d'ABI, augmentant la densité de gadgets ROP... bref, tout bon

qui a un impact de performance non-négligeable

C'est beaucoup moins vrai avec le PCID des Sandy Bridge et ultérieurs, soit plus de 4 ans de x86_64 Intel, ce qui est beaucoup plus large que Broadwell: les portables Haswell neufs sont encore loin d'être rares sur le marché.
Comme souvent, on doit choisir entre sécurité et performance.

Mais oui, on s'éloigne du sujet.