Nie zgodzę się z odpowiedziami, które mówią, że winę ponosi wiek modelu bezpieczeństwa Uniksa lub środowisko, w którym został opracowany. Nie sądzę, żeby tak było, ponieważ istnieją mechanizmy, które pozwalają sobie z tym poradzić.

System uprawnień roota ma sens, ale w systemach stacjonarnych wydaje się, że chroni niewłaściwe dane.

superużytkownik ma uprawnienia do ochrony systemu przed jego użytkownikami. Uprawnienia na kontach użytkowników służą do ochrony konta przed kontami innymi niż root.

Wykonując program, dajesz mu uprawnienia do robienia rzeczy z Twoim UID. Ponieważ twój UID ma pełny dostęp do twojego katalogu domowego, przejściowo dałeś programowi ten sam dostęp. Tak jak superużytkownik ma dostęp do wprowadzania zmian w plikach systemowych, które wymagają ochrony przed złośliwym zachowaniem (hasła, konfiguracja, pliki binarne), tak możesz mieć dane w swoim katalogu domowym, które wymagają tego samego rodzaju ochrony.

zasada najniższych przywilejów mówi, że nie należy dawać więcej dostępu, niż jest to absolutnie konieczne. Proces decyzyjny dotyczący uruchomienia dowolnego programu powinien być taki sam w odniesieniu do plików, jak do plików systemowych. Jeśli nie dałbyś fragmentu kodu, któremu nie ufasz nieograniczonemu korzystaniu z konta superużytkownika w interesie ochrony systemu, nie powinieneś zezwalać na nieograniczone korzystanie ze swojego konta w celu ochrony danych.

Czy nie ma sposobu, aby zapobiec wystąpieniu złośliwego kodu w $ HOME? I dlaczego nikogo to nie obchodzi?

Unix nie oferuje tak szczegółowych uprawnień z tego samego powodu nie ma osłony ostrza wokół polecenia rm: uprawnienia nie służą do ochrony użytkowników przed nimi samymi.

Aby zapobiec uszkodzeniu plików w katalogu domowym przez złośliwy kod, nie należy uruchamiać go przy użyciu konta. Utwórz oddzielnego użytkownika, który nie ma żadnych specjalnych uprawnień i uruchamiaj kod z tym UID, dopóki nie zdecydujesz, czy możesz mu ufać.

Są na to inne sposoby, na przykład więzienia chroot , ale ich ustawienie wymaga więcej pracy, a ucieczka od nich nie jest już wyzwaniem, jakim była kiedyś.

Ponieważ model zabezpieczeń oparty na systemie UNIX ma 50 lat.

UNIX stanowi podstawę większości rozpowszechnionych systemów operacyjnych, a nawet duży wyjątek na Windows miał większy wpływ niż się wydaje . Wynika to z czasów, gdy komputery były dużymi, drogimi, powolnymi maszynami używanymi wyłącznie przez magicznych specjalistów.

W tamtym czasie użytkownicy po prostu nie mieli obszernych zbiorów danych osobowych na żadnym komputerze, ani na serwerze uniwersyteckim, ani na komputerze osobistym (a już na pewno na telefonie komórkowym). Dane, które różniły się od użytkownika do użytkownika, były zazwyczaj danymi wejściowymi i wyjściowymi naukowych procesów obliczeniowych - ich utrata może stanowić stratę, ale w dużej mierze taką, którą można by zrekompensować poprzez ich ponowne obliczenie, z pewnością w niczym nie przypominają skutków dzisiejszych wycieków danych.

Nikt nie miałby swojego pamiętnika, informacji bankowych ani nagich zdjęć na komputerze, więc ochrona ich przed złośliwym dostępem nie miała wysokiego priorytetu - w rzeczywistości większość studenci w latach 70. prawdopodobnie byliby zachwyceni , gdyby inni wykazywali zainteresowanie ich danymi badawczymi. Dlatego zapobieganie utracie danych uznano za najwyższy priorytet w zakresie bezpieczeństwa komputerowego i jest to odpowiednio zapewniane przez regularne tworzenie kopii zapasowych zamiast kontroli dostępu.

To bardzo wnikliwa obserwacja. Tak, złośliwe oprogramowanie działające jako użytkownik może uszkodzić / zniszczyć / zmodyfikować dane w katalogu domowym. Tak, separacja użytkowników w systemach dla jednego użytkownika jest mniej przydatna niż na serwerach. Jednak wciąż jest kilka rzeczy, które tylko użytkownik root (lub odpowiednik) może zrobić:

