Merci Pikachu_2014 🙂
Sat wrote:[...] PackageKit reste plus sûr que les solutions type sudo/gksudo etc... PolicyKit (et SELinux en prime) veille au grain.
@Sat j'ai du mal à voir en quoi Package Kit est plus sûr qu'une solution sudo correctement mise en place. Tu peux développer stp ?
proxy wrote:
2Passage wrote:Pour moi l'histoire des MAJ c'est au root de le faire , point barre. Je ne vois pas l'intérêt de donner des droits de modifications système à un user normal.
Bien tu fais comme moi, tu enlèves packagekit
+1 pour le fait d'enlever packagekit yum fonctionne très bien sans; de plus yumex est de mieux en mieux .
BBT wrote:
Sat wrote:[...] PackageKit reste plus sûr que les solutions type sudo/gksudo etc... PolicyKit (et SELinux en prime) veille au grain.
@Sat j'ai du mal à voir en quoi Package Kit est plus sûr qu'une solution sudo correctement mise en place. Tu peux développer stp ?
L'intérêt de PackageKit est double :
- ne permettre d'exécuter en root une application --- graphique ou non --- que sur les parties de code spécifiées par le développeur qui nécessitent vraiment d'être root : si une application graphique est lancée en tant que root (ou via sudo), tout son code est exécuté avec les droits root, y compris les instructions graphiques dont tout le monde sait que leur exécution en root n'est pas garanti comme sûre, loin de là. PackageKit repose sur PolicyKit, peut se lancer en tant que simple utilisateur, mais seules les opérations de maintenance des paquets sont vraiment exécutées avec les droits root, avec demande d'un mot de passe root au moment où ces instructions sont exécutées si l'appli. a été configurée comme tel (ce qui était le cas pour F10 et F11 avec PackageKit, plus avec F12). Yumex et même Synaptic s'exécutent de bout en bout en root... Quelle application est la plus sûre ?
- PolicyKit permet de déléguer avec une grande finesse des tâches d'administration root liées aux appli. basées sur cette bibliothèque à de simples utilisateurs ... Et toute l'affaire qui fait l'objet de ce fil en est la preuve : un utilisateur local peut installer des paquetages sans droits, mais ne peut pas en retirer ni faire de mise à jour, et ce comportement peut être modifié en éditant un simple fichier de conf.
À l'origine, sudo c'est un outil pour gérer granulairement l'accès à certaines commandes à une époque où le bureau était inexistant. Aujourd'hui, on utilise sudo à tort et à travers sans aucun avantages par rapport au mécanisme super-utilisateur classique.
Premièrement, tu as le problème du timeout avec sudo (15m sous Ubuntu par défaut), deuxièment, avec sudo tu octroies potentiellement des privilèges à des millions de lignes de codes non audités (Xorg, Gtk+, etc ...).
En lieu et place de sudo, Fedora utilise PAM/ConsoleHelper qui est un moindre mal, mais qui est progressivement remplacé par PolicyKit, plus adapté au paradigme bureau.

Pour résumer, PolicyKit permet une gestion fine des droits selon un principe client/service (pas d'erreur, c'est un service dbus). Ton client demande le droit d'exécuter une seule action, PolicyKit vérifie qu'il a le droit d'effectuer cette opération et transmet ou non la requête à un service. Seul le service en question a les priviléges, pas les clients, donc moins de code tournant sous des priviléges élevés, une authentification plus fine (PolicyKit peut distinguer un utilisateur local, d'un utilisateur distant), etc ...
Le seul inconvénient de PolicyKit, c'est la nécessité d'intégrer le framework à l'application.

Pour en revenir à PackageKit, PackageKit s'appuie sur PolicyKit, d'où le fait que l'installation de paquets en non-root ne marche pas pour un utilisateur distant, que ça n'affecte que le mécanisme d'installation de paquets (on peut difficilement détourner PackageKit pour une élevation de droits), et ça ne marche que pour les paquets signés (par défaut, les dépôts officiels)
Certes, c'est moins sécurisé que le comportement précédent puisque l'administrateur ne peut pas filtrer les paquets installés (enfin, quand on administre un parc, on personnalise un minimum les installations) mais ça reste un zillion de fois mieux que sudo/gksudo. Enfin, ça change pas grand chose pour les utilisateurs desktop.
Le seul truc à craindre, c'est qu'un paquet contienne une faille mais c'est valable pour tout le monde. Mais dans ce cas, c'est oublier la politique de sécurité proactive (sécurité préventive) de Fedora (on est la seule distribution "grand public" à le faire) c-a-d SELinux et ses amis qui permettent de confiner la plupart des failles par avance. Pour plus de détails sur la sécurité d'une installation Fedora, je vous renvoie à l'excellent security guide (également disponible via yum)
http://docs.fedoraproject.org/security-guide/f12/en-US/html/
ok merci pour les réponses, je met +1 à PolicyKit sur l'idée.
Je testerai pour voir comment ça se met en place quand j'aurai le temps.
L'idée de la gestion par PolicyKit est très bonne d'une manière générale.

