Dlaczego mount wymaga uprawnień roota?

54

Dlaczego Linux wymaga, aby użytkownik był rootowany / korzystał z sudo / specjalnie autoryzowany dla każdego montowania, aby coś zamontować? Wydaje się, że decyzja, czy zezwolić użytkownikowi na zamontowanie czegoś, powinna opierać się na jego prawach dostępu do źródłowego wolumenu / udziału sieciowego i punktu podłączenia. Kilka zastosowań montowania użytkownika innego niż root to montowanie obrazów systemu plików w kierunku należącym do użytkownika i montowanie udziału sieciowego w katalogu należącym do użytkownika. Wygląda na to, że jeśli użytkownik ma kontrolę nad obiema stronami równania montowania, wszystko powinno być fajne.

Wyjaśnienie ograniczenia dostępu:

Wydaje mi się, że powinienem być w stanie zamontować wszystko, co w przeciwnym razie użytkownik miałby dostęp do punktu podłączenia, którego właścicielem jest użytkownik.

Na przykład na moim komputerze / dev / sda1 jest własnością użytkownika root i dysku grupy z uprawnieniami brw-rw----. Dlatego użytkownicy inni niż root nie mogą zadzierać z / dev / sda1 i najwyraźniej mount nie powinien zezwalać na ich montowanie. Jeśli jednak użytkownik jest właścicielem /home/my_user/my_imagefile.img i mount point / home / my_user / my_image / dlaczego nie powinien mieć możliwości zamontowania tego pliku obrazu w tym punkcie montowania za pomocą:

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

Jak zauważył Kormac, istnieje problem suid. Trzeba więc dodać pewne ograniczenia, aby zapobiec sytuacji, w której suid byłby problemem, a także potencjalnie innych problemów. Być może jednym ze sposobów na to byłoby sprawienie, aby system operacyjny traktował wszystkie pliki jako należące do użytkownika, który dokonał montowania. Jednak w przypadku prostego odczytu / zapisu / wykonania nie rozumiem, dlaczego byłby to problem.

Przypadek użycia:

Mam konto w laboratorium, w którym moja przestrzeń domowa jest ograniczona do 8 GB. To jest małe i bardzo irytujące. Chciałbym zamontować wolumin nfs z mojego osobistego serwera, aby zasadniczo zwiększyć ilość dostępnego miejsca. Ponieważ jednak Linux nie pozwala na takie rzeczy, utknąłem w plikach scp'ing tam iz powrotem, aby pozostać poniżej limitu 8 GB.

CrazyCasta
źródło
4
To brzmi jak problem nie jest tak dużo, że „Linux nie dopuszcza takie rzeczy”, jak ty nie wolno robić takich rzeczy w swoim laboratorium, ponieważ system może być skonfigurowany tak, aby pozwolić, aby to zrobić. Możesz omówić ten problem z osobami zarządzającymi systemem; jeśli nie są przyjaźni, to chodzi o politykę, a nie komputery;)
goldilocks
Czy można zamontować dowolne punkty montowania, do których ma się normalny dostęp? Wydaje się, że administrator musiałby dodać wyraźną linię do fstab dla mojego mounta NFS, aby na to zezwolić. To z kolei prawdopodobnie stworzyłoby precedens, w którym musieliby to zrobić również dla wszystkich innych, którzy o to poprosili, co, jak rozumiem, byłoby nie do utrzymania. Stąd pytanie, dlaczego Linux nie pozwala na montowanie dowolnych rzeczy, które byłyby bezpieczne (w pewien ograniczony sposób).
CrazyCasta
10
Próbowałeś sshfs? Zamontuje katalog zdalny ssh, tak jak ty, bez potrzeby dostępu do konta root. Wystarczy zainstalować FUSE (system plików w UserSpacE).
Arcege
1
Słyszeliście o problemie z uszkodzonym dyskiem twardym itp. Wiem, że mówiłem to już kilka razy, ale filozofia jest taka, że ​​„montowania dowolnych rzeczy” nie można zabezpieczyć i dlatego jest tak jest (należy ustalić szczególne wyjątki). BTW, jeśli nie masz BEZPIECZNIKA, sftpjest trochę przyjemniejszy w użyciu niż scp.
goldilocks,
1
Wygląda na to (odmiana), o co już tu wcześniej pytano: Zamontować plik pętli bez uprawnień roota?
Daniel Pryden

