oinkoink_daotter a écrit 1695 commentaires

C'est un peu la même finalité en fait : offrir un contrôle d'accès durci aux données, mais pas les même moyens.
sepsql via SELinux va imposer via les mécanismes du noyau un contrôle d'accès MAC très fin aux données.
cryptdb lui, va cloisonner les données par de la crypto.

L'un repose sur la robustesse du noyau, l'autre sur le fait que les clefs restent secrètes.
La solution crypto est plus robuste, mais je pense qu'elle est moins souple sur ce qui est protégé (ex: OPE pour les relations d'ordres ne me semble marcher que si toute la colonne est protégée). Je n'ai pas regardé donc je ne sais pas comment est géré le multiutilisateur dans une table ... Ca suppose aussi que la machine ne soit pas complètement corrompue, car si c'est le cas, l'admin pourra récupérer la clef des opérations crypto faites en local.
sepsql est plus souple mais n'offre de cloisonnemnt crypto au cas ou il serait bypassé (m'enfin à ce niveau, on doit être déjà marron ;) ). Et comme il marche dans la bdd, il ne faut pas oublier de mettre des acl selinux sur les fichiers physiques pour éviter que l'admin parte avec :)

edit: je ne connaissais pas sepsql, j'ai regardé la doc développeur, j'aime bien :)

OPE a l'air d'être capable de préserver les relations d'ordre. Je pense que ça doit aider (mais les bases de données c'est pas mon métier - et je les vomis).

[...] Ainsi que RND (Random), DET (Deterministic), OPE (order preserving encryption) & Join, HOM (Homomorphic encryption). CryptDB est en mesure de basculer à la volée entre divers systèmes de chiffrement en fonction des opérations... Donc de travailler sur des données dont le chiffrement est de type "oignons" (chiffrement sur chiffrement)

Si tu ne précises pas que le système en question est capable d'empiler les mécanismes précités (je n'ai pas vérifié), le "donc" est hardi : ce n'est pas parce qu'il est capable d’utiliser au choix une brique pour accéder à une donnée qu'il est capable de les empiler.

Une garantie de sureté même lorsque la totalité de la chaîne de gestion a été compromise (accès aux serveurs, failles dans les applications).

Euuuh je ne vois qui rien qui protège contre une divulgation de la clef, ce qui va arriver si toute la chaîne est compromise (auquel cas tu es coincé) ! D'ailleurs j'aimerais bien savoir ce qu'a la DARPA derrière la tête...

Enfin, il fait cela en quelques secondes lorsque les systèmes actuels demanderaient plusieurs milliers d'années.

Tu peux expliquer ? Même dans le contexte du paragraphe, ça n'a aucun sens !

Hhhhannnn, tu devrais savoir, toi qui est un pilier de la 3Bune™ !

Le mouledottage actuel montre bien la limite de l'autohébergement sur ligne adsl...

Ok !

Environ 4 lettres \o/

Et donc, grâce à la magie des "t'es plus souvent" et des "90%", on passe de "sous linux presque tout est fichier/descripteur" (ma position) à "tout est fichier/descripteur" ?
Je pinaille, certes, mais je ne suis pas le seul !

Tu remarqueras que le procès "systemd casse toute ma façon de gérer l'init" s'applique tout autant à launchd et Upstart mais personne ne le leur a fait avec autant de virulence.

En même temps, Apple rilize un truc qu'il a pondu (launchd) en license "libre" fait pour leur OS à eux. Autant dire que la critique ils n'en ont rien à battre ...

edit: added missing woueurd.

Espèce de naze de la langue.

Euh pour continuer trolldi, je dirais même

install gnome-fallback

/o/ -> []

Ben même en fait : je ne suis pas spécialiste en prog réseau système sous linux, mais de ce que je vois sur l'internet, quand tu crées une socket elle n'est pas liée à une interface. Il faut passer un paramètre textuel dans le struct ifreq que tu passes en paramètre à l'ioctl qui est fait sur le descripteur de la socket pour désigner l'interface que tu cibles. Alors pour le tout est fichier ou descripteur de fichier, je persiste : bof. On est quand même vachement loin de "je fais(faisais) des ioctl sur /dev/dsp0" pour paramétrer ma carte son !

