Forum Linux.debian/ubuntu Chmod 700 /usr/sbin

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
31
jan.
2020

Bonjour,

J'aimerai connaître les différentes méthodes de hardening sur un système linux.

J'aimerai en premier lieu interdir l'accès au /usr/sbin,

J'ai supprimer le PATH dans le bashrc des utilisateurs mais quand je chmod 700 en root sur le /usr/sbin il met impossible de redemarrer par la suite.

Connaissez vous d'autre moyens d'y arriver et d'autre astuces de hardening ? merci

  • # C'est passé dans le journal du hacker ce matin…

    Posté par  (site web personnel) . Évalué à 5.

    Un article d'it-connect sur le sujet, qui référence différentes sources dont un guide de l'ANSSI.

    Bonne lecture…

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Appliquer les recommendations existantes

    Posté par  (site web personnel) . Évalué à 3.

    Le "Center for Internet Security" fourni des guides pour renforcer la configuration de différents systèmes et applications :

    https://www.cisecurity.org/cis-benchmarks/

    C'est en anglais, dense (400+ pages pour le guide sur Ubuntu) et il faut s'enregistrer pour télécharger les documents (la validité de l'adresse email n'est pas vérifiée il me semble) mais c'est mis à jour régulièrement et les instructions peuvent s'appliquer indépendamment sur deux niveaux.

    Concernant les droits sur le système de fichiers, le droit de lecture est nécessaire pour pouvoir lancer de nombreuses applications, ce n'est pas celui a modifier en premier. Les droits en écriture et en exécution sont plus importants.

    Pouvoir lire un fichier système n'est généralement pas un problème de sécurité ; le droit en lecture ne devrait être modifié uniquement sur les fichiers contenant des données sensibles (mots de passe, fichiers journaux, base de données, fichiers personnels, …).

  • # comprendre comment fonctionne linux, et ses sécurités de bases

    Posté par  . Évalué à 4.

    J'aimerai en premier lieu interdir l'accès au /usr/sbin,

    /usr/sbin n'est en principe utilisable que par le root (Sbin) par opposition à /usr/bin, utilisable par les utilisateurs standards.

    Cependant certains outils du /usr/sbin sont utilisés par d'autres.

    J'ai supprimer le PATH dans le bashrc des utilisateurs mais quand je chmod 700 en root sur le /usr/sbin il met impossible de redemarrer par la suite.

    c'est bien tu figes l'usage de /usr/sbin à l'utilisateur root.
    mais tu as oublié qu'il y a plein d'autres utilisateurs pour faire fonctionner ton système.

    Connaissez vous d'autre moyens d'y arriver et d'autre astuces de hardening ? merci

    donc comprendre comment fonctionne linux, et ses sécurités de bases (multi utilisateur, utilisateur services, utilisateurs humains, droits sur les dossiers/fichiers)

    avant de faire n'importe quoi et de bloquer ta machine ;)

  • # Pourquoi ?

    Posté par  (Mastodon) . Évalué à 5.

    J'aimerai en premier lieu interdir l'accès au /usr/sbin

    D'abord, pourquoi ? Chez moi par exemple (Arch) c'est un lien vers /usr/bin, autant dire que ça va moins bien marcher si j'interdis à quiconque d'y aller :)

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Merci

    Posté par  . Évalué à 1.

    Bonsoir,

    Merci pour vos réponse & vos lien que je vais me presser de lire
    je vais essaye d'éclairer vos lanternes !

    Le but étant d'empêcher un utilisateur lambda de pouvoir utiliser certaine commande dans /usr/sbin

    Le fait d'enlever le path n'empêche absolument pas l'utilisateur de pouvoir executer une commande

    Exemple, je veut interdire un utilisateur non sudoers/root de pouvoir utiliser /usr/sbin/reboot

    En retirant le PATH il lui est impossible d'utiliser la commande en tapant reboot, cependant il peut toujours utiliser /usr/sbin/reboot car les utilisateurs Other peuvent execute, si j'enleve le execute impossible de démarrer l'interface graphique.

    Je pense qu'il faudrait donc passer en revu toute les commandes et savoir pour les vérouiller une à une jusqu'a trouver celle qui est utiliser lors du lancement du server X (Et pourquoi elle n'est pas lancer par root ducoup)

    • [^] # Re: Merci

      Posté par  . Évalué à 3.

      En retirant le PATH il lui est impossible d'utiliser la commande en tapant reboot, cependant il peut toujours utiliser /usr/sbin/reboot car les utilisateurs Other peuvent execute, si j'enleve le execute impossible de démarrer l'interface graphique.

      peut-être parce que ton interface graphique n'est pas lancée en root et c'est tant mieux pour la sécurité.

      et que cette interface propose un bouton reboot sur l'interface de login ou dans les menus, si cette option n'est pas disponible, le menu ne peut pas être construit, l'interface ne se lance pas.

      il faudrait plutôt voir comment supprimer le droit de faire reboot aux utilisateurs non root de l'interface graphique

    • [^] # Re: Merci

      Posté par  (site web personnel) . Évalué à 2.

      si c est juste pour interdire certaine commande, le fait de bloquer /usr/bin ne sert a rien, car il suffirait d importer un binaire d une autre machine

      regarde du cotes de rbash

      • directories with cd
      • or unsetting the values of SHELL, PATH, ENV, or BASH_ENV
      • command names containing /
      • a filename containing a / as an argument to the . builtin command
      • a filename containing a slash as an argument to the -p option to the hash builtin command
      • function definitions from the shell environment at startup
      • the value of SHELLOPTS from the shell environment at startup
      • output using the >, >|, <>, >&, &>, and >> redirection operators
      • the exec builtin command to replace the shell with another command
      • or deleting builtin commands with the -f and -d options to the enable builtin command
      • the enable builtin command to enable disabled shell builtins
      • the -p option to the command builtin command
      • off restricted mode with set +r or set +o restricted.

      /enjoy

    • [^] # Re: Merci

      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 02 février 2020 à 18:29.

      Le but étant d'empêcher un utilisateur lambda de pouvoir utiliser certaine commande dans /usr/sbin

      Mais c'est déjà le cas. Les commandes "sensibles" ont besoin de privilèges (on les exécute via sudo en général) et un utilisateur lambda n'a pas ces privilèges.

      Tu as un exemple concret de commande que tu veux interdire ?

      EDIT : oups, tu parles de reboot en effet. Bin tu fais un chmod o-x sur la commande reboot et c'est plié. D'autres exemples ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Merci

      Posté par  (site web personnel) . Évalué à 3.

      Exemple, je veut interdire un utilisateur non sudoers/root de pouvoir utiliser /usr/sbin/reboot

      Bein c'est déjà le cas, reboot/poweroff sont des actions privilégiés, pour les utiliser il faut être root ou respecter certaines règles.

      Dans un système réçent ces commandes vont être des liens vers systemctl, difficile à en bloquer l'execution via chmod sans limiter les fonctionnalités de systemd pour les utilisateurs, par contre les décisions d'autorisations pour reboot/shutdown (ainsi que d'autres actions normalement privilégiées telles que le montage/demontage de disques) vont passer par le filtre "policy-kit".

      Selon ta version de policy-kit la configuration va varier mais il est possible de configurer l'outil pour que les utilisateurs locaux n'aient plus l'autorisation de reboot, exemple:

      /etc/polkit-1/rules.d/20-disallow-shutdown.rules:

      polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.consolekit.system.stop" ||
         action.id == "org.freedesktop.consolekit.system.restart") &&
        subject.isInGroup("users")) {
            return subject.active ? polkit.Result.AUTH_ADMIN : polkit.Result.NO;
    }
});

      Ou pour policykit <= 0.105:

      /etc/polkit-1/localauthority/50-local.d/20-disallow-shutdown.pkla:

      [Disallow shutdown]
