Re-bonjour à la communauté,
Je vais installer linux mint (version basée sur ubuntu) ou debian13 trixie emmabuntus (sans ubuntu) pour les besoins d’une autre personne. Il va falloir appliquer une politique de sécurité personnalisée, pour ce compte local (sans privilèges).
L’objectif est interdire (mot de passe administratrice(teur) requis) les actions suivantes :
• ajout de quelconque application, programme (j'avais pensé à une solution bis par blocage de certaines extensions de fichier)
• désinstaller les quelques applications déjà présentes
• modifier le jeu d’icônes et le curseur
• désactiver les mises à jour automatiques (applications et système)
Ce compte local sera utilisé par une personne ayant des besoins très basiques (que navigateur internet et client mail) et n'est pas (aucune attention pour le sujet) au fait des problématiques de cybersécurité… d'où cette politique de sécurité personnalisée.
Ces règles sont-elles possibles ? Si oui quelle(s) méthode(s) seraient recommandées ?
Vous remerciant de votre attention, et bonne année
# Ajout d'applications
Posté par shuihuzhuan . Évalué à 1 (+0/-0).
Par "interdire l'ajout d'application", tu penses aux applications exécutées dans son répertoire home? Un montage du home avec l'option noexec peut aider mais ne fera pas tout (des interpréteurs type python sont installés sur le système).
Pour les extensions, cela ne marche pas comme cela sur linux.
# linux vs windows
Posté par NeoX . Évalué à 5 (+2/-0).
contrairement à windows pour lequel le premier utilisateur est admin par defaut (il clique sur "oui" pour confirer qu'il veut installer ou mettre à jour)
quand tu installes linux, le premier compte à souvent le droit de faire "l'administration system" dont l'ajout/suppression de programme mais doit quand meme confirmer l'action par son mot de passe.
ce serait alors ton compte à toi.
ensuite tu crees un compte, par defaut il est simple utilisateur, il ne peut alors pas installer/supprimer de logiciels, ni faire les mises à jours car cela demande alors le compte "administrateur systeme" qu'elle n'aura pas.
pour les icones, là c'est un peu plus compliquer car c'est quand meme tres personnelles, c'est donc son dossier à elle qu'il va falloir limiter, par exemple en empechant les droits d'ecriture pour elle
[^] # Re: linux vs windows
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Tout à fait.
Globalement, c'est le plus simple
Et ce, quelque soit l'environnement de bureau (certains sont plus ou moins customisables via le clck'o drome ou l'obscur fichier de config, mais cela se passe dans le $HOME de l'utilisateur quoi qu'il arrive et pas dans "le système").
L'autre solution étant le liveCD comme évoqué plus bas. C'est un peu raide, mais pourquoi pas selon la situation.
Mais sinon, je dirais à petitepomme
qu'il faut retenir avant tout une solution avec laquelle on est familier:
=> Il y aura peut être du support ou de la maintenance à distance à faire (par telef ou par ssh)
qu'au niveau des icons, ne rien faire est le mieux:
=> L'équipe qui a sorti la distrib s'est déjà bien cassée la tête sur le sujet (Par exemple, le bureau XFCE + labwc + wayland de RaspiOs, c'est juste parfait imho). Laisser la possibilité …
Emabuntu, c'est un bon choix:
avec un gros travail sur l'accessibilité (1000 bravos), pensée pour tourner sur de vielles bécanes (1000x2), avec un moteur Debian stable qui ronronne en fond de boutique (1000x3) et qui installe un immense paquet d'applications par défaut (1000x4, car tout le monde n'a pas la 5G ou l'internet haut débit ).
Par contre, le ménage dans le menu de démarrage pourrait s'imposer (mais c'est à toi de voir)!
Good luck
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: linux vs windows
Posté par Voltairine . Évalué à 2 (+0/-0).
Sauf si tu as choisi de créer un mot de passe pour l'utilisateur root lors de l'installation.
Dans le cas présenté c'est peu-être la meilleure solution. L'utilisateur standard est restreint à l'usage courant et l'administration de la machine se fait via le compte root__ avec la commande su.
# Avoir une idée du contexte serai pas mal
Posté par fearan . Évalué à 6 (+3/-0).
Car on ne peut que supputer ce que tu cherches à faire, donc proposer des solutions qui ne sont pas forcément optimums
À priori
Si c'est juste empêcher l'utilisateur de casser, une distrib immutable sans droit admin devrait faire l'affaire.
Si c'est empêcher ton môme de sortir de la cage, va falloir en plus de blinder le bios, blinder le boîtier, ado on avait fait du reset de CMOS :)
Si c'est pour une machine en accès libre, faut aussi prévoir un /home/guest qui se refait à chaque login (y'a des déjà de truc pour ça)
Bref y'a toute une gamme de possibilité avec une configuration/utilisation plus ou moins chiante
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Requête pas très claire
Posté par arnaudus . Évalué à 4 (+1/-0).
Je ne suis pas sûr de comprendre le coup de "si impossible : mot de passe administratrice(teur) requis", puisqu'il est évident qu'il faut que l'administrateur puisse mettre à jour la machine.
J'ai l'impression que si l'objectif est de lancer l'image d'une distribution, le plus simple est de faire exactement ça: créer l'image d'une distribution, et se débrouiller pour la lancer en lecture seule (le "live CD" évoque n'est qu'une déclinaison matérielle de cette solution). Le problème que je vois, c'est qu'il va falloir se coltiner la création d'une nouvelle image à chaque mise à jour de sécurité.
La requête de la non-modification des icones semble être liée à l'idée d'un compte unique, type "guest". De nombreuses distributions proposent l'ouverture de comptes "guest", dont toutes les modifications du home sont réinitialisées à la fermeture de la session. Une alternative pourrait être de configurer le home de l'utilisateur de manière à ce qu'aucun fichier de configuration ne soit modifiable (chmod -R u-w $HOME/.* est un proxy crado pour cette idée).
Sous Linux, le concept d'extension n'existe pas, et celui d'application ou programme non plus (dans la mesure où un script bash est un "programme"). C'est difficile d'empêcher un utilisateur de lancer bash ou python, donc on ne peut pas lui interdire d'exécuter une série d'instructions, ce qui semble être la définition d'un programme. Je ne pense pas qu'une session utilisateur puisse être lancée sans les droits pour exécuter le moindre script.
# C'est noté
Posté par petitepomme . Évalué à 1 (+0/-0).
Merci à la communauté pour ces retours, trés argumentés ! Cela m'est trés utile étant donné que j'ai tout à apprendre de linux…
Effectivement, le verrouillage du jeu d’icône et pointeur est une erreur y compris pour les fonctions d'accessibilité (contraste élevé, contraste inversé…), j'ai donc corrigé le sujet.
Bonne journée
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.