Quels droits d'accès le superutilisateur ne peut-il pas violer?

23

Fr. Br. George a dit dans une de ses conférences (c'est en russe) qu'il y a des droits d'accès que le superutilisateur ne peut pas violer. Autrement dit, il existe des droits d'accès qui peuvent interdire au superutilisateur de faire quelque chose.

Je n'ai pas pu trouver ces informations sur Internet et je suis curieux de savoir ce qu'elles sont. C'est probablement quelque chose lié à l'exécution de base du système, n'est-ce pas? Peut-être qu'il ne peut pas arrêter certains processus système? Ou peut-être qu'il ne peut pas exécuter un processus en mode réel?

Cette question n'est pas liée à SELinux (George en parlait juste avant la question).

Kolyunya
la source
2
Un "privilège" ou une "autorisation" est un droit de faire quelque chose, un droit qui peut être accordé à des comptes d'utilisateurs spécifiques. Sous UNIX et Linux (à l'exception des versions renforcées telles que SELinux), root a tous les droits. Il n'y a aucun droit qui peut être accordé root, et donc aucun droit qui peut être retiré root.
MSalters du
1
@MSalters, pardon? On peut certainement garder UID 0 tout en révoquant toujours les capacités du processus.
Charles Duffy
... set SECBIT_NOROOT, et étant uid 0 n'octroie plus automatiquement une capacité.
Charles Duffy
Autant de réponses - serait-il judicieux de transformer cela en un wiki communautaire, ou quelqu'un devrait-il écrire une réponse résumée?
Simon Richter du
1
@SimonRichter Je vais aussi en tant que George pour nous dire ce qu'il voulait dire dans sa conférence.
Kolyunya du

Réponses:

24

accès refusé à root :

rootpeut se voir refuser l'accès direct au réseau. C'est utile sur les hôtes connectés à Internet, car cela nécessite que vous vous connectiez en tant que smith, alors sudo.

certaines choses que root ne peut pas faire :

Ce n'est PAS par manque de privilège. Je ne vois rien que root ne puisse pas faire, mais certains problèmes techniques peuvent être considérés comme "interdits".

Je suis root, pourquoi ne puis-je pas créer / supprimer ce fichier, alors qu'un utilisateur ordinaire le peut?

Vous êtes sur un partage NFS / samba et vous n'avez pas donné d' access=autorisation spécifique ( ). L'utilisateur ordinaire ne respecte pas la common law. (voir racine locale vs distante ci-dessous)

Je suis root, pourquoi ne puis-je pas tuer ce processus?

Il y a une E / S en attente et le lecteur physique / LUN distant ont été déconnectés, le processus ne peut être tué que par redémarrage.

Je suis root, comment puis-je obtenir le mot de passe d'Archemar?

Vous pouvez su - archemarbien, ou changer le mot de passe d'Archemar sans connaître le précédent, mais vous ne pouvez pas le lire (à moins d'un enregistreur de frappe), car les mots de passe sont stockés à l'aide d'un hachage unidirectionnel.

racine locale vs racine distante

  • Vous pouvez être root sur votre station / PC et utiliser un partage NFS entreprise / collège / université / fournisseur.
  • Ensuite, vous ne pouvez avoir qu'une connexion non root sur un ordinateur exportant NFS.

À présent

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

connectez-vous simplement sur le serveur NFS, exécutez ./bashet vous êtes root sur le serveur de l'entreprise / université.

Archemar
la source
Le cas 1 est essentiellement une erreur car vous n'êtes que rootlocalement, pas nécessairement sur d'autres systèmes. Les cas 2 et 3 ne sont pas des privilèges (ils ne peuvent être accordés à personne). Donc +1, votre première phrase semble être correcte.
MSalters
Techniquement, rootune machine locale peut faire tout ce qu'elle veut avec le même privilège que l'utilisateur local, en fait su - usernamerien d'autre. Je ne sais jamais pourquoi ils ont pris la peine de rootne pas pouvoir écrire des partages réseau comme ça; cela semble plutôt inutile.
Tom Hunt du
4
C'est la question séculaire "Peut rootcréer un mot de passe même s'il ne peut pas accéder?"
corsiKa
5
@TomHunt, l'une des raisons de ne pas donner rootaccès aux partages NFS est d'empêcher la création de binaires "racine suid" sur le serveur distant, ce qui peut être exploité pour un accès distant complet au serveur.
Mark
1
Tuer un processus dans une attente ininterrompue ne me semble pas un droit . C'est quelque chose que vous ne pouvez pas faire. Comme écrire sur un système de fichiers complet.
Blacklight Shining
11

