J’utilise l’interface graphique zuluCrypt pour déchiffrer mes volumes veracrypt. Cependant, par défaut, les volumes sont montés dans le répertoire root.
Je voudrais modifier la configuration du programme zuluCrypt-cli afin de pouvoir travailler comme simple utilisateur.
J’ai essayé la fonction (operation) -M proposé par le manuel (commande “man zuluCrypt-cli” dans la console).
-M create a publicly accessible "mirror" of the mount point in
"/run/media/public/" from the original created in "/run/media/private/$USER/"
Je pense avoir un problème avec la syntaxe de la commande. Quel est cet argument "action" qui est manquant?
Les paquets de zuluCrypt que je fournis sont meilleurs que ceux fournis par les distributions
pour les raisons suivantes :
Mes paquets ne génèrent pas d’invite polkit nécessitant un mot de passe root.
lorsque les composants de l’interface graphique sont démarrés.
Mes paquets fournissent des composants CLI qui fonctionnent à partir d’un compte utilisateur normal.
PS : zuluCrypt-cli n’est pas un script.
PS2 : Il est facile d’imaginer que les distributions aient un zuluCrypt modifié pour un fonctionnement avec authentification root pour une bonne raison. (en raison de la grande surface d’attaque de Qt)
oui, mais je me disais que si plusieurs utilisateurs utilisent un ordi, il faut pouvoir différencier les accès et que si des centaines de user existent, cette fonction devrait alors créer des centaines de liens .
PS juste des pistes.
/*
* below tests are here because they do not use -d option
*
* zuluCryptPrintPartitions() function is defined in volumes.c
* zuluCryptSecurityCheckPartitionPermissions() is defined in security.c
*/
switch( action ){
case 'A':
case 'N':
case 'S': st = zuluCryptPrintPartitions( clargs.partition_number,clargs.print_partition_type,uid ) ;
return zuluExit( st,stl,stx,env,NULL ) ;
case 'L': st = _printOpenedVolumes( uid ) ;
return zuluExit( st,stl,stx,env,NULL ) ;
}
if( action == '\0' ){
return zuluExit( 130,stl,stx,env,gettext( "ERROR: \"action\" argument is missing" ) ) ;
}
if( device == NULL ){
return zuluExit( 120,stl,stx,env,gettext( "ERROR: Required option( device path ) is missing for this operation" ) ) ;
}
if( action == 'U' ){
st = _print_uuid_from_path( device ) ;
return zuluExit( st,stl,stx,env,NULL ) ;
}
Non, ça ne tient pas car le point de montage public miroir est toujours le même.
-M create a publicly accessible “mirror” of the mount point in /run/media/public/ from the original created in /run/media/private/$USER/
Si un user montait d’une façon ou d’une autre une image dans /run/media/private/$USER/,
je pense que le zuluCrypt-cli -M passerait comme une lettre à la poste.
Sans avoir aucune prétendue “action” à préciser.
Mon compte root est désactivé, j’ai le statut d’utilisateur principal, c’est à dire que j’accède aux droits Administrateur en saisissant mon mot de passe non-administrateur.
Quand je lance zuluCrypt ou zuluMount, Debian me réclame mon mot de passe.
Contrairement à ce qui est indiqué dans le manuel, le point de montage primaire n’est pas “/run/media/private/$USER/” mais “/run/media/private/root/”. Pourquoi ???
Lorsque zuluCrypt monte le volume, il le fait en ouvrant une fenêtre du gestionnaire de fichier sous le compte root, comme l’indique la bande de couleur jaune en haut de la fenêtre.
J’ai l’impression que vous me proposez de localiser le volume monté ? Cependant, comme expliqué ci-dessus, je n’ai aucun doute sur sa localisation.
L’utilisation des paquets de l’auteur de zulucrypt est une piste intéressante mais n’est-ce pas risqué? N’y-a-t-il pas un risque de déstabiliser le système?
Ici, $USER est assimilé à l’utilisateur qui a effectué le montage privé,
en l’occurrence root dans votre cas.
Entendu.
J’ai relu le sujet et je ne vois pas.
Le volume est effectivement monté par root de manière privée dans : /run/media/private/root/
Je n’ai trouvé aucune action supplémentaire à ajouter à la commande zuluCrypt-cli -M
Vous pouvez essayer zuluCrypt-cli -M /run/media/private/root/
Est-ce que zuluMount ou zuluCrypt en mode graphique permettrait un montage miroir public dans /run/media/public/ ?
Si vous y arrivez, votre utilisateur ordinaire accédera alors au volume monté publiquement.
Il semble réellement qu’il faille prendre les sources de l’auteur de zuluCrypt.
Ça dépend :
Fait n’importe comment, cela peut engendrer des erreurs voire une catastrophe.
Mais simplement bien fait, c’est la robustesse et la fiabilité du code source de zuluCrypt-5.5.0 qui est concernée et mise à l’épreuve.
Il faut compiler zuluCrypt-5.5.0, ce qui demande des outils et un peu d’expérience (bien lire)
C’est envisageable avec un niveau intermédiaire averti.
Il est facile d’imaginer que les distributions aient un zuluCrypt modifié pour un fonctionnement avec authentification root pour une bonne raison. (en raison de la grande surface d’attaque de Qt)
-DUSE_POLKIT=false
Set this option to “true” if project’s CLI components are to be installed with suid bit NOT set.
This option will cause GUI components to generate polkit prompt that requires a root’s password and CLI components will be unusable from normal user account.
-DUSE_POLKIT=false
Définissez cette option sur “true” si les composants CLI du projet doivent être installés avec le bit suid NON fixé. Cette option provoquera l’apparition de l’interface graphique pour générer l’invite de polkit qui nécessite le mot de passe root et les composants CLI seront inutilisables pour un compte utilisateur ordinaire.
J’aimerais bien savoir comment obtenir les directives de compilation d’un programme compilé
J’ai oublié de préciser, j’ai zuluCrypt version 5.0.2 sous Debian 9.7.
Quels sont les améliorations prévues par la nouvelle version de zuluCrypt ???
J’ai essayé : zuluCrypt-cli -M /run/media/private/root/
On obtient le même message d’erreur.
r2mi:
Ici, $USER est assimilé à l’utilisateur qui a effectué le montage privé,
en l’occurrence root dans votre cas.
$USER ce n’est pas #USER!
L’auteur précise que sa version de zuluCrypt ne nécessite pas de Mot de Passe root. Manifestement, ces indices semblent révèler que le manuel (obtenu par la commande “man”) correspond à la version de son auteur (Francis Banyikwa) et non pas à celle de Debian. C’est peut-être pourquoi cette opération -M ne fonctionne pas!?
J’ai découvert l’équivalent GUI de l’opération cli -M, aussi bien dans zuluCrypt que zuluMount.
Fenêtre “déverouiller un volume chiffré”/Share (Partage) Point de montage.
Une bulle informative nous dit: si l’option est coché, un point de montage privé primaire sera créé dans “/run/media/private/” et un <> secondaire du point de montage accessible au public sera créé dans “/run/media/public/”.
Si le curseur (il faut s’y reprendre à deux fois) est placé sur la ligne des chemins de la fenêtre zuluCrypt et clic gauche/Ouvrir Répertoir Partagé, le répertoire s’ouvre sous le compte root! Par contre, si j’accède au répertoire partagé via le système de fichiers (SdF) du Gestionnaire de Fichiers (GdF) non-adm, alors je ne suis pas sous le compte root comme l’atteste le prompte du terminal ouvert dans la fenêtre. Ainsi, si j’ai fermé toutes les fenêtres (GdF, zuluCrypt,…) sous root, est-ce que les privilèges admi sont réellement protégés sachant que le point de montage primaire existe? Serais-je en sécurité quand connecté au réseau Internet???
suggestions:
titre de la discussion: zuluCrypt, configuration du point de montage: root, privé ou public?
mot-clès: zuluCrypt, veracrypt, cli, gui.
Le windowsien ne connait pas l’existence de zuluCrypt, il recherche le paquet veracrypt.deb!
Ce n’est pas le # de votre terminal ouvert en root qui doit vous induire en erreur ;
Le $ de $USER indique que $USER est une variable qui peut avoir root comme valeur.
C’est aussi une manière d’indiquer que cette valeur pourrait changer.
J’ai du mal à suivre votre raisonnement.
Que Debian utilise le manuel rédigé par l’auteur de zuluCrypt
n’est pas une surprise ni une anomalie.
Tant que vous ne pourrez pas lancer zuluCrypt-gui avec un utilisateur ordinaire et sans avoir à préciser de mot de passe, cela signifiera que vous utilisez une version de distribution compilée avec
la directive -DUSE_POLKIT=true.
Cela signifiera également que
« les composants CLI seront inutilisables pour un compte utilisateur ordinaire.»
Autrement, identifié en root dans un terminal, l’usage de zuluCrypt-cli -M reste un mystère…
Mais, au fait, pouvez-vous faire en root et avec zuluCrypt-cli et zuluMount-cli
l’équivalent de ce que vous faites avec zuluCrypt-gui et zuluMount-gui ?
Ou juste créer et monter un volume par exemple.
Pour vérifier que les outils cli fonctionnent.
C’est une bonne nouvelle : votre problème est résolu
Je ne sais pas comment vous répondre ;
Poseriez-vous la même question vis-à-vis du branchement et du montage d’une clef USB ?
Regardez les droits d’accès au répertoire de montage primaire quand un volume y est monté.
De même pour le répertoire miroir public.
Votre sécurité quand vous êtes connecté au réseau Internet dépend de nombreux facteurs.
Par exemple :
Je vous invite à mettre à jour votre Debian en version 9.9
r2mi:
J’ai du mal à suivre votre raisonnement.
Que Debian utilise le manuel rédigé par l’auteur de zuluCrypt
n’est pas une surprise ni une anomalie.
Vous déclarez vous-même que Debian à modifié zuluCrypt. Mais Debian a-t-il modifié le manuel ?
merlind:
J’ai découvert l’équivalent GUI de l’opération cli -M, aussi bien dans zuluCrypt que zuluMount.
r2mi:
C’est une bonne nouvelle : votre problème est résolu
Pas tout à fait. Le sujet de la discussion c’est un message d’erreur qu’on suppose lié à un problème de syntaxe. Ou bien est-ce un problème de manuel ?
Il est certain que derrière cette fonction “Share (Partage) point de montage” de la GUI, il y a une ligne de commande qui fonctionne.
Il suffit donc de plonger dans le code source de Debian pour récupérer la syntaxe correcte (on va pouvoir la comparer à celle du manuel). Je ne suis pas compétent pour cette plongée! Y-a-t-il une âme sensible pour remonter cette ligne à la surface ?
merlind:
Ainsi, si j’ai fermé toutes les fenêtres (GdF, zuluCrypt,…) sous root, est-ce que les privilèges admi sont réellement protégés sachant que le point de montage primaire existe ? Serais-je en sécurité quand connecté au réseau Internet???
r2mi:
Regardez les droits du répertoire de montage primaire quand un volume y est monté.
De même pour le répertoire miroir public.
Poseriez-vous la même question vis-à-vis du branchement et du montage d’une clef USB ?
Je ne sais pas car je ne suis pas sûr de comprendre le rapport. Je parlais de la sécurité par rapport à l’exposition des privilèges administrateurs. Je ne doute pas que ces règles de permissions et privilèges soient utiles dans le cadre d’un ordinateur multi-utilisateurs (réseau d’entreprise), mais pour un ordinateur personnel c’est compliqué.
Je viens de constater que, dans une session administrateur, le prompt du terminal(…$) ouvert sur le Bureau indique que l’on est pas sous le compte root!? Il faut donner son mot de passe pour obtenir le terminal root. De plus, en session utilisateur simple, le répertoire partagé (point de montage secondaire public) s’ouvre par défaut dans le compte root!? Il faut passer par le GdF du compte utilisateur pour échapper au compte root.
J’ai remplacé mon compte utilisateur principal par un compte root et un compte utilisateur simple. Même sous ce dernier compte, le point de montage primaire se fait sous le compte root. Ainsi, avec cette version zuluCrypt modifiée par Debian, quelque soit le type de compte, le point de montage primaire se situe toujours sous le compte root.
Au final, je ne sais jamais si les droits administrateurs sont exposés ou non (à un éventuel attaquant sur le réseau), notamment en dehors du GdF, sur le Bureau et dans le navigateur.
r2mi:
Votre sécurité quand vous êtes connecté au réseau Internet dépend de plusieurs facteurs.
Oui, bien sûr, mais vu mon niveau débutant, même si je crois avoir un pare-feu bétonné, couplé avec un proxy local, et connecté à un VPN, ne serais-ce pas imprudent d’être connecté au réseau avec les privilèges root exposés ? Le problème c’est que je sais pas dans quels cas ces privilèges sont exposés. Je suggère que l’équipe Debian rajoute une petite icône qui alerterait l’utilisateur lorsque les privilèges root sont exposés. La bande jaune pour le Gdf c’est super, mais pourquoi pas rajouter une icône pour le bureau ? pour le navigateur ?
r2mi :
Mais, au fait, pouvez-vous faire en root et avec zuluCrypt-cli
l’équivalent de ce que vous faites avec zuluCrypt-gui ?
Pour la version : 5.0.2 rem@n40l:~$ man zuluCrypt-cli
LAST EDIT
Last change: Fri Jan 9 14:43:08 EAT 2015
Les manuels / docs sur le Net n’indiquent aucune sorte d’action pour l’opération -M
Quand cette opération est mentionnée.
Le composant CLI appelé par l’interface GUI fonctionne.
Allons bon !
Qu’est-ce que c’est que cette « exposition des privilèges administrateurs » que vous évoquez ?
Vous l’évoquez plusieurs fois ; expliquez-vous simplement svp et donnez un exemple. merci.
Vous avez probablement besoin d’explications sur la sécurité quand un gestionnaire de fichiers est lancé en root ou lorsque vous êtes identifié en root dans un terminal.
Une session administrateur étant encore autre chose (davantage une notion Windows)
Prévoyez un autre sujet.
Sous /run/media/private/ pour être exact.
C’est le principe.
La modification de ZuluCrypt est faite pour obtenir davantage de sécurité.
(en raison de la grande surface d’attaque de Qt)
Si vous activez le partage en cochant “Share”,
vous avez un accès ordinaire dans /run/media/public/
Ce qui vous permet de ne pas travailler en root sur le volume.
Que voulez-vous dire par « dans une session administrateur » dans ce cas ?
Autrement, c’est tout à fait normal d’avoir un terminal utilisateur ($) au lancement de celui-ci.
Ensuite, comment donnez-vous votre mot de passe pour obtenir une identification en root ?
Prévoyez un autre sujet.
C’est peut-être un défaut de ZuluCrypt mais vous lui avez fourni le mot de passe root pour ouvrir une GUI, donc il utilise cette identité pour ouvrir les dossiers.
Ouvrir le gestionnaire de fichiers avec votre utilisateur ordinaire est effectivement le contournement.
svp : utilisez GdF si vous le voulez mais ne confondez pas GdF, compte, répertoire ou user.
c’est difficile de lire et de répondre à des messages avec des approximations.
Même pas créer un fichier volume et le monter ?
C’est au point de se demander si les commandes cli fonctionnent dans un terminal root.
Il est mentionné qu’elles ne fonctionnent pas pour un utilisateur ordinaire… mais en root !!?
Version : 5.0.2
root@n40l:~# apt-get install zulucrypt-cli libzulucrypt-plugins
root@n40l:~# ls -l /usr/bin/zulu*
-rwxr-xr-x 1 root root 22520 déc. 15 2016 /usr/bin/zuluCrypt-cli
root@n40l:~# /usr/bin/zuluCrypt-cli --test
creating a testing image file
creating a testing image file
creating a testing image file
creating a keyfile
creating a keyfile
create a luks type volume using a key: PASSED
check if a luks volume is a luks volume: PASSED
create luks header backup: PASSED
restore luks header from backup: PASSED
create a plain type volume using a key: PASSED
create a tcrypt type volume using a key: PASSED
open a plain volume with a key: PASSED
closing a plain volume: PASSED
open a plain volume with a keyfile: PASSED
closing a plain volume: PASSED
open a tcrypt volume with a key: PASSED
closing a tcrypt volume: PASSED
open a plain volume using a plugin: PASSED
closing a plain volume: PASSED
open a luks volume with a key: PASSED
closing a luks volume: PASSED
open a luks volume with a keyfile: PASSED
closing a luks volume: PASSED
open a luks volume using a plugin: PASSED
closing a luks volume: PASSED
check key slots in use: 30000000
add a key to a luks volume using a key and a key: PASSED
add key to luks volume using keyfile and keyfile: PASSED
add key to luks volume using passphrase and keyfile: PASSED
add key to luks volume using keyfile and passphrase: PASSED
check key slots in use: 11111000
remove a key from a luks volume using a key: PASSED
remove a key from a luks volume using a keyfile: PASSED
check key slots in use: 01011000
check if there are no opened mappers: PASSED
root@n40l:~#
root@n40l:~/zulu# dd if=/dev/zero of=./zulu.img bs=1M count=100
root@n40l:~/zulu# zuluCrypt-cli -c -d ./zulu.img -z ext4 -t luks -p phrasedepasse
This operation will destroy all data in a device at: "/dev/loop0"
Are you sure you want to proceed?
Type "YES" and press enter if you want to process: ^C
root@n40l:~/zulu#
Pas trop rassuré là…
Type "YES" and press enter if you want to process: YES
SUCCESS: Volume created successfully
Creating a backup of the "luks" volume header is strongly advised.
Please read documentation on why this is important
root@n40l:~/zulu#
root@n40l:~/zulu# mount | grep zulu
/dev/mapper/zuluCrypt-0-NAAN-zulu.img-3143345365 on /run/media/private/root/zulu100M type ext4 (rw,nosuid,nodev,relatime,data=ordered)
Pas moyen de lui demander un zuluCrypt-cli -M ; à n’importe quelle sauce !
Ça marche mieux avec le -M placé au début de la commande d’ouverture du volume !
root@n40l:~/zulu# mount | grep zulu
/dev/mapper/zuluCrypt-0-NAAN-zulu.img-664931794 on /run/media/private/root/zulu100M type ext4 (rw,nosuid,nodev,relatime,data=ordered)
/dev/mapper/zuluCrypt-0-NAAN-zulu.img-664931794 on /run/media/public/zulu100M type ext4 (rw,nosuid,nodev,relatime,data=ordered)
root@n40l:~/zulu#
rem@n40l:~$ ls /run/media/public/zulu100M/ -al
total 13
drwxrwxrwx 3 root root 1024 mai 10 07:50 .
drwxr-xr-x 3 root root 60 mai 10 08:18 ..
drwx------ 2 root root 12288 mai 10 07:50 lost+found
rem@n40l:~$
Résolu.
Et donc, oui, tu as raison @dindoun : cette fonction peut créer des centaines de liens.
-m path component to be added to mount point prefix
Ce n’est pas le cas apparemment ; du moins pas encore.
ÉDITION
J’ai réussi à faire fonctionner zuluCrypt-cli en simple utilisateur dans un terminal.
Avec une modification Setuid (https://fr.wikipedia.org/wiki/Setuid).
N’ayant installé que les paquets zulucrypt-cli et libzulucrypt-plugins
Je pense que avec cette configuration sans paquet GUI, Il n’y a pas de problème de sécurité lié à Qt.
DONNÉ SANS GARANTIE AUCUNE, VOUS UTILISEZ CECI À VOS PROPRES RISQUES ET PÉRILS
root@n40l:~# ls -l /usr/bin/zuluCrypt-cli
-rwxr-xr-x 1 root root 22520 déc. 15 2016 /usr/bin/zuluCrypt-cli
root@n40l:~# chmod ug+s /usr/bin/zuluCrypt-cli
root@n40l:~# ls -l /usr/bin/zuluCrypt-cli
-rwsr-sr-x 1 root root 22520 déc. 15 2016 /usr/bin/zuluCrypt-cli
root@n40l:~# exit
exit
rem@n40l:~/zulu$ zuluCrypt-cli -M -o -d ./zulu.img -m zulu100M -e rw -p phrasedepasse
SUCCESS: luks volume opened successfully
volume mounted at: /run/media/private/rem/zulu100M
rem@n40l:~/zulu$ mount | grep zulu
/dev/mapper/zuluCrypt-1000-NAAN-zulu.img-664931794 on /run/media/private/rem/zulu100M type ext4 (rw,nosuid,nodev,relatime,data=ordered)
/dev/mapper/zuluCrypt-1000-NAAN-zulu.img-664931794 on /run/media/public/zulu100M type ext4 (rw,nosuid,nodev,relatime,data=ordered)
rem@n40l:~/zulu$ zuluCrypt-cli -q -d ./zulu.img
SUCCESS: volume closed successfully
rem@n40l:~/zulu$ mount | grep zulu
rem@n40l:~/zulu$
Merçi à r2mi pour son aide. Je n’ai pas encore réussi à ouvrir mes volumes chiffrés en mode CLI, mais cette fois ce n’est pas un problème de syntaxe, c’est plutôt un problème de permission (disque non reconnu ou chemin invalide ou accès non-autorisé). Il y a du progrès !
Finalement, sur lignux, il y a pire que la CLI : les problèmes de permissions, privilèges, type de compte, propriétaires, groupes, sudo, setuid,…et j’en oublis sûrment. C’est infernal.
Néanmoins, cette discussion est close, les questions en suspend seront abordées dans d’autres discussions. A bientôt.
