Postez ici vos trucs & astuces.
Répondre

[permission fichiers] Capabilities

#1Messageil y a 10 ans

Bonjour à tous,
Je découvre sur le forum d'une autre distro les possibilités qu'une commande soit "bridée" par une modification de ses "Capabilities", et donc qu'on puisse la "débrider".
C'est bien expliqué ici.
Ça pourrait rendre service à d'autres non-informaticiens comme moi à l'occasion...
Bon Dimanche.

[permission fichiers] Capabilities

#2Messageil y a 10 ans

cet article date quand même de 2010, la plupart des distributions a évolué vers d'autres solutions...

le problème, c'est que même si on donne des permissions supplémentaires (ou qu'on en enlève) à un processus en cours d'utilisation, on a toujours le même problème: ces permissions sont accordées, et peuvent donc être exploitées (en bien ou en mal).

on a aujourd'hui des solutions plus sécures, qui soit accordent des permissions en fonction de règles prédéfinies à certains groupes d'utilisateurs sur identification (Policykit), soit exécutent à la place de l'utilisateur les fonctions pour lesquelles il n'a pas les droits, sur la base de règles prédéfinies (Dbus).

d'ailleurs, si on regarde ceci, on y voit une liste des binaires setuid root; si on compare avec ce qu'on obtient avec cette commande:

find /usr/bin /usr/lib -perm /4000 -user root

on s'aperçoit que la liste des binaires qui ont cette ancienne autorisation est en baisse...

[permission fichiers] Capabilities

#3Messageil y a 10 ans

Bonjour Loubrix,
et merci de tes précisions.
En effet, j'obtiens:

waitnsea@asus ~ $ find /usr/bin /usr/lib -perm /4000 -user root
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/fusermount
/usr/bin/newgrp
/usr/bin/Xorg
/usr/bin/ksu
/usr/bin/chfn
/usr/bin/expiry
/usr/bin/gpasswd
/usr/bin/ntfs-3g
/usr/bin/chage
/usr/bin/chsh

Ils sont vraiment peu... :salut:

[permission fichiers] Capabilities

#4Messageil y a 10 ans

l'exemple type de ce qu'on peut faire sans accorder aucune permission supplémentaire:

dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop

explication: logiquement, seul Root a le droit d'arrêter la machine; pour que le simple utilisateur puisse arrêter la machine, il demande au serveur Dbus, via le client, l'exécution d'une règle bien précise d'arrêt de la machine (org.freedesktop.ConsoleKit.Manager.Stop); c'est très sécurisé, car la règle est définie à l'avance d'une part, et l'utilisateur doit connaitre la règle à invoquer auprès de Dbus.
avant ça, pour arrêter la machine, la commande "shutdown -h" nécessitait d'être Root (soit directement, soit grâce à Sudo); grâce à Dbus, ce n'est plus nécessaire.
d'ailleurs, pour ceux qui se font des environnements avec des scripts ou des menus perso (comme avec Openbox), je vous donne les autres commandes; plus haut, celle pour arrêter; celle pour redémarrer:

dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart

pour la mise en veille sur RAM:

dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend

et l'hibernation:

dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

(à vérifier pour la dernière, j'ai un doute)
il n'y a plus d'excuse pour faire ça avec un Sudo sans mot de passe ;)

[permission fichiers] Capabilities

#5Messageil y a 10 ans

Puissant !
Les trois commandes fonctionnent parfaitement
- la 1ère, après avoir installé consolekit-git par AUR
- l'hibernation - qui me plantait auparavant - fonctionne parfaitement avec ta commande, je sens qu'il va y avoir un nouveau lanceur dans mon tableau de bord... :smack:

[permission fichiers] Capabilities

#6Messageil y a 10 ans

l'ideal serait de mettre la main sur l'équivalent Systemd de ces commandes, comme ça il n'y aurait pas besoin d'installer consolekit...

edit: tu peux enlever Consolekit; avec Systemd, c'est bien plus simple...
éteindre:

systemctl poweroff

redémarrer:

systemctl reboot

veille sur RAM:

systemctl suspend

hibernation:

systemctl hibernate

