Sécurité info - Page 27

Ah oui, mais ça c'est pas spécifique à LDAP ou NIS, c'est aussi valable pour un compte shadow local, et c'est effectivement "by design", parce que root = "SYSTEM", et pas "Administrator".

a chaque fois que j'essaye avec un user local non autorisé ca me demande un password

C'est ROOT qu'il faut utiliser, pas un user local

En même temps, c'est ce mécanisme qui permet à root d'exécuter les services avec des utilisateurs autres que lui, hein...

Sauf que utilisateurs locaux c'est une chose, utilisateurs "distant" en est une autre, en l'occurence si tu es root sur la machine tu peux faire ce que tu veux sur le disque dont changer mots de passes & co des utilisateurs locaux.

Il n'en est pas de meme pour des utilisateurs distants, on ne peux pas en changer leur mot de passe par exemple, alors pourquoi on peux se faire passer pour eux?

su/sudo* devrait savoir que ce ne sont pas des utilisateurs locaux et refuser de faire quoique ce soit sans que tu te soit authentifié.

ah mais si t'es root c'est normal!

Pas vraiment

Linux/Unix ne fait absolument aucune différence entre compte local et compte distant ; d'ailleurs tu peux très bien avoir un root distant, ou un fichier passwd/shadow qui soit lu depuis le réseau.

C'est bien la le probleme

Tu as le même problème avec Windows, cela dit, par design (mais pas de façon simple, par contre) https://stackoverflow.com/questions/137254/is-it-possible-to-impersonate-a-user-without-logging-him-on

Mais en vrai, tu n'as pas de notion d'utilisateurs distants ou utilisateurs locaux ; tous les utilisateurs sont sur la machine.
En revanche, tu as plusieurs possibilités pour stocker les informations de l'utilisateur (celles-ci peuvent être stockées dans un LDAP, et ça consiste essentiellement en UID/GID) et, indépendamment de ces informations, il y a plusieurs possibilités pour vérifier son authentification.