Odpowiedzi:

37

Jest to zarówno ograniczenie historyczne, jak i bezpieczeństwa.

Historycznie większość dysków nie była wymienna. Dlatego sensowne było ograniczenie montowania do osób, które miały legalny fizyczny dostęp i prawdopodobnie miałyby dostęp do konta root. Wpisy fstab pozwalają administratorom delegować montaż innym użytkownikom na dyski wymienne.

Z punktu widzenia bezpieczeństwa istnieją trzy główne problemy zezwalaniem arbitralnym użytkownikom na montowanie dowolnych urządzeń blokowych lub obrazów systemu plików w dowolnych lokalizacjach.

  • Montowanie w lokalizacji innej niż własność powoduje zacienianie plików w tej lokalizacji. Na przykład: zamontuj wybrany system plików /etcprzy użyciu /etc/shadowznanego hasła root. Jest to naprawione przez umożliwienie użytkownikowi zamontowania systemu plików tylko w katalogu, którego jest właścicielem.
  • Sterowniki systemu plików często nie były testowane tak dokładnie ze źle sformatowanym systemem plików. Błędny sterownik systemu plików może pozwolić użytkownikowi dostarczającemu nieprawidłowy system plików na wstrzyknięcie kodu do jądra.
  • Podłączenie systemu plików może pozwolić instalatorowi na pojawienie się niektórych plików, których w innym przypadku nie miałby uprawnień do tworzenia. Suid pliki wykonywalne i urządzenia są najbardziej oczywiste przykłady, i są one ustalone przez nosuidi nodevopcji, które są regulowane mający userw /etc/fstab.
    Dotychczasowe egzekwowanie userkiedymountnie jest wywoływany przez root wystarczy. Ale bardziej ogólnie możliwość tworzenia pliku należącego do innego użytkownika jest problematyczna: zawartość tego pliku może zostać przypisana przez rzekomego właściciela zamiast montera. Zwykła, zachowująca atrybuty kopia z katalogu głównego do innego systemu plików wygenerowałaby plik będący własnością zadeklarowanego, ale niezaangażowanego właściciela. Niektóre programy sprawdzają, czy żądanie użycia pliku jest uzasadnione, sprawdzając, czy plik należy do określonego użytkownika, i nie byłoby to już bezpieczne (program musi również sprawdzić, czy katalogi na ścieżce dostępu są własnością tego użytkownika; jeśli zezwolono na dowolne montowanie, musieliby również sprawdzić, czy żaden z tych katalogów nie jest punktem montowania, w którym montowanie nie zostało utworzone ani przez root, ani przez żądanego użytkownika).

Ze względów praktycznych można obecnie montować system plików bez rootowania za pomocą FUSE . Sterowniki FUSE działają jako użytkownik instalujący, więc nie ma ryzyka eskalacji uprawnień poprzez wykorzystanie błędu w kodzie jądra. Systemy plików FUSE mogą ujawniać tylko te pliki, które użytkownik ma uprawnienia do tworzenia, co rozwiązuje ostatni problem powyżej.

Gilles „SO- przestań być zły”
źródło
24

Jeśli użytkownik ma bezpośredni dostęp do zapisu do urządzenia blokowego i może zamontować to urządzenie blokowe, może napisać plik wykonywalny suid na urządzeniu blokowym, zamontować go i wykonać ten plik, a tym samym uzyskać dostęp do systemu root. To dlatego montaż zwykle ogranicza się do rootowania.

Teraz root może zezwolić zwykłym użytkownikom na montowanie z określonymi ograniczeniami, ale musi się upewnić, że jeśli użytkownik ma dostęp do zapisu do urządzenia blokowego, że mount nie zezwala na suid, a także devnodes, które mają podobny problem (użytkownik może tworzyć devnode, który daje im dostęp do zapisu do ważnego urządzenia, do którego nie powinni mieć dostępu do zapisu).

