Porównanie funkcji autoryzacji uprawnień

Szereg komputerowych systemów operacyjnych wykorzystuje funkcje bezpieczeństwa, aby uniemożliwić złośliwemu oprogramowaniu uzyskanie uprawnień wystarczających do naruszenia bezpieczeństwa systemu komputerowego. Systemy operacyjne pozbawione takich funkcji, takie jak DOS , implementacje Windows wcześniejsze niż Windows NT (i jego następcy), CP/M-80 i wszystkie systemy operacyjne Mac wcześniejsze niż Mac OS X, miały tylko jedną kategorię użytkowników, którym wolno było robić wszystko. Dzięki oddzielnym kontekstom wykonania wielu użytkowników może przechowywać prywatne pliki, jednocześnie korzystać z komputera przez wielu użytkowników, chronić system przed złośliwymi użytkownikami i chronić system przed złośliwymi programami. Pierwszym bezpiecznym systemem dla wielu użytkowników był Multics , którego rozwój rozpoczął się w latach 60.; dopiero systemach UNIX , BSD , Linux i NT wielozadaniowe konteksty bezpieczeństwa zostały wprowadzone na konsumenckie komputery x86 .

Wprowadzenie do wdrożeń

Microsoft Windows
User Account Control promptOkno dialogowe Monit kontroli konta użytkownika
Kontrola konta użytkownika ( UAC ): Zawarta w systemach operacyjnych Windows Vista i nowszych systemach operacyjnych Microsoft Windows , UAC monituje użytkownika o autoryzację, gdy aplikacja próbuje wykonać zadanie administratora.

Runas : narzędzie wiersza poleceń i czasownik menu kontekstowego wprowadzone w systemie Windows 2000 , które umożliwia uruchamianie programu, apletu panelu sterowania lub przystawki MMC jako inny użytkownik. Runas korzysta z usługi Windows „Secondary Login ”, wprowadzonej również w systemie Windows 2000. Ta usługa umożliwia aplikacjom działającym jako oddzielny użytkownik interakcję z pulpitem zalogowanego użytkownika. Jest to konieczne do obsługi przeciągania i upuszczania, udostępniania schowka i innych interaktywnych funkcji logowania.
System operacyjny Mac
Authenticate Mac OS X zawiera okno dialogowe Uwierzytelnij , które monituje użytkownika o wprowadzenie hasła w celu wykonania zadań administracyjnych. Zasadniczo jest to graficzny interfejs polecenia sudo .
Unix i uniksopodobne
PolicyKit in GNOME
PolicyKit/pkexec : funkcja autoryzacji uprawnień, zaprojektowana tak, aby była niezależna od używanego środowiska graficznego i już przyjęta przez GNOME . W przeciwieństwie do wcześniejszych systemów, aplikacje korzystające z PolicyKit nigdy nie działają z uprawnieniami wyższymi niż bieżący użytkownik. Zamiast tego pośrednio wysyłają żądania do demona PolicyKit , który jest jedynym programem działającym jako root.
su
su : Narzędzie wiersza poleceń dla systemu Unix . su (użytkownik zastępczy) umożliwia użytkownikom przełączenie terminala na inne konto poprzez wprowadzenie nazwy użytkownika i hasła do tego konta. superużytkownika systemu operacyjnego (znane jako „root”), zapewniając w ten sposób szybką metodę uzyskania powłoki logowania z pełnymi uprawnieniami do systemu. Wydanie wyjścia powoduje powrót użytkownika do jego własnego konta.
sudo
sudo : Utworzony około 1980 r. Sudo jest wysoce konfigurowalnym narzędziem wiersza poleceń systemu Unix, podobnym do su , ale pozwala niektórym użytkownikom uruchamiać programy z uprawnieniami roota bez tworzenia powłoki roota lub wymagania hasła roota.
gksudo
GKSu i GKsudo : GTK+ Graficzna nakładka na su i sudo . GKsu pojawia się automatycznie, gdy obsługiwana aplikacja musi wykonać akcję wymagającą uprawnień roota. Zamiennik, „ gksu PolicyKit ”, który używa PolicyKit zamiast su / sudo , jest opracowywany jako część GNOME .
kdesu
kdesu : Graficzny interfejs Qt dla polecenia su dla KDE .
kdesudo
kdesudo : graficzny interfejs Qt do sudo , który zastąpił kdesu w Kubuntu , począwszy od Kubuntu 7.10.
Ktsuss
ktsuss : ktsuss oznacza „ zachowaj prosty , głupi ” i jest graficzną wersją su . Ideą projektu jest pozostanie prostym i wolnym od błędów.
beesu
beesu : Graficzny interfejs dla polecenia su , który zastąpił gksu w systemach operacyjnych opartych na Red Hat . Został opracowany głównie dla RHEL i Fedory .

