Réunion du Collège Technique

• Date : Mardi 19 juin 2018
• Lieu : 2B
• Début : 19h22
• Fin : 20h10

• Lien vers l'etherpad associé

Présents

• Blupon
• Boudy (va bosser)
• Charlie
• Chibrac
• Esum
• Gasnier

Ordre du jour

• Création de comptes wiki
• .forward
• Le CAS
• Mot de passe unique
• ARPEJ

Créer compte wiki

Quelle est la bonne manière d'interfacer le compte re2o avec le compte wiki ?

https://phabricator.crans.org/T293

On remarque que c'est ptet pas release critical, mais pouvoir se logguer sur le wiki via le cas semble tout de meme pratique.

Problème du .forward

Ce serait bien de ne plus avoir à écrire dans les homes des gens pour le .forward. Le mail de redirection serait idéalement stocké dans la BDD, et postfix pourrait taper directement dedans. Il y a le problème des gens qui veulent conserver un .forward custom (procmail)

https://phabricator.crans.org/T295

Le CAS

Que va devenir le CAS avec re2o ?

Est-ce qu'on prévoit de le faire fonctionner avec re2o ?

Est-ce qu'on le garde uniquement pour quelques services ou pas ?

re2o ne change rien pour le CAS, on exporte toujours la base ldap. On peut, si on veut, permettre le login re2o via le cas, mais c'est le seul point.

Mot de passe unique

Dans re2o, il n’y a qu’un seul login/mdp pour tout, et donc les machines wifi.

Avantages :

• plus simple pour les users à comprendre et à retenir comme système
• permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de son compte crans en entier à un « ami ».

Inconvénients :

• le mdp est le même partout, cela peut poser un problème de sécu en particulier pour les admin, qui ont accès aux serveurs + serveur web
• la phase transitoire, il va falloir gérer les mdp legacy des machines, mais il « suffira » de tweaker un peu auth.py au moins temporairement pour ça.

La grande question est : est-ce que cela pose un véritable problème de sécurité, ou est-ce que je fais parler ma paranoïa actuellement ?

Si oui, il faut trouver une solution :

• Avoir un second compte; mais ça semble pénible, est-ce que les gens le feront ? Cela dit, pour les nounous, si on a un compte avec que sudo, pas de mails, etc, et un autre pour tout le reste, on a pas vraiment le choix…
• Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en place un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou l’accès mail, mais surtout les accès serveurs sudo qui sont la pièce critique, comme actuellement au CRANS.
• Forcer l’authentification par clef ssh pour les admin, comme ça si un mot de passe est compromis, les accès serveurs ne le sont pas. Problème : cela ne résout pas le problème de l’accès re2o-web qui serait toujours le même mot de passe. Par aileurs, en cas d'urgence, c'est balot de ne pas pouvoir réparer le crans juste parce qu'on a pas son propre pc sous la main.
• Faire taper ailleurs que dans la base ldap la commande sudo, pour pouvoir avoir un autre mdp (c'est possible simplement ?), et pareille sur re2o-web.

• --> dans man 5 sudoers il y a le flag `rootpw' qui permet de prompter le mot de passe de root plutôt que celui de l'utilisateur.

• (il y a aussi runaspw et targetpw qui ont des comportements du même type)

• Sinon ça peut se faire avec un module PAM, c'est un peu chiant mais ça peut s'écrire en python.

On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet de couvrir à peu près tout.

Il y aura un problème à la transition, car les machines enregistré ne seront pas sur le système du single password. On pense mettre côté auth.py une table had oc contenant toutes les exceptions, que l'on fera disparaitre à terme, mais pas en même temps que la rentrée. On peut envisager de faire disparatitres les exceptions au fur et à mesure, genre tiers par tiers, pour ne pas avoir trop de monde en même temps dont les machines wifi ne marchent plus.

On propose de mettre en place un système à deux mot de passes. Le premier est pour le compte classique, le second permet d'accéder à tous ce qui demande des droits (ssh, re2o).

Arpej

Il n'y aura pas d'ARPEJ d'ici le 2 juillet, et entre le 3 et 11 aout. À part ça, feu.

---

CatégoriePagePublique