psusi
źródło
8

Nie zawsze wymaga to superużytkowników. Odman mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.
RS
źródło
Tak, masz rację, moje pytanie było trochę nieprecyzyjne. Wiem, że można uzyskać konkretną autoryzację na podstawie montażu. Wygląda jednak na to, że jeśli zarówno punkt podłączenia, jak i wolumin są własnością użytkownika, użytkownik powinien mieć możliwość podłączenia bez określonej autoryzacji.
3
@CrazyCasta: punkt podłączenia może być własnością użytkownika, ale węzeł urządzenia nie jest. Własność itp. Danych w partycji jest a) niepoznawalna, b) nieistotna.
goldilocks,
Ale co, jeśli węzeł urządzenia jest własnością użytkownika.
CrazyCasta
Następnie powinien istnieć równoległy wyjątek w fstab, ponieważ węzeł urządzenia należący do użytkownika byłby wyjątkowy na początek (spróbuj utworzyć). Ponownie, zasada jest taka, że ​​bezpieczny system jest ograniczony, a ludzie mają uprawnienia ... jeśli nie otrzymałeś uprawnień, niestety nie masz szczęścia. Zobacz, * nix nie sprzedaje magazynów o dużej pojemności bez recepty - potrzebujesz pozwolenia.
goldilocks,
Żeby było jasne, mount()wywołanie systemowe zawsze wymaga roota. narzędzia suid mogą stać się rootami i zezwalać użytkownikom innym niż root na montowanie, a jeśli mountpolecenie zostanie zainstalowane suid, zrobi to na podstawie flagi użytkownika w fstab. Inne pliki wykonywalne suid zostały napisane, aby umożliwić użytkownikom montowanie, takie jak pmount, co pozwala użytkownikom montować nośniki zewnętrzne i wymusza odpowiednie ograniczenia, takie jak nosuid, nodev.
psusi
5

Kormac i inni wskazali, że nie jest to dylemat, który przedstawiasz; wydaje mi się, że sprowadza się to do filozofii jawnego nadawania użytkownikom uprawnień w stosunku do systemu, w którym wszyscy użytkownicy mieliby niezmienne prawo do montowania systemu plików.

Gilles rozwiązuje niektóre problemy bezpieczeństwa związane z montowaniem systemów plików. Z mocą wsteczną uniknę prologicznej i stycznej dyskusji na temat potencjalnych problemów technicznych z tym związanych (patrz komentarze), ale uważam, że to uczciwe, że niezaufani użytkownicy nie mają niezmiennego prawa do montowania dysków twardych.

Problem w odniesieniu do wirtualnych i zdalnych systemów plików (lub zdalnych systemów plików za pośrednictwem wirtualnych systemów plików, a la FUSE) jest mniej znaczący, ale to nie rozwiązuje pytania bezpieczeństwa (chociaż FUSE może i na pewno rozwiązałoby twój problem). Ważne jest również, aby wziąć pod uwagę, że dostęp do danych w takich systemach plików można prawie zawsze uzyskać bez potrzeby instalowania urządzenia, albo poprzez przesyłanie plików, albo narzędzia, które wyodrębniają obrazy bez montażu, więc system, który nie pozwala na zamontowanie czegoś, robi nie stanowią problemu nie do pokonania w związku z dostępem do danych, które dziwnie umieściłeś w pliku obrazu, lub (co zrozumiałe) chcesz uzyskać z systemu zdalnego. Jeśli masz sytuację, w której tak nie jest, warto zapytać:

  1. Co dokładnie staram się zrobić?

  2. Gdzie próbuję to zrobić?

Jeśli administracja systemem jest sprawiedliwa, to # 2 wyjaśnia, dlaczego # 1 jest dla ciebie niemożliwy. Jeśli administracja systemem jest niesprawiedliwa, to jest to polityka . Rozwiązaniem problemu „Mój administrator sys jest niesprawiedliwy” nie jest przeprojektowanie systemu operacyjnego, aby administratorzy sys wszędzie nie mogli ograniczać użytkowników.

