[Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

Qid · Le 15/11/2022, à 07:15

iznobe a écrit :

il me semble qu ' on avit deja vu passer un cas similaire ( si ce n' est pas exactement identique ) et qui est resolu il ya quelques mois en arriere .

Ah bah ce serait bien de pouvoir remettre la main dessus tien...

iznobe · Le 15/11/2022, à 07:18

c ' est sur , mais tu as deja essayé de rechercher un post relativement ancien dont tu ne te rapelles plus dans quelle categorie du forum il a été posté , ni son titre ...
je pense y avoir participer , cela dit ca fait une paire de page a afficher et a chercher dedans sans info en relation directe avec ce post dont je serais certain , je me vois mal y passer des heures .
c' est d' ailleurs dans cette fameuse discussion ( ou Ceour Noir etait aussi intervenu si mes souvenirs sont bons ) , qu ' en fait il etait question d' un parametres de l' interface graphique : cf mes tout 1er messages .

Dernière modification par iznobe (Le 15/11/2022, à 07:20)

Qid · Le 15/11/2022, à 07:21

iznobe a écrit :

c ' est sur , mais tu as deja essayé de rechercher un post relativement ancien dont tu ne te rapelles plus dans quelle categorie du forum il a été posté , ni son titre ...
je pense y avoir participer , cela dit ca fait une paire de page a afficher et a chercher dedans

Je sais oui... Passe peut-être par le lien "voir les messages de cet utilisateur" auquel on a accès sur notre propre profil aussi... ça peut aider... Bon courage...

Coeur Noir · Le 15/11/2022, à 14:05

Iznobe a écrit :

@Coeur noir : lsblk ne permet pas de voir les partitions montées ( mais toutes )

C'est justement parce qu'elle permet de voir toutes les partitions - les montées comme les pas montées - qu'elle est pertinente : elle donne une « photo » de tout le contexte, avec les noms / labels / uuid des périphériques, les points de montage éventuels, etc.
En montrant ça depuis chaque OS, on saura quelle(s) partition(s) voire disque(s) on veut éviter de voir dans l'un ou l'autre - ce qui est l'objet initial de la discussion.

Resterait plus qu'à créer dans chaque OS une règle udev adéquate, pour « planquer » tel ou tel périphérique. Mon problème : je ne sais pas comment on fabrique une telle règle udev or la solution est là.

Qid · Le 15/11/2022, à 14:15

Coeur Noir a écrit :

Resterait plus qu'à créer dans chaque OS une règle udev adéquate, pour « planquer » tel ou tel périphérique. Mon problème : je ne sais pas comment on fabrique une telle règle udev or la solution est là.

mouais... ça ressemble tout autant à une rustine bien moche vis à vis du souci présenté mais j'avoue préférer celle-ci à celle du fstab... tu voudrais pas quand même essayer de retrouver la même piste que celle à laquelle fait allusion iznobe

Coeur Noir · Le 15/11/2022, à 14:25

Rustine, rustine… c'est une règle udev pour un cas précis, c'est exactement à ça que peut servir une règle udev non ?

Chercher dans le forum / chercher dans ses propres messages → sur ce forum d'un autre siècle sans tag, sans permalink ou backlink, sans hébergement d'images, c'est juste a huge pain in the ass…

Qid · Le 15/11/2022, à 14:30

Coeur Noir a écrit :

Chercher dans le forum / chercher dans ses propres messages → sur ce forum d'un autre siècle sans tag, sans permalink ou backlink, sans hébergement d'images, c'est juste a huge pain in the ass…

lol... enfin c'est quand même bien dommage parce que l'intérêt d'un forum c'est de pouvoir chercher dedans si une question a déjà été posée... et surtout quant on a participer à sa résolution sa devrait être encore plus facile... mais c'est sûr que pour ubuntu-fr... je reconnais que c'est compliqué si ce n'est impossible...

Arbiel · Le 15/11/2022, à 14:51

Il me semble que chercher comment interdire dans fstab le montage de telle ou telle partition est une fausse piste.

Une partition ne peut être montée que par une commande de montage, soit implicitement par fstab, soit explicitement.

