Dlaczego pliki wykonywalne np. / Usr / sbin są zapisywane przez root?

Czy możesz wyjaśnić, dlaczego skompilowany plik binarny (na przykład /usr/sbin) ma uprawnienia do zapisu dla rootużytkownika?

Dla mnie to jest skompilowane. Oznacza to, że bezpośredni zapis nie ma zastosowania i może w jakiś sposób narazić plik na pewne problemy z bezpieczeństwem.

Skrypt (np. bashPlik) może być zapisywalny, ponieważ jest to w zasadzie plik tekstowy, ale dlaczego jest taki sam dla skompilowanego pliku, w którym, o ile wiem, nie jest konieczne żadne zapisywanie?

Z góry dziękuję za opinię.

— t1m0th33
źródło

Aby wyjaśnić, zastanawiasz się, dlaczego użytkownik rootma uprawnienia do zapisu do pliku binarnego? Jeśli nic innego nie pomogłoby to podczas aktualizacji tego pakietu.

— Eric Renouf,

Zauważ, że ironicznie pliki binarne są jedynymi plikami, które zwykle zapisujemy / edytujemy bezpośrednio na dysku. Nie możemy tego zrobić w przypadku plików tekstowych, takich jak skrypty, ponieważ modyfikacje tekstu polegają na nie zapisywaniu do pliku, ale dodawaniu dodatkowych bajtów na środku pliku lub usuwaniu bajtów na środku pliku. Nie można tego zrobić z fseek fwrite. W przypadku plików tekstowych zwykle odczytujemy pamięć RAM, a następnie usuwamy stary plik i zapisujemy zawartość pamięci RAM na dysk (tj. Nadpisujemy). Ponadto podczas instalowania, przenoszenia lub zastępowania plików wykonywalnych zapisujesz na dysku, więc potrzebujesz uprawnień do zapisu.

— slebetman

@slebetman: Możesz bezpośrednio edytować pliki tekstowe. Na przykład otwórz plik, rozszerz go, mapuj pamięć, użyj, memmove()aby przesunąć ostatnią część na koniec i otworzyć otwór, a następnie wstawić nowy tekst do otworu. Lub możesz użyć serii pread()/, pwrite()aby zrobić to samo.

— Zan Lynx,

@EricRenouf Właściwie, uprawnienia do zapisu pliku binarnego nie są wymagane do aktualizacji pakietu, który go zawiera. Podczas aktualizacji pakietu stary plik binarny nie jest zapisywany; w rzeczywistości jest to niemożliwe, jeśli plik binarny jest obecnie uruchomiony (wyszukaj ETXTBSY). Zamiast tego stary plik binarny jest usuwany , a nowy plik binarny jest zapisywany w nowym pliku o tej samej nazwie. Usuwanie plików nie wymaga do nich uprawnień do zapisu, a jedynie do katalogu zawierającego (tj /usr/sbin/.).

— marcelm

@marcelm: Ściśle mówiąc, nie używasz tylko fseek i piszesz, buforujesz resztę do pamięci RAM. Możesz także buforować pozostałą część do innego pliku. Lub możesz napisać nową zawartość do nowego pliku. Żaden z nich nie pozwala na rozszerzenie plików tekstowych bez jakiegoś dużego bufora.

— slebetman

Tak naprawdę nie ma znaczenia, czy pliki w /bin(lub w innym standardowym katalogu, w którym przechowywane są pliki wykonywalne) są zapisywane przez root, czy nie. Na serwerze Linux, którego używam, są one zapisywane przez root, ale na moim komputerze OpenBSD nie.

Tak długo, jak nie są zapisywalne przez grupę lub przez „inne”!

Nie ma problemu z bezpieczeństwem, np

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Jeśli ktoś chciałby go zastąpić, musiałby być rootem, a jeśli tak, rooti to, to albo

instalowanie nowej wersji lub
niezdarny lub
atakujący z uprawnieniami roota już .

Inną rzeczą do rozważenia jest to, że root może zapisywać do pliku bez względu na to, czy jest chroniony przed zapisem, czy nie, ponieważ ... root.

Zauważ też, że „skrypt” jest tak samo wykonywalny jak plik binarny. Skrypt nie musi być zapisywalny „ponieważ jest to plik tekstowy”. Jeśli już, to prawdopodobnie powinno mieć takie same uprawnienia jak inne pliki wykonywalne w tym samym katalogu.

Nie zmieniaj teraz uprawnień do wszystkiego! Może to powodować wszelkiego rodzaju spustoszenie i potencjalnie dezorientować menedżerów pakietów, którzy mogą sprawdzić, czy uprawnienia są ustawione poprawnie. Może również narazić system na niebezpieczeństwo, jeśli przypadkowo zmienisz uprawnienia w niewłaściwy sposób w aplikacji o kluczowym znaczeniu dla bezpieczeństwa.