Dans le cas habituel, ceci est incorrect - le superutilisateur a des privilèges / autorisations sur toutes les fonctionnalités fournies par le système (1). Lorsque cette règle tombe en panne, c'est lorsque vous lancez SELinux dans le mix. Avec SELinux, il est possible de restreindre même les privilèges root pour interdire certaines actions. Cependant, les actions spécifiques interdites dépendent fortement de la configuration SELinux de la machine locale, donc même avec SELinux, cette question ne peut pas être répondue dans le sens général.

(1) - si un système ne fournit pas une fonctionnalité donnée, par exemple, il n'y a pas de fonctionnalité de noyau en temps réel, alors je considère que la déclaration "root n'a pas accès à cette fonctionnalité" est fausse, car cette déclaration repose sur un fausse supposition (à savoir que la fonctionnalité donnée est disponible pour quiconque sur ce système)

John
la source
1
Merci pour votre réponse, John! Mais il a explicitement déclaré que cette question n'est pas liée à SELinux ...
Kolyunya
À moins de détails, je vais devoir considérer que la déclaration selon laquelle root n'a pas accès à certaines fonctionnalités est fausse. (Je ne considère pas le cas du verrouillage du système d'exploitation du BIOS ou similaire par la sécurité du BIOS.)
John
Vous avez également la complication que root contrôle la configuration SELinux. Si je (en tant que root) suis bloqué dans une action, je peux modifier SELinux pour autoriser l'action, puis la modifier à nouveau par la suite. Pourrait s'en tirer en fonction de l'emplacement de stockage du journal.
doneal24
2
Pas nécessairement vrai. Otez son CAP_NET_ADMIN, et étant uid 0 ne laisse toujours pas un processus changer la configuration réseau. (De même pour CAP_SYS_ADMIN et les capacités qu'il contrôle, etc.).
Charles Duffy
5

D'une part, il y a des choses qu'aucun utilisateur ne peut faire, comme

  • répertoires de liaison fixe (en raison des limitations du système de fichiers)
  • écrire sur un CD-ROM déjà gravé (parce que la physique)

Mais ce ne sont pas des privilèges, car ils ne peuvent pas être accordés, ils ne sont tout simplement pas possibles pour quiconque.

Ensuite, il existe des restrictions pour l'ensemble du système ou des parties de celui-ci qui peuvent être activées ou désactivées.
Par exemple, sous OS X, il existe une option pour autoriser l'exécution du code uniquement s'il a été signé par Apple.

Je ne considère pas cela comme un privilège réel, car aucun utilisateur ne peut l'avoir si le superutilisateur ne le peut pas. Vous ne pouvez le désactiver que globalement.

Edit:
Votre idée d'un fichier sans le bit exécutable tomberait également dans cette catégorie, car personne ne peut le faire, et personne ne peut obtenir cette autorisation.
Et même lorsque vous accordez à un autre utilisateur ou groupe l'autorisation d'exécuter ce fichier, mais pas root ou qu'un groupe d'utilisateurs root est présent, root pourra toujours exécuter ce fichier (testé sur OS X 10.10, 10.11 et Ubuntu 15.04).

En dehors de ces cas, il n'y a pratiquement rien que root ne puisse faire.
Il existe cependant une chose appelée mode noyau (par opposition au mode utilisateur).

Pour autant que je sache, sur un système sain, seul le noyau, les extensions et les pilotes du noyau s'exécutent en mode noyau, et tout le reste (y compris le shell à partir duquel vous vous connectez en tant que root) s'exécute en mode utilisateur.
On pourrait donc affirmer qu '"être root ne suffit pas". Cependant, sur la plupart des systèmes, l'utilisateur root est capable de charger les modules du noyau, qui s'exécuteront à leur tour en mode noyau, donnant ainsi à root un moyen d'exécuter du code en mode noyau.

Il existe cependant des systèmes (comme iOS) où cela n'est pas (arbitrairement) possible, du moins pas sans exploiter les ensembles de sécurité. Cela est principalement dû à une sécurité accrue, comme l'application de la signature de code.
Par exemple, des clés de chiffrement AES sont intégrées aux processeurs d'iDevices, auxquelles on ne peut accéder qu'en mode noyau. Les modules du noyau pourraient y accéder, mais le code de ces modules du noyau devrait également être signé par Apple pour que le noyau les accepte.

Sous OS X, depuis la version 10.11 (El Capitan), il existe également un soi-disant "mode sans racine" (bien que le nom soit trompeur car root existe toujours), ce qui interdit efficacement root certaines choses que les installateurs peuvent toujours faire.
Citant cette excellente réponse sur AskDifferent :

Voici ce qu'il restreint, même à partir de la racine:

  • Vous ne pouvez rien modifier dans / System, / bin, / sbin ou / usr (sauf / usr / local); ou l'une des applications et utilitaires intégrés. Seuls le programme d'installation et la mise à jour logicielle peuvent modifier ces zones, et même ils ne le font que lors de l'installation de packages signés Apple.
Siguza
la source
1
En fait, vous pouvez exécuter un exécutable sans que les bits d'exécution ne soient définis: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hellodonne la Hello, World!sortie attendue ,
doneal24
@ DougO'Neal Mais /lib64/ld-linux-x86-64.so.2l'exécutable n'est-il pas alors ./helloun argument? Parce que c'est comme passer un fichier texte contenant du code PHP à l'interpréteur PHP ... ou comme exécuter un script bash en utilisant bash ./my_script...
Siguza
1
@ DougO'Neal Cela fonctionnait, mais a été désactivé dans les versions récentes de glibc (pour éviter qu'il ne s'agisse d'un contournement trivial des montures noexec).
duskwuff
@duskwuff Quelle est la version récente de la glibc? Cela fonctionne toujours sous Ubuntu 14.04.
doneal24
1
Apple ne l'a pas ajouté à ln mais la classe système utilisée par ln, par exemple link, le permet, voir stackoverflow.com/a/4707231/151019 C'est ainsi que fonctionne Time Machine
user151019
4