L'interdiction dans fstab n'aura aucun effet si par la suite une commande explicite de montage est exécutée. À mon humble avis, une telle commande est présente quelque part, et il faut la trouver pour la supprimer. Personnellement, je ne vois comme possibilité que sa présence dans un script ou une application lancé automatiquement au démarrage, d'où l'idée que j'ai précédemment présentée.

Mais il peut y avoir d'autres possibilités qui m'échappent. Quelles sont-elles ?

Arbiel

Dernière modification par Arbiel (Le 15/11/2022, à 14:52)

iznobe · Le 15/11/2022, à 14:59

+1 avec Arbiel . j ' ai dis quasimment la meme chose precedemment et je persiste .

Qid · Le 15/11/2022, à 15:12

iznobe a écrit :

+1 avec Arbiel . j ' ai dis quasimment la meme chose precedemment et je persiste .

à 3 on devrait pouvoir être entendu... enfin là moi je ne vais pouvoir que soutenir car techniquement je n'ai pas les compétences pour dire quoi faire exactement... je continue à suivre en tous cas...

stephweb · Le 15/11/2022, à 15:58

Merci à tous pour vos réponses.

Mais je me rends compte que de créer 2 partition avec 2 Ubuntu, que ça ne m'améliore pas de beaucoup ma sécurité.

Tant pis.

geole · Le 15/11/2022, à 16:58

Bonsoir.
Il aurait fallu que tu installes un ubuntu chiffré. L'autre n'aurait pas pu y accéder sauf à connaitre la phrase magique. Cela a été dit à l'échange N° 19

Dernière modification par geole (Le 15/11/2022, à 17:04)

stephweb · Le 15/11/2022, à 17:05

geole a écrit :

Bonsoir.
Il aurait fallu que tu installes un ubuntu chiffré. L'autre n'aurait pas pu y accéder sauf à connaitre la phrase magique. Cela a été dit à l'échange N°

Hello

Mais on peut installer un Ubuntu (entierement) chiffré uniquement si on installe un seul Ubuntu sur son disque SSD.

Je peux toujorus chiffrer le home du Ubuntu que je veux sécuriser, mais en vrai ça ne rajoute pas une grosse sécurité... car le reste de l'OS ne sera pas chiffrée et sera accéssible depuis l'autre Ubuntu.

Qid · Le 15/11/2022, à 17:08

stephweb a écrit :

je me rends compte que de créer 2 partition avec 2 Ubuntu, que ça ne m'améliore pas de beaucoup ma sécurité.

C'est sûr que comme je l'ai dit c'est vraiment se complexifier la vie pour un bénéfice tout relatif pour ne pas dire illusoire...

geole · Le 15/11/2022, à 17:22

stephweb a écrit :

geole a écrit :
Bonsoir.
Il aurait fallu que tu installes un ubuntu chiffré. L'autre n'aurait pas pu y accéder sauf à connaitre la phrase magique. Cela a été dit à l'échange N°19
Hello
Mais on peut installer un Ubuntu (entierement) chiffré uniquement si on installe un seul Ubuntu sur son disque SSD.

Oui si tu veux utiliser le partitionnement ZFS
Non si tu utilises le partitionnent EXT4 et une installation par le choix "autre chose".
Il te faut une partition chiffrée qui est alors assimilée à un disque.
Tu auras un piège. Si après tu installes d'autres O.S. tu perdras la possibilité de le booter sauf si pense à faire une partition de boot dans un espace non chiffré.
===> https://forum.ubuntu-fr.org/viewtopic.php?id=2075611
https://forum.ubuntu-fr.org/viewtopic.php?id=2075001

Dernière modification par geole (Le 15/11/2022, à 17:40)

Arbiel · Le 15/11/2022, à 17:58

Quelques précisions

MicP a écrit :

Comme je le fais souvent remarquer, seul un système de fichiers peut être monté => on ne peut pas monter un disque, ni une clef USB, ni une carte SD ou µSD, ni une partition, ni quoi que ce soit d'autre qu'un système de fichiers.

