Jak działają uprawnienia do systemu Linux, gdy proces działa jako określona grupa?

To jest coś, o czym nie mogłem znaleźć wielu informacji, więc każda pomoc byłaby mile widziana.

Tak rozumiem. Weź następujący plik:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

Użytkownik philnie może uzyskać dostępu do tego pliku:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

Jeśli philzostanie dodany do admgrupy, może:

root@server:~# adduser phil adm
Adding user `phil' to group `adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

Jeśli jednak proces zostanie uruchomiony podczas gdy wyraźnie ustawienie user:groupna phil:philnim nie można odczytać pliku. Proces rozpoczął się w następujący sposób:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

Jeśli proces zostanie uruchomiony jako phil:adm, może odczytać plik:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

Tak naprawdę pytanie brzmi:

Co jest specjalnego w uruchamianiu procesu z określoną kombinacją użytkowników / grup, która uniemożliwia temu procesowi dostęp do plików należących do dodatkowych grup tego użytkownika i czy można temu zaradzić?

Proces jest uruchamiany z uid i gid. Oba mają przypisane uprawnienia. Możesz wywołać chroot ze specyfikacją użytkownika użytkownika i grupy, podczas gdy w rzeczywistości użytkownika nie ma w tej grupie. Proces byłby wówczas wykonywany z identyfikatorem użytkownika i podanymi grupami.

Zobacz przykład. Mam użytkownika o nazwie user, a on jest w grupie student:

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

Mam plik w następujący sposób:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

Nie może tego przeczytać:

user@host:~$ cat file
cat: file: Permission denied 

Teraz mogę obserwować catproces w kontekście użytkownika userORAZ grupy root. Teraz proces cat ma niezbędne uprawnienia:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

Ciekawie jest zobaczyć, co idmówi:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Hm, ale użytkownika usernie ma w tej grupie ( root). Skąd czerpię idinformacje? Jeśli wywołana bez argumentów, idużywa wywołań systemowych, getuid(), getgid()i getgroups(). Tak więc kontekst procesu idjest drukowany. Kontekst, z którym się zmieniliśmy --userspec.

Po wywołaniu z argumentem, idpo prostu określa przypisania grupowe użytkownika:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

Na twoje pytanie:

Co jest specjalnego w uruchamianiu procesu z określoną kombinacją użytkowników / grup, która uniemożliwia temu procesowi dostęp do plików należących do dodatkowych grup tego użytkownika i czy można temu zaradzić?

Możesz ustawić kontekst procesu bezpieczeństwa, który jest potrzebny do rozwiązania zadania, które proces musi wykonać. Każdy proces ma ustawiony identyfikator UID i GID, w ramach którego działa. Zwykle proces „przyjmuje” uid i gid użytkownika wywołującego jako kontekst. Przez „wzięcia” mam na myśli jądro, inaczej byłby to problem z bezpieczeństwem.

Tak naprawdę to nie użytkownik, który nie ma uprawnień do odczytu pliku, to uprawnienia procesu ( cat). Ale proces przebiega z identyfikatorem uid / gid wywołującego użytkownika.

Nie musisz więc należeć do konkretnej grupy, aby proces działał z twoim identyfikatorem użytkownika i identyfikatorem grupy.

Użycie tej --userspecopcji chrootokreśla użytkownika i pojedynczą grupę do użycia podczas uruchamiania chroot. Aby zdefiniować grupy dodatkowe, musisz również użyć tej --groupsopcji.

Domyślnie procesy dziedziczą podstawową i uzupełniającą grupę użytkownika, który je uruchamia, ale za pomocą polecenia --userspecmówisz, chmodaby zastąpić to za pomocą podanej pojedynczej grupy.

Szczegółowa dokumentacja uprawnień w systemie Linux jest dostępna na stronie credentials(7)podręcznika.

Gdy logujesz się do Linuksa, proces logowania¹ - po sprawdzeniu, czy możesz zalogować się jako phil - pobiera identyfikator użytkownika phil i grupy, do których należy, ustawiając je jako proces, który jest następnie uruchamiany jako powłoka. Grupy UID, GID i Uzupełniające są własnością tego procesu.

Wszelkie późniejsze programy uruchomione po tym są potomkami tej powłoki i po prostu otrzymują kopię tych danych uwierzytelniających. * To wyjaśnia, dlaczego zmiana uprawnień użytkownika nie wpływa na uruchomione procesy. Zmiany zostaną jednak odebrane przy następnym logowaniu.

* Wyjątkiem są programy, których bity setuid lub setgid są ustawione, które będą miały inny efektywny identyfikator użytkownika . Jest to używane na przykład w su (1), więc może działać z rootuprawnieniami, nawet jeśli jest wykonywane przez phil.

Po dodaniu phildo admgrupy, on może uruchomić su phil, a sunastępnie - uruchomić jako root - sprawdzić, czy rzeczywiście podaje hasło phila, a następnie umieścić go w powłoce z uid, gid i dodatkowymi grupami, do których należy phil. A ponieważ dzieje się tak po dodaniu użytkownika do grupy, ta powłoka byłaby już w admgrupie.

Nie uważam chroot (1) za najbardziej odpowiedni program do uruchamiania jako inny użytkownik , ale z pewnością wykona on pracę. Ten parametr --userspec phil:philpowoduje, że działa z identyfikatorami UID phili GID phil. Żadne dodatkowe grupy nie są ustawione (do tego byś podał --groups). Zatem proces potomny nie jest w admgrupie.

Byłby to bardziej normalny sposób uruchamiania procesu tak, jak phil su phil -c "process". Podczas suładowania grup UID, GID i grup uzupełniających z informacji z bazy danych użytkowników processbędą miały takie same poświadczenia, jakie aktualnie posiada użytkownik.

¹ Może to być login (1) , sshd, su, gdb lub inne programy. Ponadto prawdopodobnie jest zarządzany przez moduły pam.