Dlaczego zwykły użytkownik nie może „zmienić” pliku?

Dlaczego chownpolecenie jest tylko do rootowania? Dlaczego użytkownicy inni niż root nie mogą używać chown do rozdawania swoich plików?

permissions not-root-user chown

— flegma
źródło

Nie mogę zrozumieć, że twoje polecenie chown może być używane również przez użytkownika innego niż root

— harish.venkat

Może źle to zrozumiałem. Dokładnie pytanie mojego profesora brzmiało: „Dlaczego przenoszenie praw od zwykłego użytkownika jest niedozwolone w systemach UNIX?” ...

— fleg

Myślę, że prawdziwe pytanie brzmi: dlaczego nie mogą użytkownicy inni niż root używać chowndo rozdania pliki są właścicielami. (Widziałem systemy, w których, w zależności od konfiguracji systemu plików, możesz.)

— Keith Thompson,

powiązane: askubuntu.com/questions/95985/…

— Ciro Santilli 29 改造中心法轮功六四事件

Odpowiedzi:

Większość systemów uniksowych uniemożliwia użytkownikom „rozdawanie” plików, co oznacza, że użytkownicy mogą uruchamiać się tylko chownwtedy, gdy mają uprawnienia użytkownika docelowego i grupy. Ponieważ używanie chownwymaga posiadania pliku lub bycia rootem (użytkownicy nigdy nie mogą przywłaszczyć plików innych użytkowników), tylko root może uruchomić, chownaby zmienić właściciela pliku na innego użytkownika.

Powodem tego ograniczenia jest to, że przekazanie pliku innemu użytkownikowi może pozwolić na złe rzeczy w nietypowych, ale wciąż ważnych sytuacjach. Na przykład:

Jeśli system ma włączone przydziały dysku, Alice może utworzyć plik do zapisu na świecie w katalogu dostępnym tylko dla niej (aby nikt inny nie mógł uzyskać dostępu do tego pliku do zapisu na świecie), a następnie uruchomić, chownaby plik ten był własnością innego użytkownika Billa. Plik byłby wtedy wliczany do limitu dysku Billa, nawet jeśli tylko Alice może go użyć.
Jeśli Alice oddaje plik Billowi, nie ma śladu, że Bill go nie utworzył. Może to stanowić problem, jeśli plik zawiera nielegalne lub w inny sposób naruszające dane dane.
Niektóre programy wymagają, aby ich plik wejściowy należał do konkretnego użytkownika w celu uwierzytelnienia żądania (na przykład plik zawiera instrukcje, które program wykona w imieniu tego użytkownika). Zwykle nie jest to bezpieczny projekt, ponieważ nawet jeśli Bill utworzył plik zawierający poprawne składniowo instrukcje, być może nie zamierzał ich wykonać w tym konkretnym czasie. Niemniej jednak zezwolenie Alicji na utworzenie pliku z dowolną zawartością i pobranie go jako danych wejściowych od Billa może tylko pogorszyć sytuację.

— Gilles
źródło

W poprzednim zadaniu zbudowałem system oprogramowania, który zależał od niemożności rozdawania plików. Wykorzystał własność pliku, aby sprawdzić, czy wniosek został przesłany przez konkretnego użytkownika. Podczas instalacji sprawdzał, czy rozdawanie plików jest dozwolone, a jeśli tak, to odmówił kontynuacji.

— Keith Thompson,

Inną bardziej krytyczną kwestią jest to, że użytkownik może skopiować /bin/bash, ustawić go, a następnie udostępnić dowolnemu chown. Teraz mają dostęp do powłoki jako ta osoba.

— Patrick,

@Patrick chownzawsze usuwa bity setuid i setgid.

— Gilles

@Gilles i nie bez powodu ... jeśli mógłbyś gdzieś skopiować plik binarny powłoki, możesz uzyskać do niego dostęp, ustawić na nim bity setuid / gid i zmienić go na rootowanie (lub dowolną ich kolejność, która daje ci 6755/0: 0 perms / własność) możesz uzyskać root w tym systemie. Och, dokładnie przegapiłem komentarz Patricka.

— hanetzer

Ok, ale jeśli jestem właścicielem dir ( drwxr-xr-x ring0 ring0 .), w którym korzeń ma regularny plik ( -rw-r--r-- root root file), to dlaczego nie mogę zrobić, chown ring0 fileponieważ jest to i tak wolno, jak ring0, cp file x ; rm file ; mv x file(a niektóre opcjonalne touch sometime file...)?

— Pierścień Ø

W Linuksie potrzebujesz zdolności CAP_CHOWN do chown. root otrzymuje takie. Wyjaśnienia : http://vouters.dyndns.org/tima/Linux-OpenVMS-C-Implementing_chown.html w celu uzyskania wyjaśnień. Jeśli zamierzasz udostępnić funkcję CAP_CHOWN, skompiluj swój kod za pomocą libcap-ng lub libcap, jak pokazano przez: http://vouters.dyndns.org/tima/Linux-PAM-C-Pluggable_Authentication_Modules_programming_example.html gdzie musisz po prostu wymienić CAP_AUDIT_WRITE z CAP_CHOWN.

— użytkownik1910461
źródło

+1, ponieważ nie musisz być rootem. Ponieważ nie musisz już być rootem.

— ctrl-alt-delor

Czasami nawet nie potrzebujesz CAP_CHOWN: unix.stackexchange.com/questions/399975/... Z mojego lektury źródła jądra, każda implementacja systemu plików ma za zadanie sprawdzenie uprawnień do zmiany. I wygląda na to, że w NFS uprawnienia są sprawdzane po stronie serwera. A jeśli serwer jest ... dziwny ... to jest to możliwe.

— Mike S

Możesz uruchomić polecenie, ale nie zadziała, jeśli nie jesteś rootem. To proste: wyobraź sobie użytkownika, który może zmienić oprogramowanie na użytkownika root. Może dodać bit setuida i, voilà, facet jest rootem! Tak więc użycie może dodać bit z chmod, ale nie ma szansy na zmianę właściciela plików.

— Dom
źródło

Nie możesz dodać bitu setuid do pliku, którego nie jesteś właścicielem, a implementacje, które pozwalają na rozdawanie plików, usuwają bit setuid.

— Gilles

Myślę, że sednem odpowiedzi Dom jest to: Wyobraź sobie, że możesz. Wtedy będą kłopoty. Twój punkt, którego nie możesz, jest poprawny. Ale OP pyta „dlaczego?” Usunięcie bitu setuid to kolejna funkcja bezpieczeństwa, która ponownie nasuwa pytanie „dlaczego?” Który chciałbym następnie odnieść się do odpowiedzi Dom: JEŚLI użytkownik może się oderwać, a JEŚLI użytkownik może być setuid, wtedy ta kombinacja byłaby katastrofalna. Myślę, że ma rację, nawet jeśli trochę brakuje.

— Mike S