Dlaczego nieuprzywilejowany użytkownik nie może zmienić właściciela pliku?

15

Z chown (2):

Tylko proces uprzywilejowany (Linux: jeden z funkcją CAP_CHOWN) może zmienić właściciela pliku. Właściciel pliku może zmienić grupę pliku na dowolną grupę, której członek jest członkiem. Uprzywilejowany proces (Linux: z CAP_CHOWN) może dowolnie zmienić grupę.

Jaki jest powód tego ograniczenia? Dlaczego nieuprzywilejowany użytkownik nie może zmienić właściciela pliku, który posiada (tj. Nie / etc / shadow)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted
Alexandru
źródło

Odpowiedzi:

27

Pozwalając użytkownikom na „rozdawanie” plików, możesz korzystać z różnych funkcji systemu operacyjnego. Jak na przykład:

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
źródło
8

To tylko osobisty wybór projektantów Linuksa, aby na to nie zezwalać - wszystkie podane pseudo-zabezpieczenia są podstępne, ponieważ istnieją systemy uniksowe, które to umożliwiają.

Myślę, że ta funkcjonalność sprowadzała się do tego, czy zachowanie twojego uniksa było zgodne z „System-V” (AT&T) czy Berkeley's unix (BSD) ...

Jeśli chodzi o inne wymienione kwestie bezpieczeństwa:

  • Podszywanie się pod innego użytkownika (lub nawet użytkownika root) przez setuid.

    Brak problemu: zmiana „właściciela” usuwa wszystkie bity „setXid” (U / G)

  • Brak wystarczających uprawnień do cofnięcia pomyłki

    W rzeczywistości nie jest to „zagrożenie bezpieczeństwa”, ALE, może być w systemach, które pozwalają na zmianę użytkownika, możesz zmienić to z powrotem, jeśli znajduje się w katalogu, który posiadasz, w przeciwnym razie: „bądź ostrożny”!

  • Sprawiając, że ktoś utworzył dany plik.

    Nadal byłby w katalogu, który możesz zapisać. Tj. Nie możesz przenieść go do ich katalogu głównego, chyba że ma on otwarty zapis do twojej grupy lub wszystkich (lub szczególnie jeśli ACL są dostępne).

  • Konfigurowanie zadań cron do uruchamiania na kontach innych użytkowników.

    Znowu nie zadziałałoby - ponieważ crondir są własnością użytkownika i nie są ustawione tak, aby były czytelne dla innych użytkowników, nie mówiąc już o zapisywaniu.

  • jeśli ktokolwiek może zmienić własność, to każdy może zmienić uprawnienia do uzyskania dostępu do dowolnego pliku w systemie.

    Nie: tylko jeśli użytkownik „jest właścicielem” katalogu zawierającego ten plik. To znaczy, że mogę przekazać plik o nazwie „passwd” do rootowania, ale nie mogłem go przenieść do / etc /, chyba że mam uprawnienia do zapisu do / etc /.

  • kwoty

    Potencjalnie ważny punkt - JEŻELI korzystasz z przydziałów, ale wydaje się, że łatwo byłoby wykryć, jeśli zsumujesz miejsce na dysku według katalogu domowego; Jedynym problemem byłyby katalogi, które mogą być zapisywane przez wielu użytkowników. W takim przypadku może pójdzie właściciel tego „reż”. To MOŻE być w przypadku tych systemów, że wsparcie „rozdawanie” plików, które można to zrobić tylko w katalogach, że „własne”, ale to był długi czas odkąd faktycznie w systemie, który pozwala na to, aby Nie pamiętam dokładnych ograniczeń.

Wydaje mi się, że pamiętam pewne kompromisy za umożliwienie „rozdawania plików” ... np. - w systemach, które na to pozwoliły, coś innego nie było dozwolone, na co pozwala Linux, ale nie pamiętam, co było wyłączone dłoń...

Powiedziałbym, że powyższa „odpowiedź” powinna zostać odznaczona jako odpowiedź, ponieważ NIE jest to prawdziwa odpowiedź. To bardziej decyzja projektowa - po prostu nie wiem, jakie były kompromisy.

Mogą istnieć problemy bezpieczeństwa nie podniesione powyżej, które byłyby uzasadnione, ale powyższe nie są prawidłowe.

IMO, powinna to być ustawialna przez system „wartość” w „/ proc”, ale ogólnie mówiąc, myślę, że większość ludzi nie przejmuje się tak bardzo.

Jeśli zajdzie taka potrzeba, „chown” może zostać ulepszony pod kątem bezpieczeństwa i zmodyfikowany, aby na to pozwolić, a następnie skonfigurować w / setuid „root”, aby umożliwić mu wdrożenie takiej polityki.

Astara
źródło
Przydziały zawsze zależą od własności pliku , a nie od lokalizacji . W przeciwnym razie ktoś mógłby wszystko zatrzymać /tmp.
user1686,
+1, wydajesz się cholernie słuszny :). W systemach OpenSolaris (które w rzeczywistości jest potomkiem Systemu V) można to ustawić za pomocą mountopcji (ustawienie to można zatem ograniczyć do jednego punktu montowania zamiast całego systemu, zgodnie z sugestią wartości ustawialnej dla systemu): rstchown(domyślnie ), aby ograniczyć zmiany właściciela pliku do użytkownika root, norstchownaby umożliwić nieuprzywilejowanym użytkownikom zmianę właściciela własnych plików (nie mogą go zmienić z powrotem).
WhiteWinterWolf
6

Cóż, jeśli ktoś może zmienić własność, to każdy może zmienić uprawnienia do uzyskania dostępu do dowolnego pliku w systemie. Jest to złe nie tylko z punktu widzenia złośliwego oprogramowania (nie wymaga sudo), ale z punktu widzenia sysadmin. Jeśli którykolwiek z użytkowników może zmienić dowolny z plików, uprawnienia do plików są bezużyteczne.

Cześć71
źródło
2
Dobrze. Zmodyfikowałem pytanie, aby było jasne, że mam na myśli pliki, które użytkownik posiada, a nie żaden plik.
Alexandru
1
@Alexandru: pomyśl o złośliwym użytkowniku zmieniającym się myTrojan.shna roota i flagę SUID.
Benjamin Bannier
@honk: teraz ma sens.
Alexandru
5

Ponieważ wtedy użytkownik może uniknąć kwot systemu plików. Jeśli mam limit 100 MB, a limit 100 MB, mogę przesłać 100 MB, przesłać chmod a + r, sprawdzić, a następnie przesłać kolejne 100 MB.


źródło