Identity=unix-group:users
Action=org.freedesktop.consolekit.system.stop;org.freedesktop.consolekit.system.restart
ResultAny=no
ResultInactive=no
ResultActive=auth_admin

      https://superuser.com/questions/354678/what-is-the-correct-way-to-prevent-non-root-users-from-issuing-shutdowns-or-rebo

      • [^] # Re: Merci

        Posté par  . Évalué à 2.

        yep ça ça marche bien, mais après faut aussi virer le ctrl-alt-suppr de la console (ctrl-alt-f3 par exemple)

        puis virer le bouton power
        puis virer le bouton reset
        puis coller le câble d'alim à la prise et à l'alim
        puis virer le bouton on/off de l'alim,
        puis coller le disjoncteur/fusible
        et enfin appeler les pompiers ;)

        bon on peut aussi mettre l'unité centrale dans un local sécurisé, mais c'est moins drôle.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Merci

          Posté par  (site web personnel) . Évalué à 2.

          ah bein ça … je répondais juste a la demande initiale d'empecher un utilisateur lambda d'executer le reboot, je n'aime pas contester la pertinence des demandes des gens (ou en tout cas pas up-front ).

          Effectivement pour le ctrl-alt-suppr/bouton power c'est init qui va le déclencher donc il faut aussi configurer ça, ça doit être documenté quelque part.

          pour le reste…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.