• Zainstaluj rootkita w jądrze.
• Zmodyfikuj bootloader, aby zawierał wczesnego backdoora dla trwałości.
• Wymaż wszystkie bloki z dysku twardego, uniemożliwiając odzyskanie danych.

Szczerze mówiąc, uważam, że separacja uprawnień na stacjach roboczych jest najbardziej przydatna do ochrony stacji roboczej przed to największy wróg: ja. Utrudnia to schrzanić i zepsuć mój system.

Dodatkowo, zawsze możesz skonfigurować zadanie crona jako root, które utworzy kopię zapasową twojego katalogu domowego (np. rsnapshot ) i przechowuje go w taki sposób, aby użytkownik nie mógł go zapisywać. To byłby pewien poziom ochrony w opisanej sytuacji.

Obowiązkowe xkcd

Pierwotny projekt bezpieczeństwa Unix / Linux miał na celu ochronę użytkownika przed innymi użytkownikami i plików systemowych przed użytkownikami. Pamiętaj, że 30-40 lat temu większość systemów Unix była konfiguracjami dla wielu użytkowników, w których wiele osób logowało się do tej samej maszyny w tym samym czasie. Te systemy kosztują dziesiątki tysięcy dolarów, a posiadanie własnego komputera osobistego było niezwykle rzadkie, więc komputer był współdzielony w środowisku logowania wielu użytkowników.

Projekt nigdy nie miał na celu ochrony użytkownika lub plików użytkowników przed złośliwym kodem, a jedynie w celu ochrony użytkowników przed innymi użytkownikami, użytkowników przed modyfikowaniem podstawowego systemu i użytkowników przed używaniem zbyt wielu zasobów systemowych. W naszej obecnej erze, w której każdy ma własny komputer, projekt przełożył się (głównie) na maszyny jednego użytkownika, które chronią jeden proces przed zajęciem zbyt wielu zasobów systemowych.

Z tego powodu program wykonywany przez użytkownika ma dostęp do dowolnego plik, którego właścicielem jest użytkownik. Nie ma koncepcji dalszego dostępu do własnych plików użytkownika. Innymi słowy, proces wykonywany jako użytkownik A ma dostęp do odczytu, modyfikowania i usuwania wszystkich plików należących do użytkownika A. Obejmuje to (jak zauważyłeś) pliki autostartu.

Bardziej nowoczesne podejście może pociągają za sobą jakąś formę dalszej kontroli nad niektórymi plikami. Coś w rodzaju „ponownego uwierzytelnienia wymagane”, aby uzyskać dostęp do tych plików, lub być może jakaś forma dalszej ochrony plików jednego programu przed plikami innego programu. AFAIK nie ma (obecnie) czegoś takiego w świecie komputerów stacjonarnych Linuksa. Popraw mnie, jeśli się mylę?

Czy nie ma sposobu, aby zapobiec występowaniu złośliwego kodu w $ HOME?

Aby odpowiedzieć na to pytanie, niektóre instalacje wykorzystują istniejące ramy bezpieczeństwa, tworząc użytkownika specjalnie do uruchomienia programu. Programy będą miały opcję konfiguracji, aby określić jako użytkownika, który powinien być uruchomiony. Na przykład moja instalacja PostgreSQL zawiera pliki bazy danych, których właścicielem jest użytkownik postgres , a serwer bazy danych działa jako postgres . W przypadku poleceń administracyjnych PostgreSQL zmieniłbym użytkowników na postgres . OpenVPN ma również opcję zmiany na użytkownika nieuprzywilejowanego po wykonaniu tej czynności przy użyciu uprawnień administratora root (w celu dodania interfejsów sieciowych itp.). Instalacje mogą mieć użytkownika o nazwie nobody specjalnie do tego celu. W ten sposób exploity na PostgreSQL lub OpenVPN niekoniecznie doprowadziłyby do kompromitacji $HOME.

Inną opcją jest użycie czegoś takiego jak SELinux i dokładne określenie, jakie pliki i inne zasoby program ma dostęp do. W ten sposób możesz nawet zabronić programowi działającemu jako root dotykać twoich plików w $ HOME . Pisanie szczegółowej polityki SELinuksa, która określa każdy program, jest żmudne, ale uważam, że niektóre dystrybucje, takie jak Fedora, idą w połowie i mają zdefiniowane zasady, które tylko dodają dodatkowe ograniczenia do programów sieciowych.