System pozwala superużytkownikowi ograniczyć Twoje działania, jawnie lub przez pominięcie („Nie zapewniamy BEZPIECZNIKA” itp.). Uprawnienia są jednym z mechanizmów, dzięki którym można to osiągnąć. Być może nie jest miło powiedzieć „nie musisz tego robić”, ale jeśli to prawda… que sera… nie musisz tego robić. Użyj ftp itp. Jeśli to nie jest prawda, powinieneś znęcać się nad osobami odpowiedzialnymi.

Złotowłosa
źródło
Twoja odpowiedź jest myląca, czy same woluminy (np. / Dev / sda1, / dev / sda2 itp.) Nie są chronione przed użytkownikami czytającymi / piszącymi? Zastanawiam się, dlaczego użytkownik nie może zamontować czegoś, do czego miałby dostęp. Aby wyjaśnić, jeśli mam plik obrazu, który mówi ext2, mógłbym napisać aplikację, która pozwala mi czytać / zapisywać z / do tego obrazu (oczywiście nie jako część systemu plików systemu operacyjnego). Wspomniana aplikacja nie będzie mogła czytać / zapisywać z partycji w / dev (chyba że partycje te zostały zmienione, aby umożliwić użytkownikowi dostęp do nich, co zwykle nie ma sensu).
CrazyCasta
PS Nie zgadzam się, że użytkownicy powinni mieć możliwość zamontowania systemu plików, do którego inaczej nie mieliby dostępu bez konkretnej autoryzacji, ponieważ sam montaż może potencjalnie spowodować jakieś działanie (takie jak sprawdzenie systemu plików), którego root nie chciał.
CrazyCasta
Montowanie obrazu nadal obejmuje węzły urządzeń (np. / Dev / loop). Masz rację, że stwarza to problem, ale „dokonywanie uzgodnień” będzie się różnić w zależności od systemu (na przykład istnieje ograniczona ilość urządzeń pętlowych), więc ponownie, dlatego domyślnie wszystko jest ograniczone. Ale to domyślne ustawienie może zostać zastąpione przez superużytkownika w imieniu kogokolwiek innego.
złotowłosa
To dobra uwaga na temat limitu węzłów urządzeń z pętlą zwrotną. Nie jestem do końca jasne, dlaczego potrzebne jest urządzenie z pętlą zwrotną, wydaje się nieco zbędne. Wiem, że to dlatego, że montowanie wymaga pliku blokowego, a nie normalnego. Nie rozumiem jednak, dlaczego tak się dzieje. Czy możesz zaoferować wgląd, na przykład, czy jądro traktuje urządzenia blokowe i zwykłe pliki zupełnie inaczej?
CrazyCasta
1
@goldilocks: Powodem, dla którego ta odpowiedź jest bzdurna, jest to, że twoja teoria ograniczenia jest bardzo przekonująca, ale jest całkowicie błędna, wspomniany problem nie istnieje. Zezwolenie na utworzenie wirtualnego systemu plików (takiego jak FUSE) nie pozwala na robienie czegokolwiek, co nie jest jeszcze możliwe w bardziej okrągły sposób przy użyciu IPC. Twoja notatka dotycząca przerwań na urządzeniach jest całkowicie nieistotna; jedyne znaczące przerwanie zdalne dla systemu plików pochodzi z karty sieciowej, która jest w całości obsługiwana przez jądro.
Lie Ryan,
5

FYI: Najnowsze jądra mają obsługę „przestrzeni nazw”. Zwykli użytkownicy mogą tworzyć przestrzeń nazw, aw obrębie tej przestrzeni nazw, stać się root i robić fajne rzeczy, takie jak montowanie systemów plików.

Nie daje ci jednak „prawdziwych” uprawnień superużytkownika - możesz robić tylko to, co już możesz (tzn. Możesz montować tylko urządzenia, które już potrafisz czytać).

http://lwn.net/Articles/531114/ Patrz sekcja 4.

BraveNewCurrency
źródło
Przestrzenie nazw są bardziej ograniczone. Możesz pojawić się rootw przestrzeni nazw użytkownika, ale nie pozwala na zamontowanie normalnych typów systemów plików, nawet jeśli możesz odczytać i zapisać urządzenie blokowe. Zobacz eksperyment 2 tutaj: unix.stackexchange.com/questions/517317/…
sourcejedi
0

