Uprawnienia, ACL i atrybuty plików w Linuxie – jak naprawdę działa bezpieczeństwo plików

Bezpieczeństwo plików w Linuxie to nie jest tylko chmod 755.
To wielowarstwowy model, który przez lata był rozbudowywany, łatany i rozszerzany, aż powstał system:

• prosty na pierwszy rzut oka,
• bardzo precyzyjny w środku,
• często źle rozumiany nawet przez administratorów.

Efekt?
Systemy, które „działają”, ale są:

• zbyt otwarte,
• źle delegowane,
• podatne na eskalację uprawnień.

Ten artykuł wyjaśnia jak Linux naprawdę chroni pliki – od klasycznych uprawnień, przez ACL, aż po atrybuty, o których wielu adminów zapomina.

Model bezpieczeństwa plików w Linuxie – trzy warstwy

Każdy plik i katalog w Linuxie jest chroniony jednocześnie przez:

1. Klasyczne uprawnienia (UID / GID / rwx)
2. ACL – dodatkowe reguły dostępu
3. Atrybuty plików (immutable, append-only itd.)

I dopiero razem tworzą pełny obraz.

1. Klasyczne uprawnienia: chmod, chown, umask

Właściciel, grupa, inni – fundament modelu

Każdy plik ma:

• właściciela (user)
• grupę (group)
• resztę świata (others)

Dla każdej z tych kategorii istnieją prawa:

• r – odczyt
• w – zapis
• x – wykonanie / wejście do katalogu

To nie jest symbolika – kernel sprawdza je przy każdej operacji.

chmod – zmiana praw, nie odpowiedzialności

chmod:

• nie zmienia właściciela,
• nie zmienia grupy,
• tylko modyfikuje maskę dostępu.

Kluczowa zasada:

chmod nigdy nie „naprawia” złej architektury uprawnień

Najczęstszy błąd:

• chmod 777, bo „coś nie działa”

📌 777 to brak bezpieczeństwa, nie rozwiązanie.

chown – kto naprawdę kontroluje plik

W Linuxie:

• właściciel zawsze wygrywa (poza MAC i atrybutami),
• użytkownik może zmieniać prawa własnych plików.

Dlatego:

• zły chown = potencjalna eskalacja uprawnień
• usługi nie powinny działać jako root

📌 Prawa bez kontroli właściciela są iluzją.

umask – cichy generator luk

umask określa:

• jakie prawa są odejmowane przy tworzeniu pliku,
• działa globalnie lub per użytkownik.

Typowy problem:

• umask 000 → pliki tworzone jako światowo zapisywalne
• umask ustawiony „na sztywno” w skryptach

📌 umask nie dodaje praw – on je blokuje lub nie blokuje.

2. ACL – gdy klasyczne rwx to za mało

ACL (Access Control Lists) powstały, bo:

• model user/group/others jest zbyt sztywny,
• nowoczesne systemy potrzebują delegacji per użytkownik.

ACL pozwala:

• dać dostęp konkretnemu użytkownikowi,
• bez zmiany grupy,
• bez łamania istniejących praw.

getfacl i setfacl – jak to działa

ACL:

• nakłada się na klasyczne uprawnienia
• może je ograniczać, ale nie rozszerzać poza maskę

Kluczowe pojęcie:

• mask – maksymalne efektywne prawa ACL

📌 ACL bez zrozumienia maski prowadzi do chaosu.

ACL na katalogach – największa pułapka

ACL domyślne (default:):

• są dziedziczone przez nowe pliki,
• działają automatycznie,
• często są zapominane.

Efekt:

• „dziwne prawa”
• administrator nie wie, skąd się wzięły

📌 Jeśli nie wiesz, czy katalog ma ACL – sprawdź, zanim coś zmienisz.

3. Atrybuty plików – poziom, którego wielu nie zna

Atrybuty (chattr, lsattr) działają:

• poniżej chmod
• często poniżej roota

To ostatnia linia obrony.

Najważniejsze atrybuty

immutable (i)

• pliku nie da się:
  • zmodyfikować,
  • usunąć,
  • nadpisać,
• nawet root musi najpierw zdjąć atrybut.

append-only (a)

• można tylko dopisywać,
• idealne dla logów.

📌 Atrybuty są ignorowane przez wielu adminów – i to błąd.

Dlaczego to ważne dla bezpieczeństwa

Atrybuty:

• chronią przed:
  • malware,
  • błędami skryptów,
  • nieautoryzowaną modyfikacją,
• utrudniają ataki po eskalacji uprawnień.

📌 Root bez kontroli też bywa zagrożeniem.

4. Typowe błędy administratorów

1. chmod 777 jako „rozwiązanie”

To nie naprawa.
To wyłączenie bezpieczeństwa.

2. ACL bez dokumentacji

ACL działają długo po tym, jak admin o nich zapomni.

3. Brak atrybutów na krytycznych plikach

Pliki konfiguracyjne i binarki:

• powinny być niemodyfikowalne
• poza kontrolowanym procesem aktualizacji.

4. Mylenie uprawnień pliku i katalogu

• x w katalogu ≠ x w pliku
• brak x = brak dostępu, nawet przy r

Jak myśli kernel – klucz do zrozumienia

Przy każdym dostępie kernel sprawdza:

1. atrybuty
2. MAC (jeśli aktywny)
3. ACL
4. klasyczne rwx
5. kontekst procesu

📌 chmod to tylko jeden etap.

Podsumowanie

Bezpieczeństwo plików w Linuxie:

• nie jest trudne,
• ale jest łatwe do zepsucia.

Prawdziwy hardening to:

• poprawny właściciel,
• minimalne prawa,
• świadome ACL,
• atrybuty tam, gdzie trzeba,
• zero „chmod 777 w panice”.

Bo w Linuxie:

nie wygrywa ten, kto ma „działający system”
tylko ten, kto rozumie, dlaczego działa i kto ma do czego dostęp.

Polecane wpisy

Najlepsze aplikacje edukacyjne na Linux dla dzieci w wieku 6–14 lat

🎓 Najlepsze aplikacje edukacyjne na Linux dla dzieci (6–14 lat) GCompris Jeden z najbardziej wszechstronnych pakietów edukacyjnych. Zawiera ponad 140 Czytaj dalej

Czytaj  Zaawansowane techniki twardego zabezpieczania serwerów Linux

Bezpieczeństwo systemu Debian: Konfiguracja firewalla i IDS/IPS

Bezpieczeństwo systemu Debian: Konfiguracja firewalla i IDS/IPS Bezpieczeństwo systemów operacyjnych jest kluczowym elementem zarządzania serwerami i infrastrukturą IT. Debian, będący Czytaj dalej