Eksperymentuję z możliwościami na Debian Gnu / Linux.

Skopiowałem / bin / ping do mojego bieżącego katalogu roboczego. Zgodnie z oczekiwaniami nie działa, pierwotnie był to setuid root.

Następnie daję swojemu pingowi minimalne możliwości (nie rootowanie) sudo /sbin/setcap cap_net_raw=ep ./ping, a mój ping działa zgodnie z oczekiwaniami.

Następnie, sudo /sbin/setcap -r ./pingaby odwołać tę funkcję. Teraz nie działa zgodnie z oczekiwaniami.

Teraz próbuję uruchomić ping przy użyciu capsh.

capsh nie ma żadnych uprawnień, więc muszę uruchomić go jako root, ale potem upuścić roota, a tym samym wszystkie inne uprawnienia.

Myślę, że też potrzebuję secure-keep-caps, nie jest to udokumentowane capsh, ale znajduje się w podręczniku zdolności. Mam numery bitów od /usr/include/linux/securebits.h. Wydają się poprawne, ponieważ wynik --printpokazuje, że te bity są poprawne.

Bawiłem się godzinami, jak dotąd mam to.

sudo /sbin/capsh --keep=1 --secbits=0x10 --caps="cap_net_raw+epi" == --secbits=0x10 --user=${USER} --print -- -c "./ping localhost"

Jednak pingz błędami ping: icmp open socket: Operation not permitted, dzieje się tak, gdy nie ma takiej możliwości. Także --printprogramy Current: =p cap_net_raw+i, to nam nie wystarczy e.

sudo /sbin/capsh --caps="cap_net_raw+epi" --print -- -c "./ping localhost"ustawi zdolność do Current: = cap_net_raw+eiptego jest poprawna, ale pozostawia nas jako root.

Edycja-1

Próbowałem teraz sudo /sbin/capsh --keep=1 --secbits=0x11 --caps=cap_net_raw+epi --print -- -c "touch zz; ./ping -c1 localhost;"

Daje to:

