Pourquoi un utilisateur non privilégié ne peut pas changer la propriété d'un fichier?

15

De chown (2):

Seul un processus privilégié (Linux: un avec la capacité CAP_CHOWN) peut changer le propriétaire d'un fichier. Le propriétaire d'un fichier peut remplacer le groupe du fichier par tout groupe dont ce propriétaire est membre. Un processus privilégié (Linux: avec CAP_CHOWN) peut changer arbitrairement le groupe.

Quelle est la raison de cette restriction? Pourquoi un utilisateur non privilégié ne peut pas changer la propriété d'un fichier qu'il possède (c'est-à-dire pas / etc / shadow)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted
Alexandru
la source

Réponses:

27

En permettant aux utilisateurs de "distribuer" des fichiers, vous exécutez à l'encontre de diverses fonctionnalités du système d'exploitation. Tel que:

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...
Chris Nava
la source
8

C'est juste un choix personnel des concepteurs de Linux de ne pas le permettre - toutes les raisons de pseudo-sécurité, étant donné , sont spécieuses, car il existe des systèmes Unix qui le permettent.

Je pense que cette fonctionnalité se résumait à savoir si le comportement de votre Unix suivait ou non 'System-V' (AT&T) ou Berkeley's Unix (BSD) ...

Quant aux autres problèmes de sécurité mentionnés:

  • Usurper l'identité d'un autre utilisateur (ou même root) via setuid.

    Aucun problème: le changement de «propriétaire» efface tous les bits «setXid» (U / G)

  • Avoir des privilèges insuffisants pour annuler un chown erroné

    Ce n'est pas vraiment un «risque de sécurité», MAIS, cela peut être sur des systèmes qui permettent de changer d'utilisateur, vous pouvez le modifier s'il se trouve dans un répertoire que vous possédez, sinon: «soyez prudent»!

  • Faire apparaître que quelqu'un d'autre a créé un fichier donné.

    Ce serait toujours dans un répertoire que vous pouvez écrire. C'est-à-dire que vous ne pouvez pas le déplacer dans leur homedir, à moins qu'il ne soit ouvert pour l'écriture à votre groupe ou à tous (ou vous spécifiquement si les ACL sont disponibles).

  • Configuration des tâches cron à exécuter sur les comptes d'autres utilisateurs.

    Encore une fois, cela ne fonctionnerait pas - car les crondirs appartiennent à l'utilisateur et ne sont même pas configurés pour être lisibles par les autres utilisateurs, et encore moins en écriture.

  • si quelqu'un pouvait changer la propriété, alors n'importe qui pouvait changer les autorisations pour accéder à n'importe quel fichier du système.

    Non: seulement si l'utilisateur «possède» le répertoire contenant ce fichier. C'est-à-dire que je peux donner un fichier nommé 'passwd' à root, mais je ne pouvais pas le déplacer dans / etc / à moins d'avoir la permission d'écrire dans / etc /.

  • quotas

    Un point potentiellement valide - SI vous utilisez des quotas, mais il semble qu'il serait facile de détecter si vous additionnez l'espace disque par home-dir; Le seul problème serait dans les répertoires accessibles en écriture par plusieurs utilisateurs. Dans ce cas, peut-être par le propriétaire de ce «dir». Cela PEUT être le cas sur ces systèmes qui prennent en charge la «distribution» de fichiers, que vous ne pouvez le faire que dans des répertoires que vous «possédez», mais cela fait longtemps que je n'ai pas été sur un système qui le permet, donc Je ne me souviens pas des restrictions exactes.

Je semble me rappeler qu'il y a eu un certain "compromis" pour permettre de "donner des fichiers" ... par exemple - sur des systèmes qui permettaient cela, quelque chose d'autre n'était pas autorisé que Linux autorise, mais je ne me souviens pas de ce que c'était main...

Je dirais que la «réponse» ci-dessus ne doit pas être marquée comme réponse, car ce n'est PAS la vraie réponse. C'est plus une décision de conception - je ne sais tout simplement pas quel (s) compromis.

Il peut y avoir des problèmes de sécurité non soulevés ci-dessus qui seraient des préoccupations valables, mais ceux ci-dessus ne sont pas valides.

OMI, cela devrait être une «valeur» réglable par le système dans «/ proc», mais de manière générale, je pense que la plupart des gens s'en moquent beaucoup.

S'il y en avait un fort besoin, 'chown' pourrait être amélioré et modifié pour le permettre, puis configuré avec setuid 'root' pour lui permettre de mettre en œuvre une telle politique.

Astara
la source
Les quotas sont toujours basés sur la propriété du fichier et non sur l' emplacement . Sinon, quelqu'un pourrait tout garder dedans /tmp.
user1686
+1, vous semblez très bien :). Sur les systèmes OpenSolaris (qui est en effet un descendant du système V), vous pouvez définir cela via une mountoption (ce paramètre peut donc être limité à un seul point de montage au lieu d'être à l'échelle du système selon votre suggestion de valeur réglable par le système): rstchown(la valeur par défaut ) pour limiter les modifications apportées au propriétaire du fichier à l'utilisateur racine, norstchownpour permettre aux utilisateurs non privilégiés de changer le propriétaire de leurs propres fichiers (ils ne peuvent pas le modifier).
WhiteWinterWolf
6

Eh bien, si quelqu'un pouvait changer la propriété, alors n'importe qui pouvait changer les autorisations pour accéder à n'importe quel fichier du système. C'est mauvais non seulement du point de vue des logiciels malveillants (aucun sudo requis), mais du point de vue d'un administrateur système. Si l'un des utilisateurs peut modifier l'un des fichiers, les autorisations de fichier sont inutiles.

Bonjour71
la source
2
Droite. J'ai modifié la question pour être clair: je faisais référence aux fichiers que l'utilisateur possède et non à aucun fichier.
Alexandru
1
@Alexandru: pensez à un utilisateur malveillant changeant myTrojan.shpour appartenir à root et avoir un drapeau SUID.
Benjamin Bannier du
@honk: a du sens maintenant.
Alexandru
5

Parce qu'alors l'utilisateur peut échapper aux quotas du système de fichiers. Si j'ai un quota de 100 Mo et que vous avez un quota de 100 Mo, je peux télécharger 100 Mo, chmod a + r, vous montrer, puis télécharger 100 Mo supplémentaires.


la source