Non, on peut monter des répertoires, des fichiers sur des répertoires ou des fichiers avec l'option bind
Si on monte un support sur un point de montage (malgré ce que l'on lit souvent, un objet ne devient point de montage que lorsque l'on monte quelque chose dessus), on masque le contenu qui était précédemment monté, contenu que l'on récupère au démontage.

stephweb a écrit :

Mais on peut installer un Ubuntu (entierement) chiffré uniquement si on installe un seul Ubuntu sur son disque SSD.

On peut en installer autant que l'on veut.

stephweb a écrit :

Je peux toujorus chiffrer le home du Ubuntu que je veux sécuriser, mais en vrai ça ne rajoute pas une grosse sécurité... car le reste de l'OS ne sera pas chiffrée et sera accéssible depuis l'autre Ubuntu.

On peut chiffrer ce que l'on veut, en bloc ou en autant de partitions ou de volumes logiques (LVM) que nécessaire. Le chiffrement de la racine n'apporte pas grand chose car il n'y a rien de confidentiel là dedans, sauf peut-être /etc/fstab, /etc/crypttab ou d'autres fichiers de /etc si l'on veut masquer l'organisation de son système. /etc ne peut pas être extrait de la racine.
Les données sensibles que l'on veut rendre invisibles peuvent bien évidemment être chiffrées sur des contenants distincts de sorte que la nécessité d'accéder momentanément à certaines d'entre elles n'implique pas l'ouverture (au sens de cryptsetup) de l'ensemble de ces données.

La deuxième instance d'Ubuntu n'apporte rien, et tu peux définir de nouvelles partitions que tu chiffreras et dans lesquelles tu enresgistreras tes données avec la répartition qui conviendra à l'analyse que tu as faite de tes besoins. Tu pourras ensuite la supprimer.

Tu as maintenant suffisamment d'informations pour te sortir de manière autonome de ton problème.

Arbiel

Dernière modification par Arbiel (Le 15/11/2022, à 18:01)

Coeur Noir · Le 16/11/2022, à 02:48

Parce que proposer du chiffrement, vous trouvez ça bien ? Sans risques ? Confortable ? Facile à long terme ?
…alors qu'une pauvre règle udev d'une ligne dans chaque OS suffirait à « invisibiliser / empêcher » l'accès à un périphérique ( par ex. ici, une partition ) ?
Mais bon, on peut adopter une autre stratégie et jouer avec l'aspect foncièrement multi-utilisateurs de Linux aussi…

je me rends compte que de créer 2 partition avec 2 Ubuntu, que ça ne m'améliore pas de beaucoup ma sécurité
C'est sûr que comme je l'ai dit c'est vraiment se complexifier la vie pour un bénéfice tout relatif pour ne pas dire illusoire...

Et tu fais comment - quand tu veux installer 2 OS - pour ne pas avoir au moins une partition pour chaque ?

Le chiffrement c'est se compliquer la vie pour un bénéfice très relatif mais un risque très certain de perdre l'accès aux données chiffrées un jour ou l'autre…
…ne me faites pas dire ce que je ne dis pas : le chiffrement a ses cas d'usage mais requiert aussi des précautions. Et impose de maîtriser « les fondamentaux » du système où on l'emploie.

