Zezwolić użytkownikom innym niż administratorzy na instalowanie pakietów za pośrednictwem apt lub rpm?

13

Czy można zezwolić użytkownikom innym niż root na instalowanie pakietów w całym systemie za pomocą apt lub rpm?

Miejsce, w którym pracuję, ma obecnie nieaktualną konfigurację na polach linuksowych, a administratorzy mają dość wykonywania wszystkich instalacji dla użytkowników na żądanie, więc myślą o przyznaniu pełnych praw sudo wszystkim użytkownikom. Ma to oczywiste wady bezpieczeństwa. Zastanawiam się więc, czy istnieje sposób, aby zezwolić zwykłym użytkownikom na instalowanie oprogramowania - oraz na jego aktualizację i usunięcie?

— naught101
źródło

4

Jeśli dajesz uprawnienia do instalowania pakietów, w zasadzie masz pełne uprawnienia administratora, ponieważ użytkownik może po prostu zainstalować pakiet z powłoką root setuid.

— camh

@camh hrm .. możesz mieć sprawdzone repozytorium i nie pozwolić użytkownikom dodawać nowych repozytoriów, prawda? A może apt pozwala na instalowanie pakietów z plików .deb? Zdaję sobie sprawę z tego, że sprawdzone repo prawdopodobnie będzie więcej pracy na dłuższą metę, to bardziej koncepcyjne pytanie :)

— naught101

1

apt-secure(8)mówi: „apt-get będzie obecnie ostrzegał tylko przed niepodpisanymi archiwami, przyszłe wydania mogą wymusić weryfikację wszystkich źródeł przed pobraniem z nich pakietów”. W zależności od stopnia zaawansowania ataku możliwe jest przejęcie połączenia ze źródłem repozytorium i wstrzyknięcie niezaufanego pakietu. Jednak przeczytaj tę stronę podręcznika, aby uzyskać więcej szczegółów. Być może masz wystarczająco bezpieczne rozwiązanie dla swojego modelu wątku.

— camh

2

Powiązane: Menedżerowie pakietów innych niż root

— Piotr Dobrogost

1

Powiązane: Czy w systemie Linux istnieje odpowiednik Homebrew dla kont użytkowników z ograniczonym dostępem?

— Piotr Dobrogost

23

Możesz określić dozwolone polecenia za pomocą sudo, nie musisz zezwalać na nieograniczony dostęp, np

username ALL = NOPASSWD : /usr/bin/apt-get , /usr/bin/aptitude

Pozwoliłoby to nazwa użytkownika, aby uruchomić sudo apt-geti sudo aptitudebez hasła, ale nie pozwoli żadnych innych poleceń.

Możesz także użyć packagekit w połączeniu z PolicyKit, aby uzyskać lepszy poziom kontroli niż sudo.

Zezwalanie użytkownikom na instalowanie / usuwanie pakietów może stanowić ryzyko. Mogą dość łatwo sprawić, że system przestanie działać po prostu przez odinstalowanie niezbędnego oprogramowania, takiego jak libc6, dpkg, rpm itp. Zainstalowanie dowolnego oprogramowania ze zdefiniowanych archiwów może pozwolić atakującym na zainstalowanie przestarzałego lub nadającego się do wykorzystania oprogramowania i uzyskanie dostępu do konta root. Moim zdaniem główne pytanie brzmi: jak bardzo ufasz swoim pracownikom?

Oczywiście Twój zespół administracyjny może również zacząć korzystać z systemu zarządzania konfiguracją, takiego jak marionetka, szef kuchni lub zajrzeć do spacerów, aby zarządzać systemem. Pozwoliłoby im to skonfigurować system i zarządzać nim z systemu centralnego.

— Ulrich Dangel
źródło

Zostawiłem to poza moim pytaniem, ale czy masz jakieś uwagi na temat redukcji bezpieczeństwa wynikającej z na to zgody? Mam na myśli, że nie możesz zmienić repozytoriów pakietów, więc prawdopodobnie nie uzyskasz pełnego dostępu do sudo, ale możesz napisać do dowolnego pliku za pomocą aptitude (opcje> preferencje> „Plik, do którego logujesz akcje”), co mogłoby spowodować poważne szkody. Nie jestem pewien co do PolicyKit ...

— naught101

1

@ naught101 ok, dodałem kilka uwag na temat bezpieczeństwa. JFTR jako zestaw zasad nie zapewnia dostępu do katalogu głównego, byłoby mniej problematyczne niż korzystanie z sudo

— Ulrich Dangel

Istnieją sposoby na uruchomienie powłoki z dpkg lub rpm. Na przykład: dpkg wyświetli monit, gdy nastąpi zmiana pliku konfiguracyjnego, który koliduje, a jedną z opcji jest uruchomienie powłoki w celu zbadania sytuacji . Spowoduje to uruchomienie powłoki jako root, jeśli zostanie uruchomiony przez sudo. Podobnie, jeśli możesz uruchomić edytor z poziomu narzędzia, ponieważ większość edytorów pozwala na uruchamianie z nich dowolnych poleceń powłoki (np.! Polecenie w vi).

— David Gardner

@ naught101 Chciałbym przetestować eskalację uprawnień za pomocą RPM, która zawiera powłokę SUID, jak opisuje ten blog: nosedookie.blogspot.com/2011/07/... W scenariuszu wstrzykiwania powłoki, jednak w przypadku naruszenia konta sudoer można złagodzić eskalacja uprawnień przez sudo, wymagająca podania hasła , w przeciwieństwie do NOPASSWD.

— Matt

7

aptdcon

Ze stron podręcznika:

aptdcon: umożliwia wykonywanie zadań związanych z zarządzaniem pakietami, np. instalowaniem lub usuwaniem oprogramowania za pomocą aptdaemon. Aby uruchomić ten program, nie trzeba być rootem.

— pl1nk
źródło

1

Chociaż nie potrzebujesz uprawnień roota / sudo, aby uruchomić aptdcon, natychmiast uruchamia okno uwierzytelnienia dla nieuprzywilejowanych użytkowników - właśnie przetestowałem na Ubuntu. Jeśli nie jesteś uprzywilejowanym / autoryzowanym użytkownikiem, nie powoduje to dodawania / usuwania pakietów.

— mędrzec

1

Nie działa na operacjach

ERROR: You are not allowed to perform this action. ('system-bus-name', {'name':  ':1.716'}): org.debian.apt.install-or-remove-packages

— JacopKane

4

username ALL = NOPASSWD : /usr/bin/yum, /bin/rpm

— fromnaboo
źródło

1

Szukałem również czegoś takiego, ale nic się nie pojawiło, więc zakodowałem to łatwe rozwiązanie „kanałami oprogramowania”:

https://github.com/alfem/softwarechannels

Jest to bardzo prosty system pozwalający zwykłym użytkownikom (bez administratora) na instalowanie pakietów z ograniczonych katalogów.

Wystarczy zdefiniować „kanały” (grupy pakietów) w prostym pliku tekstowym i dać użytkownikom uprawnienia do uruchamiania kanałów oprogramowania.

Będą widzieć tylko pakiety w kanałach pasujących do ich grup uniksowych.

— Alfonso EM
źródło