Po prostu załóż, że uprawnienia do plików wykonywalnych są ustawione poprawnie, chyba że znajdziesz coś, co wygląda naprawdę dziwnie, w takim przypadku prawdopodobnie powinieneś skontaktować się z odpowiednim opiekunem pakietu, aby zweryfikować, a nie zacząć zmieniać rzeczy.

Z komentarzy i na czacie było wezwanie do historii.

Historia uprawnień do plików binarnych w systemie Linux nie jest niczym, o czym wiem. Można spekulować, że po prostu odziedziczyli uprawnienia z katalogu lub po prostu z domyślnego umasksystemu Linux, ale tak naprawdę nie wiem.

Wiem tylko, że OpenBSD instaluje pliki binarne w systemie podstawowym ¹ z domyślnym trybem uprawnień 555 ( -r-xr-xr-x). Jest to określone we fragmencie Makefile, w /usr/share/mk/bsd.own.mkktórym ustawia się BINMODEna 555 (chyba że jest już ustawione). Jest to później używane podczas instalowania plików wykonywalnych podczas make buildin /usr/src.

Spojrzałem na opatrzony adnotacjami dziennik CVS tego pliku i stwierdziłem, że ta linia w pliku pozostaje niezmieniona, ponieważ została zaimportowana z NetBSD w 1995 roku.

Na NetBSD plik został po raz pierwszy umieszczony w CVS w 1993 roku, z BINMODEustawieniem 555.

Projekt FreeBSD wydaje się być używany dokładnie ten sam plik jako NetBSD co najmniej od 1994 roku , a z później popełnić dodaje podpowiedź w commit wiadomość, że stare pliki zostały z wydaniem 4.4BSD z Berkeley Software Distribution.

Poza tym CSRG w Berkeley zachowało źródła w SCCS, ale ich repozytorium jest dostępne w formie Git na GitHub ² . Wydaje się, że akta, które tutaj zajmujemy się badaniem kryminalistycznym, zostały popełnione przez Keitha Bostica (lub kogoś bliskiego) w 1990 roku.

To jest ta historia. Jeśli chcesz dlaczego , to chyba będziemy musieli zapytać Keitha. Miałem nadzieję, że zobaczę komunikat zatwierdzenia zmiany, który mówi „ to musi być 555, ponieważ ... ”, ale nie.

¹ _{Systemy BSD mają bardziej rygorystyczny podział na „system podstawowy” i „pakiety innych firm” (porty / pakiety) niż Linux. System podstawowy jest spójną jednostką, która zapewnia pełny zestaw funkcji do uruchamiania systemu operacyjnego, podczas gdy porty lub pakiety są postrzegane jako „oprogramowanie lokalne” i są instalowane pod nimi /usr/local.}

² _{Bardziej kompleksowe repozytorium GitHub uwolnień Unix od 70. roku dostępna jest zbyt .}

— Kusalananda
źródło

Dziękuję za odpowiedź. Zezwolenie na pisanie jest normalne, ponieważ tak naprawdę nie ma znaczenia, jako użytkownik root (może zrobić wszystko). Ale ponieważ to tak naprawdę nie ma znaczenia, dlaczego nie pozwolimy na zapis, jeśli jest taki sam od samego początku? Czy to arbitralna decyzja?

— t1m0th33

@ t1m0th33 Wierzę, że może to być arbitralna decyzja, którą ktoś podjął, tak. Jak powiedziałem, w moim systemie OpenBSD pliki w tych lokalizacjach nie są zapisywane przez root.

— Kusalananda

Nie sądzę, żeby była to świadoma decyzja. Menedżer pakietów domyślnie instaluje plik z bitami uprawnień, które zakończyły się podczas procesu kompilacji; podczas budowania konsolidatora utworzyłem pliki z uprawnieniami 755, ponieważ to właśnie otrzymujesz po odjęciu umask od 777, a root umask (na maszynach kompilacyjnych dostawcy systemu operacyjnego) miał podczas budowania 022, ponieważ 022 jest domyślną umaską dla wszystkich i tworzeniem będzie to 222, ponieważ root byłby bezcelowy dodatkowej pracy.

— Henning Makholm

+1 za „Nie zmieniaj teraz uprawnień do wszystkiego!” I tak wiele takich pytań dotyczące ASK Ubuntu gdzie użytkownik zrobili chmod -R na /usrlub /vari zaskoczenia - ich sudonie działa lub coś innego nie działa.

— Sergiy Kolodyazhnyy

Historycznie brak uprawnień do zapisu dla roota nie miałby żadnego efektu (root może chmodować wszystko, a nawet nie musi, ponieważ root nigdy nie dostaje EPERM przy otwartym lub pisaniu). Zastanawiam się, czy te 555 rzeczy się zaczęły, ponieważ faktycznie stało się możliwe ograniczenie roota (kiedy po raz pierwszy pojawiły się bezpieczne poziomy? Mniej więcej w tym samym czasie co 4.4BSD lub wczesne 386BSD / NetBSD?)