cryptsetup pour un utilisateur lambda?
Le
Fran=c3=a7ois Patte
Bonjour,
J'aimerais donner la possibilité à un utilisateur lambda de monter une
partition chiffrée pour qu'il puisse y stocker des données, c'est-à-dire
qu'il puisse effectuer la séquence suivante quand il le désire:
$ cryptsetup luksOpen /dev/partition-chiffrée secret
$ mount /dev/mapper/secret /home/lambda/mes-petits-secrets
Écrire tout ce qu'il veut protéger dans son répertoire
"mes-petits-secrets", puis démonter et fermer la partition chiffrée:
$ umount /home/lambda/mes-petits-secrets
$ cryptsetup luksClose secret
Les points 2 et 3 ne posent pas de problème, mais je n'ai pas trouvé
comment donner des droits à lambda sur cryptsetup sans qu'il ait des
droits de type root.
Il semble qu'il soit possible d'effectuer automatiquement les points 1
et 4 soit au démarrage de la machine mais alors la partition est
"ouverte" tant que la machine est en marche , soit quand lambda ouvre
sa session (mieux) mais la partition est ouverte pour toute la durée de
la session.
Quelqu'un connait-il une solution ou une doc qui permettrait d'y arriver?
Merci.
--
François Patte
Université Paris Descartes
J'aimerais donner la possibilité à un utilisateur lambda de monter une
partition chiffrée pour qu'il puisse y stocker des données, c'est-à-dire
qu'il puisse effectuer la séquence suivante quand il le désire:
$ cryptsetup luksOpen /dev/partition-chiffrée secret
$ mount /dev/mapper/secret /home/lambda/mes-petits-secrets
Écrire tout ce qu'il veut protéger dans son répertoire
"mes-petits-secrets", puis démonter et fermer la partition chiffrée:
$ umount /home/lambda/mes-petits-secrets
$ cryptsetup luksClose secret
Les points 2 et 3 ne posent pas de problème, mais je n'ai pas trouvé
comment donner des droits à lambda sur cryptsetup sans qu'il ait des
droits de type root.
Il semble qu'il soit possible d'effectuer automatiquement les points 1
et 4 soit au démarrage de la machine mais alors la partition est
"ouverte" tant que la machine est en marche , soit quand lambda ouvre
sa session (mieux) mais la partition est ouverte pour toute la durée de
la session.
Quelqu'un connait-il une solution ou une doc qui permettrait d'y arriver?
Merci.
--
François Patte
Université Paris Descartes
Ce n'est pas tout-à-fait ce que tu demandes, mais il me semble que
libpam-mount permette d'automatiser cela à l'ouverture et la fermeture
de session.
Sinon, voir peut-être du côté de udisks/udisks2 ?
En dernier ressort, sudo pour donner à l'utilisateur le droit d'exécuter
un script bien précis en tant que root ?
Là, on peut avancer... merci pour la suggestion. La première étape est
réalisée avec:
$ udisksctl unlock -b /dev/partition-chiffrée
Mais... le mot de passe de root est demandé (curieusement après que l'on
ait mis le mot de passe pour débloquer le chiffrage). On peut
s'affranchir de l'authentification de root en modifiant la règle
"org.freedesktop.udisks2.encrypted-unlock-system" dans le fichier
/usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy, passant de
<allow_active>auth_admin_keep</allow_active> à:
<allow_active>yes</allow_active>
Question: quel inconvénient pour la sécurité du système? A priori, un
disque chiffré est protégé par un mot de passe sans lequel il est
impossible de l'ouvrir.... Merci pour vos remarques et suggestions.
Les étapes 2 se règlent avec le fichier fstab (option "user")
L'étape 4 avec:
$ udisksctl lock -b /dev/partition-chiffrée
Pour cette dernière étape, aucune modification n'est nécessaire vis à
vis de polkit....
Oui, j'y avais pensé mais j'ai une aversion, sans doute irrationnelle,
pour sudo...
Merci
--
François Patte
Université Paris Descartes
On n'est pas censé faire les configurations locales dans /etc et éviter
de modifier ce qui est installé dans /usr par la distribution ?
Ça serait mieux en effet... mais je n'ai pas trouvé de doc expliquant
comment modifier la config, où mettre les fichiers et quelle syntaxe
utiliser....
Il y a bien un répertoire /etc/udisks2/modules.conf.d/ vide, j'ai essayé
d'y mettre un fichier xml portant la partie du fichier "policy" que j'ai
modifiée, mais ça ne fait rien....
--
François Patte
Université Paris Descartes
Dans le manuel de polkit, on a:
Authorization Rules Examples
Allow all users in the admin group to perform user administration
without changing policy
for other users:
polkit.addRule(function(action, subject) {
if (action.id = "org.freedesktop.accounts.user-administration" &&
subject.isInGroup("admin")) {
return polkit.Result.YES;
}
});
Define administrative users to be the users in the wheel group:
polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
});
À mettre dans un fichier xxxx.rules dans /etc/polkit-1/rules.d
J'essaie en adaptant à mon cas (action-id et group), mais ça ne marche pas!!
--
François Patte
Université Paris Descartes
Encore faut-il que l'action org.freedesktop.accounts.user-administration
existe, à tester avec pkaction, et évidemment que l'utilisateur soit dans
le group wheel, ÀMHA.
Me suis mal fait comprendre: quand je dis que j'adapte à mon cas c'est
que je pointe l'action:
"org.freedesktop.udisks2.encrypted-unlock-system" (comme je le disais
dans mon précédent courrier) et que je mets le groupe auquel
j'appartiens (et pas wheel... C'est curieux d'ailleurs que ce groupe qui
date de la nuit des temps existe tjrs, du moins dans les exemples...) ce
qui donne:
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.udisks2.encrypted-unlock-system") &&
subject.local &&
subject.active &&
subject.isInGroup("ufr")) {
return polkit.Result.YES;
}
});
Quant à la listes des actions on la trouve dans les fichiers contenus
dans /usr/share/polkit-1/action.
La doc globale est ici:
https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
J'ai résolu mon problème: une erreur de syntaxe s'était glissée dans mon
fichier... je ne suis pas un expert de la syntaxe java!
Ça marche et ça a l'air dans les clous....
Merci pour m'avoir signalé udisk.
--
François Patte
Université Paris Descartes