Pozwól grupie spoza sudo kontrolować zadanie Upstart

11

Usiłuję skonfigurować zadanie Upstart do uruchamiania przy uruchamianiu systemu, które może być również uruchomione / zatrzymane przez członków grupy innej niż sudo. W poprzedniej wersji używałem update-rc.dskryptów i zapisywałem /etc/init.d/je, aby to działało, dodając %Group ALL = NOPASSWD: /etc/init.d/scriptnamedo mojego pliku sudoers, ale nie mogę uzyskać odpowiednika działającego dla Upstart.

Próbowałem dodać %Group ALL = NOPASSWD: /sbin/initctl start jobnamedo pliku sudoers, ale próba uruchomienia polecenia start jobnamepowoduje błąd:

start: Rejected send message, 1 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=5148 comm="start jobname " interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

O ile wiem, jest to skarga na to, że moje konto użytkownika nie ma uprawnień do wysyłania wiadomości „Start” w pliku konfiguracyjnym D-Bus dla Upstart. Nie byłem w stanie znaleźć żadnych informacji o tym, jak edytować ten plik, aby dać grupie pozwolenie na dostęp do określonej usługi - czy taka opcja istnieje? Czy istnieje sposób edycji pliku Sudoers, dzięki czemu mogę uruchomić zadanie bez edycji pliku konfiguracyjnego? Czy lepiej mi pozostać przy poprzedniej wersji?

Angle O'Saxon
źródło

Odpowiedzi:

7

Możesz zacząć od ustalenia, gdzie przechowywana jest konfiguracja D-Bus specyficzna dla Upstart. Widzisz ten destination="com.ubuntu.Upstart"fragment kodu z komunikatu o błędzie? Teraz spróbuj grepować go w folderze z plikami konfiguracyjnymi D-Bus:

vhost07:~ $ grep -r "com.ubuntu.Upstart" /etc/dbus-1
/etc/dbus-1/system.d/Upstart.conf:    <allow own="com.ubuntu.Upstart" />
[...skipped...]

Ten Upstart.confplik zawiera kilka przykładów zasad. Sądzę, że możesz spróbować na ich podstawie ustalić format polisy. Następnie spróbuj zezwolić określonemu użytkownikowi na działania, których potrzebuje. Na przykład jak w:

<policy user="pope_benedict">
  <allow send_destination="com.ubuntu.Upstart"
         send_interface="com.ubuntu.Upstart0_6.Job"
         send_member="Start"/>
</policy>

Powinno to pozwolić pope_benedictużytkownikowi na rozpoczęcie tego zadania.

Pamiętaj, że wartości atrybutów zasad „zezwalaj” są wymienione w oryginalnym komunikacie o błędzie.

Iuliu Pascaru
źródło
1
Aha, i po tym nie zapomnij ponownie uruchomić D-Bus! :)
Iuliu Pascaru,
Uznałem to za nieco oszałamiające, ale pomogło to: blog.arkency.com/2014/07/...
Mike Campbell
7

Osobiście używam następującego wiersza w pliku /etc/sudoers.d/jobname_myuser:

myuser ALL = (root) NOPASSWD: /sbin/start jobname, /sbin/stop jobname, /sbin/restart jobname, /sbin/status jobname

zgodnie z opisem tutaj: /server//a/390723/68608

Szymon Jeż
źródło
2

Taka opcja nie istnieje w sudo.

Różnica między skryptami Sysv a plikami konfiguracyjnymi Upstart polega na tym, że: Skrypty Sysv to skrypty, pliki wykonywalne same w sobie i możesz powiedzieć sudo, aby zezwoliło niektórym grupom na ich wykonanie. Z drugiej strony, pliki konfiguracyjne Upstart są jedynie plikami konfiguracyjnymi, a nie plikami wykonywalnymi, więc wykonanie start(dowiązanie symboliczne initctl) jest tym, na co pozwala sudo. Twój problem polega na tym, że zezwalanie ludziom na uruchamianie initctlcię pozwala ci na initctlwszystko.

Rozwiązanie jest proste, jeśli dotyczy tylko jednego zadania. Stwórz skrypt, powiedz /usr/bin/jobname.shz

#!/bin/sh
initctl $1 jobname

a następnie chmod 755 /usr/bin/jobname.shdodaj plik wykonywalny do pliku sudoers:

%Group ALL = NOPASSWD: /usr/bin/jobname.sh

W ten sposób każdy może zadzwonić jobname.sh startlub jobname.sh stopkontrolować określone zadanie. Możesz dodać trochę sprawdzania, aby zezwolić tylko starti stopparametry itp.