Odpowiadając na drugą część pytania: istnieją mechanizmy piaskownicy, ale nie są one domyślnie włączone w większości dystrybucji Linuksa.

Bardzo starym i skomplikowanym jest selinux. Nowsze i łatwiejsze w użyciu podejście to apparmor. Najbardziej przydatny do użytku osobistego (apparmor i podobne systemy są najczęściej używane do ochrony demonów) to firejail, który izoluje procesy we własnym więzieniu.

Firefox może na przykład zapisywać tylko swój katalog profilu i katalog pobierania. Z drugiej strony nie będziesz mógł przesyłać obrazów, jeśli nie umieścisz ich w katalogu Pobrane. Ale to jest projekt takiej piaskownicy. Program może usunąć twoje obrazy lub przesłać je do losowych stron, więc więzienie temu zapobiega.

Używanie firejail jest łatwe. Instalujesz go, a dla programów, które mają już profil (patrz / etc / firejail ), możesz po prostu wykonać (jako root) ln -s / usr / bin / firejail / usr / local / bin / firefox . Jeśli nie jesteś rootem lub chcesz używać argumentów wiersza poleceń dla firejail (np. Niestandardowej ścieżki do plików profilu), możesz uruchomić firejail firefox .

Systemy takie jak snap chcą dodać mechanizmy piaskownicy, dzięki czemu możesz uruchomić niezaufany program zainstalowany z repozytorium losowego snapu bez zbyt wielu konsekwencji. Mając wszystkie te mechanizmy, pamiętaj, że niezaufane programy mogą nadal wysyłać spam lub być częścią ataku dDoS.

Domniemanie, że niewłaściwe dane są chronione, jest fałszywe.

Ochrona działań root chroni zdjęcia z wakacji z 2011 roku. A ja, i twoich braci oraz wszystkich innych użytkowników komputera.

Nawet jeśli zaimplementowałeś system operacyjny ze schematem, który chronił konto domowe, żądając hasła za każdym razem, gdy aplikacja próbowała uzyskać dostęp do pliku, i usuwała ochrony hasłem root, nie użyłbym go, ponieważ byłoby to gorsze w przypadku zdjęć z wakacji.

Jeśli mój brat naruszy podstawowe funkcje systemu na naszym komputerze domowym, moje zdjęcia z wakacji są usunięte, pozbawione okupu lub cokolwiek innego pomimo ochrony twojego katalogu domowego, ponieważ sam system jest teraz zagrożony i może obejść wszelkie wprowadzone przez Ciebie ograniczenia na poziomie użytkownika.

A większość ludzi byłaby bardzo zirytowana, gdyby musieli wprowadzać hasło za każdym razem, gdy wybierali File -> Open w swoim edytorze tekstu.

Poza tym Zdarzało się, że zbyt często pojawiał się problem kontroli dostępu na komputerach domowych. Kiedy Microsoft po raz pierwszy wprowadził swój UAC (do którego nie musisz nawet wpisywać hasła, jeśli używasz konta głównego ... wszystko, co musisz zrobić, to nacisnąć przycisk ), pojawił się dużo, a ludzie wystarczająco narzekali, że 0,5 sekundy ich życia zmarnowało 20 razy dziennie, że Microsoft je zmienił. To nie był rodzaj ochrony, o której mówisz, ale pokazuje nam, że jeśli ludzie nie chcą klikać przycisku bezpieczeństwa kilkadziesiąt razy dziennie w celu zabezpieczenia systemu Microsoft, nie będą chcieli kliknąć (lub, co gorsza, wpisz hasło) do wszystkiego, co zostanie zaimplementowane w celu ochrony ich zdjęć przed tą losową aplikacją, którą właśnie uruchomili.

Podstawowa odpowiedź brzmi:

1. Ochrona roota nie chroń swoje osobiste zdjęcia.
2. Ludzie narzekają, że tego typu uwierzytelnianie jest zadawane zbyt często.

Inne odpowiedzi dotyczą dlaczego * nix jest taki, jaki jest.

Ale warto zauważyć, że można zrobić trochę więcej niż konfigurację „po wyjęciu z pudełka” , do ochrony katalogu domowego użytkownika, skryptów i plików.

