Excellent billet qui en plus de montrer l'évolution chronologique donne de bonnes pistes alternatives comme :
avoir des comptes dédiés pour certaines actions (d'ailleurs, du sudo sans cela, où les gens se retrouvent root pour tout, m'a toujours intrigué —et il prend d'ailleurs l'exemple de l'abus d'un simple visualiseur de texte pour faire des choses non tracées)
utiliser des accès par clés pour certains comptes (et sachant qu'une clé protégée par une phrase de passe vaut bien mieux qu'un mot de passe qu'on ne peut retenir, je vous laisse imaginer mon infarctus quand la boîte où je suis maintenant veut remplacer les accàs par clé par une authentification microchiotte AD…) et les limiter à des adresses précises (c'est le cas ici mais ça va sauter me demandez pas pourquoi)
Après, le tout n'est pas de cracher sur sudo, mais de très bien le comprendre et l'utiliser à bon escient (ce qui est un peu antinomique avec la tendance actuelle de vouloir aller trop vite et de s'appuyer sur des croyances en des outils automagiques …au passage c'est bien loin de l'esprit unixien je trouve.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
sudo a était populaire pour les machines de bureau. C'est des distributions comme ubuntu qui l'on popularisé en l'activant par défaut (et en désactivant la connexion root). Appliquer des droits fins pour une machine de bureau (qui ne fait pas parti d'un parc) est très couteux par rapport à l'usage.
Ce n'est qu'après que son usage s'est répandu sur serveur et la raison est simple : c'est très simple à mettre en place. selinux (et les autres modules de sécurité) sont très efficaces, mais elles sont très complexes à mettre en place. Appliquer selinux sur une distribution qui ne l'inclut pas de base est assez risqué et risque de casser le système. grsecurity aussi est très rarement inclu dans les distributions.
Il faut comprendre qu'aujourd'hui les serveurs ne sont plus gérés que par des sysadmin professionnels qui ont du temps pour ça. Tous les rpi, vps, etc sont pour beaucoup installés et géré par des utilisateurs++. Comme le développement n'est plus fait que par des développeurs qui prennent du temps pour écrire des tests unitaires par exemple.
sudo a des problèmes. Je pense qu'il en fait trop de base et qu'il a une surface d'attaque trop importante. Il devrait être initialement configuré avec bien moins de fonctionnalités pour avoir un coté "incassable" de base.
d'ailleurs, du sudo sans cela, où les gens se retrouvent root pour tout, m'a toujours intrigué
Si créer un compte pour créer un vase clos (créer un utilisateur toto pour le service toto) est trivial, créer un utilisateur qui n'a le droit que d'aller modifier le fichier /etc/passwd par exemple n'est pas simple. Ça ne s'exprime pas très bien en droits unix. Le plus simple pour ça c'est d'avoir des commandes dédiées genre useradd et c'est précisément ce que permet de faire sudo.
Cela aurait un sens de faire des groupes de fonctionnalité selon les risques :
- possibilité de perte de donnée
- possibilité de violation de la vie privé
- possibilité de perte du service
Je comprends bien et je ne m'attendais pas à ce que ce soit simple, c'est justement pour ça que je trouve l'usage qui est fait de sudo (en mode open-bar) ahurissant. On doit prendre la peine d'indiquer chaque commande utilisable et son contexte : ce ne sera pas incassable, mais déjà beaucoup moins friable en réduisant drastiquement la surface d'attaque.
Les commandes dédiées c'est encore autre chose, et il faut des commandes conçues pour certains fichiers sensibles avec les impératifs de sécurité en tête dès le départ (sinon on se retrouve à refaire une partie du boulot avec SELinux ou AppArmor et compagnie.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je comprends bien et je ne m'attendais pas à ce que ce soit simple, c'est justement pour ça que je trouve l'usage qui est fait de sudo (en mode open-bar) ahurissant. On doit prendre la peine d'indiquer chaque commande utilisable et son contexte : ce ne sera pas incassable, mais déjà beaucoup moins friable en réduisant drastiquement la surface d'attaque.
Ça demande à avoir une politique de sécurité très très mature. Énormément de serveurs ne sont pas géré avec un tel niveau d'industrialisation. Je ne vois pas ce qu'il y a d'ahurissant. Pleins de projets libres n'ont aucun (ou très peu) tests unitaires (pour le closed source je ne sais pas je n'ai pas les sources). Encore une fois faut distinguer l'équipe formée qui travaille 7h/jour + astreintes à gérer des serveurs et le gars qui a entendu parler de raspberrypi et qui monte un petit serveur chez lui en dilettante.
Une grande partie de l'information classique que tu peux trouver un peu partout sur le net se destine au second car le premier se forme d'abord lors de sa formation initiale et ensuite par des formations internes. Je ne crois pas qu'il soit "ahurissant" que les gens qui administrent de manière très industriels ne suivent pas le dernier tuto d'un blog obscure écrit par quelqu'un qui a essayé 1h de configuré son postfix. On parle de gens qui auditent les règles selinux des rhel qu'ils installent.
Est-ce que pour autant ils décident ou refusent d'utiliser sudo ? Je ne sais pas c'est un choix de leur pars.
C'est intéressant de remarquer que Fedora, par défaut, ne propose plus de configurer un mot de passe root mais de passer par sudo. On sent bien ici une démarcation entre Red Hat et Fedora.
Pas vraiment. Ce n'est pas une documentation officielle sur comment utiliser ta redhat enterprise mais un article d'opinion.
Du reste je comprends son idée que sudo donne un faux sens de la sécurité, comme l'alias rm='rm -i' en somme qui est très populaire pour de mauvaises raisons. Mais au final sudo disponible ou pas, mot de passe root dispo ou pas, au final ça ne change absolument rien.
L'avantage d'avoir l'habitude d'utiliser sudo, c'est que toutes les commandes sont trackées dans les logs et qu'en cas de connerie faites, tu sais qui contacter sans devoir utiliser auditd. Dans ma boite c'est intéressant parce qu'on délègue des droits root à des équipes tierces mais parfois on reçoit des alertes du monitoring avant eux. L'inconvénient, c'est qu'il n'y a pas un bash history unique mais que tu dois éventuellement en consulter plusieurs en cas de post mortem.
Dans tous les cas il y a des admins responsables et des moins responsable et les meilleurs admins du monde peuvent faire une erreur.
Posté par bubar🦥 (Mastodon) .
Évalué à 5.
Dernière modification le 05 mai 2021 à 03:36.
L'usage de sudo que je constate est :
-basique (qq commandes et c'est tout, user ou groupe)
-pour contourner quelque chose de mal fait en amont
Son usage irraisonné ou manquant de freins (cas des devops sans ops) fait que parfois nous sommes passés d'un modèle théorique d'abandon de privilèges à un modèle pratique d'élévation de privilèges.
Au lieu de corriger le tir (nouveaux groupes, meilleure gestion des droits sur l'arbo, namespaces, linger systemd,..) on va utiliser sudo en se disant que restreindre à une commande est la solution. Dommage.
Une touche d'humour ? Le pire que j'ai vu de sudo : des scripts sysv livré par un industriel qui fait faire du sudo au compte Root. Si si.
sudo n'est pas fait pour élever des privilèges mais pour lancer des commandes sous un autre user. En gros c'est un su mais en plus flexible donc il n'y a rien d'abérrant d'utiliser sudo -u <user> plutôt que su [-] <user> -c et j'ai même tendance à trouver le premier plus simple à taper avec moins d'espaces.
L'avantage d'avoir l'habitude d'utiliser sudo, c'est que toutes les commandes sont trackées dans les logs
Tu peux faire autrement, même si ton shell n'a pas le support de syslog (ou autre raffinement plus récent) : tu colles une grosse trappe, de l'historique que tu envoie à local.3, dans le bashrc central. Et hop.
Bon si tu as 10 users simultanés et que chacun a un environnement de plus de 500 lignes, ça va bouffer un peu de cpu :p (et faudra bien trier ce log qui va grossir vite)
On est obligé d'élever de temps en temps ses droits. À ma connaissance, il y a plusieurs méthodes :
- sudo
- su (+ mot de passe root - bof bof)
- polkit
- suid
- daemon en tout sens
Si on élimine la solution su qui est ce que sais faire Windows, on se retrouve au final avec deux usines à gaz, sudo ou polkit. Je trouve souvent que la configuration de sudo plus clair et elle privilégie des commandes qu'on peut faire indépendamment. Polkit, c'est un peu une grosse boite noire…
Les binaires suid, cela marche bien aussi depuis des années ! C'est un peu pour tous les utilisateurs, un peu moins fin que sudo au final.
Enfin, des daemons dans tous les sens… C'est aussi ce que propose Windows. On finit par avoir 50 services sur une machine alors qu'on souhaite juste éditer un fichier sous /etc… Je suis sceptique devant la prolifération de daemon.
Si on élimine la solution su qui est ce que sait faire Windows
Presque-calomnie :-)
En fait, avec les Fenêtres 9x/XP (qui sont toujours le système mono-usager DOS avec une interface graphique) les profils (car c'est multi-comptes mais pas au sens simultanés) sont tous administrateurs, ce qui équivaut dans le cas unixien au suid partout…
Je ne suis pas certain, mais il me semble avec vu que les Fenêtres Vista/2kWS demandaient effectivement le mot de passe du compte administrateur, ce qui peut être comparable à un su…
De ce que j'ai compris, l'implémentation actuelle est bien une élévation de privilège un peu plus générique qui est assez proche de SUDo et qui s'appelle RunAs : on ne fourni plus le passe de l'administrateur mais celui du compte qu'on va utiliser pour perforer l'action…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Avec RunAs, tu fournis toujours le mot de passe du compte cible et non ton mot de passe. C'est un équivalent du su.
La plupart des utilisateurs sont toujours admin de leur poste donc Windows est meilleure qu'avant et leur demande leur mot de passe pour exécuter des actions sensibles. Mais à la base, les comptes sont admins…
Donc pour moi, pas grand chose de changé, c'est juste plus sécurisé, mais toujours sans sudo possible.
Avec RunAs, tu fournis toujours le mot de passe du compte cible et non ton mot de passe.
On est d'accord, c'est ce que je disais par
on ne fourni plus le passe de l'administrateur mais celui du compte qu'on va utiliser pour perforer l'action…
Le compte cible = le compte qu'on va utiliser
C'est un peu la subtilité (ou fourberie plutôt) digne des gens de Redmond.
Dans l'idée, quand on fait du SUDo, on fait bien un Switch User pour Do une commande en tant que ce compte ; raison pour laquelle l'implémentation *BSD du truc s'appelle Do As qui s'entend bien comme Run As …sauf que ce dernier fonctionne à l'ancienne (vraiment les deux outils Linux et Windows auraient du échanger leur nom…)
Si effectivement (je n'ai pas vérifié et moins j'entends parler de ce faux système mieux je m'en porte)
La plupart des utilisateurs sont toujours admin de leur poste donc Windows est meilleure qu'avant et leur demande leur mot de passe pour exécuter des actions sensibles. Mais à la base, les comptes sont admins…
…alors c'est que c'est encore une escroquerie : on ne fait qu'une demande de confirmation sauf que les gens au lieu de cliquer sur oui vont taper leur mot de passe. C'est toujours aussi troué si tout le monde est super utilisateur mais les gens ont l'impression que c'est plus sécure parce-que c'est plus casse-pied ? (ah tiens c'est ce que dénonce le lien : l'usage de sudo à tort et à travers en mettant tous les gens autorisés en root en accès sur tout reproduit la même hérésie)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par bubar🦥 (Mastodon) .
Évalué à 4.
Dernière modification le 05 mai 2021 à 03:47.
Polkit a acquis la réputation de boîte noire pour deux bonnes raisons me semble t'il :
-ses carences documentaires flagrantes
-ses modifications internes faisant qu'à v+1 une conf pourtant basique issue de v ne fonctionne plus
Je n'ai jamais vu un seul administrateur système (sauf ceux des distros ou des packageurs) configurer polkit pour des besoins précis (cas d'usage, par exemple l'interdiction d'actions sur des utilitaires graphiques ou encore n'avoir qu'une seule conf de choix d'affichage du gestionnaire graphique de connexions quelque soit ce dernier) Je ne dis pas que ça n'existe pas (la preuve: p) juste que j'en jamais vu en entreprise.
Polkit devait permettre une gestion plus aisée et fine, entre autre pour les applications graphiques, s'il est toujours présent et utilisé on peut quant même constater que dans "aisée et fine" aisée est raté.
J'utilise polkit pour autoriser les utilisateurs à modifier le réseau via network-manager, ainsi qu'à monter des systèmes de fichier.
Effectivement, pour network-manager, on finit par donner les droits sur toutes les cartes réseau car sur un parc, cela deviens trop bouffe temps de vouloir faire plus fin… Il arrive un moment où il faut juste que cela marche pour l'utilisateur de son portable !
Et profitons-en pour répondre à la question que personne ne se pose, à savoir à partir de combien de sudo c'est trop ?
$ gruik='';for i in $(seq 1100);dogruik="$gruik sudo";done;eval$gruik id
uid=0(root)gid=0(root)groupes=0(root)
$ gruik='';for i in $(seq 11000);dogruik="$gruik sudo";done;eval$gruik id
uid=0(root)gid=0(root)groupes=0(root)
$ gruik='';for i in $(seq 110000);dogruik="$gruik sudo";done;eval$gruik id
uid=0(root)gid=0(root)groupes=0(root)# 259 MB de /var/log/auth.log, des sudo prennent parfois 30% du CPU, sinon c'est systemd-journal
$ gruik='';for i in $(seq 1100000);dogruik="$gruik sudo";done;eval$gruik id
# ...mouline... à suivre
ça tient mais c'est lent (le temps de recopier les lignes de commande avec 100000 arguments aussi…). Le auth.log (1,2 GB actuellement) vient de loguer la commande qui contient 98234 sudo (530 lignes de log rien que pour lui), au bout de 6h…
# Complement
Posté par Selenith (site web personnel) . Évalué à 5.
Ce lien vient en complément d'un article ecrit par dimitry khlebnikov sur lequel je suis tombé il y a quelques mois.
[^] # Re: Complement
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Excellent billet qui en plus de montrer l'évolution chronologique donne de bonnes pistes alternatives comme :
Après, le tout n'est pas de cracher sur sudo, mais de très bien le comprendre et l'utiliser à bon escient (ce qui est un peu antinomique avec la tendance actuelle de vouloir aller trop vite et de s'appuyer sur des croyances en des outils automagiques …au passage c'est bien loin de l'esprit unixien je trouve.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Complement
Posté par barmic 🦦 . Évalué à 2.
sudoa était populaire pour les machines de bureau. C'est des distributions comme ubuntu qui l'on popularisé en l'activant par défaut (et en désactivant la connexion root). Appliquer des droits fins pour une machine de bureau (qui ne fait pas parti d'un parc) est très couteux par rapport à l'usage.Ce n'est qu'après que son usage s'est répandu sur serveur et la raison est simple : c'est très simple à mettre en place. selinux (et les autres modules de sécurité) sont très efficaces, mais elles sont très complexes à mettre en place. Appliquer selinux sur une distribution qui ne l'inclut pas de base est assez risqué et risque de casser le système. grsecurity aussi est très rarement inclu dans les distributions.
Il faut comprendre qu'aujourd'hui les serveurs ne sont plus gérés que par des sysadmin professionnels qui ont du temps pour ça. Tous les rpi, vps, etc sont pour beaucoup installés et géré par des utilisateurs++. Comme le développement n'est plus fait que par des développeurs qui prennent du temps pour écrire des tests unitaires par exemple.
sudoa des problèmes. Je pense qu'il en fait trop de base et qu'il a une surface d'attaque trop importante. Il devrait être initialement configuré avec bien moins de fonctionnalités pour avoir un coté "incassable" de base.Si créer un compte pour créer un vase clos (créer un utilisateur toto pour le service toto) est trivial, créer un utilisateur qui n'a le droit que d'aller modifier le fichier
/etc/passwdpar exemple n'est pas simple. Ça ne s'exprime pas très bien en droits unix. Le plus simple pour ça c'est d'avoir des commandes dédiées genreuseraddet c'est précisément ce que permet de fairesudo.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Complement
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Cela aurait un sens de faire des groupes de fonctionnalité selon les risques :
- possibilité de perte de donnée
- possibilité de violation de la vie privé
- possibilité de perte du service
"La première sécurité est la liberté"
[^] # Re: Complement
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Je comprends bien et je ne m'attendais pas à ce que ce soit simple, c'est justement pour ça que je trouve l'usage qui est fait de sudo (en mode open-bar) ahurissant. On doit prendre la peine d'indiquer chaque commande utilisable et son contexte : ce ne sera pas incassable, mais déjà beaucoup moins friable en réduisant drastiquement la surface d'attaque.
Les commandes dédiées c'est encore autre chose, et il faut des commandes conçues pour certains fichiers sensibles avec les impératifs de sécurité en tête dès le départ (sinon on se retrouve à refaire une partie du boulot avec SELinux ou AppArmor et compagnie.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Complement
Posté par barmic 🦦 . Évalué à 2.
Ça demande à avoir une politique de sécurité très très mature. Énormément de serveurs ne sont pas géré avec un tel niveau d'industrialisation. Je ne vois pas ce qu'il y a d'ahurissant. Pleins de projets libres n'ont aucun (ou très peu) tests unitaires (pour le closed source je ne sais pas je n'ai pas les sources). Encore une fois faut distinguer l'équipe formée qui travaille 7h/jour + astreintes à gérer des serveurs et le gars qui a entendu parler de raspberrypi et qui monte un petit serveur chez lui en dilettante.
Une grande partie de l'information classique que tu peux trouver un peu partout sur le net se destine au second car le premier se forme d'abord lors de sa formation initiale et ensuite par des formations internes. Je ne crois pas qu'il soit "ahurissant" que les gens qui administrent de manière très industriels ne suivent pas le dernier tuto d'un blog obscure écrit par quelqu'un qui a essayé 1h de configuré son postfix. On parle de gens qui auditent les règles selinux des rhel qu'ils installent.
Est-ce que pour autant ils décident ou refusent d'utiliser sudo ? Je ne sais pas c'est un choix de leur pars.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Fedora n'est pas Red Hat
Posté par lejocelyn (site web personnel) . Évalué à 4.
C'est intéressant de remarquer que Fedora, par défaut, ne propose plus de configurer un mot de passe root mais de passer par sudo. On sent bien ici une démarcation entre Red Hat et Fedora.
[^] # Re: Fedora n'est pas Red Hat
Posté par Psychofox (Mastodon) . Évalué à 9.
Pas vraiment. Ce n'est pas une documentation officielle sur comment utiliser ta redhat enterprise mais un article d'opinion.
Du reste je comprends son idée que sudo donne un faux sens de la sécurité, comme l'alias rm='rm -i' en somme qui est très populaire pour de mauvaises raisons. Mais au final sudo disponible ou pas, mot de passe root dispo ou pas, au final ça ne change absolument rien.
L'avantage d'avoir l'habitude d'utiliser sudo, c'est que toutes les commandes sont trackées dans les logs et qu'en cas de connerie faites, tu sais qui contacter sans devoir utiliser auditd. Dans ma boite c'est intéressant parce qu'on délègue des droits root à des équipes tierces mais parfois on reçoit des alertes du monitoring avant eux. L'inconvénient, c'est qu'il n'y a pas un bash history unique mais que tu dois éventuellement en consulter plusieurs en cas de post mortem.
Dans tous les cas il y a des admins responsables et des moins responsable et les meilleurs admins du monde peuvent faire une erreur.
[^] # Re: Fedora n'est pas Red Hat
Posté par barmic 🦦 . Évalué à 5.
Entièrement d'accord. Je suis sûr qu'il est possible d'en parler sans juger les gens.
Linux a un paquet d'usages et une paquet de façons de gérer les droits et les utilisateurs. Ils ont des intérêts différents selon le contexte.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fedora n'est pas Red Hat
Posté par bubar🦥 (Mastodon) . Évalué à 5. Dernière modification le 05 mai 2021 à 03:36.
L'usage de sudo que je constate est :
-basique (qq commandes et c'est tout, user ou groupe)
-pour contourner quelque chose de mal fait en amont
Son usage irraisonné ou manquant de freins (cas des devops sans ops) fait que parfois nous sommes passés d'un modèle théorique d'abandon de privilèges à un modèle pratique d'élévation de privilèges.
Au lieu de corriger le tir (nouveaux groupes, meilleure gestion des droits sur l'arbo, namespaces, linger systemd,..) on va utiliser sudo en se disant que restreindre à une commande est la solution. Dommage.
Une touche d'humour ? Le pire que j'ai vu de sudo : des scripts sysv livré par un industriel qui fait faire du sudo au compte Root. Si si.
[^] # Re: Fedora n'est pas Red Hat
Posté par Pol' uX (site web personnel) . Évalué à 2.
Ça m'arrive de faire
sudo -uen tant que root et je trouve ça plus pratique quesu -c. Hérésie ?Adhérer à l'April, ça vous tente ?
[^] # Re: Fedora n'est pas Red Hat
Posté par Psychofox (Mastodon) . Évalué à 4.
idem.
sudo n'est pas fait pour élever des privilèges mais pour lancer des commandes sous un autre user. En gros c'est un su mais en plus flexible donc il n'y a rien d'abérrant d'utiliser
sudo -u <user>plutôt quesu [-] <user> -cet j'ai même tendance à trouver le premier plus simple à taper avec moins d'espaces.[^] # Re: Fedora n'est pas Red Hat
Posté par bubar🦥 (Mastodon) . Évalué à 4.
Tu peux faire autrement, même si ton shell n'a pas le support de syslog (ou autre raffinement plus récent) : tu colles une grosse trappe, de l'historique que tu envoie à local.3, dans le bashrc central. Et hop.
Bon si tu as 10 users simultanés et que chacun a un environnement de plus de 500 lignes, ça va bouffer un peu de cpu :p (et faudra bien trier ce log qui va grossir vite)
okok je sors :-)
# polkit
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
On est obligé d'élever de temps en temps ses droits. À ma connaissance, il y a plusieurs méthodes :
- sudo
- su (+ mot de passe root - bof bof)
- polkit
- suid
- daemon en tout sens
Si on élimine la solution su qui est ce que sais faire Windows, on se retrouve au final avec deux usines à gaz, sudo ou polkit. Je trouve souvent que la configuration de sudo plus clair et elle privilégie des commandes qu'on peut faire indépendamment. Polkit, c'est un peu une grosse boite noire…
Les binaires suid, cela marche bien aussi depuis des années ! C'est un peu pour tous les utilisateurs, un peu moins fin que sudo au final.
Enfin, des daemons dans tous les sens… C'est aussi ce que propose Windows. On finit par avoir 50 services sur une machine alors qu'on souhaite juste éditer un fichier sous /etc… Je suis sceptique devant la prolifération de daemon.
J'ai certainement oublié autre chose ;-)
[^] # Re: polkit
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Presque-calomnie
:-)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: polkit
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Avec RunAs, tu fournis toujours le mot de passe du compte cible et non ton mot de passe. C'est un équivalent du su.
La plupart des utilisateurs sont toujours admin de leur poste donc Windows est meilleure qu'avant et leur demande leur mot de passe pour exécuter des actions sensibles. Mais à la base, les comptes sont admins…
Donc pour moi, pas grand chose de changé, c'est juste plus sécurisé, mais toujours sans sudo possible.
[^] # Re: polkit
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
On est d'accord, c'est ce que je disais par
Le compte cible = le compte qu'on va utiliser
C'est un peu la subtilité (ou fourberie plutôt) digne des gens de Redmond.
Dans l'idée, quand on fait du SUDo, on fait bien un Switch User pour Do une commande en tant que ce compte ; raison pour laquelle l'implémentation *BSD du truc s'appelle Do As qui s'entend bien comme Run As …sauf que ce dernier fonctionne à l'ancienne (vraiment les deux outils Linux et Windows auraient du échanger leur nom…)
Si effectivement (je n'ai pas vérifié et moins j'entends parler de ce faux système mieux je m'en porte)
…alors c'est que c'est encore une escroquerie : on ne fait qu'une demande de confirmation sauf que les gens au lieu de cliquer sur oui vont taper leur mot de passe. C'est toujours aussi troué si tout le monde est super utilisateur mais les gens ont l'impression que c'est plus sécure parce-que c'est plus casse-pied ? (ah tiens c'est ce que dénonce le lien : l'usage de sudo à tort et à travers en mettant tous les gens autorisés en root en accès sur tout reproduit la même hérésie)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: polkit
Posté par bubar🦥 (Mastodon) . Évalué à 4. Dernière modification le 05 mai 2021 à 03:47.
Polkit a acquis la réputation de boîte noire pour deux bonnes raisons me semble t'il :
-ses carences documentaires flagrantes
-ses modifications internes faisant qu'à v+1 une conf pourtant basique issue de v ne fonctionne plus
Je n'ai jamais vu un seul administrateur système (sauf ceux des distros ou des packageurs) configurer polkit pour des besoins précis (cas d'usage, par exemple l'interdiction d'actions sur des utilitaires graphiques ou encore n'avoir qu'une seule conf de choix d'affichage du gestionnaire graphique de connexions quelque soit ce dernier) Je ne dis pas que ça n'existe pas (la preuve: p) juste que j'en jamais vu en entreprise.
Polkit devait permettre une gestion plus aisée et fine, entre autre pour les applications graphiques, s'il est toujours présent et utilisé on peut quant même constater que dans "aisée et fine" aisée est raté.
[^] # Re: polkit
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
J'utilise polkit pour autoriser les utilisateurs à modifier le réseau via network-manager, ainsi qu'à monter des systèmes de fichier.
Effectivement, pour network-manager, on finit par donner les droits sur toutes les cartes réseau car sur un parc, cela deviens trop bouffe temps de vouloir faire plus fin… Il arrive un moment où il faut juste que cela marche pour l'utilisateur de son portable !
# Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 02 mai 2021 à 07:43.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les vrais sysadmins
Posté par Benoît Sibaud (site web personnel) . Évalué à 7. Dernière modification le 02 mai 2021 à 12:36.
Et profitons-en pour répondre à la question que personne ne se pose, à savoir à partir de combien de sudo c'est trop ?
[^] # Re: Les vrais sysadmins
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
ça tient mais c'est lent (le temps de recopier les lignes de commande avec 100000 arguments aussi…). Le auth.log (1,2 GB actuellement) vient de loguer la commande qui contient 98234 sudo (530 lignes de log rien que pour lui), au bout de 6h…
[^] # Re: Les vrais sysadmins
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Après une douzaine d'heures, ça pataugeait encore… J'ai interrompu l'expérience (mais ça semble possible en quelques jours probablement).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les vrais sysadmins
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
pour moi oui, et pareil.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.