Euh... En quoi ça invalide ce que je dis ?

En attendant, on embarque de plus en plus de couches d'interprétation de langages (bientôt, un interpréteur écrit en Javascript d'un langage de plus haut-niveau)

Tu veux parler de ce genre d'infamie ? :-)

En fait, à KDE, il ne lui manque que juste un bouton "transformer en un truc utilisable, merci" qui ferait tout ça d'un coup :-)

Avec alsa, on a perdu l'aspect tout est fichier du monde unix

Non : sous Linux, tout n'est pas fichier car point de /dev/ethX pour les périphériques réseaux.

Non, cf le commentaire en bas du post cité précédemment : http://home.regit.org/2011/12/code-edenwall/

Nan, mais faut arrêter avec les boîtes qui font de la défense ! La réglementation impose des contraintes qui font que ce genre de fuites n'est pas possible fortuitement.
Par contre, c'est le b a b a(?) de n'importe quelle politique SSI (normalement une politique SSI, ça devrait être assez courant) d'avoir une charte informatique . Ça doit être la première ou la deuxième exigence du manuel (ptet que j’exagère). Si la boite a un RSSI, il doit y avoir une charte.

quand je lançais mon petit Firefox, le proxy HTTPS me demandait de m'authentifier (avec des identifiants que bien sûr je n'avais pas) pour environ la moitié des sites, ce qui revenait en gros à les bloquer

Ben c'est que l'admin s'y est pris comme un branque ou que la friture n'était pas sèche.
Ca marche pas mal du tout en fait (et ça bloque mon ajaxterm, f*ck).
(Pour confirmer ce que dit gle<, ça se voit bien quand on clique sur les propriétés de sécurité de la page, et les sites à validation SSL "EV" ne sont plus en vert)

Les impots surtout : c'est le seul site que je connaisse qui fasse un check sur le certificat client ...

C'est un problème avec les utilisateurs, ils voient une alerte SSL, ils l'ignorent et la passe. Dans le cas dont tu parles, à mon avis, ça déchiffre le connexion SSL vers le serveur et la « re-chiffre » pour le client. Et au milieu, le « proxy HTTPS » peut tout écouter et voit tout en clair. C'est plus du HTTPS, le HTTPS c'est pour que personne d'autre, à part le client et le serveur, ne puisse écouter ou modifier le flux ; c'est pour ça d'ailleurs que le navigateur met une alerte, car plus rien n'est sécurisé.

Si la boîte est maline, le gars de l'informatique va déployer une mise à jour des CA des navigateurs en incluant la chaîne de certificats qui va bien pour que le navigateur reconnaisse le certificat du proxy comme étant "digne de confiance".

Vu le nombre de boîtes qui utilisent ça, je pense que quelqu'un, peut être même les antennes françaises des constructeurs qui dealent ces machins se sont posés la question ?
En pratique la violation du secret des correspondances est loin d'être si évidente si la seule intervention est par exemple des vérifications protocolaires sans regarder ce qu'il y a dedans (ie, ce qu'il y a dans un flux à destination d'un port 443 est bien du https avec des "get" dedans et pas juste un truc qui ressemble de l'extérieur) ou du contrôle antivirus (donc automatisé).
En outre, à ma connaissance, le secret de la correspondance privée n'est pas acquis en milieu professionnel, il y a eu pas mal de jurisprudences un peu contradictoires je dirais ces 5 dernières années dans le domaine du cercle privé "transporté au boulot". (Non je n'ai pas de liens)

mais pas d'un doctorat

Si, car ils soutiennent une thèse.
Par contre pour la pharmacie, c'est un peu spécial : il y a une année avant laquelle la thèse était optionnelle, maintenant elle est obligatoire. Mes parents sont dans le premier cas.

J'ai été ébahi par un pote qui faisait ça avec la carte son de son ordi. Sa machine freezait durant le boot (windows xp). Il enlevait la carte (PCI) et le windows finissait son boot. Si il la remettait, le truc faisait le petit son "hay, j'ai trouvé un nouveau périphérique", puis freezait au bout de 5 secondes. Si il l'enlevait, ça continuait comme si de rien était. Un machin dell lambda.

J'ai jamais dit ça :)
Je relance avec la Gougueul TV niveau echec.