Jakie role odgrywają DAC (uprawnienia do plików), ACL i MAC (SELinux) w zabezpieczeniach plików w systemie Linux?

Potrzebuję wyjaśnienia / potwierdzenia / opracowania na temat różnych ról, jakie DAC, ACL i MAC odgrywają w zabezpieczeniach plików Linuksa.

Po kilku badaniach z dokumentacji, rozumiem stos:

1. SELinux musi umożliwiać dostęp do obiektu pliku.
2. Jeśli ACL pliku (np, setfacl, getfaclza mocowanie ACL) wyraźnie zezwala / zabrania dostępu do obiektu, wówczas nie jest wymagane żadne dalsze przetwarzanie.
3. W przeciwnym razie zależy to od uprawnień pliku (model DAC rwxrwxrwx).

Czy coś brakuje? Czy są sytuacje, w których tak nie jest ?

Kiedy proces wykonuje operację na pliku, jądro Linuksa wykonuje sprawdzenie w następującej kolejności:

1. Dyskretna kontrola dostępu (DAC) lub podyktowana przez użytkownika kontrola dostępu. Obejmuje to zarówno klasyczne sprawdzanie uprawnień w stylu UNIX, jak i listy kontroli dostępu POSIX (ACL) . Klasyczne kontrole UNIX porównują bieżący UID i GID procesu z UID i GID pliku, do którego uzyskiwany jest dostęp, w odniesieniu do tego, które tryby zostały ustawione (Odczyt / Zapis / eXecute). Lista kontroli dostępu rozszerza klasyczne kontrole systemu UNIX, aby umożliwić więcej opcji dotyczących kontroli uprawnień.

2. Obowiązkowa kontrola dostępu (MAC) lub kontrola dostępu oparta na zasadach. Jest to realizowane za pomocą Linux Security Modules (LSM), które nie są już prawdziwymi modułami (kiedyś były, ale zostały porzucone). Umożliwiają dodatkowe kontrole w oparciu o inne modele niż klasyczne kontrole bezpieczeństwa w stylu UNIX. Wszystkie te modele opierają się na polityce opisującej, jakie rodzaje operacji są dozwolone dla jakiego procesu w jakim kontekście.

Oto przykład dostępu do i-węzłów (który obejmuje dostęp do plików), aby poprzeć moją odpowiedź linkami do internetowego linuksowego odnośnika . Podane „ function_name(nazwa_pliku: linia)” dotyczy wersji 3.14 jądra Linuksa.

Funkcja inode_permission( fs / namei.c: 449 ) najpierw sprawdza uprawnienia do odczytu w samym systemie plików ( sb_permissionw fs / namei.c: 425 ), a następnie wywołuje __inode_permission( fs / namei.c: 394 ) w celu sprawdzenia odczytu / zapisu / wykonania uprawnienia i POSIX ACL dla i-węzła w do_inode_permission( fs / namei.c: 368 ) (DAC), a następnie uprawnienia związane z LSM (MAC) w security_inode_permission( security / security.c: 550 ).

Był tylko jeden wyjątek od tej kolejności (DAC, a potem MAC): dotyczyło to sprawdzania mmap. Zostało to jednak naprawione w wersji 3.15 jądra Linuksa ( odpowiednie zatwierdzenie ).

DAC== Discretionary Access Control, http://en.wikipedia.org/wiki/Discretionary_access_control
MAC == Mandatory Access Control, http://en.wikipedia.org/wiki/Mandatory_access_control
ACL == Access Control List, http://en.wikipedia.org/wiki/Access_control_list

W ACLOkreśla przeprowadzanie kontroli metodą sterowania, DACalbo MAC. MACjest jawny, kontrolowany centralnie i nie pozwala użytkownikom na przyznanie uprawnień do obiektu, chyba że mają wyraźne uprawnienia, a jednocześnie DACumożliwia użytkownikom udzielanie innym użytkownikom dostępu do obiektów, do których mają dostęp.

MAC ACLs zawsze będzie najpierw stosowane do żądania, a jeśli odmówiono dostępu, przetwarzanie zostaje zatrzymane. Jeśli dostęp jest dozwolony, DAC ACLs są stosowane, i ponownie, jeśli odmowa dostępu, przetwarzanie zostanie zatrzymane. Tylko jeśli dostęp jest przyznawany przez obie MACi DAC ACLs mogą użytkownikowi dostęp obiekt poprosili.

SELinuxjest MACimplementacją dla Linuksa (istnieją inne), podczas gdy tradycyjne rwxuprawnienia do plików w połączeniu z właścicielem i grupą będącą właścicielem tworzą komplet DAC ACL. SELinux„Polityka” jest w istocie MAC ACL.

Przykro mi, ale mam nadzieję, że niektóre z odpowiedzi tutaj mogą być niepoprawne. Bezpośrednio z http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html :

Reguły polityki SELinuksa są sprawdzane po regułach DAC. Reguły polityki SELinux nie są używane, jeśli reguły DAC najpierw odmawiają dostępu.