Il faudrait préciser ce fumeux besoin de « sécurité » : je suppose qu'il s'agit que les utilisateurs du système A n'accèdent pas aux données des utilisateurs du système B ?
Il suffira que tous les utilisateurs ne soient surtout pas de type administrateur, mais des comptes utilisateurs normaux ( sans accès à sudo ).
Donner aux humains du système A des uid qui n'existent pas dans le système B ( dans l'un on aura par ex. des uid 1100, 1101, 1102 ; dans l'autre des uid 1200, 1201, 1202, etc. )
Seul le premier utilisateur créé dans chaque système garde ses uid et gid initiaux : 1000 et 1000 et seul celui-là est de type administrateur ( avec accès sudo ) → seul lui a complètement accès aux 2 systèmes, avec potentiellement les pleins pouvoirs de root.
Voire mettre les utilisateurs humains du système A dans un groupe avec un certain gid ( gid qui n'existe pas dans le système B ) - et vice versa.

Bref, jouer avec les droits~permissions et type de comptes, ça peut déjà cloisonner bien des choses, et c'est nativement géré par le système de fichiers.

Dans ce cas on peut même monter volontairement et automatiquement dans chaque OS la partition de l'autre OS :
⋅ seul l'utilisateur administrateur d'uid 1000 peut faire ce qu'il veut de part et d'autre, et peut travailler indifféremment dans les 2 $HOME appartenant à l'uid 1000 sans besoin de sudo ;
⋅ tandis que les utilisateurs normaux ont accès aux éléments correspondants à leur uid et sans pouvoir d'administration nulle part.

C'est pas assez comme "sécurité" ?
____________________

⋅ un objet ne devient point de montage que lorsque l'on monte quelque chose dessus dedans
⋅ /etc ne peut pas être extrait de la racine → qu'entends-tu par extraire ? Est-ce que quelque chose empêche de monter dans ce dossier /etc de la racine d'un système, des éléments provenant d'un autre système de fichiers, depuis une autre partition ? Ça m'a l'air faisable lors de l'installation de l'OS.
____________________

@stephweb
La situation de base :
Lorsque je boot sur un des deux Kubuntu, j'ai aussi la partition de l'autre Kubuntu qui est autolmatiquement montée. Et je souhaite empêcher ce montage automatique
La surprise est là : « l'autre » partition n'est pas censée monter automatiquement.
Il faudrait comprendre pourquoi ça arrive dans un cas et pas dans l'autre. Une astuce dans le Dolphin de la 22.04 ? Des manip's un peu différentes lors de l'installation de l'un puis l'autre OS ?

On manque de contexte « concret » ; on manque aussi d'objectifs opérationnels précis ( la "sécurité" ça ne veut rien dire en soi ) ; du coup cette discussion est partie un peu dans tous les sens.

Si tu es toujours dans la même situation, les retours juste après démarrage de

cat /etc/fstab
lsblk -fe7,11 -o +size,model
# ou
mount -l | grep nvme

depuis l'un ET l'autre OS permettraient de comparer et trouver d'éventuelles différences ?
Et entre autre voir où monte cette fameuse partition non désirée… ça donnerait un indice sur quel mécanisme la monte.

Sachant que comme évoqué ci-dessus, on peut gérer finement qui a accès à quoi, où, avec les propriétés basiques et fondamentales d'un système de fichiers Linux.
Donc finalement le fait que la partition d'un syst. A soit visible depuis un syst. B ( et vice-versa ) n'a que peu d'importance : ce qui importe c'est à qui les données dans telle partition accordent des droits.
Et chaque élément ( fichier, dossier ) de données dans une partition porte en lui-même ces droits~permissions : un élément X peut se rendre visible à tous, mais modifiable seulement à tel utilisateur, un élément Y peut se rendre invisible à tous sauf à un utilisateur en particulier, ou à un groupe d'utilisateurs, et bien d'autres combinaisons…

Dernière modification par Coeur Noir (Le 16/11/2022, à 04:57)

Qid · Le 16/11/2022, à 07:07

(je suis désolé si je vais paraître désagréable dans mes propos pour le demandeur)

Il faudrait préciser ce fumeux besoin de « sécurité » : je suppose qu'il s'agit que les utilisateurs du système A n'accèdent pas aux données des utilisateurs du système B ?

J'adore ta réplique... Mais non de ce que je me souviens du cas (j'ai pas relu la demande initiale) c'est effectivement encore plus tordu : il n'est pas seulement question d'utilisateur humain... Il est question de système au sens large (oui on est pas loin d'une parano)... Et du coup la meilleure solution c'est encore d'avoir 2 machines physiquement différentes et sur 2 réseaux physiquement différents aussi car il ne faut pas oublier qu'une machine infectée dans un réseau est susceptible d'infecter les autres...

Après pour tenter d'adoucir mes propos faudrait quand-même rappeler que la base c'est avant tout de ne pas faire et laisser n'importe quelle trace sur internet qui serait susceptible d'attirer les foudres...

stephweb · Le 16/11/2022, à 08:16

Coeur Noir a écrit :

