
Aus chown(2):
Nur ein privilegierter Prozess (Linux: einer mit der Fähigkeit CAP_CHOWN) kann den Besitzer einer Datei ändern. Der Besitzer einer Datei kann die Gruppe der Datei in jede beliebige Gruppe ändern, deren Mitglied er ist. Ein privilegierter Prozess (Linux: mit CAP_CHOWN) kann die Gruppe beliebig ändern.
Was ist der Grund für diese Einschränkung? Warum kann ein nicht privilegierter Benutzer den Dateibesitz einer Datei, die ihm gehört, nicht ändern (d. h. kein /etc/shadow)?
$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted
Antwort1
Wenn Sie Benutzern erlauben, Dateien „herzugeben“, verstoßen Sie gegen verschiedene Funktionen des Betriebssystems. Zum Beispiel:
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...
Antwort2
Es ist nur eine persönliche Entscheidung der Linux-Entwickler, dies nicht zuzulassen - aus allen pseudo-Sicherheitsgründen,gegeben, sind trügerisch, da es Unix-Systeme gibt, die dies erlauben.
Ich denke, diese Funktionalität hing davon ab, ob das Verhalten Ihres Unix dem von „System-V“ (AT&T) oder dem von Berkeley (BSD) folgte …
Zu den anderen erwähnten Sicherheitsproblemen:
Über Setuid die Identität eines anderen Benutzers (oder sogar Root) annehmen.
Kein Problem: Durch Ändern des „Eigentümers“ werden alle „setXid“-Bits gelöscht (U/G).
Unzureichende Berechtigungen zum Rückgängigmachen eines fehlerhaften Chowns
Eigentlich kein „Sicherheitsrisiko“, ABER es könnte auf Systemen, die eine Benutzeränderung zulassen, eines sein. Sie können es wieder ändern, wenn es sich in einem Verzeichnis befindet, das Ihnen gehört. Ansonsten gilt: „Seien Sie vorsichtig“!
Es so aussehen lassen, als ob jemand anderes eine bestimmte Datei erstellt hätte.
Es wäre immer noch in einem Verzeichnis, das für Sie beschreibbar ist. D. h. Sie könnten es nicht in ihr Home-Verzeichnis verschieben, es sei denn, sie haben es zum Schreiben für Ihre Gruppe oder alle geöffnet (oder speziell für Sie, wenn ACLs verfügbar sind).
Einrichten von Cron-Jobs zur Ausführung auf den Konten anderer Benutzer.
Auch das würde nicht funktionieren, da die Crondirs dem Benutzer gehören und nicht einmal so eingestellt sind, dass sielesbarvon anderen Benutzern, geschweige denn beschreibbar.
Wenn jeder den Eigentümer ändern könnte, könnte jeder die Berechtigungen ändern, um Zugriff auf alle Dateien im System zu erhalten.
Nö: nur wenn der Benutzer das Verzeichnis „besitzt“, das diese Datei enthält. Ich kann also root eine Datei mit dem Namen „passwd“ geben, aber ich kann sie nicht nach /etc/ verschieben, es sei denn, ich habe Schreibberechtigung für /etc/.
Quoten
Ein möglicherweise gültiger Punkt –WENNSie verwenden Kontingente, aber es scheint, als wäre es leicht zu erkennen, wenn Sie den Speicherplatz nach Home-Verzeichnis zusammenfassen. Das einzige Problem wäre in Verzeichnissen, die von mehreren Benutzern beschreibbar sind. In diesem Fall sollten Sie sich vielleicht nach dem Besitzer dieses „Verzeichnisses“ richten. EsMAIAuf Systemen, die das „Verschenken“ von Dateien unterstützen, kann es sein, dass Sie dies nur in Verzeichnissen tun können, die Ihnen „gehören“, aber es ist schon SEHR lange her, dass ich tatsächlich an einem System gearbeitet habe, das dies zulässt, daher erinnere ich mich nicht mehr an die genauen Einschränkungen.
Ich meine mich zu erinnern, dass es einen Kompromiss gab, wenn man das „Verschenken von Dateien“ erlaubte … z. B. war auf Systemen, die das erlaubten, etwas anderes nicht erlaubt, was Linux erlaubt, aber ich kann mich nicht spontan erinnern, was das war …
Ich würde sagen, die obige „Antwort“ sollte nicht als Antwort gekennzeichnet werden, da es NICHT die wirkliche Antwort ist. Es ist eher eine Designentscheidung – ich weiß einfach nicht, was die Kompromisse waren.
Möglicherweise gibt es Sicherheitsprobleme, die oben nicht angesprochen wurden, aber berechtigte Bedenken darstellen könnten, aber die oben genannten sind nicht gültig.
Meiner Meinung nach sollte es ein vom System einstellbarer „Wert“ in „/proc“ sein, aber im Allgemeinen glaube ich, dass es den meisten Leuten ziemlich egal ist.
Wenn es wirklich nötig wäre, könnte die Sicherheit von „chown“ verbessert und entsprechend geändert werden. Anschließend könnte es mit dem Setuid „root“ eingerichtet werden, um die Implementierung einer solchen Richtlinie zu ermöglichen.
Antwort3
Wenn jeder den Eigentümer ändern könnte, könnte jeder auch die Berechtigungen ändern, um auf jede Datei im System zuzugreifen. Das ist nicht nur aus Sicht der Malware schlecht (kein Sudo erforderlich), sondern auch aus Sicht eines Systemadministrators. Wenn jeder Benutzer eine der Dateien ändern könnte, wären die Dateiberechtigungen nutzlos.
Antwort4
Denn dann kann der Benutzer Dateisystemkontingente umgehen. Wenn ich ein Kontingent von 100 MB habe und Sie ein Kontingent von 100 MB haben, kann ich 100 MB hochladen, chmod a+r, chown Sie und dann weitere 100 MB hochladen.