Tuminoid
źródło
Innymi słowy, moim problemem nie jest to, że system odmawia członkom grupy możliwości uruchomienia initctl, ale że Upstart odrzuca wszelkie sygnały wysyłane przez użytkowników / grupy, którzy nie otrzymali wyraźnego wpisu Zezwól w Upstart.conf? I nie ma sposobu, aby zapewnić większą szczegółowość niż ustawienie „wszystkie zadania lub brak” w pliku konfiguracyjnym?
Angle O'Saxon
Initctl w twoim przypadku działa dobrze nawet bez zmiany sudoers, Upstart po prostu odmawia wiadomości z niego, jeśli nie pozwalasz na to użytkownikom innym niż root. Zobacz pozostałe dwie odpowiedzi. Możesz zdefiniować zasady dbus dla poszczególnych zadań (patrz com.ubuntu.Upstart0_6.<JOB>część) w Upstart.conf. W zależności od potrzeb, może być prostsze wykonanie tego rodzaju skryptu zamiast pisania zasad dbus i restartowania dbus itp. Polityka Dbus jest oczywiście „właściwą” rzeczą, ale w zależności od przypadku prosty skrypt może przejść długa droga z mniejszymi problemami.
Tuminoid
Edycja zasad DBus, aby użyć com.ubuntu.Upstart0_6.jobnamejako send_interfacewygenerowanego tego samego komunikatu o błędzie jak poprzednio. Jeśli zgaduję, że wyjście błędu zawiera informację o sygnale, wygląda na to, że interfejs lub miejsce docelowe nie odzwierciedlają usługi Upstart, do której odnosi się sygnał. Myślę, że informacje o usłudze to tylko argumenty w komunikacie wywołania metody D-Bus, i nie jestem pewien, czy mogę edytować zasady D-Bus dla Upstart, aby podejmować decyzje na podstawie wartości argumentów.
Angle O'Saxon
Skrypt, który sugerujesz, działa dla mnie całkiem dobrze, z jednym zastrzeżeniem: musiałem go uruchomić jako sudo jobname.sh start, aby Upstart widział żądanie jako pochodzące od rootużytkownika. Staram się to zrobić jest to „właściwa” droga (przede wszystkim odejście od skryptów Sys-V), więc chciałbym, aby działało to poprzez politykę D-Bus lub inną opcję konfiguracji Upstart, ale jeśli nie mogę zacznij działać Akceptuję tę odpowiedź.
Angle O'Saxon
1
Zacytowałbym również "$1". W twoim [ "$1" = "start" -o "$1" = "stop" ]teście uważam, że jest to bezpieczne, ale nie cytowane $1rozszerzenie skryptu, ponieważ root jest po prostu niezdrowym nawykiem (chyba że celowe dzielenie słów jest celowe) ...
Beni Cherniavsky-Paskin
0

Jak wskazano powyżej, demon dbus ma plik konfiguracyjny, który specjalizuje się w konkretnej aplikacji.

ls /etc/dbus-1/system.d/
avahi-dbus.conf
bluetooth.conf
...
Upstart.conf
wpa_supplicant.con

Plik konfiguracyjny określa również limity zasobów, parametry bezpieczeństwa i tak dalej.

Aby uzyskać szczegółowe informacje, patrz dbus-daemon-1 (1) - strona podręcznika użytkownika systemu Linux

Aby umożliwić grupie uruchamianie / zatrzymywanie zadań Upstart, dodaj następujące zasady do /etc/dbus-1/system.d/Upstart.conf

  <policy group="YourGroupName">
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Start" />
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Stop" />
  </policy>

Przed zmianą domyślnych zasad należy rozważyć wpływ takich zasad na bezpieczeństwo. Członkowie YourGroupName będą mogli rozpocząć / zatrzymać wszystkie zadania Upstart.

Goran Miskovic
źródło
Ale czy istnieje sposób na ograniczenie zadań, które mogą kontrolować? Czy to nie jest możliwe, ponieważ D-Bus nie zwraca uwagi na treść wiadomości?
Angle O'Saxon
Próbowałem dodać tę zasadę do Upstart.conf (zastępując nazwę grupy moją rzeczywistą nazwą grupy), zrestartowałem D-Bus i dostałem, start: You do not have permission to modify job: jobnamegdy próbowałem uruchomić usługę.
Angle O'Saxon
OK. Oznacza to, że zasady zostały pomyślnie zastosowane. Wygląda na to, że twoja.job znajduje się w / etc / init. Zadania użytkownika powinny być w ~ / .init. Czy w twoim przypadku użycia jest prawdopodobne umieszczenie yourjob.conf w ~ / .init?
Goran Miskovic
W odniesieniu do pierwszego pytania: Polityka określa, które interfejsy i członkowie mogą być dostępni. Określa, które treści / argumenty mogą być wysyłane / przekazywane. Obecna restrykcyjna polityka została złagodzona na wcześniejszych etapach procesu. See nie może zacząć działać, aby uruchomić zadanie użytkownika
Goran Miskovic