L '"exécution du noyau du système" dont vous parlez est bien sous rootle contrôle, par exemple via des modules de noyau chargeables. Bien sûr, cela suppose que le chargement des modules du noyau est pris en charge par le noyau, personne ne peut même effectuer des actions qui ne sont pas réalisables root.

Il en va de même pour les processus système. rootest autorisé à tuer n'importe quel processus, mais il est impossible d'arrêter un processus en cours d'exécution en mode noyau sans compromettre l'intégrité du noyau, il est donc tout simplement impossible d'arrêter un tel traitement immédiatement. Notez que rootne sera pas refusé de tuer ces processus, le fait de se tuer n'aura tout simplement aucun effet.

Enfin, le mode réel: le noyau Linux n'a pas de support, donc encore une fois, personne ne peut faire l'impossible, même pas root.

@Siguza a mentionné l'exécution de fichiers sans xautorisation, ce qui est tout à fait possible pour l' rootutilisateur:

/lib/ld-linux.so.2 /path/to/executable
Dmitry Grigoryev
la source
... mais un processus uid-0 peut perdre la capacité de charger de nouveaux modules du noyau (ou de les transférer à chaud /proc/kmem) via la révocation des capacités.
Charles Duffy
4

Un exemple pourrait être la modification d'un fichier immuable: vous pouvez définir un attribut de fichier iavec chattrqui rend le fichier immuable même pour root. Par exemple:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Notez que le fichier apparaît en tant que fichier inscriptible normal en ls -lsortie:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Pour voir l' iattribut, vous devez utiliser lsattr:

# lsattr god
----i----------- god

La page de manuel de chattr indique ce qui suit à propos de l' iattribut:

