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

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

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

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.

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.

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.