Większość nowoczesnych * nix obsługuje POSIX lub warianty list ACL, które można skonfigurować tak, aby dodać rodzaj szczegółowej kontroli dostępu, której szuka OP. Musisz ustawić je ręcznie i nie próbują rozróżniać dostępu na żadnej podstawie poza tym, które konto użytkownika / grupy działa. Ale po skonfigurowaniu możesz bardzo dokładnie określić, które konta mogą wykonywać określone czynności na plikach i uzyskać przynajmniej dodatkową kontrolę, zmuszając polecenia do używania ograniczonych kont dla niektórych poleceń lub plików, zamiast jednego konta użytkownika do wszystkiego. Jednak będzie miał dość wąski limit praktyczny.

Jednym z kluczowych punktów zabezpieczenia root / kernel jest integralność kryminalistyczna . W przypadku, gdy domena zawierająca Twoje cenne dane (użytkownik komputera z prywatnymi dokumentami i tokenami uwierzytelniania internetowego, serwer deweloperski z poufnym kodem / zasobami, serwer aplikacji internetowej z bazą danych użytkowników itp.) Zostanie przejęta, nadal masz bezkompromisową domenę na podstawie którego należy ocenić kompromis, ustalić, co się stało, opracować plan obrony przed tym samym, co się powtórzy, itp.

Unix nie jest tak naprawdę systemem desktopowym. To system działający na dużym komputerze, który kosztuje mniej więcej tyle, ile dom zlokalizowany gdzieś w piwnicy Twojej uczelni. Ty, jako ktoś, kogo nie stać na własny komputer, musisz go dzielić z dwoma tysiącami innych, a nawet z kilkudziesięcioma użytkownikami jednocześnie.

Nawiasem mówiąc, obecnie możesz także uruchomić system podobny do Uniksa na swoim komputerze stacjonarnym lub na SoC wielkości karty kredytowej, który kosztuje 20 $.

Zasadniczo jednak Unix nie jest przeznaczony dla pojedynczych użytkowników. Pojedynczy użytkownik nie jest ważny. To, co znajduje się w twoim katalogu domowym, jest twoim problemem, ale to, co może zrobić root , to problem każdego. Dlatego tylko kilka zadań, które naprawdę wymagają pracy jako root , powinno być wykonanych z tym użytkownikiem, a najlepiej (aby ograniczyć okno czasowe, w którym możesz wyrządzić krzywdę) nie logując się na to konto, ale jawnie używając sudo dla pojedynczych poleceń, które tego wymagają. Jest w tym również dużo religii, dlatego niektórzy dystrybutorzy są tak cholernie aroganccy, że grożą ci, gdy wpiszesz su zamiast sudo dla każdego z nich 10 różnych poleceń apt , które musisz uruchomić, aby zainstalować jakąś drobnostkę.

Więc możesz usunąć wszystkie swoje osobiste zdjęcia bez bycia root . Zgadza się. Złośliwe oprogramowanie może usunąć całą zawartość katalogu domowego, to prawda. Może odmówić usługi, wypełniając dysk, dopóki nie zostanie osiągnięty limit użytkowników, to prawda. Ale z punktu widzenia systemu to tylko twój problem i nikogo to nie obchodzi. Żaden inny użytkownik nie jest (w zasadzie) zagrożony.

Problem z nowoczesnym systemem dla jednego (lub kilku) użytkowników polega na tym, że model zabezpieczeń logiki biwalentnej jest zupełnie nie do zastosowania, podobnie jak „są setki użytkowników „pomysł.

Na szczęście bardzo trudno jest wymyślić coś lepszego. Spójrz na Windows, jeśli chcesz zobaczyć, jak nie ukraść pomysłu (naprawdę udało im się pogorszyć złe podejście).

Niektóre przeglądarki internetowe i systemy operacyjne telefonów (lub smart TV) próbują (i zawodzą ) w dostarczaniu czegoś lepszego, a współczesny Linux ma też bardziej drobnoziarnisty system (ale nie wiedziałbym, jak go poprawnie skonfigurować, nie spędzając tygodni swojego czasu).

Problem polega na tym, że biwalentny model bezpieczeństwa zakłada, że ​​normalne aplikacje nie wymagają żadnych przywilejów (co jest błędne, ponieważ niektóre w większości nieszkodliwe rzeczy wymagają uprawnień), podczas gdy niestandardowe aplikacje wymagają pełnego dostępu do systemu komputerowego (który jest również źle, prawie żaden program nigdy nie potrzebuje pełnego dostępu).