Tu peux très bien avoir une authentification purement locale d'un utilisateur dont les caractéristiques sont stockées dans un LDAP, ou au contraire une authentification réseau d'un utilisateur dont le UID/GID est défini localement. Tu peux très bien définir plusieurs méthodes d'authentification (réseau en premier et local en secours, par exemple) pour un même utilisateur, et tu peux également définir plusieurs sources pour l'UID/GID du même utilisateur (en réseau ou locales, charge à toi d'assurer la cohérence si tu ne veux pas avoir de soucis ^^).

Partant de là, je ne vois pas trop comment root ne pourrait se faire passer que pour certains utilisateurs

Fondamentalement, ça reste cohérent : root peut modifier tout fichier local (ce qui ne veut pas dire modifier toutes les méthodes d'authentification locales), mais pas les éléments distants (sauf trucs particulièrement mal foutus comme NFS v. 3), qu'ils concernent les utilisateurs définis localement ou en réseau.

Tu viens de prouver par A + B ce que je dit. Les UNIXiens/Linuxiens trouvent ca normal.

Ca ne l'est pas.

Root local n'as pas moyen d'acceder a des partages NFS sans que le partage ne se fasse avec des droits speciaux.
Root local ne peux pas changer le mot de passe d'un compte distant.

Par contre root peux se faire passer pour un compte distant et la acceder a tous les fichiers.

Mais tout est normal oui c'est sur.

Si l'utilisateur distant n'est pas connecté, et que tu partage réseau est correct (ou correctement configuré ; à nouveau tu peux oublier NFS v3), root ne peut pas accéder à aux fichiers distants d'un utilisateur.

Après, si l'utilisateur est connecté, root peut voler ses credentials, mais je ne vois pas comment faire autrement.
Et à nouveau, sur quel critère exactement root pourrait choisir entre les utilisateurs qu'il peut incarner et ceux qu'il ne pourrait pas incarner ?
La méthode de vérification du mot de passe ? Mais si le LDAP était indisponible et qu'il a pris le mot de passe local en secours ? Le stockage des UID/GID ? mais même objection : si le LDAP était indisponible et qu'il a pris la version locale des UID/GID en secours ?

Godzil (./792) :

Root local n'as pas moyen d'acceder a des partages NFS sans que le partage ne se fasse avec des droits speciaux.
Root local ne peux pas changer le mot de passe d'un compte distant.

Par contre root peux se faire passer pour un compte distant et la acceder a tous les fichiers.

Comme le dit flan, tu ne pourras pas accéder de cette façon aux dossiers distants si c'est fait proprement (avec PAM), parce qu'il y a besoin du mot de passe (qui permet d'obtenir un jeton d'authentification réseau valide) pour monter ces volumes.

Et Flan a tout bien expliqué : un utilisateur distant est un utilisateur local (contrairement à un domaine Windows, où un utilisateur distant est géré par une entité supérieure et possède lui-même un jeton d'authentification).

D'ailleurs, root ne pourrait que prendre l'identité d'un compte qui existe localement (qui a un UID/GID local). Il ne peut, dans le cas d'un annuaire LDAP, le faire que si le compte LDAP s'est déjà connecté (et que ça a abouti à la création d'un UID quelque part dans le système), soit parce que l'UID est accessible en lecture pour le compte root ou le système. Dans le cas contraire, je pense qu'il y a un message d'erreur indiquant "no such uid". Idem pour une authentification avec Kerberos.
Flan > Il y a énormément de situations où le UID/GID n'existe que sur l'annuaire et pas localement (ce que tu appelles "de secours") - sauf pour root, évidemment, mais avoir un compte root dans l'annuaire LDAP est sujet à risques - mais il faut que les mécanismes de création de compte dans l'annuaire LDAP interdisent la création d'un compte avec l'uid root (je crois qu'il y a des cas documentés de pourrissage du système avec genre un Robert Oot, qui devient un compte "root", mais sans uid 0, ce qui perturbe le système).

D'ailleurs, root ne pourrait que prendre l'identité d'un compte qui existe localement (qui a un UID/GID local). Il ne peut, dans le cas d'un annuaire LDAP, le faire que si le compte LDAP s'est déjà connecté (et que ça a abouti à la création d'un UID quelque part dans le système), soit parce que l'UID est accessible en lecture pour le compte root ou le système. Dans le cas contraire, je pense qu'il y a un message d'erreur indiquant "no such uid". Idem pour une authentification avec Kerberos.

Je ne suis pas sûr : pour moi, root va pouvoir prendre l'identité de n'importe quel utilisateur défini dans getent passwd (sachant que getent passwd prend un login et fournit un uid/gid en échange, en cherchant dans toutes les bases configurées : /etc/passwd, LDAP, NIS, …).
Bien sûr, on ne parle que de la fourniture d'identité par LDAP (via getent), pas la fourniture de mot de passe (même si les deux généralement stockés au même endroit dans LDAP, ça pourrait être deux LDAP différents).
Si l'utilisateur en question ne s'est pas connecté, root n'aura pas de credentials à voler et donc il ne pourra pas monter les partages réseau (par exemple son home) — à nouveau, sauf si le serveur de fichier n'est pas un gros trou de sécurité à lui tout seul.

En revanche, je ne suis pas d'accord sur l'uid quelque part dans le système : si ton utilisateur n'est que dans le LDAP (solution propre) et que tu coupes le LDAP (et le magnifique cache de nslcd/nscd), tu n'auras aucune trace de l'association login/uid dans le système et tu vas te retrouver avec des fichiers orphelins qui appartiennent à un uid inconnu.

Contrairement à LDAP (qui fait à la fois fournisseur d'identité ET validation de mot de passe), Kerberos ne fait que l'authentification : tu peux très bien n'avoir que des utilisateurs définis dans /etc/passwd et avoir tout de même une authent' Kerberos (testé et approuvé ^^) -> l'authentification Kerberos ne fonctionnera que si ton utilisateur existe localement et que le serveur est d'accord (mot de passe correct, par exemple).

Flan > Il y a énormément de situations où le UID/GID n'existe que sur l'annuaire et pas localement (ce que tu appelles "de secours") - sauf pour root, évidemment, mais avoir un compte root dans l'annuaire LDAP est sujet à risques - mais il faut que les mécanismes de création de compte dans l'annuaire LDAP interdisent la création d'un compte avec l'uid root (je crois qu'il y a des cas documentés de pourrissage du système avec genre un Robert Oot, qui devient un compte "root", mais sans uid 0, ce qui perturbe le système).

Oui, bien sûr : ce n'est qu'une possibilité, et c'est très risqué en local pour la base des uid/gid (il suffit d'avoir un uid/gid différent dans le LDAP et le /etc/passwd pour avoir des bugs « rigolos »).
De façon générale, il faut être sûr de ne jamais avoir un même username dans deux sources différentes, sauf en étant absolument sûr que les uid/gid sont identiques… et encore, même dans ce cas il vaut mieux éviter
Après, ce sont des bonnes pratiques, comme préfixer ou suffixer les administrateurs par "-admin" ou les utilisateurs locaux de /etc/passwd par "-local" ^^

Je voulais simplement souligner
- d'une part que la base uid/gid était simplement la concaténation de plusieurs sources (dont le LDAP et le /etc/passwd) et qu'il suffisait que le login soit défini dans l'une de ces sources,
- d'autre part que l'authentification était également la concaténation de plusieurs sources (dont LDAP, /etc/passwd, carte à puce, Kerberos, Kerberos via carte à puce),
- et pour finir, que les deux sont totalement orthogonales ^^

mais bon, fondamentalement, je pense qu'on est d'accord

Au final, c'est plutôt pas mal fichu sur Linux, ça permet beaucoup de souplesse — le problème se trouve plutôt dans nslcd/nscd et dans les interfaces graphiques de login qui ont du mal à accepter autre chose que du login/mot de passe bidon.
Je ne connais pas assez Windows du côté admin sys, mais en tant qu'utilisateur c'est bien mieux fichu en tout cas (pour l'interface graphique, justement).

flanker (./795) :
Je ne suis pas sûr : pour moi, root va pouvoir prendre l'identité de n'importe quel utilisateur défini dans getent passwd (sachant que getent passwd prend un login et fournit un uid/gid en échange, en cherchant dans toutes les bases configurées : /etc/passwd, LDAP, NIS, …).
Bien sûr, on ne parle que de la fourniture d'identité par LDAP (via getent), pas la fourniture de mot de passe (même si les deux généralement stockés au même endroit dans LDAP, ça pourrait être deux LDAP différents).
Si l'utilisateur en question ne s'est pas connecté, root n'aura pas de credentials à voler et donc il ne pourra pas monter les partages réseau (par exemple son home) — à nouveau, sauf si le serveur de fichier n'est pas un gros trou de sécurité à lui tout seul.

Dans cette situation, getent fait une requête LDAP sur le serveur qui va retourner l'uidNumber. Faut-il que le système Unix en question soit configuré avec un utilisateur LDAP permettant de faire des requêtes qui retournent l'uidNumber (ou que l'uidNumber revienne avec une requête anonyme), ce qui n'est pas forcément le cas : tu peux très bien récupérer l'uidNumber à la négociation de la session par PAM, avec l'utilisateur seul qui soit en mesure de récupérer cet attribut dans l'annuaire. Du coup, dans ce cas-là, getent passwd ne renverra rien, mais un login fonctionnera. Et root, sauf s'il existe dans l'annuaire évidemment, ne pourra pas récupérer un uid pour devenir "quelqu'un d'autre du réseau).

(Mais sinon oui, on est fondamentalement d'accord ^^)

Les risques de sécurité du format CSV (si si) :
http://georgemauer.net/2017/10/07/csv-injection.html

L'auteur n'est pas tout à fait honnête quand même. D'accord c'est un risque, mais il prétend que Excel n'affiche qu'un warning qui est "a big block of text, which nobody is going to read". Je viens de tester chez moi, et j'obtiens successivement les deux messages suivants :

puis

Alors certes il y aura toujours des gens pour cliquer deux fois sur "OK" sans lire, mais à moins de supprimer totalement l'évaluation des fonctions dans Excel j'ai l'impression qu'il n'y avait pas beaucoup mieux comme solution non plus.

Malheureusement, cliquer sur "OK" sans lire le message est loin d'être un cas exceptionnel : plein de gens le font.
La solution évidente était de ne pas autoriser ce genre de trucs dans un format qui est censé servir à importer du texte et des nombres, mais c'est trop tard, il y a probablement plein de boîtes qui dépendent de cette feature maintenant.

La preuve, d'après les commentaires, les anciennes versions de LibreOffice ne faisaient pas ça et ça a été rajouté comme une "feature".

Bah oui ça reste une fonctionnalité, CSV n'est qu'un des nombreux formats dont Excel autorise l'import, et l'évaluation des fonctions est un outil indispensable dans Excel. À part ajouter une exception "les fonctions sont interdites quand un classeur est importé à partir d'un format CSV" qui n'aurait été qu'un bout de scotch ils ont préféré afficher deux warnings qui ne me semblent pas si incompréhensibles que ça ("n'activez pas le contenu sauf si vous êtes certain sur la source est fiable"). Je suis même sûr que vous auriez trouvé tout autant à redire si la fonctionnalité avait été totalement désactivée...

Je n'ai pas la même vision. Pour moi, l'import CSV pour un tableur, c'est comme l'import TXT pour un traitement de texte : c'est fait pour importer des données brutes telles quelles (si on m'avait posé la question avant de lire l'article, j'aurais dit que les formules étaient importées en tant que texte). Et justement, il y a plein de gens qui utilisent Excel de cette façon.

Quant aux warnings, la question de savoir s'ils sont bien rédigés est assez accessoire : aussi triste que ça puisse être, l'utilisateur moyen ne lit pas les warnings, tout comme il ne lit pas la doc. Ça fait depuis les débuts de l'info qu'on espère que ça changera, mais en pratique ça n'a jamais changé, malgré tous les efforts déployés pour ça.

Pour moi c'est une feature qui devrait être au minimum désactivée par défaut, parce qu'elle est dangereuse. Mais malheureusement, c'est un problème typique d'un logiciel qui date d'une époque où on ne se préoccupait pas de sécurité, et qui a évolué dans tous les sens "naturellement" au fil du temps.

Zerosquare (./802) :
Je n'ai pas la même vision. Pour moi, l'import CSV pour un tableur, c'est comme l'import TXT pour un traitement de texte : c'est fait pour importer des données brutes telles quelles (si on m'avait posé la question avant de lire l'article, j'aurais dit que les formules étaient importées en tant que texte).

Tu établis ta vision en partant du fichier CSV, en considérant que c'est un fichier qui contient des données brutes et donc n'importe quel logiciel devrait le traduire en données brutes. Je n'ai pas le même avis. Excel est un tableur qui propose des fonctions et des macros. Il propose également d'importer un certain nombre de fichiers et de les considérer comme des tableurs, qui peuvent donc contenir des fonctions et des macros. En d'autres termes ça dépend si tu considères que l'interprétation doit être dictée par le fichier ou l'éditeur, pour moi c'est la deuxième option. Pour la même raison, si j'ouvre un ".txt" avec mon éditeur d'image je me retrouve avec un bitmap dans lequel les caractères ont été retranscris sous une forme visuelle. Pour autant je ne m'en étonne pas et je ne m'attendais pas à ce que parce que c'est un document texte il me l'ouvre comme un éditeur de texte.

Zerosquare (./802) :
Pour moi c'est une feature qui devrait être au minimum désactivée par défaut, parce qu'elle est dangereuse.

C'est exactement le cas : tu remarqueras dans mes captures que les boutons qui n'activent pas les fonctions sont ceux par défaut. Si ce que tu veux dire c'est "ça aurait du être planqué au 36-ième niveau d'un sous-menu caché" alors ça n'est pas ce que j'appelle de la sécurité.

csv c'est values, pas formulaes (ils auraient peut-être pu faire un autre type de fichier, un peu comme les docxm par exemple ?)

Zeph > ta vision est défendable aussi, c'est sûr. Maintenant en pratique, ce qui est important, c'est qu'un simple fichier CSV peut représenter un risque de sécurité. Je n'ai pas l'impression que ce soit de notoriété publique.

Pour la question du "désactivé par défaut", pour moi ça veut dire "il faut aller dans les options changer un réglage pour pouvoir l'utiliser". Un simple popup à l'ouverture d'un document a un apport quasi nul en matière de sécurité, parce ce que tout ce que l'utilisateur verra, c'est "cliquer ici pour que ça marche" (et au bout de quelques fois, il cliquera machinalement sans même y penser).

Je trouve que le ruban d'alerte (comme quand un fichier est en lecture seule) est plus efficace qu'un message d'alerte, perso.

jamais je n'aurais pensé que le CSV pouvait véhiculer des formules O_o

Pas bon pas bon pas bon du tout:

https://www.krackattacks.com/

( https://www.theregister.co.uk/2017/10/16/wpa2_inscure_krackattack/ )

CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088.

Je n'arrive pas à voir si ça vaut aussi pour le WPA2 Entreprise ou pas.
Mais ça pue du cul ouais.

oui ca vaut aussi. WPA1/2 perso/enterprise

c'est le handshake d'établissement de clé de session qui est pété, ca sert a rien de changer le mot de passe ou la clé via radius.