Un fichier avec l'attribut «i» ne peut pas être modifié: il ne peut pas être supprimé ou renommé, aucun lien ne peut être créé vers ce fichier et aucune donnée ne peut être écrite dans le fichier. Seul le superutilisateur ou un processus possédant la capacité CAP_LINUX_IMMUTABLE peut définir ou effacer cet attribut.

Cependant, root peut facilement annuler l'immuabilité:

# chattr -i god
# rm -v god
removed ‘god’
Tuomas
la source
Le noyau Linux n'implémente plus correctement la fonction de niveau de sécurité BSD , ce qui vous donne des rendements décroissants sur les attributs immuables et n'ajoute que les attributs. Avec securelevel , ces bits ne peuvent pas être réinitialisés une fois que le système est dans un niveau d'exécution multi-utilisateur, donc l'administrateur devrait fermer et utiliser une console locale, ce qui arrêterait les attaquants du réseau.
Simon Richter du
2

Sur FreeBSD, vous ne pouvez pas utiliser gmirrorsur une partition déjà montée, même en tant que root:

gmirror label -v -b prefer gm0s1 ad4s1
gmirror: Impossible de stocker les métadonnées sur ad4s1: Opération non autorisée.

Vous devez définir un sysctl( kern.geom.debugflags=16) pour pouvoir le faire.

rootest un utilisateur privilégié, mais ces droits sont accordés par le noyau. Le noyau a donc plus de privilèges que root.

Vinz
la source
1

En supposant que la collaboration de l'utilisateur racine lui-même, rootil soit impossible d'accéder aux montages FUSE (avec les options allow_otherou allow_root), mais cela est dû au fait que FUSE a été conçu pour agir de cette façon. Étant donné que FUSE réside sur une couche virtuelle, il peut retourner toute erreur qu'il aime en fonction de la logique, par opposition aux modules de périphérique de bloc courants qui s'efforcent d'être aussi transparents et fins que possible, en déléguant des autorisations à une autre couche.

Cela n'empêche pas l'utilisateur root de désactiver l'option ou de remplacer le module FUSE par un module qui rejette silencieusement l'option, sauf si vous rendez le système de fichiers en lecture seule. Cependant, cela ne mène qu'à une situation "qui surveille les gardiens": comment pouvez-vous valider que le système ne ment pas? Votre shell peut même être assis dans un chroot qui vous montre un module FUSE légitime, tandis que le noyau en exécute une version malveillante.

sleblanc
la source
0

Je dirais que l'impossibilité d'exécuter des fichiers non exécutables est trivialement une limitation, car elle dépend des autorisations de fichier. (Il est possible de contourner cela en utilisant /lib64/ld-linux-x86-64.so.2 pour un fichier non exécutable, mais pas un fichier sur un montage sans exécutable)

Il y a aussi le problème des verrous de fichiers obligatoires, qui empêchent la modification des fichiers si un fichier est actuellement utilisé par un processus, bien que le super utilisateur puisse tuer le processus.

À un moment donné, le super utilisateur n'a pas pu démonter un appareil alors que l'appareil était occupé, mais cela peut maintenant être fait en utilisant un umount paresseux.

Les autres limitations sont:

ne peut pas modifier les fichiers immuables et ne peut être ajouté qu'à des fichiers à ajouter uniquement (linux permet au super utilisateur de supprimer les indicateurs immuables et à ajouter uniquement à n'importe quel niveau d'exécution, mais en partie en dérogeant à leur objectif)

ne peut pas écrire sur un montage en lecture seule, ou exécuter quoi que ce soit sur un montage sans exécutable

ne peut pas lier une monture non liée

ne peut pas remonter un système de fichiers en lecture-écriture si son périphérique de bloc est en lecture seule

ne peut rien statuer sur un support de fusible appartenant à un autre utilisateur, sauf s'il est monté allow-other ou allow-root

ne peut pas violer les paramètres SELinux

limitations délibérées inhérentes au système lui-même, qui affectent la racine:

ne peut pas définir directement l'heure c d'un fichier (ou l'heure de naissance, si elle est déjà implémentée)

ne peut pas afficher les mots de passe en texte brut

un autre type
la source