Z drugiej strony nawet bardziej szczegółowe modele zabezpieczeń (które nadal są dość zgrubne) przyjmują błędne założenie, że jeśli aplikacja zażąda zestawu uprawnień , naprawdę potrzebuje tego pełnego zestawu, a użytkownik czuje się komfortowo z jego przyznaniem.

O ile wiem, nie ma rdzeń, w którym aplikacja może zażądać uprawnień A, B i C, a użytkownik może zgodzić się na przyznanie A (ale nie B i C), a aplikacja może następnie zapytać, jakie uprawnienia otrzymała i zdecydować, czy jest w stanie wykonać żądane zadanie, czy nie.

W związku z tym, ogólnie rzecz biorąc, masz możliwość przyznania aplikacji XYZ „przechowywania danych w stałym magazynie” (z czym być może zgadzasz się) oraz „Uzyskaj dostęp do mojej lokalizacji” i „uzyskaj dostęp do moich danych osobowych” lub „zainstaluj sterownik systemowy” (z którym nie zgadzasz się), albo nie możesz uruchomić programu.
Lub możesz zezwolić programowi XYZ aby „wprowadzić zmiany w komputerze”, cokolwiek to znaczy, lub możesz go nie uruchamiać. I za każdym razem musisz to potwierdzać. Co, szczerze mówiąc, naprawdę jest do bani z punktu widzenia użytkownika.

Takie uprawnienia nie istnieją, ponieważ są niewygodne.

Ogólnym celem uprawnień jest zapobieganie niepożądanym działaniom. Rodzaje działań, które może wykonać root , są znacznie bardziej podstępne. Aplikacja ransomware na poziomie użytkownika może być w stanie zaszyfrować Twoje pliki, ale nie może ukryć tego, że to robi. Gdy znajdziesz zaszyfrowany plik, zostaje on otwarty tak jak zwykle i ujawnia, że ​​został zaszyfrowany. Dzięki ransomware na poziomie roota może przejąć cały system plików i stworzyć iluzję, że pliki nie są szyfrowane do ostatniej chwili, a potem zapomnieć o kluczu i bam ! Wszystkie twoje pliki stają się niedostępne w tym samym czasie.

Oczywiście w dzisiejszych czasach nie logujemy się jako root. Używamy sudo. Jest to forma przywileju opartego na rolach. Nie masz uprawnień roota, dopóki nie przyjmiesz roli „użytkownika wykonującego zadania administracyjne”. Następnie uzyskujesz te przywileje, aż do zakończenia polecenia.

Jedna mogła utworzyć precyzyjne role, które mają dostęp do różnych folderów. Być może chcesz, aby „zdjęcia z wakacji” były tylko do odczytu, chyba że wpiszesz rolę „dodawanie / edycja zdjęć”. Byłoby to potężne, ale wymagające. Jak wspomniał Aaron, UAC systemu Windows był szeroko omawiany za marnowanie cennych sekund na prośby o pozwolenie, zamiast po prostu robić rzeczy. Komputer musiałby częściej prosić o pozwolenie, gdyby musiał zmieniać role w celu ochrony danych. Użytkownicy generalnie nie stwierdzili, że jest to opłacalne, więc nie jest obsługiwane.

(Jeśli byłeś zainteresowany takimi możliwościami i chciałbyś użyć sudo do ich wykonania, możesz utworzyć oddzielną partycję, którą można zamontować ro lub rw, w zależności od tego, co chcesz zrobić, i przechowuj tam swoje zdjęcia).

Jednym z najtrudniejszych zadań w takich przypadkach jest szczegółowość ról. Jeśli użytkownik przyjmie taką czy inną rolę, będzie to dość łatwe w obsłudze. Jednak trudniej jest obsłużyć przypadek, w którym dana aplikacja musi wejść w tę rolę. Może Firefox nie może pisać do twoich zdjęć, ale GIMP ma pozwolenie. Jest to trudne, ponieważ tam, gdzie istnieją granice, nie można uzyskać spójnej, bezproblemowej integracji. Co jeśli Firefox wykorzystuje wtyczkę GIMP do edycji zdjęć? Jedynym sposobem, aby temu zapobiec, jest uniemożliwienie komunikacji z GIMP-em.

