Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux cryptsetup pour un utilisateur lambda?

cryptsetup pour un utilisateur lambda?

7 réponses
Avatar
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
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Pascal Hambourg
Le 25/05/2018 à 19:36, François Patte a écrit :
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

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 ?
Avatar
Fran=c3=a7ois Patte
Le 25/05/2018 à 20:56, Pascal Hambourg a écrit :
Le 25/05/2018 à 19:36, François Patte a écrit :
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

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 ?

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....
En dernier ressort, sudo pour donner à l'utilisateur le droit d'exécuter
un script bien précis en tant que root ?

Oui, j'y avais pensé mais j'ai une aversion, sans doute irrationnelle,
pour sudo...
Merci
--
François Patte
Université Paris Descartes
Avatar
Pascal Hambourg
Le 26/05/2018 à 12:36, François Patte a écrit :
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>

On n'est pas censé faire les configurations locales dans /etc et éviter
de modifier ce qui est installé dans /usr par la distribution ?
Avatar
Fran=c3=a7ois Patte
Le 26/05/2018 à 13:25, Pascal Hambourg a écrit :
Le 26/05/2018 à 12:36, François Patte a écrit :
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>

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
Avatar
Fran=c3=a7ois Patte
Le 26/05/2018 à 17:07, François Patte a écrit :
Le 26/05/2018 à 13:25, Pascal Hambourg a écrit :
Le 26/05/2018 à 12:36, François Patte a écrit :
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>

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....

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
Avatar
Christophe PEREZ
Le Sun, 27 May 2018 11:38:36 +0200, François Patte a écrit :
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!!

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.
Avatar
Fran=c3=a7ois Patte
Le 27/05/2018 à 18:42, Christophe PEREZ a écrit :
Le Sun, 27 May 2018 11:38:36 +0200, François Patte a écrit :
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!!

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