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

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).

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é.

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)

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.

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

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’

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.

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.

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