Il faudrait préciser ce fumeux besoin de « sécurité » : je suppose qu'il s'agit que les utilisateurs du système A n'accèdent pas aux données des utilisateurs du système B ?

Non, je suis (et restera) le seul user de ce PC.

C'est parce que je vais (en travaillant pour un client) utiliser des logiciels auxquels je n'ai pas confience. Et si je chope un truc (virus ou autre), je ne veux pas que mon OS que lequel j'aurai des données "sensibles" soit pententielement vulnérable

Coeur Noir a écrit :

Il faudrait comprendre pourquoi ça arrive dans un cas et pas dans l'autre. Une astuce dans le Dolphin de la 22.04 ? Des manip's un peu différentes lors de l'installation de l'un puis l'autre OS ?

Je viens d'installer 2 Kubuntu 22.04. Maintenant, peut importe sur la partition sur laquelle je boot, l'autre aussi est automatiquement montée.

Dernière modification par stephweb (Le 16/11/2022, à 08:20)

Qid · Le 16/11/2022, à 08:57

stephweb a écrit :

Je viens d'installer 2 Kubuntu 22.04. Maintenant, peut importe sur la partition sur laquelle je boot, l'autre aussi est automatiquement montée.

Non... Ce n'est pas crédible... Dixit la fin de ma première intervention au post 8... Pour moi on en est toujours à ce stade de la confusion entre visible et accessible...

Quant au besoin tu ne serais pas mieux en machine virtuelle suivant ce pourquoi tu travailles avec ce client en qui par extension tu n'as pas confiance ? Là au moins tu seras sûr que ta machine virtuelle n'accèdera pas à ton système hôte... L'inverse est potentiellement moins vrai mais faut pas pousser... Sinon à un moment c'est bien l'interface chaise clavier qu'il faudra remettre en cause...

stephweb · Le 16/11/2022, à 09:08

Qid a écrit :

stephweb a écrit :
Je viens d'installer 2 Kubuntu 22.04. Maintenant, peut importe sur la partition sur laquelle je boot, l'autre aussi est automatiquement montée.
Pour moi on en est toujours à ce stade de la confusion entre visible et accessible...

Elle est visible, et aussi montée.
J'ai fais des tests avec "lsblk", et aussi dans KDE, j'ai l'option "Unmout"

Dernière modification par stephweb (Le 16/11/2022, à 09:09)

geole · Le 16/11/2022, à 10:15

Bonjour.
Comme déjà demandé, il faudrait que tu postes les commandes suivantes et leurs retours.

grep -v "#" /etc/fstab

sudo mount

lsblk -fe7

Normalement les partitions ext4 ne se montent pas automatiquement même si elles sont externes. En revanche, elles sont proposées au montage.
Je serais surpris que la version Kubuntu 22.04 ait un compormement différant des autres.

Coeur Noir · Le 16/11/2022, à 18:38

@stephweb
on est plusieurs à te demander des retours de commandes - et grosso modo les mêmes - afin d'y voir plus clair, lever les confusions.
Tant que tu ne donnes pas ces retours de commande, on parle dans le vide et on est aveugle. On ne t'aide pas, on ne fait qu'émettre des hypothèses tous azimuts sans certitude sur le contexte et les besoins.
Donc tu démarres sur un de tes OS, tu ouvres ta session et sans rien faire d'autre ( tu ne lances rien, tu ne touches à rien, tu n'ouvres pas ton explorateur de fichiers, rien, que dalle, nada )
tu ouvres seulement un terminal où tu lances les commandes suggérées, dont tu copies le résultat ici dans ton message entre balises code.
Important et crucial, tu quittes cet OS puis tu fais exactement la même chose depuis l'autre OS : l'idée c'est qu'on puisse comparer les retours dans les 2 contextes.

Non, je suis (et restera) le seul user de ce PC.

Et ? Ça ne signifie surtout pas qu'il doit y avoir seulement une seule session dans le système ;-)