il y a même "hybrid-sleep", mais j'avoues ne pas savoir à quoi ça correspond:

systemctl hybrid-sleep

toutes ces commandes peuvent être lancées par un utilisateur sans privilège, à condition que Polkit soit installé (ce qui est le cas sous Manjaro).

[permission fichiers] Capabilities

#7Messageil y a 10 ans

Consolekit n'est plus installé depuis un moment car obsolète ?

Warning: From ConsoleKit's web site:
ConsoleKit is not actively maintained. The focus has shifted to the built-in seat/user/session management of systemd called systemd-loginctl.

[permission fichiers] Capabilities

#8Messageil y a 10 ans

oui, j'ai édité...
effectivement, je n'avais pas calculé que Systemd changeait la donne à ce niveau (et les commandes viennent de mes vieux script pour Openbox et Icewm).

[permission fichiers] Capabilities

#9Messageil y a 10 ans

Toutes ces commandes sont efficaces et même impressionnantes: poweroff éteint la bécane instantanément, sans faire de dégâts (apparemment).
Bon je désinstalle ConsoleKit.

[permission fichiers] Capabilities

#10Messageil y a 10 ans

Y a-t-il une différence entre systemd poweroff et poweroff ou shutdown -P ?

[permission fichiers] Capabilities

#11Messageil y a 10 ans

au niveau de l'action effectuée, il ne devrait pas y avoir de différence; en revanche, Poweroff ou Shutdown doivent être lancé par Root (ou Sudo), tandis que "systemctl poweroff" peut être lancé par un simple utilisateur.

[permission fichiers] Capabilities

#12Messageil y a 10 ans

shutdown, c'est le vieux truc systemV. Ils le gardent pour des raisons de compatibilité, mais c'est tout. Maintenant, savoir comment c'est implémenté en-dessous... A leur place, je l'aurais branché sur le nouveau.

La grosse différence introduite par systemD, c'est la maîtrise totale des services. Avant, ils étaient lancés un peu n'importe comment (dans n'importe quel ordre selon les listes utilisateurs en général) alors que là, systemD connaît la totale et optimise cet ordre, ce qui ne peut aller qu'en s'améliorant.

Au niveau de l'arrêt; c'est encore plus frappant : au lieu d'essayer de retrouver les services qui tournent et des les arrêter tant bien que mal, systemD en a gardé d'un bout à l'autre la liste et les caractéristiques, donc peut les arrêter très sec, presque violemment.

Chez moi, c'est quasi-instantané. 1 à 2" après la frappe de cet ordre, j'entends le claquement du relais de ma tour. Ça défile encore un peu à l'écran le temps que les condensateurs se vident, mais c'est déjà fini.

[permission fichiers] Capabilities

#13Messageil y a 10 ans

Esclapion a écrit :La grosse différence introduite par systemD, c'est la maîtrise totale des services. Avant, ils étaient lancés un peu n'importe comment (dans n'importe quel ordre selon les listes utilisateurs en général) alors que là, systemD connaît la totale et optimise cet ordre, ce qui ne peut aller qu'en s'améliorant.

et surtout, des choses que SysVinit ne savait pas faire:
-lancer plusieurs services en même temps, parallèlement (SysVinit les lançait l'un après l'autre): c'est surtout ça qui accélère le boot et l'arrêt.
-établir un jeu de dépendances, un service dépendant d'un autre pour se lancer; par exemple, rien ne sert de lancer Ntpd avant Netctl.
-gérer des permissions (avec Polkit); les services de SysVinit ne pouvaient être lancés que par Root, avec Systemd (comme on vient de le voir), un simple utilisateur peut avoir accès à certains services.

une des premières distributions à avoir utilisé Systemd était Frugalware, et c'était plutôt bluffant; maintenant ça se généralise (sauf Ubuntu qui persiste avec une solution maison), et même Debian est en train de s'y mettre (je crois même que la testing doit l'avoir, à confirmer).

[permission fichiers] Capabilities

#14Messageil y a 10 ans

La testing permet de l'avoir mais pas en install par défaut je pense, il y avait encore des sondages et des débats avant les vacances.
Répondre