touch: cannot touch `zz': Permission denied
ping: icmp open socket: Operation not permitted

Pierwszy błąd jest oczekiwany, secure-noroot: yes ale drugi nie jestCurrent: = cap_net_raw+eip

Edycja-2

Jeśli postawię ==przed --print, pokazuje to teraz Current: = cap_net_raw+i, więc to wyjaśnia poprzedni błąd, ale nie dlatego, że tracimy możliwości przy wyłączaniu roota, pomyślałem, że to secure-keep-capspowinno to naprawić.

Edycja-3

Z tego, co widzę, tracę Efektywny (e) i Dozwolony (p), gdy wywoływane jest exec. Jest to oczekiwane, ale pomyślałem, że czapki z daszkiem powinny zatrzymać ich zagubienie. Czy coś mi umknęło?

Edycja-4

Przeprowadziłem więcej badań i ponownie przeczytałem instrukcję. Wydaje się, że normalnie ei pmożliwości są tracone, gdy: przełączysz się z użytkownika root(lub zastosujesz secure-noroot, dzięki czemu root stanie się normalnym użytkownikiem), można to zmienić secure-keep-caps; kiedy dzwonisz exec, o ile wiem, to niezmiennik.

O ile wiem, działa zgodnie z instrukcją. O ile wiem, nie ma sposobu, aby zrobić coś pożytecznego capsh. O ile mi wiadomo, aby korzystać z możliwości, musisz: korzystać z możliwości plików lub mieć program obsługujący możliwości, który nie korzysta exec. Dlatego nie ma uprzywilejowanego opakowania.

Więc teraz moje pytanie brzmi: po co mi tęsknię, po co capsh.

Edycja-5

Dodałem odpowiedź dotyczącą możliwości otoczenia. Być capshmoże można go również używać z odziedziczonymi funkcjami, ale aby były użyteczne, trzeba je ustawić w pliku wykonywalnym. Nie widzę, w jaki sposób capsh może zrobić coś użytecznego bez funkcji otoczenia lub pozwolić na odziedziczone funkcje.

Wersje:

• capshz libcap2-binwersji pakietu1:2.22-1.2
• przed Edit-3 złapałem ostatni capshod git://git.debian.org/collab-maint/libcap2.giti zaczął go używać.
• uname -a Linux richard-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux Obszar użytkownika jest 32-bitowy.

Możliwości są właściwościami procesów. Tradycyjnie istnieją trzy zestawy:

• Dozwolone możliwości ( p ): możliwości, które mogą być „aktywowane” w bieżącym procesie.
• Efektywne możliwości ( e ): możliwości, które są obecnie użyteczne w bieżącym procesie.
• Możliwości dziedziczenia ( i ): możliwości plików, które mogą być dziedziczone.

Programy uruchamiane jako root zawsze mają pełne dozwolone i skuteczne możliwości, więc „dodanie” dodatkowych funkcji nie ma zauważalnego efektu. (Zestaw funkcji dziedziczonych jest zwykle pusty.) Po setcap cap_net_raw+ep pingwłączeniu tych funkcji domyślnie dla każdego użytkownika uruchamiającego ten program.

Niestety te możliwości są powiązane z wykonanym plikiem i nie są zachowywane po wykonaniu nowego procesu potomnego. Linux 4.3 wprowadził funkcje Ambient, które umożliwiają dziedziczenie funkcji przez procesy potomne. (Zobacz także Transformacja możliwości podczas execve () w zdolnościach (7) .)

Podczas zabawy z możliwościami zauważ następujące pułapki:

• Podczas zmiany użytkownika z root na non-root, efektywne i dozwolone funkcje są usuwane (patrz Wpływ zmian ID użytkownika na możliwości w możliwościach (7) ). Możesz użyć --keep=1opcji, capshaby uniknąć czyszczenia zestawów.
• Zestaw funkcji otoczenia jest usuwany podczas zmiany identyfikatora użytkownika lub grupy. Rozwiązanie: dodaj funkcje otoczenia po zmianie ID użytkownika, ale przed wykonaniem procesu potomnego.
• Możliwość można dodać do zestawu funkcji otoczenia tylko wtedy, gdy znajduje się już w zestawie dozwolonych i dziedziczonych funkcji.

capshProgramu ze libcap 2,25 nie ma zdolności do modyfikowania jeszcze możliwości otoczenia, ale nowsze wersje dodać nowe opcje. Pamiętaj, że kolejność opcji jest znacząca. Przykładowe użycie:

sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" \
    --keep=1 --user=nobody --addamb=cap_net_raw -- \
    -c "./ping -c1 127.0.0.1"

Wskazówka: możesz dodać tę --printopcję w dowolnym miejscu capshwiersza polecenia i zobaczyć jej aktualny stan możliwości.

Uwaga: cap_setpcapjest potrzebny, --addambdopóki nie cap_setuid,cap_setgidsą potrzebne dla --useropcji.

Odpowiedź Lekensteyna wydaje się dokładna i kompletna, ale postaram się przedstawić inne wyjaśnienie z innej strony, które będzie próbowało podkreślić problem, który rozwiązują ustawione możliwości otoczenia.

Po uruchomieniu sudo capsh --user=<some_user> --Istnieją 2 systemowe wywołania zainteresowania, które powodują ponowne obliczenie (i potencjalne odrzucenie) możliwości:

1. setuid: Według man capabilities:

SECBIT_KEEP_CAPS Ustawienie tej flagi pozwala wątkowi, który ma jeden lub więcej 0 identyfikatorów UID, aby zachować swoje możliwości po przełączeniu wszystkich swoich identyfikatorów UID na niezerowe wartości. Jeśli ta flaga nie jest ustawiona, taki UIDswitch powoduje, że wątek traci wszystkie możliwości.

Innymi słowy, w capshpowyższym poleceniu musimy upewnić się, że podczas setuidwywołania systemowego jest ustawiony parametr SECBIT_KEEP_CAPS . W przeciwnym razie wszystkie możliwości zostaną utracone. To właśnie --keep=1robi. Tak więc teraz polecenie staje sięsudo capsh --user=<some_user> --keep=1 --

2. execve: Jeśli używamy --keep=1opcji wszystkie zestawy zdolności (skuteczne, jest dozwolone, dziedziczne) są zachowane aż do execvewywołania systemowego, jednak execvepowoduje możliwości by obliczyć (dla użytkowników innych niż root), jak również, a nie w tak oczywisty sposób. Krótko mówiąc, przed dodaniem zestawu funkcji otoczenia , aby po połączeniu można było znajdować się w zestawie „dozwolonych” wątków execve:

   • Plik musi mieć taką możliwość w zestawie „dozwolonych” . Można to zrobić za pomocą setcap cap_net_raw+p /bin/bash. Wykonanie tego powoduje, że całe ćwiczenie jest bezużyteczne, ponieważ zestawy możliwości wątku (inne niż zestaw ograniczający) nie mają już żadnego efektu.
   • Zarówno plik, jak i wątek muszą mieć taką możliwość w swoich „dziedziczonych” zestawach . Możesz pomyśleć, setcap cap_net_raw+iże to execvezałatwi sprawę, ale okazuje się, że powoduje to, że nieuchronne uprawnienia wątku są odrzucane, gdy są wywoływane przez nieuprzywilejowanych użytkowników (za które obecnie jesteśmy setuid). Dlatego nie ma sposobu, aby spełnić ten warunek jako użytkownik nieuprzywilejowany.

Funkcje otoczenia wprowadzone w Linuksie 4.3 pozwalają wątkowi zachować swoje możliwości nawet po setuidnieuprzywilejowanym użytkowniku, po którym następuje execve, bez konieczności polegania na możliwościach plików.

W jądrze może znajdować się błąd / funkcja. Odbyła się dyskusja:

• https://bugzilla.altlinux.org/show_bug.cgi?id=16694
• http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/5224.html

Nie mam pojęcia, czy coś zostało zrobione, aby to naprawić.

Nie zrozum mnie źle - obecne zachowanie jest bezpieczne. Ale jest tak bezpieczny, że przeszkadza w działaniu rzeczy, które powinny wydawać się działać.

Edycja: Według http://man7.org/linux/man-pages/man7/capabilities.7.html wprowadzono nowy zestaw funkcji Ambient (od Linuksa 4.3). Wygląda na to, że pozwoli to na to, co jest potrzebne.