Figure-toi qu'un système Linux ( même sans utilisateur humain enregistré ) compte déjà de nombreux utilisateurs et groupes. Les éléments du système appartiennent à ces divers utilisateurs et groupes et portent des droits divers à leur attention. Cette organisation en termes de propriétaires et droits détermine dans le système qui a le droit de faire quoi et où. Parmi tous ces utilisateurs, il n'y en a qu'un qui peut toujours tout faire : l'utilisateur d'uid 0 appelé root ( le Super-Utilisateur ) qui est responsable du lancement de l'ensemble du système. L'accès à cet utilisateur tout puissant, privilégié, est par conséquent protégé : en tant qu'humain on n'a jamais besoin de prendre les droits de root, sous ×buntu ( et autres distributions ) on ne le fait que temporairement via des mécanismes qui vérifient la légitimité de l'accès à root : par ex. la commande sudo qui n'est accessible qu'à des utilisateurs dont le compte est de type administrateur ; un utilisateur dont le compte est de type normal n'a pas accès aux pouvoirs de root via sudo. Il est donc vital et obligatoire de ne jamais informer les utilisateurs de type « normal » du mot de passe de l'utilisateur de type « administrateur ». Seul l'humain administrateur légitime du système doit connaître un tel mot de passe.

Donc afin d'obtenir une organisation optimale de ton système - pour toi le seul humain qui t'en sers - je te recommande fortement d'y créer plusieurs sessions utilisateur « thématiques » :
⋅ une session de type administrateur nommée steph : celle là te sert essentiellement à gérer ton système, installer/supprimer des logiciels, paramétrer ci ou ça, régler les droits et permissions des autres sessions/utilisateurs… cette session là, tu t'en sers peu et tu la transformes peu, tu la laisses plus ou moins comme neuve, comme elle est par défaut ;
⋅ une session de type normal nommée par exemple maison pour tes activités quotidiennes, hors boulot, tes trucs perso' et celle-là tu la personnalises autant que tu veux, à ta convenance ;
⋅ une ( autre ) session de type normal nommée par ex. travail que tu personnalises en fonction de tes besoins professionnels ;
⋅ encore une autre, toujours de type normal nommée par ex. extra que tu utiliseras pour des activités qui ne concernent pas maison mais en rapport avec travail.

Une fois ces sessions en place, par le jeu des droits, permissions, utilisateurs et groupes c'est plutôt simple de séparer ou partager les données entre ces sessions :
⋅ ajoute l'utilisateur maison aux groupes travail et extra → maison aura accès en lecture aux $HOME de travail et extra ;
⋅ ajoute l'utilisateur travail au groupe extra, ajoute le droit d'écriture pour le groupe sur le $HOME ( + son contenu ) de extra, ajoute le droit spécial de groupe ( bit sgid ) à tous les dossiers du $HOME de extra
→ l'utilisateur travail a accès en lecture + écriture au $HOME de extra ;
⋅ sans rien faire d'autre :
→ extra ne voit pas les $HOME de travail et maison ;
→ travail ne voit pas le $HOME de maison ;
→ maison voit les $HOME de travail et extra mais ne peut pas y écrire ( mais maison peut copier des éléments depuis ces autres $HOME pour les coller chez lui ) ;
→ steph ne voit que son $HOME mais il est le seul compte de type administrateur : lui, en prenant temporairement les droits root via sudo, peut tout faire n'importe où.