Zakładam, że masz pewne doświadczenie z systemem Windows. Czy zastanawiałeś się kiedyś, dlaczego ekran gaśnie, gdy pojawia się UAC? W rzeczywistości nie służy do wizualnego potwierdzenia, że ​​robisz coś specjalnego. To o wiele ważniejsze niż to. Okna nad przyciemnioną częścią są częścią innego ekranu , odizolowanego od okien poniżej. Dlaczego to jest ważne? Cóż, okazuje się, że każde okno na ekranie może manipulować dowolnym innym oknem na tym samym ekranie. Jeśli UAC pojawił się na tym samym ekranie, co program instalacyjny z prośbą o uprawnienia, instalator mógłby dosłownie uzyskać uchwyt do okna UAC i kliknąć OK za Ciebie ! To z pewnością podważyłoby cel takiej zachęty. Rozwiązaniem jest to, że kontrola konta użytkownika jest dostarczana na innym ekranie, więc żadna inna aplikacja nie może samodzielnie kliknąć OK. Jedynym sposobem na kliknięcie przycisku OK jest poruszenie myszą i kliknięcie przez użytkownika. Przyciemnienie jest naprawdę po to, aby pokazać, że nie możesz wchodzić w interakcję z żadnym z okien poniżej, podczas gdy ekran UAC ma kontrolę nad klawiaturą / myszą.

Więc to jest poziom wysiłku, który należy podjąć, aby się odizolować. To nie jest łatwe. W rzeczywistości jest to na tyle trudne, że ochrona kluczowych danych może mieć sens, mając wiele kont użytkowników i zapewniając każdemu inny dostęp do danych. Następnie możesz użyć możliwości przełącznika użytkownika, aby przełączać się między nimi. Zapewniłoby to rodzaj izolacji potrzebnej do wykonywania przyzwoitych przywilejów opartych na rolach.

Czy nie ma sposobu, aby zapobiec występowaniu złośliwego kodu w $ HOME?

Zakładając, że masz / home jako indywidualny punkt montowania na jest to własna partycja - możesz po prostu edytować / etc / fstab i dodać flagę noexec do opcji montowania. To wyłącza całe wykonywanie kodu na tej partycji, z wadą tego, że kod w ~ / bin (ponieważ niektóre instalacje dla użytkownika mogą go utworzyć) również nie będzie już działać. nie powstrzyma to jednak pliku wykonywalnego znajdującego się w innym miejscu w systemie plików przed usunięciem /home.

SE Linux to pełnoprawny system bezpieczeństwa , który może ładnie izolować - podczas gdy AppArmor służy tylko do izolacji aplikacji. Podstawowy system Linux obsługuje to, od wersji 5.0. W systemie Windows niedawno wprowadzili „foldery chronione”, co jest prawie takie samo (całkowite zdzierstwo). tutaj wadą jest to, że podczas ręcznej instalacji czegoś nowego często trzeba oznaczyć i / lub ustawić odpowiednie flagi, aby na to pozwolić, podczas gdy kontekst, w którym coś działa, jest tam najważniejszy. ludzie często sugerują wyłączenie go, po prostu dlatego, że nie rozumieją, jak sobie z tym poradzić. cóż, nie o to dokładnie chodzi przy wyborze dystrybucji SE Linuksa do wdrożenia.

Dziwię się, że nikt nie wspomniał o następujących rzeczach:

Jednym z głównych powodów, dla których nie należy logować się do komputera jako root, jest to, że wiele działań zmieni prawa własności plików, aby stały się rootem. Zwykle oznacza to, że „zwykli” użytkownicy nie będą mogli uruchamiać wielu aplikacji, ponieważ nie mogą odczytać domyślnego pliku konfiguracyjnego utworzonego przez administratora.

Jeden z głównych powodów niezalogowania się na serwer jako root jest to, że z punktu widzenia audytu / śledzenia lepiej jest mieć kogoś, kto loguje się jako siebie, a następnie wykonuje polecenia jako root, aby istniał jakiś audytowalny dziennik, który wskazuje, że `` użytkownik1 '' zalogował się, a następnie przełączył się na roota, zamiast tylko o tym wiedzieć „root” zalogowany z adresu IP 10.2.1.2, który może być ogólnym terminalem dostępnym dla wielu ludzi. Na serwerze jest bardziej powszechne, że ma ograniczony dostęp sudo do wielu poleceń, aby usiłować sprawić, by akcje wykonywane przez administratora były łatwiejsze do kontrolowania i śledzenia.

Podobnie jak w przypadku wszystkich działań roota, możesz robić to, co chcesz; pamiętaj tylko, że im więcej robisz, tym większy pistolet wycelowany w twoją stopę i wystarczy jedno błędne polecenie, aby pociągnąć za spust.

  rm -rf {uninitializedVariable} / *