119 lines
4.4 KiB
Markdown
119 lines
4.4 KiB
Markdown
# Réunion du Collège Technique
|
||
|
||
* Date : Mardi 19 juin 2018
|
||
* Lieu : 2B
|
||
* Début : 19h22
|
||
* Fin : 20h10
|
||
* <<Pad>>
|
||
|
||
## 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.
|