Encore que, comme il est dit dans fedora-devel-list, la problématique de l'installation sans authentification de paquets signés représente une faille de sécurité interne à la famille ou au cercle des personnes qui ont un accès physique à une machine sans en être administrateur.

D'accord, Fedora n'a pas vocation à être installée dans des ministères ou des grandes entreprises, mais s'il venait à l'idée de RedHat de généraliser le choix qui a été fait dans cette release, on imagine quelles catastrophes celà engendrerait.

Une autre chose que je ne comprends pas, si toutefois j'ai bien lu: Un user sans droit pourrait installer des paquets sans authentification, mais ne pourrait pas en retirer ? Et s'il s'aperçoit qu'il a fait une bêtise alors ?
Si tu permets de supprimer un paquet ==> pkcon remove glibc ===> vlan dans les dents.
Pour résoudre ce problème, il faudrait enregistrer quelque part les paquets installés par l'utilisateur en question (des méta-données propres à PK, une base rpm utilisateur etc ...), mais visiblement ça n'a pas été pris en compte. Preuve de l'immaturité de la fonctionnalité.
Là, le lynchage aurait été largement mérité si on pouvait désinstaller comme ça les paquets.


> mais s'il venait à l'idée de RedHat de généraliser le choix qui a été fait dans cette release
Aucun risque, RHEL a des standards plus stricts que Fedora y compris au niveau du bureau.
remi wrote:Un retour au fonctionnement précédent (F-10/F-11) est prévu très bientôt.

https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html

+
Merci beaucoup pour l'info.

Ce sera donc réparé pour F12.

Mais j'ai pas très bien compris ce qu'ils cherchent à faire. Pouvoir définir des compte "Administrateur" et des compte "Non Administrateur", avec non demande de mot de passe pour les comptes "Administrateur", comme sous Windows?

Ce qui me pose problème, ce n'est pas tant le fonctionnement interne, mais c'est l'impacte sur l'utilisateur: il n'y a plus cette démarcation entre utilisation et administration qu'est la demande du mot de passe ROOT. Ça désensibilise l'utilisateur sur son acte et ne lui fait pas prendre conscience de son importance. Il faut bien marquer la différence, notamment via la demande de mot de passe root, afin de donner les bonne habitudes à l'utilisateur.

Sinon, si on commence par supprimer la demande de mot de passe sois disant pour simplifier la vie de l'utilisateur, on finit par enlever la gestion avancé des droit aussi sur les fichiers... C'est ce qu'avait fait Microsoft, et on a vue ou ça a menez (et la génération d'utilisateur inconscient).
Par contre, je ne vois pas de changement pour les mises à jour.

Les réglages des mises à jours se font depuis le sous-menu Préférence, par l'utilisateur (qui peut demander une installation automatique), et non depuis le sous-menu Administration avec demande du mot de passe root.
5 jours plus tard
Pour ceux qui veulent savoir: c'est bon, la mise à jour a été faite.

Il me semblait qu'avec Policykit le mot de passe root n'était pas demandé dans les 15 minutes après qu'il ai été donnée par l'utilisateur.
Est que c'est exprès ce passage de l'extrême pas de demande de mot de passe à l'autre extrême demande à chaque fois?
Le mainteneur du paquet veut-il agacer les gens avec une demande constante de mot de passe root pour que son idée paraisse bien?

Non, cela témoignerai d'une mesquinerie bien prononcé.

Bref, c'est réglé pour l'installation, mais pas pour les mises à jour. Une idée concernant ceci?
Pour les mises à jour ça a l'air moins grave que l'installation de nouveaux paquets,
mais de manière générale, je pense que toutes ces responsabilités relèvent de l'administrateur.
C'est à lui de décider de déléguer ou pas ces tâches à un ou plusieurs utilisateurs,
et si l'administrateur n'est pas au courant de ces possibilités, autant les bloquer plutôt que les autoriser par défaut.
Pour bloquer la fonctionnalité de mise à jour, je pense qu'il faut faire cette cette commande: 
pklalockdown -lockdown org.freedesktop.packagekit.system-update
Si quelqu'un peut confirmer.

Par contre, c'est pour bloquer les réglages que je sais pas comment faire.