Ponieważ dane w systemie plików, które zamierzają zamontować, mogą zagrozić bezpieczeństwu serwera, a nawet go zawiesić (jeśli został on celowo skonstruowany).

sendmoreinfo
źródło
Czy mógłbyś opracować? Nie jestem pewien, w jaki sposób „dane w systemie plików, który zamierzają zamontować”, zagroziłyby bezpieczeństwu. Jeśli potrafisz normalnie czytać / zapisywać plik, powinieneś być w stanie go zamontować (to mój argument). Jeśli mogę odczytać / napisać punkt montowania, powinienem być w stanie zainstalować wszystko, z wyjątkiem montowania go w katalogu. Jeśli nie możesz go odczytać / napisać lub nie możesz wyświetlić katalogu, w którym się znajduje, aby sprawdzić, czy istnieje, wówczas mount nie powiedzie się tak samo, jak komenda ls lub cat.
Twój argument jest ważny, jeśli „ty” jesteś pojedynczym użytkownikiem; pamiętaj, że Linux (i Unix) to systemy dla wielu użytkowników, w których użytkownicy niekoniecznie są zaufani.
sendmoreinfo
Pliki binarne suid mogą być dodane do urządzenia, zamontowane na twoim pudełku i użyte do zrootowania pudełka, dlatego domyślnie owneri user(s)ustawiane nosuid. Nie chciałbyś, aby ktoś mógł to łatwo ominąć, umożliwiając ręczne usunięcienosuid
RS
@sendmoreinfo Wiem, że Linux to system dla wielu użytkowników, nie trzeba patronować. Zastanawiam się, dlaczego nie mogę montować udziałów sieciowych i plików obrazów, do których w przeciwnym razie mam duży dostęp. Odpowiedź kormoc jest pouczająca, chociaż jestem ciekawy, dlaczego niektóre flagi nie mogły zostać narzucone użytkownikom innym niż root (np. nosuid), aby to naprawić. Wydaje się, że powinienem być w stanie zamontować w celu prostego odczytu / zapisu pliku obrazu / udziału sieciowego, do którego w przeciwnym razie mam dostęp do posiadanego punktu montowania.
CrazyCasta
1
@CrazyCasta WRT „powodując awarię systemu”, z pewnością można zamontować wadliwy sprzęt, który wykorzystuje luki w interfejsie sprzętowym. Każdy, kto miał dysk twardy z wystarczającą ilością uszkodzonych bloków, może powiedzieć ci, jak może wpłynąć na jądro (a zatem i cały system) - przechodzi w zajętą ​​pętlę i skutecznie paraliżuje cały zestaw i kaboodle. Prawdopodobnie u podstaw leży logika, która uniemożliwia jej rozwiązanie, ponieważ jest to dobrze znany problem, który istniał od dawna bez rozwiązania.
Złotowłosa
0

W GNOME, gvfs nie wymaga roota do montowania zdalnego systemu plików (ftp lub ssh), a gnome-mount również nie potrzebuje roota do montowania pamięci zewnętrznej (napęd USB, CD / DVD itp.).

Większość systemów prawdopodobnie nie chciałby mieć całego GNOME tylko do jakiegoś zdalnego montażu, wtedy możesz użyć lufs , sshfs lub ftpfs .

gvfs, lufs, sshfs i ftpfs używają FUSE, aby umożliwić użytkownikom innym niż root montowanie wirtualnego systemu plików; i w przeciwieństwie -o userdo mountów, FUSE nie wymaga od sysadmin ustawiania określonych mountów. Tak długo, jak masz uprawnienia do katalogu montowania i do wszelkich zasobów potrzebnych do zbudowania systemu plików, możesz utworzyć FUSE.

Dlaczego mount wymaga uprawnień roota?

Ponieważ mountjest głównie / pierwotnie przeznaczony dla lokalnego systemu plików, który prawie zawsze wymaga sprzętu.

Lie Ryan
źródło