[ repère si vous venez du message #82 ]

Tu noteras aussi que depuis les sessions de type normal, les utilitaires graphiques d'administration te permettront de sélectionner l'utilisateur steph ( l'administrateur ) quand ils requièrent le mot de passe. Mot de passe que toi seul dois connaître. Donc même quand tu es dans les sessions de type « normal » tu n'es pas complètement dénué de pouvoirs administrateurs ( pour installer des logiciels par ex. ) Par contre dans un terminal depuis les sessions maison, travail ou extra, ces utilisateurs là n'ont pas accès à la commande sudo - mais c'est aussi possible de changer d'utilisateur « dans » le terminal, si besoin.

Bref, ça c'est déjà une bonne base d'organisation des données bien préférable à une session unique, fourre-tout, qui plus est administrative.
En faisant cela, tu ranges séparément et automatiquement les infos utilisateurs ( sessions, thématiques ) dans leurs $HOME respectifs.
Au pire des cas, en cas de problème quelconque, ça n'impactera qu'une session, et tu auras toujours les autres à côté pour enquêter, diagnostiquer, réparer.

Ensuite, puisqu'il s'agit d'organiser les données afin de les mettre à l'abri d'éventuels accidents côté système, il s'agit donc de stocker les données visibles du ou des utilisateurs ailleurs que dans la racine du système.
Une racine système ça tient sur 40~50Go ( quand on n'y stocke pas les documents~médias des utilisateurs ) on peut donc créer une autre partition bien plus grande sur ce qui reste du support et l'organiser en conséquence :
⋅ y créer un répertoire ( et une corbeille ) appartenant à chaque utilisateur potentiel du ou des systèmes ;
⋅ dans lequel chaque utilisateur potentiel trouvera ses dossiers par défaut usuels ( Bureau, Documents, Images, Modèles, Musique, Public, Téléchargements, Vidéos ).
⋅ depuis les $HOME du ou des divers utilisateurs, il s'agit alors de créer des liens symboliques qui ciblent les dossiers utiles dans la grosse partition.

Enfin, si ton travail consiste à fabriquer des logiciels qui requièrent ou impactent profondément le fonctionnement du système, là il faut que tu ajoutes une autre stratégie, déjà évoquée : des machines virtuelles.
Dans ces systèmes virtuels ( lancés grosso-merdo comme s'il s'agissait d'une application ) tu modifies tout ce que tu veux, sans impact sur le système hôte sous-jacent, installé en dur.

Le chiffrement de données - si tu veux vraiment passer par là - n'aura qu'un seul intérêt : si on te vole cette machine éteinte OU si un individu indésiré accède physiquement à cette machine éteinte, sans la passphrase adéquate il ne saura pas déchiffrer les données. Sans chiffrement, quelqu'un avec un accès physique à ta machine et un accès au bios pourra toujours tenter d'y démarrer un système en live-session - on peut aussi un peu verrouiller le bios avec un mot de passe.

Cela dit ne pas oublier que plus on tente de verrouiller l'accès à des données, plus on prend aussi le risque de s'en exclure soi-même : ooops je ne me souviens plus de ma passphrase de chiffrement… ooops je ne me souviens plus du mot de passe de mon bios… oooops il y avait un bug de sécurité critique dans la méthode de chiffrement que j'ai utilisée… ooops quelqu'un a regardé par dessus mon épaule ( au sens propre comme au figuré… )
Il y a bien d'autres aspects plus simples à gérer concernant la "sécurité" avant de se lancer dans le chiffrement.

Dernière modification par Coeur Noir (Le 17/11/2022, à 23:27)

Qid · Le 16/11/2022, à 20:38

Ouais alors par contre niveau fonctionnement pour moi ça change pas grand chose niveau complexité inutile d'avoir plusieurs users sur un unique système plutôt que plusieurs systèmes...

Coeur Noir · Le 16/11/2022, à 23:06

Zéro contre-argument, as-tu au moins lu ce que je propose ?
Moi j'ai tendance à organiser comme ça mes données et mes systèmes, ça n'est jamais qu'une possibilité parmi d'autres qui me semble coller au contexte de stephweb…

Que proposes-tu comme alternative ?

HS

plusieurs users sur un unique système plutôt que plusieurs systèmes...

Tu as de facto et en permanence plusieurs utilisateurs dans un système Linux - c'est la base même de son fonctionnement.
Donc ça ne change rien et ça n'ajoute pas de complexité, c'est juste le fonctionnement basique de l'OS.

Créer des sessions « thématiques » distinctes ( ou gérer plusieurs « humains » distincts, c'est pareil ) c'est une tranquillité opérationnelle et facile à long terme, qui permet de ne pas mettre tous les œufs dans le même panier, à bien des égards. Et ça ( ne pas mettre tous les œufs… ) c'est le moindre préalable à la tentative de sécuriser des données : les ranger dans des endroits opportuns, qui accordent des accès à l'utilisateur ( ou aux utilisateurs ) concerné(s).
C'est techniquement, factuellement vrai qu'il y ait un(e) ou plusieurs « humains / sessions thématiques ».

C'est facile parce que c'est complètement intégré au système, nativement, dans son adn, ça fait appel à des notions communes à tous les systèmes Linux, pas besoin d'aller chercher quoi que ce soit d'autre : c'est les droits et permissions.

C'est en fourrant tout dans une seule session ( des activités et des données qu'on veut « séparer » les unes des autres ) qu'on se complique la vie et qu'on met en péril les données…
…c'est enfantin de passer d'une session à l'autre, et de pouvoir travailler sereinement dans l'une sans avoir à se soucier de ce qui se passe dans l'autre.
C'est faisable depuis n'importe quel env. de bureau. Et ça n'a rien de spécifique à un env. de bureau ou à une distribution puisque ça relève du fonctionnement fondamental de l'OS Linux.

Cette tranquillité du chacun chez soi ( en tant que thème ou personne ) est impossible à garantir dans un système où il n'y aurait qu'une seule session fourre-tout.
Session fourre-tout ET potentiellement administrative, capable de péter tout et n'importe quoi.

Tu as raison sur un truc : il n'y a pas besoin d'installer 2 OS pour obtenir cette « séparation » rassurante, un seul peut suffire, ce qui compte c'est la gestion des utilisateurs~sessions ( les envisager en tant que personnes ou thèmes, ça dépend du contexte de l'administrateur : ici une approche thématique fait sens puisque stephweb a précisé qu'il est le seul humain à se servir du pc, à priori. )

D'où aussi l'intérêt de stocker ailleurs que dans la ( ou les ) racine(s) système les données visibles des utilisateurs : ça n'interdit pas d'avoir moult OS, sans besoin de dupliquer les données utilisateur visibles ( les cachées restent dans les $HOME de chaque utilisateur ET dans leurs OS respectifs, depuis chaque OS ou utilisateur on crée des liens symboliques vers les visibles ) ; ça permet d'isoler les données utilisateurs et de les préserver, sauvegarder, ré-employer bien plus facilement.

Bref, c'est faire de l'administration système, avec les outils natifs proposés par l'OS et c'est un sujet qui est généralement peu voire mal abordé dans le forum et la doc'.

Par contre pour conseiller le chiffrement, y'a toujours quelqu'un alors que c'est une pratique aussi risquée qu'exigeante, qui au quotidien complique terriblement la vie pour un bénéfice extrêmement rare.

Si tu veux qu'on en débatte, on ouvre un autre fil de discussion mais pas ici, où on aimerait bien que stephweb nous aide à l'aider, avec les retours de commande suggérés par les uns et les autres.

Fin HS

Dernière modification par Coeur Noir (Le 17/11/2022, à 01:23)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 15/11/2022, à 07:15

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#52 Le 15/11/2022, à 07:18

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#53 Le 15/11/2022, à 07:21

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#54 Le 15/11/2022, à 14:05

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#55 Le 15/11/2022, à 14:15

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#56 Le 15/11/2022, à 14:25

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#57 Le 15/11/2022, à 14:30

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#58 Le 15/11/2022, à 14:51

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#59 Le 15/11/2022, à 14:59

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#60 Le 15/11/2022, à 15:12

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#61 Le 15/11/2022, à 15:58

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#62 Le 15/11/2022, à 16:58

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#63 Le 15/11/2022, à 17:05

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#64 Le 15/11/2022, à 17:08

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#65 Le 15/11/2022, à 17:22

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#66 Le 15/11/2022, à 17:58

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#67 Le 16/11/2022, à 02:48

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#68 Le 16/11/2022, à 07:07

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#69 Le 16/11/2022, à 08:16

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#70 Le 16/11/2022, à 08:57

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#71 Le 16/11/2022, à 09:08

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#72 Le 16/11/2022, à 10:15

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#73 Le 16/11/2022, à 18:38

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#74 Le 16/11/2022, à 20:38

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

#75 Le 16/11/2022, à 23:06

Re : [Résolu] Install 2 Linux, empêcher l'autre Linux d'être automatique...

Pied de page des forums