doas : zamiennik sudo od OpenBSD 5.8 (październik 2015)

Względy bezpieczeństwa

Fałszywe/przechwycone dane wprowadzone przez użytkownika

Ważną kwestią związaną z bezpieczeństwem jest zdolność złośliwych aplikacji do symulowania naciśnięć klawiszy lub kliknięć myszą, a tym samym oszukania lub sfałszowania funkcji bezpieczeństwa w celu nadania złośliwym aplikacjom wyższych uprawnień.

  • Korzystanie z klienta opartego na terminalu (samodzielnego lub w ramach pulpitu/GUI): su i sudo działają w terminalu, gdzie są podatne na sfałszowane dane wejściowe. Oczywiście, gdyby użytkownik nie korzystał ze środowiska wielozadaniowego (tj. tylko jednego użytkownika w powłoce), nie stanowiłoby to problemu. Okna terminala są zwykle renderowane dla użytkownika jako zwykłe okna, dlatego na inteligentnym kliencie lub systemie komputerowym używanym jako klient użytkownik musi wziąć odpowiedzialność za zapobieganie manipulowaniu, symulowaniu lub przechwytywaniu danych wejściowych przez inne złośliwe oprogramowanie na jego pulpicie.
  • Używanie graficznego interfejsu użytkownika/pulpitu ściśle zintegrowanego z systemem operacyjnym: zwykle system stacjonarny blokuje lub zabezpiecza wszystkie popularne sposoby wprowadzania danych przed zażądaniem hasła lub innego uwierzytelnienia, aby nie można było ich przechwycić, zmanipulować ani symulować:
  • PolicyKit ( GNOME - nakazuje serwerowi X przechwytywanie wszystkich danych wejściowych z klawiatury i myszy. Inne środowiska graficzne korzystające z PolicyKit mogą używać własnych mechanizmów.
  • gksudo - domyślnie „blokuje” klawiaturę, mysz i okno, uniemożliwiając komukolwiek poza rzeczywistym użytkownikiem wprowadzenie hasła lub inną ingerencję w okno dialogowe potwierdzenia .
  • UAC (Windows) — domyślnie działa w Bezpiecznym pulpicie , uniemożliwiając złośliwym aplikacjom symulowanie kliknięcia przycisku „Zezwól” lub ingerencję w okno dialogowe potwierdzenia. W tym trybie pulpit użytkownika jest przyciemniony i nie można z nim wchodzić w interakcje.
Jeśli funkcja „blokady” gksudo lub Bezpieczny pulpit UAC zostały naruszone lub wyłączone, złośliwe aplikacje mogłyby uzyskać uprawnienia administratora, używając rejestrowania naciśnięć klawiszy w celu zarejestrowania hasła administratora; lub, w przypadku UAC, jeśli działa jako administrator, sfałszowanie kliknięcia myszą na przycisk „Zezwalaj”. Z tego powodu funkcja rozpoznawania głosu również nie może wchodzić w interakcję z oknem dialogowym. [ potrzebne źródło ] Należy zauważyć, że ponieważ żądanie hasła gksu działa bez specjalnych uprawnień, złośliwe aplikacje mogą nadal rejestrować naciśnięcia klawiszy, używając np. narzędzia strace . (ptrace było ograniczone w późniejszych wersjach jądra)

Fałszywe okna dialogowe uwierzytelniania

Inną kwestią związaną z bezpieczeństwem jest zdolność złośliwego oprogramowania do fałszowania okien dialogowych, które wyglądają jak uzasadnione żądania potwierdzenia bezpieczeństwa. Gdyby użytkownik wprowadził dane uwierzytelniające do fałszywego okna dialogowego, myśląc, że okno dialogowe jest prawidłowe, złośliwe oprogramowanie znałoby hasło użytkownika. Gdyby Bezpieczny pulpit lub podobna funkcja była wyłączona, złośliwe oprogramowanie mogłoby użyć tego hasła, aby uzyskać wyższe uprawnienia.

UAC żąda bezpiecznej sekwencji uwagi w systemie Windows 11, prosząc użytkownika o naciśnięcie najpierw klawiszy Ctrl + Alt + Delete w celu wprowadzenia poświadczeń, aby uniknąć fałszowania logowania.
  • Chociaż nie jest to zachowanie domyślne ze względów użyteczności, UAC można skonfigurować tak, aby wymagał od użytkownika naciśnięcia klawiszy Ctrl+Alt+Del (znanej jako sekwencja bezpiecznej uwagi ) w ramach procesu uwierzytelniania. Ponieważ tylko system Windows może wykryć tę kombinację klawiszy, wymaganie tego dodatkowego środka bezpieczeństwa uniemożliwiłoby zachowywanie się sfałszowanych okien dialogowych w taki sam sposób, jak prawidłowe okno dialogowe. Na przykład sfałszowane okno dialogowe może nie wymagać od użytkownika naciśnięcia klawiszy Ctrl+Alt+Del, a użytkownik może zorientować się, że okno dialogowe jest fałszywe. Lub, gdy użytkownik naciśnie Ctrl+Alt+Del, zostanie przeniesiony do ekranu Ctrl+Alt+Del, do którego zwykle prowadzi zamiast okna dialogowego potwierdzenia UAC. W ten sposób użytkownik mógł stwierdzić, czy okno dialogowe było próbą nakłonienia go do podania hasła do złośliwego oprogramowania.
  • W środowisku GNOME PolicyKit używa różnych okien dialogowych, w zależności od konfiguracji systemu. Na przykład okno dialogowe uwierzytelniania w systemie wyposażonym w czytnik linii papilarnych może wyglądać inaczej niż okno dialogowe uwierzytelniania w systemie bez takiego czytnika. Aplikacje nie mają dostępu do konfiguracji PolicyKit, więc nie mają możliwości dowiedzenia się, które okno dialogowe się pojawi, a co za tym idzie, jak je sfałszować.

Rozważania dotyczące użyteczności

Inną kwestią, która została uwzględniona w tych implementacjach, jest użyteczność .

Oddzielne konto administratora

  • su wymagają od użytkownika znajomości hasła do co najmniej dwóch kont: konta zwykłego użytku oraz konta z wyższymi uprawnieniami, takiego jak root .
  • Sudo , kdesu i gksudo używają prostszego podejścia. W tych programach użytkownik jest wstępnie skonfigurowany, aby uzyskać dostęp do określonych zadań administracyjnych, ale musi jawnie autoryzować aplikacje do uruchamiania z tymi uprawnieniami. Użytkownik wprowadza własne hasło zamiast hasła administratora lub innego konta.
  • UAC i Authenticate łączą te dwa pomysły w jeden. W przypadku tych programów administratorzy jawnie zezwalają na uruchamianie programów z wyższymi uprawnieniami. Użytkownicy niebędący administratorami są proszeni o podanie nazwy użytkownika i hasła administratora.
  • PolicyKit można skonfigurować do przyjęcia dowolnego z tych podejść. W praktyce dystrybucja wybierze jedną.

Prostota dialogu

  • Aby przyznać aplikacji uprawnienia administracyjne, Sudo , gksudo i Authenticate monitują administratorów o ponowne wprowadzenie hasła.
  • W UAC , gdy jest zalogowany jako użytkownik standardowy, użytkownik musi wprowadzić nazwę i hasło administratora za każdym razem, gdy chce nadać aplikacji podwyższone uprawnienia; ale po zalogowaniu się jako członek grupy Administratorzy (domyślnie) po prostu potwierdzają lub odrzucają, zamiast za każdym razem ponownie wprowadzać swoje hasło (chociaż jest to opcja). Chociaż domyślne podejście jest prostsze, jest również mniej bezpieczne, ponieważ jeśli użytkownik fizycznie odejdzie od komputera bez jego blokowania, inna osoba może podejść i uzyskać uprawnienia administratora w systemie.
  • PolicyKit wymaga od użytkownika ponownego wprowadzenia hasła lub podania innego sposobu uwierzytelnienia (np. odcisku palca).

Zapisywanie poświadczeń

  • UAC monituje o autoryzację za każdym razem, gdy jest wywoływany w celu podniesienia poziomu programu.
  • Sudo , gksudo i kdesu nie proszą użytkownika o ponowne wprowadzenie hasła za każdym razem, gdy jest wywoływany w celu podniesienia poziomu programu. Zamiast tego użytkownik jest proszony o podanie hasła raz na początku. Jeśli użytkownik nie korzystał ze swoich uprawnień administracyjnych przez określony czas (domyślnie w Sudo jest to 5 minut), użytkownik jest ponownie ograniczony do standardowych uprawnień użytkownika, dopóki ponownie nie wprowadzi hasła.
Podejście sudo to kompromis między bezpieczeństwem a użytecznością. Z jednej strony użytkownik musi wprowadzić swoje hasło tylko raz, aby wykonać serię zadań administracyjnych, zamiast wpisywać hasło dla każdego zadania. Ale jednocześnie powierzchnia ataku jest większa, ponieważ wszystkie programy działające w tym tty (dla sudo) lub wszystkie programy nie działające w terminalu (dla gksudo i kdesu) poprzedzone którymkolwiek z tych poleceń przed upływem limitu czasu otrzymują administratora przywileje. Użytkownicy dbający o bezpieczeństwo mogą usunąć tymczasowe uprawnienia administratora po wykonaniu wymagających ich zadań za pomocą polecenia sudo -k z każdego tty lub pts, w którym użyto sudo (w przypadku pts zamknięcie emulatora terminala nie jest wystarczające). Odpowiednikiem polecenia dla kdesu jest kdesu -s . Nie ma opcji gksudo, aby zrobić to samo; jednak uruchomienie sudo -k poza instancją terminala (np. poprzez okno dialogowe Alt + F2 „Uruchom aplikację”, odznaczając opcję „Uruchom w terminalu”) przyniesie pożądany efekt.
  • Uwierzytelnianie nie zapisuje haseł. Jeśli użytkownik jest użytkownikiem standardowym, musi wprowadzić nazwę użytkownika i hasło. Jeśli użytkownik jest administratorem, nazwa bieżącego użytkownika jest już wpisana i wystarczy wprowadzić hasło. Nazwę można nadal modyfikować, aby działała jako inny użytkownik.
Aplikacja wymaga uwierzytelnienia tylko raz i jest wymagana w momencie, gdy aplikacja potrzebuje uprawnienia. Po „podniesieniu uprawnień” aplikacja nie musi ponownie uwierzytelniać się, dopóki aplikacja nie zostanie zamknięta i ponownie uruchomiona.
Istnieją jednak różne poziomy uwierzytelniania, zwane prawami. Żądane prawo można wyświetlić, rozwijając trójkąt obok „szczegółów”, pod hasłem. Zwykle aplikacje używają system.privilege.admin, ale można użyć innego, na przykład niższego prawa dla bezpieczeństwa lub wyższego prawa, jeśli potrzebny jest wyższy dostęp. Jeśli uprawnienia aplikacji nie są odpowiednie do zadania, aplikacja może wymagać ponownego uwierzytelnienia w celu zwiększenia poziomu uprawnień.
  • PolicyKit można skonfigurować do przyjęcia jednego z tych podejść.

Określanie, kiedy potrzebne są prawa administracyjne

Aby system operacyjny wiedział, kiedy monitować użytkownika o autoryzację, aplikacja lub działanie musi identyfikować się jako wymagające podwyższonych uprawnień. Chociaż jest technicznie możliwe, aby użytkownik został poproszony dokładnie w momencie wykonania operacji wymagającej takich uprawnień, często nie jest idealnym rozwiązaniem pytanie o uprawnienia w trakcie wykonywania zadania. Jeśli użytkownik nie byłby w stanie podać odpowiednich poświadczeń, praca wykonana przed wymaganiem uprawnień administratora musiałaby zostać cofnięta, ponieważ zadania nie można było przejrzeć do końca.

W przypadku interfejsów użytkownika, takich jak Panel sterowania w systemie Microsoft Windows i panele Preferencje w systemie Mac OS X, dokładne wymagania dotyczące uprawnień są zakodowane na stałe w systemie, dzięki czemu użytkownik otrzymuje okno dialogowe autoryzacji w odpowiednim czasie ( na przykład przed wyświetleniem informacji, które powinni zobaczyć tylko administratorzy). Różne systemy operacyjne oferują aplikacjom różne metody identyfikowania ich wymagań bezpieczeństwa:

  • Sudo skupia wszystkie informacje o autoryzacji uprawnień w jednym pliku konfiguracyjnym /etc/sudoers , który zawiera listę użytkowników oraz uprzywilejowane aplikacje i akcje, z których użytkownicy mogą korzystać. Gramatyka pliku sudoers ma być wystarczająco elastyczna, aby obejmowała wiele różnych scenariuszy, takich jak nakładanie ograniczeń na parametry wiersza poleceń. Na przykład użytkownikowi można przyznać dostęp do zmiany hasła dowolnej osoby, z wyjątkiem konta root, w następujący sposób: 
 pete ALL = /usr/bin/passwd [Az]*, !/usr/bin/passwd root
  • Kontrola konta użytkownika wykorzystuje kombinację skanowania heurystycznego i „manifestów aplikacji” w celu ustalenia, czy aplikacja wymaga uprawnień administratora. Pliki manifestu ( .manifest ), po raz pierwszy wprowadzone w systemie Windows XP, to pliki XML o tej samej nazwie co aplikacja i z sufiksem „.manifest”, np. Notepad.exe.manifest . Po uruchomieniu aplikacji manifest jest przeglądany w celu uzyskania informacji o wymaganiach bezpieczeństwa aplikacji. Na przykład ten fragment XML wskaże, że aplikacja będzie wymagać dostępu administratora, ale nie będzie wymagać nieskrępowanego dostępu do innych części pulpitu użytkownika poza aplikacją: 

    
           
    
 <security>  <requestedPrivileges>  <requestedExecutionLevel  level=  "requireAdministrator"  uiAccess=  "false"  />  </requestedPrivileges>  </security>
Pliki manifestu można również wkompilować w sam plik wykonywalny aplikacji jako zasób osadzony . Wykorzystywane jest również skanowanie heurystyczne, głównie w celu zapewnienia kompatybilności wstecznej. Jednym z przykładów jest patrzenie na nazwę pliku wykonywalnego; jeśli zawiera słowo „Setup”, zakłada się, że plik wykonywalny jest instalatorem, a przed uruchomieniem aplikacji wyświetlany jest monit UAC.
UAC rozróżnia również żądania podniesienia uprawnień z podpisanego pliku wykonywalnego i niepodpisanego pliku wykonywalnego; a jeśli to pierwsze, niezależnie od tego, czy wydawcą jest „Windows Vista”. Kolor, ikona i treść monitów są różne w każdym przypadku: na przykład próba przekazania większego ostrzeżenia, jeśli plik wykonywalny jest niepodpisany, niż jeśli nie.
  • Aplikacje korzystające z PolicyKit proszą o określone uprawnienia podczas monitowania o uwierzytelnienie, a PolicyKit wykonuje te czynności w imieniu aplikacji. Przed uwierzytelnieniem użytkownicy mogą zobaczyć, która aplikacja zażądała akcji i która akcja została zażądana.

Zobacz też

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Comparison_of_privilege_authorization_features&oldid=1130907949 ”