Security (Polski) - ArchWiki

Jump to content

# Security (Polski)

From ArchWiki
Status tłumaczenia: Ten artykuł jest przetłumaczoną wersją Security. Data ostatniego tłumaczenia: 2025-12-15. Możesz pomóc zsynchronizować tłumaczenie, jeśli nastąpiły zmiany w wersji angielskiej.

Powiązane artykuły

- Arch Security Team
- General recommendations (Polski)
- Identity management
- Capabilities
- List of applications (Polski)/Security (Polski)
- Arch package guidelines/Security

Ten artykuł zawiera zalecenia i najlepsze praktyki dotyczące utwardzania systemu Arch Linux.

## Koncepcje

- Możliwe jest zaostrzenie zabezpieczeń do tego stopnia, że system jest nieużyteczny. Bezpieczeństwo i wygoda muszą być zrównoważone. Sztuką jest stworzenie bezpiecznego i użytecznego systemu.
- Największym zagrożeniem jest i zawsze będzie użytkownik.
- Zasada najmniejszego przywileju: Każda część systemu powinna mieć dostęp tylko do tego, co jest ściśle wymagane i nic więcej.
- Obrona w głąb: Bezpieczeństwo działa lepiej w niezależnych warstwach. Gdy jedna warstwa zostanie naruszona, inna powinna zatrzymać atak.
- Bądź trochę paranoiczny i podejrzliwy. Jeśli coś brzmi zbyt pięknie, aby mogło być prawdziwe, to prawdopodobnie tak jest!
- Nigdy nie możesz sprawić, aby system był w 100% bezpieczny, nawet jeśli odłączysz maszynę z sieci, wyłączysz ją, zamkniesz w sejfie, zalejesz w betonie i nigdy jej nie użyjesz.
- Przygotuj się na porażkę. Stwórz plan z wyprzedzeniem, którego będziesz przestrzegać, gdy twoje zabezpieczenia zostaną złamane.

## Hasła

Hasła są kluczem do bezpieczeństwa systemu. Zabezpieczają konta użytkowników, zaszyfrowane systemy plików, oraz klucze SSH/GPG. Są one głównym sposobem, w jaki komputer decyduje się zaufać osobie, która go używa, więc duża część bezpieczeństwa polega tylko na wybieraniu bezpiecznych haseł i ich ochronie.

### Różnica pomiędzy Password a Passphrase

Może być ważne podkreślenie różnicy pomiędzy tymi słowami, gdyż w języku polskim oba tłumaczą się na hasło.

- Password jest definiowany, jako ciąg znaków (liter, cyfr i innych symboli) służący do uwierzytelniania tożsamości lub weryfikacji uprawnień dostępu. W dalszej części nazywany hasłem.
- Passphrase jest definiowany, jako łatwa do zapamiętania tajemnica składająca się z sekwencji słów lub innego tekstu, którego używa osoba ubiegająca się o dostęp w celu uwierzytelnienia swojej tożsamości. W dalszej części nazywany hasłem frazy.

W skrócie: ważne jest, aby zapamiętać, że password to ciąg znaków `8&YIjth718h!&2es@Fb!+[whR`, które zazwyczaj są trudne do zapamiętania przez człowieka, natomiast passphrase to ciąg słów `Urwane-Różnorodne-Pieczenie-Śmieciarz-Czekolada2`, przez co jest dłuższe, ale łatwiejsze do zapamiętania.

### Wybór bezpiecznych haseł

Hasła muszą być wystarczająco złożone, aby nie można było ich łatwo odgadnąć, np. na podstawie informacji osobistych, lub aby nie zostały złamane przy użyciu metod takich jak socjotechnika lub ataki brute-force. Siła hasła zależy głównie od jego długości i losowości. W kryptografii jakość hasła jest często określana jako jego entropia.

Niebezpieczne hasła to takie, które zawierają lub wykorzystują jako podstawę przed zastąpieniem/zmianą:

- Dane pozwalające na identyfikację (np. imię twojego psa, data urodzenia, kod pocztowy/kierunkowy, ulubiona gra wideo)
- Proste podstawienia znaków w słowach (np. `$mu7n4k0t3k`), ponieważ współczesne ataki słownikowe z łatwością sobie z nimi radzą.
- Słowa bazowe (rdzenie) lub pospolite ciągi znaków, po których następują lub które poprzedzają dodane liczby, symbole lub znaki (np. `Hasło123%`, lub `Qwedsazxc123`).
- Pospolite frazy lub krótkie ciągi powszechnie używanych słów słownikowych (np. `żebyniczegoniebyło`), w tym z podstawieniem znaków (np. `Ż3byN!cz3g0n!3był0`). (Patrz Diceware poniżej, by sprawdzić, kiedy kombinacja słów słownikowych może być bezpieczna).
- Którekolwiek z najczęściej używanych haseł

Najlepszym wyborem dla hasła jest coś długiego (im dłuższe, tym lepsze) i generowanego z losowego źródła. Ważne jest, aby używać długiego hasła. Słabe algorytmy haszujące pozwalają na złamanie hasza 8-znakowego hasła w zaledwie kilka godzin. CERT zaleca przynajmniej 14 znakowe hasło, ale NIST zaleca przynajmniej 15 znakowe, jeśli to jedyny składnik dla większej ilości składników pozwala na 8.

Narzędzia takie jak pwgen lub apgAUR pozwalają generować losowe hasła. Jednak takie hasła mogą być trudne do zapamiętania. Jedną z technik zapamiętywania (dla tych często wpisywanych) jest wygenerowanie długiego hasła i zapamiętanie minimalnie bezpiecznej liczby znaków, tymczasowo zapisując pełny wygenerowany ciąg znaków. Z czasem zwiększaj liczbę wpisywanych znaków, aż hasło zostanie zakorzenione w pamięci mięśniowej i nie będzie musiało być świadomie zapamiętywane. Ta technika jest trudniejsza, ale może zapewnić pewność, że hasło nie pojawi się w listach słów ani w "inteligentnych" atakach brute-force, które łączą słowa i zastępują znaki.

Oprócz zarządzania hasłami, keepassxc oferuje generowanie haseł / haseł fraz.

Jedna z technik zapamiętywania hasła polega na użyciu frazy mnemonicznej, w której każde słowo w frazie przypomina kolejne znaki w haśle. Na przykład fraza „dziewczyna idzie w dół deszczowej ulicy” mogłaby być przetłumaczona na `d6!WdR5` lub, mniej prosto, `d&6!RrlW@WdR,57`. To podejście może ułatwić zapamiętanie hasła, ale pamiętaj, że różne litery mają bardzo różne prawdopodobieństwa występowania na początku słów.

Zobacz: (Częstotliwość liter w języku Polskim).

Inną skuteczną techniką może być zapisywanie losowo generowanych haseł i przechowywanie ich w bezpiecznym miejscu, na przykład w portfelu, torebce lub sejfie na dokumenty. Większość ludzi dobrze chroni swoje fizyczne kosztowności przed kradzieżą, a większości ludzi łatwiej jest zrozumieć najlepsze praktyki bezpieczeństwa fizycznego w porównaniu z praktykami bezpieczeństwa cyfrowego.

Bardzo skuteczne jest również łączenie techniki mnemonicznej i losowej poprzez zapisywanie długich, losowo generowanych haseł w menedżerze haseł, do którego dostęp uzyskuje się za pomocą łatwego do zapamiętania "hasła głównego" / "hasła pierwotnego", które musi być używane tylko w tym celu. Hasło główne musi być zapamiętane i nigdy nie zapisane. Wymaga to też zainstalowania menedżera haseł w systemie, aby łatwo uzyskać dostęp do haseł (co może być postrzegane jako niedogodność lub funkcja bezpieczeństwa, w zależności od sytuacji). Niektóre menedżery haseł posiadają również aplikacje mobilne, które mogą wyświetlać hasła do ręcznego wprowadzania na systemach, w których menedżer nie jest zainstalowany (jeśli jest to częsty przypadek użycia, zamiast całkowicie losowych haseł, możesz używać dla każdej usługi haseł bezpiecznych, ale łatwiejszych do wpisania – patrz poniżej). Pamiętaj, że menedżer haseł wprowadza pojedynczy punkt awarii, jeśli kiedykolwiek zapomnisz hasła głównego. Niektóre menedżery haseł obliczają zawarte hasła na podstawie hasła głównego i nazwy usługi, do której chcesz się zalogować, zamiast je szyfrować, co umożliwia korzystanie z nich w nowym systemie bez synchronizowania jakichkolwiek danych.

Skuteczne może być użycie łatwej do zapamiętania długiej serii niepowiązanych słów jako hasła. Teoria mówi, że jeśli użyta zostanie wystarczająco długa fraza, zdobyta entropia z długości hasła może przeciwdziałać utraconej entropii z użycia słów słownikowych. Ten komiks xkcd pokazuje kompromis entropii tej metody, biorąc pod uwagę ograniczony zestaw możliwych słów dla każdego słowa w haśle frazie. Jeśli zestaw słów, które wybierasz, jest duży (wiele tysięcy słów) i wybierasz z niego 5-7 lub nawet więcej losowych słów, ta metoda zapewnia wielką entropię, nawet zakładając, że atakujący zna zestaw możliwych słów wybranych i liczbę wybranych słów. Liczba możliwych haseł fraz po ustaleniu zestawu słów i ich liczby wynosi: (liczba słów w zestawie do wyboru) do potęgi (liczby słów wybranych dla hasła frazy).

Zobacz: Diceware. The passphrase FAQ lub Mocne hasło aby zgłębić temat.

### Zarządzanie hasłami

Po wybraniu silnego hasła należy je bezpiecznie przechowywać. Uważaj na keyloggery (oprogramowanie i sprzęt), programy rejestrujące zawartość ekranu, inżynierię społeczną, podglądanie przez ramię. Nie używaj tego samego hasła w różnych miejscach, gdyż w sytuacji wycieku danych z jednego serwisu narażasz wszystkie swoje konta. Menedżer haseł może pomóc w zarządzaniu dużą liczbą złożonych haseł: jeśli kopiujesz i wklejasz zapisane hasła z menedżera do aplikacji, które ich potrzebują, pamiętaj, aby za każdym razem czyścić schowek i upewnić się, że nie są one zapisywane w żadnym dzienniku (np. nie wklejaj ich w zwykłych poleceniach terminala, które przechowują je w plikach takich jak `.bash_history`). Należy pamiętać, że menedżery haseł zaimplementowane jako rozszerzenia przeglądarki mogą być podatne na ataki kanału bocznego. Można to ograniczyć, korzystając z menedżerów haseł działających jako oddzielne aplikacje.

Z zasady nie należy wybierać niebezpiecznych haseł tylko dlatego, że bezpieczne są trudniejsze do zapamiętania. Hasła to kwestia kompromisu. Lepiej jest mieć zaszyfrowaną bazę danych bezpiecznych haseł, chronioną kluczem i jednym silnym hasłem głównym, niż wiele podobnych, słabych haseł. Zapisywanie haseł (np. na kartce) jest prawdopodobnie równie skuteczne [1], ponieważ pozwala uniknąć potencjalnych luk w zabezpieczeniach oprogramowania, wymagając jednocześnie zabezpieczenia fizycznego.

Jeśli używasz tego samego hasła do szyfrowania dysku, co hasła logowania (przydatne np. do automatycznego montowania zaszyfrowanej partycji lub folderu podczas logowania), upewnij się, że `/etc/shadow` znajduje się na zaszyfrowanej partycji i/lub używa silnej funkcji generowania klucza (tj. yescrypt / argon2 lub sha512 z PBKDF2, ale nie md5 lub niskich iteracji w PBKDF2) dla przechowywanego skrótu hasła (więcej informacji można znaleźć w SHA password hashes).

Wskazówka Arch Linux zmienił algorytm domyślnego haszowania na yescrypt. Jeśli nie dostosowałeś domyślnych ustawień, konieczne (i wystarczające) jest wykonanie zmiany hasła za pomocą `passwd`, aby zastosować nowe domyślne ustawienia.

Jeśli tworzysz kopię zapasową bazy danych haseł, upewnij się, że żadna kopia nie jest przechowywana za pomocą innego hasła, które z kolei jest w niej przechowywane, np. na zaszyfrowanym dysku lub w uwierzytelnionej usłudze zdalnego przechowywania danych, ponieważ w razie potrzeby nie będziesz w stanie uzyskać do niej dostępu. Przydatną sztuczką jest zabezpieczenie dysków lub kont, na których znajduje się kopia zapasowa bazy danych, za pomocą prostego skrótu kryptograficznego hasła głównego. Prowadź listę wszystkich lokalizacji kopii zapasowych: jeśli pewnego dnia będziesz podejrzewać, że hasło główne zostało naruszone, będziesz musiał natychmiast zmienić je we wszystkich kopiach zapasowych bazy danych i lokalizacjach chronionych kluczami pochodnymi od hasła głównego.

Bezpieczne kontrolowanie wersji bazy danych może być bardzo skomplikowane: jeśli zdecydujesz się to zrobić, musisz mieć możliwość aktualizacji hasła głównego wszystkich wersji bazy danych. Nie zawsze od razu wiadomo, kiedy hasło główne zostało ujawnione: aby zmniejszyć ryzyko, że ktoś inny odkryje Twoje hasło, zanim zorientujesz się, że zostało ujawnione, możesz zdecydować się na jego okresową zmianę. Jeśli obawiasz się, że utraciłeś kontrolę nad kopią bazy danych, musisz zmienić wszystkie hasła w niej zawarte w czasie, jaki może zająć złamanie hasła głównego metodą brute-force, w zależności od jego entropii.

#### Menedżery haseł

Najprawdopodobniej, najlepszym rozwiązaniem będzie dla ciebie, wykorzystanie jakiegoś menedżera haseł, ponieważ jest to program który, będzie za Ciebie przetrzymywał i generował nowe hasła, dobrze skonfigurowany pomaga też bronić się przed Phishingiem. Jednak sam powinieneś wybrać najlepszą metodę dla ciebie,

Ostrzeżenie Program keepassxc posiada wbudowaną w siebie opcje auto-wpisywania, ale sprawdza ona tytuł, a nie adres strony, przez co strony Phishingowe mogą dostać hasło od menedżera KeePassXC. Jest to spowodowane tym, że łatwiej można odczytać tytuł okna, niż zawartość paska adresowego. Jednakże KeePassXC oferuje inną metodę (rozszerzenie do przeglądarki), która bazuje na adresie URL.
Uwaga Dodatkowo funkcja ta w Wayland jest domyślnie wyłączona należy ustawić `QT_QPA_PLATFORM=xcb`, lub rozpocząć KeePassXC z flagą `keepassxc -platform xcb`.

Programy do zarządzania hasłami możemy podzielić ze względu:

- Tworzącą bazę lokalnie, przykład keepassxc
- Tworzącą bazę w chmurze, przykład bitwarden

Wadą takich rozwiązań jest, że od teraz jeśli ktoś posiada hasło główna posiada dostęp do twoich WSZYSTKICH haseł (zawartych w bazie), musisz zabezpieczyć hasło do bazy z hasłami. Jeżeli zdecydowałeś się na opcje działającą lokalnie, ponosisz PEŁNĄ odpowiedzialność za utrzymanie spójności danych, synchronizację między urządzeniami oraz tworzenie kopii zapasowych zaszyfrowanej bazy danych. Rozwiązanie chmurowe, wiąże się z podwyższonym prawdopodobieństwem utraty kontroli operacyjnej nad fizycznym położeniem i infrastrukturą bazy haseł. (w skrócie, najpewniej kiedyś ta baza wycieknie.)

Można niektóre z tych problemów ograniczyć, poprzez wykorzystanie metody Haseł podwójnie ślepych/ Horcruxing, zakłada ona, że ani ty, ani wybrany przez Ciebie menedżer haseł nie zna pełnego hasła, tylko posiadacie po kawałku hasła, dzięki czemu utrudnisz atakującemu wykorzystanie twojej bazy z hasłami, gdyż musi jakoś uzyskać Twoją część haseł.

Zobacz: Hasła podwójnie ślepe Dokumentacja KeePassXC

Wskazówka Jeśli strona oferuje, wykorzystaj logowanie dwuskładnikowe. Zapewnia ona mniejsze prawdopodobieństwo nieautoryzowanego dostępu do twoich kont.

Zobacz: WebAuthn, Konfiguracja U2F dla konta użytkownika

### Hasze haseł

Hash (funkcja skrótu) jest funkcją jednokierunkową, co oznacza, że została zaprojektowana tak, aby niemożliwe było wywnioskowanie danych wejściowych na podstawie jej wyniku bez ponownego obliczenia funkcji haszującej z tymi danymi. (Przykłady: MD5, SHA.)

Funkcja haszowania hasła została zaprojektowana tak, aby uniemożliwić odgadnięcie danych wprowadzonych przez użytkownika (hasła) bez obliczenia funkcji haszującej (przykład: bcrypt). Funkcja wyprowadzania klucza (KDF; przykłady: yescrypt, scrypt, PBKDF2) to algorytm kryptograficzny zaprojektowany w celu wyprowadzenia tajnych kluczy (np. klucza AES, skrótu hasła) z danych wejściowych (klucza głównego, hasła). W związku z tym funkcja KDF może służyć wielu zastosowaniom, w tym funkcji skrótu hasła.

Domyślnie Arch przechowuje zhaszowane hasła użytkowników w pliku `/etc/shadow`, który jest dostępny tylko dla administratora root, oddzielnie od innych parametrów użytkowników przechowywanych w pliku `/etc/passwd`, który jest dostępny dla wszystkich użytkowników, patrz Users and groups#User database. Zobacz także #Ogranicz konto root.

Hasła są ustawiane za pomocą polecenia „passwd”, które rozciąga je za pomocą funkcji kryptograficznej systemu, a następnie zapisuje w `/etc/shadow`. Hasła są również solone, aby chronić je przed atakami tęczowych tablic. Zobacz: How are passwords stored in Linux (Understanding hashing with shadow utils), lub z nowszego Understanding /etc/shadow file format on Linux.

Ponieważ skróty haseł mają określony format, metodę i parametr można skonfigurować dla kolejnych nowych wywołań polecenia passwd. W związku z tym poszczególne skróty przechowywane w pliku `/etc/shadow` mogą stanowić heterogeniczną mieszankę funkcji skrótu obsługiwanych przez system.

Więcej informacji na temat formatu, metod haszowania i parametrów można znaleźć w crypt(5).

Plik `/etc/login.defs` konfiguruje domyślną metodę haszowania haseł, przez `ENCRYPT_METHOD YESCRYPT` oraz jej parametr `YESCRYPT_COST_FACTOR`.

Na przykład zwiększenie domyślnego parametru `YESCRYPT_COST_FACTOR` spowoduje logarytmiczny wzrost czasu obliczeniowego wymaganego do wyprowadzenia skrótu z hasła. Dotyczy to również osób trzecich próbujących uzyskać tajne hasło oraz systemu uwierzytelniającego logowanie użytkownika.

Natomiast czas obliczeniowy funkcji skrótu SHA-512 jest konfigurowany za pomocą parametru o liniowym wpływie. Informacje na temat poprzedniego domyślnego ustawienia Arch można znaleźć w sekcji Skróty haseł SHA. Należy pamiętać, że algorytm yescrypt wykorzystuje wewnętrznie funkcje SHA-256, HMAC i PBKDF2 do obliczania skrótu hasła. Głównym powodem jest połączenie pozytywnych cech tych szeroko stosowanych i przetestowanych funkcji w celu zwiększenia odporności na ataki. Na przykład użyteczność SHA do różnych celów spowodowała wsparcie sprzętowe dla tej funkcji, tj. wydajność obliczania czystego skrótu SHA znacznie wzrosła, co sprawia, że jego zastosowanie jako funkcji skrótu hasła staje się coraz bardziej przestarzałe.

### Wymuszanie silnych haseł za pomocą pam_pwquality

pam_pwquality zapewnia ochronę przed Atakami słownikowymi i pomaga skonfigurować zasady dotyczące haseł, które mogą być egzekwowane w całym systemie. Jest oparty na pam_cracklib, więc jest wstecznie kompatybilny z jego opcjami.

Zainstaluj pakiet libpwquality.

Ostrzeżenie Konto root nie podlega domyślnie tej polityce.
Uwaga

- Możesz użyć konta root, żeby ustawić hasło dla użytkownika, które omija żądaną/skonfigurowaną politykę. Jest to przydatne przy ustawianiu tymczasowych haseł.

Jeśli na przykład chcesz egzekwować tę politykę:

- dwukrotne zapytanie o hasło w przypadku błędu (opcja retry)
- minimalna długość 10 znaków (opcja minlen)
- co najmniej 6 znaków powinno różnić się od starego hasła podczas wprowadzania nowego (opcja difok)
- co najmniej 1 cyfra (opcja dcredit)
- co najmniej 1 wielka litera (opcja ucredit)
- co najmniej 1 mała litera (opcja lcredit)
- co najmniej 1 inny znak (opcja ocredit)
- nie może zawierać słów „myservice” i „mydomain”
- egzekwuj zasady dla użytkownika root

Edytuj plik `/etc/pam.d/passwd`, aby wyglądał następująco:

    #%PAM-1.0
    password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
    password required pam_unix.so use_authtok sha512 shadow

Ostrzeżenie To jest tylko przykład, nie zaleca się takiej polityki, ponieważ nie poprawia ona bezpieczeństwa (zobacz też CERT.pl). Obecne wytyczne odradzają wymuszanie znaków specjalnych, cyfr czy liter, bo prowadzą do przewidywalnych zmian i frustrują użytkowników. Zamiast tego skup się na długości hasła (minimum 15 znaków, jeśli jest jedynym sposobem uwierzytelniania).

Polecenie `password required pam_unix.so use_authtok` nakazuje modułowi pam_unix nie wyświetlać zapytania o podanie hasła, lecz użyć hasła dostarczonego przez moduł pam_pwquality.

Więcej informacji można znaleźć na stronach podręcznika pam_pwquality(8) i pam_unix(8).

## CPU

### Microkod

Informacje na temat instalowania ważnych aktualizacji zabezpieczeń mikrokodu procesora można znaleźć w sekcji microcode.

### Luki w zabezpieczeniach sprzętu

Niektóre procesory zawierają luki w zabezpieczeniach sprzętu. Lista tych luk oraz przewodniki dotyczące wyboru środków zaradczych, które pomogą dostosować jądro w celu złagodzenia tych luk w konkretnych scenariuszach użytkowania, znajdują się w dokumentacji jądra dotyczącej luk w zabezpieczeniach sprzętu.

Aby sprawdzić, czy dotyczy Cię znana luka w zabezpieczeniach, uruchom następujące polecenie:

    $ grep -r . /sys/devices/system/cpu/vulnerabilities/

W większości przypadków aktualizacja jądra i mikrokodu pozwoli złagodzić luki bezpieczeństwa.

#### Wielowątkowość współbieżna (hyper-threading)

Wielowątkowość współbieżna (SMT), zwane również hiperwątkowością w procesorach Intel, to funkcja sprzętowa, która może być źródłem luk w zabezpieczeniach L1 Terminal Fault i Microarchitectural Data Sampling. Aktualizacje jądra systemu Linux i mikrokodu zawierają środki zaradcze dla znanych luk w zabezpieczeniach, ale W przypadku niektórych procesorów może być nadal konieczne wyłączenie funkcji SMT, jeśli obecne są niezaufane goście wirtualizacji.

Uwaga Wyłączenie SMT jest korzystne głównie dla hiperwizorów. [2] W zwykłym systemie ma to bardzo małe lub żadne korzyści dla bezpieczeństwa.

Funkcję SMT można często wyłączyć w oprogramowaniu układowym systemu. Więcej informacji można znaleźć w dokumentacji płyty głównej lub systemu. Funkcję SMT można również wyłączyć w jądrze, dodając następujący parametr jądra:

    mitigations=auto,nosmt

## Pamięć

### Wzmocnienie malloc

hardened_mallocAUR jest wzmocnionym zamiennikiem funkcji malloc() biblioteki glibc. Projekt został pierwotnie opracowany przez Daniela Micaya z GrapheneOS w celu integracji z Biometrią i musl systemu Android, ale autor dodał również obsługę standardowych dystrybucji systemu Linux w architekturze x86_64.

Chociaż hardened_malloc nie jest jeszcze zintegrowany z glibc (mile widziana pomoc i prośby o pull), można go łatwo używać z LD_PRELOAD. W dotychczasowych testach powoduje on problemy tylko w kilku aplikacjach, jeśli jest włączony globalnie w `/etc/ld.so.preload`. Ponieważ hardened_malloc ma wpływ na wydajność, warto zdecydować, której implementacji użyć w poszczególnych przypadkach, w oparciu o aktualne rodzaje ataku i wymagania dotyczące wydajności.

The factual accuracy of this article or section is disputed.

Reason: Firefox może wymagać przebudowy, aby korzystanie z hardened-malloc było skuteczne. (Discuss in Talk:Security (Polski)#Use of hardened-malloc with Firefox)

Aby wypróbować to w trybie samodzielnym, użyj skryptu opakowującego hardened-malloc-preload lub ręcznie uruchom aplikację z odpowiednią wartością preload:

    LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

Właściwe użycie Firejail można znaleźć na jego stronie wiki, a niektóre konfigurowalne opcje kompilacji dla hardened_malloc można znaleźć w repozytorium github.

## Pamięć masowa

### Szyfrowanie danych w spoczynku

Szyfrowanie danych w spoczynku, przy czym preferowane jest szyfrowanie całego dysku za pomocą silnego hasła frazy, jest to jedyny sposób ochrony danych przed fizycznym odzyskaniem. Zapewnia to poufność danych, gdy komputer jest wyłączony lub dyski są odmontowane.

Jednak po włączeniu komputera i zamontowaniu dysku dane na nim przechowywane stają się tak samo podatne na zagrożenia jak w przypadku dysku niezaszyfrowanego. Dlatego najlepszym rozwiązaniem jest odmontowanie partycji danych, gdy tylko przestaną być potrzebne.

Można również zaszyfrować dysk za pomocą klucza przechowywanego w module TPM, chociaż w przeszłości występowały luki w zabezpieczeniach i klucz można uzyskać za pomocą ataku typu TPM-sniffing.

Niektóre programy, takie jak dm-crypt, umożliwiają użytkownikowi szyfrowanie pliku pętli jako wirtualnego woluminu. Jest to rozsądna alternatywa dla szyfrowania całego dysku, gdy tylko niektóre części systemu wymagają zabezpieczenia.

Chociaż typy szyfrowania oparte na urządzeniach blokowych lub systemach plików porównane w artykule data-at-rest encryption są przydatne w ochronie danych na nośnikach fizycznych, większość z nich nie może być używana do ochrony danych w systemie zdalnym, nad którym nie masz kontroli (takim jak pamięć masowa w chmurze). W niektórych przypadkach przydatne będzie szyfrowanie poszczególnych plików.

Oto kilka metod szyfrowania plików:

- Niektóre narzędzia do archiwizacji i kompresji zapewniają również podstawowe szyfrowanie. Przykładami są 7-Zip (flaga `-p`), zip (flaga `-e`). Szyfrowanie powinno być stosowane wyłącznie z zachowaniem szczególnej ostrożności, ponieważ narzędzia te mogą wykorzystywać niestandardowe algorytmy w celu zapewnienia kompatybilności między platformami. [3]
- GnuPG może być używane do szyfrowania plików.
- age to proste i łatwe w użyciu narzędzie do szyfrowania plików. Obsługuje również wielu odbiorców i szyfrowanie przy użyciu kluczy SSH, co jest przydatne do bezpiecznego udostępniania plików.

### Systemy plików

Jądro zapobiega teraz problemom bezpieczeństwa związanym z dowiązaniami fizycznymi i symbolicznymi, jeśli przełączniki sysctl `fs.protected_hardlinks` i `fs.protected_symlinks` są włączone, więc oddzielanie katalogów z prawem zapisu dla wszystkich użytkowników nie zapewnia już znaczącej korzyści w zakresie bezpieczeństwa.

Systemy plików zawierające katalogi z prawem zapisu dla wszystkich użytkowników mogą być nadal przechowywane oddzielnie, co stanowi prosty sposób ograniczenia szkód wynikających z wyczerpania miejsca na dysku. Jednak zapełnienie katalogów `/var` lub `/tmp` wystarczy, aby unieruchomić usługi. Istnieją bardziej elastyczne mechanizmy radzenia sobie z tym problemem (takie jak limity), a niektóre systemy plików same zawierają podobne funkcje (Btrfs ma limity na podwoluminach).

#### Opcje montażu

Zgodnie z zasadą minimalnych uprawnień systemy plików powinny być montowane przy użyciu najbardziej restrykcyjnych opcji montowania (bez utraty funkcjonalności).

Odpowiednie opcje montażu to:

- `nodev`: Nie interpretuj znaków lub bloków urządzeń specjalnych w systemie plików.
- `nosuid`: Nie zezwalaj na działanie bitów set-user-identifier lub set-group-identifier.
- `noexec`: Nie zezwalaj na bezpośrednie wykonywanie żadnych plików binarnych w zamontowanym systemie plików.
  - Ustawienie `noexec` w `/home` uniemożliwia wykonywanie skryptów i działania programów Wine, Steam, PyCharm, .NET itp.
    - Wine nie potrzebuje flagi `exec` do otwierania plików binarnych systemu Windows. Jest ona potrzebna tylko wtedy, gdy Wine jest zainstalowane w katalogu `/home`.
    - Aby Steam działał poprawnie, można zamontować `/home/user/.local/share/Steam` jako `exec` w fstab, dodając następujący wpis:

          /home/user/.local/share/Steam  /home/user/.local/share/Steam  none defaults,bind,user,exec,nofail  0  0

  - Niektóre pakiety (na przykład nvidia-dkms[broken link: replaced by nvidia-open-dkms]) mogą wymagać `exec` w `/var`.

Systemy plików używane do przechowywania danych powinny być zawsze montowane z opcjami `nodev`, `nosuid` i `noexec`.

Potencjalne montowania systemu plików do rozważenia:

- `/var`
- `/home`
- `/dev/shm`
- `/tmp`
- `/boot`

{{Tip (Polski)|W przypadku korzystania z automatycznego montowania partycji GPT, partycje ESP i XBOOTLDR są zawsze zabezpieczane za pomocą `noexec,nosuid,nodev`.

#### Migawki

Korzystając z migawek systemu plików, np. w Btrfs, LVM lub ZFS, należy pamiętać, że migawki mogą zawierać poufne informacje, które użytkownicy oczekują, że zostaną usunięte. Dotyczy to zwłaszcza sytuacji, gdy skonfigurowane są narzędzia do automatycznego tworzenia migawek, takie jak Snapper, ponieważ mogą one przechwytywać migawki w regularnych odstępach czasu lub w odpowiedzi na zdarzenia systemowe. Oto kilka przykładów tego, jak poufne informacje w `/home/` mogą pozostać w migawkach:

- Usunięte pliki i katalogi: Nawet jeśli pliki lub katalogi zostały usunięte z systemu plików, mogą nadal istnieć w starszych migawkach. W większości przypadków jest to normalne, ale warto rozważyć, czy pliki i katalogi takie jak `.local/share/Trash/`, `.history` itp. powinny zostać zachowane.
- Pliki tymczasowe i pamięć podręczna: Pliki tymczasowe i dane z pamięci podręcznej generowane przez aplikacje mogą być zawarte w migawkach. Na przykład pliki przechowywane w zaszyfrowanych katalogach mogą generować miniatury (`.cache/thumbnails`) lub kopie robocze po otwarciu, które z kolei mogą być zawarte w migawkach. To samo dotyczy np. historii przeglądania (`.mozilla/`, `.config/chromium/` itp.), która mogła zostać uwzględniona w migawce przed jej usunięciem.

Jeśli jest to obsługiwane, rozważ całkowite wykluczenie takich katalogów z migawek. Na przykład, jeśli używasz Btrfs, możesz utworzyć podwoluminy, takie jak `.cache/`, `.config/`, `.local/`, `.var/` lub dowolny inny katalog zgodnie z Twoim przypadkiem użycia.

Uwaga Przeniesienie `.local/share/Trash` do oddzielnego podwoluminu może w niektórych przypadkach spowodować nieprawidłowe działanie funkcji kosza, np. w przypadku GNOME/Files.

### Uprawnienia dostępu do plików

The factual accuracy of this article or section is disputed.

Reason: `chmod go-r` nie „usuwa wszystkich uprawnień”, a jedynie uprawnienia do odczytu. (Discuss in Talk:Security (Polski))

Domyślne uprawnienia do plików pozwalają na dostęp do prawie wszystkiego, a zmiana uprawnień może ukryć cenne informacje przed atakującym, który uzyska dostęp do konta niebędącego kontem root, takiego jak użytkownicy `http` lub `nobody`. Możesz użyć chmod, aby odebrać wszystkie uprawnienia grupie i innym osobom:

    # chmod go-r część_do_ukrycia

Ostrzeżenie Nie stosuj tego rozwiązania na szeroką skalę. Wypróbuj je najpierw dla jednej konfiguracji, upewniając się, że warto ją ukryć i że nie zakłóci to działania programu. Jeśli grupa jest niezbędna, może być konieczne usunięcie `g` z polecenia (lub ponowne dodanie uprawnień za pomocą `chmod g+r część`, jeśli polecenie zostało już uruchomione).

Niektóre ścieżki, które warto rozważyć, to:

- `/boot`: Katalog boot, który może zawierać tradycyjne obrazy vmlinuz i initramfs lub Jednolity obraz jądra. Należy pamiętać, że podczas korzystania z systemd#GPT partition automounting domyślnie stosowane są bezpieczne uprawnienia.
- `/etc/nftables.conf`: Konfiguracja nftables, mająca zastosowanie do nftables i iptables-nft[broken link: replaced by iptables].
- `/etc/iptables`: Starsza konfiguracja iptables, mająca zastosowanie do iptables.

Domyślną wartość umask `0022` można zmienić, aby poprawić bezpieczeństwo nowo tworzonych plików. W Przewodniku bezpieczeństwa NSA RHEL5 sugeruje się ustawienie umask na `0077` w celu zapewnienia maksymalnego bezpieczeństwa, co sprawia, że nowe pliki nie są czytelne dla użytkowników innych niż właściciel. Aby to zmienić, zobacz Umask#Set the mask value. Jeśli używasz sudo, rozważ skonfigurowanie go tak, aby używał domyślnej maski root.

### Pliki SUID i SGID

Ważne jest, aby mieć świadomość istnienia plików z bitem Setuid lub Setgid. Przykłady plików z ustawionym bitem SUID:

- unix_chkpwd
- chage, expiry, gpasswd, groupmems, passwd, sg (shadow)
- fusermount3, fusermount2
- pkexec, polkit-agent-helper-1[4] (polkit)
- ssh-keysign
- chfn, chsh, mount, newgrp, umount, wall, write (util-linux)
- sudo, sudo-rs, doas, su, su-rs, ksu
- firejail
- dbus-daemon-launch-helper
- chromium-sandbox
- Xorg.wrap

Do głównych zagrożeń związanych z takimi plikami wykonywalnymi należą luki w zabezpieczeniach umożliwiające podwyższenie uprawnień, patrz np. Wikipedia:Setuid#Security impact.[5][6][7]

Pliki z ustawionym bitem SUID, które nie należą do użytkownika root, lub pliki z ustawionym bitem SGID zazwyczaj mają mniejszy potencjalny wpływ, ale teoretycznie nadal mogą wyrządzić spore szkody, jeśli są podatne na ataki. Zazwyczaj można uniknąć używania SUID lub SGID, przypisując zamiast tego Capabilities.

Wskazówka Aby zapobiec sytuacji, w której system jest podatny na ataki, należy być czujnym i dbać o aktualność pakietów zawierających pliki wykonywalne SUID/SGID.

Aby wyszukać pliki z bitem SUID lub SGID:

    $ find / -perm "/u=s,g=s" -type f 2>/dev/null

### Kopie zapasowe

This article or section is a candidate for merging with System backup.

Notes: Istnieje specjalna strona poświęcona kopiom zapasowym systemu. (Discuss in Talk:Security (Polski))

Regularnie twórz kopie zapasowe ważnych danych. Regularnie sprawdzaj integralność kopii zapasowych. Regularnie sprawdzaj, czy kopie zapasowe można przywrócić.

Upewnij się, że co najmniej jedna kopia danych jest przechowywana w trybie offline, tj. nie jest w żaden sposób połączona z systemem, który jest zagrożony. Oprogramowanie ransomware i inne destrukcyjne ataki mogą również zaatakować wszelkie podłączone systemy kopii zapasowych.

Można skorzystać z zasady 3-2-1 czyli, z zasady mówiącej, że minimalne rozwiązanie do tworzenia kopii zapasowych powinno zawierać trzy kopie danych, w tym dwie kopie lokalne i jedną kopię poza twoim domem, na wypadek np. pożaru. Najprościej wykonać kopie zapasowe za pomocą programu takiego jak deja-dup, oczywiście zaleca się je zaszyfrować. Co może wydać się oczywiste, ale zaznaczę to tutaj, reguła powinna tyczyć się baz z hasłami, jeżeli zdecydowałeś się na użycie keepassxc, lub każdego innego który nie działa w chmurze, ponieważ w przypadku utraty takiej bazy tracisz dostęp do swoich haseł.

### Tryb zamrożenia dysku SSD SATA

Zobacz: Solid state drive#Setting the SATA SSD state to frozen mode after waking up from sleep.

## Konfiguracja użytkownika

### Nie korzystaj z konta root do codziennego użytku

Zgodnie z zasadą najmniejszego przywileju, nie należy używać konta root do codziennego użytkowania. Dla każdej osoby korzystającej z systemu należy utworzyć konto użytkownika bez uprawnień. Sposoby tymczasowego uzyskania uprawnień specjalnych opisano w sekcji List of applications (Polski)/Security (Polski)#Podniesienie uprawnień.

### Wprowadź opóźnienie po nieudanej próbie logowania

Dodaj następujący wiersz do pliku `/etc/pam.d/system-login`, aby dodać co najmniej 4-sekundowe opóźnienie między nieudanymi próbami logowania:

    /etc/pam.d/system-login

    auth optional pam_faildelay.so delay=4000000

`4000000` jest czasem opóźnienia w mikrosekundach.

Uwaga Inne moduły PAM oprócz `pam_faildelay` mogą również sugerować takie opóźnienie; jeśli zrobi to wiele modułów, PAM użyje najdłuższego z nich.

W szczególności zarówno `pam_unix`, jak i `pam_faillock` domyślnie ustawiają minimalne opóźnienie wynoszące 2 sekundy. Aby całkowicie usunąć to opóźnienie, należy dodać parametr `nodelay` do wszystkich linii `auth` tych modułów, np.

    /etc/pam.d/system-auth

    auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok nodelay

### Zablokuj użytkownika po trzech nieudanych próbach logowania

Od wersji pambase 20200721.1-2, `pam_faillock.so` jest domyślnie włączone, aby blokować użytkowników na 10 minut po 3 nieudanych próbach logowania w ciągu 15 minut (patrz FS#67644). Blokada dotyczy tylko uwierzytelniania hasłem (np. logowanie i „sudo”), uwierzytelnianie kluczem publicznym przez SSH jest nadal akceptowane. Aby zapobiec całkowitemu odmowie usługi, blokada ta jest domyślnie wyłączona dla użytkownika root.

Aby odblokować użytkownika, wykonaj następujące czynności:

    $ faillock --user username --reset

Domyślnie mechanizm blokujący to plik dla każdego użytkownika, który znajduje się w `/run/faillock/`. Usunięcie lub opróżnienie pliku odblokowuje tego użytkownika — katalog należy do roota, ale plik należy do użytkownika, więc polecenie `faillock` tylko opróżnia plik, więc nie wymaga uprawnień roota.

Moduł `pam_faillock.so` można skonfigurować za pomocą pliku `/etc/security/faillock.conf`. Parametry blokady:

- `unlock_time` — czas blokady (w sekundach, domyślnie 10 minut).
- `fail_interval` — czas, w którym nieudane logowania mogą spowodować blokadę (w sekundach, domyślnie 15 minut).
- `deny` — liczba nieudanych logowań przed blokadą (domyślnie 3).

Wskazówka Głównym celem blokady jest spowolnienie ataków brute-force, tak aby stały się one niewykonalne. Dlatego też, jeśli blokady spowodowane błędnym wpisaniem hasła stają się zbyt częste, lepszym rozwiązaniem może być zwiększenie liczby prób, niż skrócenie czasu blokady.
Uwaga `deny = 0` całkowicie wyłączy mechanizm blokady.

Domyślnie wszystkie blokady użytkowników są tracone po ponownym uruchomieniu systemu. Jeśli osoba atakująca może ponownie uruchomić komputer, bezpieczniej jest, aby blokady pozostały aktywne. Aby blokady pozostały aktywne, należy zmienić parametr `dir` w `/etc/security/faillock.conf` na `/var/lib/faillock`.

Aby zmiany zaczęły obowiązywać, nie trzeba restartować systemu. Więcej opcji konfiguracyjnych, takich jak włączenie blokady konta root, wyłączenie scentralizowanego logowania (np. LDAP) itp., znajdziesz w faillock.conf(5).

### Ogranicz liczbę procesów

W systemach z dużą liczbą użytkowników lub użytkownikami, którym nie ufamy, ważne jest, aby ograniczyć liczbę procesów, które każdy z nich może uruchomić jednocześnie, zapobiegając w ten sposób fork bombom i innym atakom typu denial-of-service. Konfiguracja `/etc/security/limits.conf` określa, ile procesów może mieć otwartych każdy użytkownik lub grupa, i domyślnie jest pusta (z wyjątkiem przydatnych komentarzy). Dodanie poniższych wierszy do tego pliku ograniczy wszystkich użytkowników do 100 aktywnych procesów, chyba że użyją oni polecenia `prlimit`, aby wyraźnie podnieść maksymalną liczbę do 200 dla tej sesji. Wartości te można zmienić zgodnie z odpowiednią liczbą procesów, które użytkownik powinien uruchamiać, lub sprzętem komputera, którym zarządzasz.

    * soft nproc 100
    * hard nproc 200

Aktualną liczbę wątków dla każdego użytkownika można sprawdzić za pomocą polecenia `ps --no-headers -Leo user | sort | uniq --count`. Może to pomóc w określeniu odpowiednich wartości limitów dla użytkowników; zobacz także limits.conf.

### Używaj Wayland

Preferuj używanie Wayland zamiast Xorg. Projekt Xorg powstał przed wprowadzeniem nowoczesnych praktyk bezpieczeństwa i przez wielu jest uważany za niebezpieczny. Na przykład klienci Xorg mogą rejestrować naciśnięcia klawiszy, gdy są nieaktywne.

Jeśli musisz uruchomić Xorg, zaleca się uniknięcie uruchamiania go jako root. W Waylandzie warstwa kompatybilności Xwayland automatycznie użyje rootless Xorg.

## Ogranicz konto root

Użytkownik root jest z definicji najpotężniejszym użytkownikiem w systemie. Trudno jest również przeprowadzić audyt konta użytkownika root. Dlatego ważne jest, aby w jak największym stopniu ograniczyć korzystanie z konta użytkownika root. Istnieje wiele sposobów na zachowanie uprawnień użytkownika root przy jednoczesnym ograniczeniu jego możliwości wyrządzenia szkody.

### Używaj sudo zamiast su

This article or section is a candidate for merging with sudo.

Notes: Istnieje specjalny artykuł na ten temat. (Discuss in Talk:Security (Polski))

Parę powodów, żeby korzystać z sudo zamiast su do podnoszenia uprawnień.

- Prowadzi dziennik, w którym zapisuje, który użytkownik z normalnymi uprawnieniami uruchomił każde z poleceń wymagających uprawnień administratora.
- Nie ma potrzeby podawania hasła administratora każdemu użytkownikowi, który potrzebuje dostępu do uprawnień administratora.
- `sudo` zapobiega przypadkowemu uruchamianiu przez użytkowników poleceń jako „root”, które nie wymagają uprawnień administratora, ponieważ nie jest tworzony pełny terminal administratora. Jest to zgodne z zasadą najmniejszego przywileju.
- Poszczególne programy mogą być włączane dla poszczególnych użytkowników, zamiast oferować pełny dostęp root tylko w celu uruchomienia jednego polecenia. Na przykład, aby dać użytkownikowi archie dostęp do określonego programu:

    # visudo

    /etc/sudoers

    archie ALL = NOPASSWD: /path/to/program

Można też zezwolić na używanie poszczególnych poleceń wszystkim użytkownikom. Aby zamontować udziały Samba z serwera jako zwykły użytkownik:

    %users ALL=/sbin/mount.cifs,/sbin/umount.cifs

Dzięki temu wszyscy użytkownicy należący do grupy users mogą uruchamiać polecenia `/sbin/mount.cifs` i `/sbin/umount.cifs` z dowolnego komputera (ALL).

Wskazówka Aby używać ograniczonej wersji `nano` zamiast `vi` z `visudo`,

    /etc/sudoers

    Defaults editor=/usr/bin/rnano

Eksportowanie `EDITOR=nano visudo` jest uważane za poważne zagrożenie bezpieczeństwa, ponieważ wszystko może być używane jako `EDITOR`.

#### Edytowanie plików za pomocą sudo

Zobacz Sudo#Editing files. Alternatywnie można użyć edytora takiego jak `rvim` lub `rnano`, który ma ograniczone możliwości, aby można było go bezpiecznie uruchamiać jako root.

### Ograniczanie logowania jako root

Po prawidłowym skonfigurowaniu sudo pełny dostęp administratora może zostać znacznie ograniczony lub zablokowany bez utraty użyteczności. Aby wyłączyć administratora, ale nadal umożliwić korzystanie z sudo, można użyć passwd(1) z `passwd --lock root`.

#### Zezwól tylko zaufanym użytkownikom

Plik PAM `pam_wheel.so` pozwala tylko użytkownikom z grupy `wheel` logować się za pomocą su. Zobacz su#su and wheel.

#### Zablokuj logowanie przez SSH

Nawet jeśli nie chcesz blokować logowania root dla lokalnych użytkowników, zawsze warto zablokować logowanie root przez SSH. Ma to na celu dodanie dodatkowej warstwy zabezpieczeń, zanim użytkownik będzie mógł całkowicie przejąć kontrolę nad systemem zdalnie.

#### Określanie akceptowalnych kombinacji logowania za pomocą access.conf

Ostrzeżenie Regresja w GNOME 49 powoduje zawieszanie się GDM, jeśli ustawisz regułę `-:ALL:ALL`. [8]

Kiedy ktoś próbuje się zalogować za pomocą PAM, sprawdzany jest plik `/etc/security/access.conf` pod kątem pierwszej kombinacji, która pasuje do jego właściwości logowania. Jego próba kończy się niepowodzeniem lub sukcesem w zależności od reguły dla tej kombinacji.

    +:root:LOCAL
    -:root:ALL

Reguły można ustawić dla określonych grup i użytkowników. W tym przykładzie użytkownik archie może logować się lokalnie, podobnie jak wszyscy użytkownicy z grup wheel i adm. Wszystkie inne logowania są odrzucane:

    +:archie:LOCAL
    +:(wheel):LOCAL
    +:(adm):LOCAL
    -:ALL:ALL

Przeczytaj więcej na access.conf(5)

## Obowiązkowa kontrola dostępu (MAC)

Mandatory access control (MAC) to rodzaj polityki bezpieczeństwa, która znacznie różni się od dyskrecjonalnej kontroli dostępu (DAC) stosowanej domyślnie w Archu i większości dystrybucji Linuksa. MAC zasadniczo oznacza, że każda czynność wykonywana przez program, która w jakikolwiek sposób wpływa na system, jest sprawdzana pod kątem zestawu reguł bezpieczeństwa. W przeciwieństwie do metod DAC, zestaw ten nie może być modyfikowany przez użytkowników. Zastosowanie praktycznie dowolnego systemu obowiązkowej kontroli dostępu znacznie poprawi bezpieczeństwo komputera, chociaż istnieją różnice w sposobie jego wdrażania.

### Ścieżka dostępu MAC

Kontrola dostępu oparta na ścieżkach to prosta forma kontroli dostępu, która przyznaje uprawnienia na podstawie ścieżki danego pliku. Wadą tego rodzaju kontroli dostępu jest to, że uprawnienia nie są przenoszone wraz z plikami, jeśli są one przenoszone w obrębie systemu. Zaletą jest natomiast to, że kontrola dostępu oparta na ścieżkach może być wdrażana w znacznie szerszym zakresie systemów plików, w przeciwieństwie do alternatywnych rozwiązań opartych na etykietach.

- AppArmor to implementacja MAC utrzymywana przez Canonical, postrzegana jako „łatwiejsza” alternatywa dla SELinux.
- TOMOYO to kolejny prosty, łatwy w użyciu system oferujący obowiązkową kontrolę dostępu. Został zaprojektowany tak, aby był prosty zarówno w użyciu, jak i we wdrażaniu, wymagając bardzo niewielu zależności.

### Etykiety MAC

Kontrola dostępu oparta na etykietach oznacza, że rozszerzone atrybuty pliku są wykorzystywane do zarządzania jego uprawnieniami bezpieczeństwa. Chociaż system ten jest prawdopodobnie bardziej elastyczny pod względem oferowanych zabezpieczeń niż kontrola dostępu oparta na ścieżkach, działa on tylko w systemach plików obsługujących te rozszerzone atrybuty.

- SELinux, oparty na projekcie NSA mającym na celu poprawę bezpieczeństwa systemu Linux, implementuje MAC całkowicie niezależnie od użytkowników systemu i ról. Oferuje niezwykle solidną, wielopoziomową implementację polityki MAC, która pozwala z łatwością utrzymać kontrolę nad systemem, który rozrasta się i zmienia w stosunku do swojej pierwotnej konfiguracji.

### Listy kontroli dostępu

Listy kontroli dostępu (ACL) stanowią alternatywę dla bezpośredniego dołączania reguł do systemu plików. Listy ACL realizują kontrolę dostępu poprzez sprawdzanie działań programu względem listy dozwolonych zachowań.

## Utwardzenie jądra

### Samozabezpieczenie jądra / ograniczanie skutków exploitów

Pakiet linux-hardened wykorzystuje podstawowy zestaw poprawek wzmacniających zabezpieczenia jądra oraz opcje konfiguracyjne kompilacji bardziej ukierunkowane na bezpieczeństwo niż pakiet linux. Możliwe jest stworzenie niestandardowej kompilacji, aby wybrać inny kompromis między bezpieczeństwem a wydajnością niż domyślne ustawienia ukierunkowane na bezpieczeństwo.

Należy jednak pamiętać, że niektóre pakiety nie będą działać przy użyciu tego jądra. Na przykład throttled.

Jeśli korzystasz ze sterownika spoza drzewa, takiego jak NVIDIA, może być konieczne przełączenie się na jego pakiet DKMS.

#### Porównanie ASLR w przestrzeni użytkownika

Pakiet linux-hardened zapewnia ulepszoną implementację losowego rozmieszczenia przestrzeni adresowej dla procesów przestrzeni użytkownika. Polecenie paxtest może być użyte do uzyskania oszacowania dostarczonej entropii:

##### Procesy 64-bitowe

    linux-hardened 5.4.21.a-1-hardened

    Test randomizacji mapowania anonimowego     : 32 bity jakości (oszacowane)
    Test randomizacji sterty (ET_EXEC)        : 40 bitów jakości (oszacowane)
    Test randomizacji sterty (PIE)            : 40 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (ET_EXEC)  : 32 bity jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (PIE)      : 32 bity jakości (oszacowane)
    Test randomizacji bibliotek współdzielonych        : 32 bity jakości (oszacowane)
    Test randomizacji VDSO                  : 32 bity jakości (oszacowane)
    Test randomizacji stosu (SEGMEXEC)      : 40 bitów jakości (oszacowane)
    Test randomizacji stosu (PAGEEXEC)      : 40 bitów jakości (oszacowane)
    Test randomizacji argumentów/środowiska (SEGMEXEC)    : 44 bity jakości (oszacowane)
    Test randomizacji argumentów/środowiska (PAGEEXEC)    : 44 bity jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_EXEC): 34 bity jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_DYN) : 34 bity jakości (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @~0: 32 bity (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @0 : 32 bity (oszacowane)

    linux 5.5.5-arch1-1

    Test randomizacji mapowania anonimowego     : 28 bitów jakości (oszacowane)
    Test randomizacji sterty (ET_EXEC)        : 28 bitów jakości (oszacowane)
    Test randomizacji sterty (PIE)            : 28 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (ET_EXEC)  : 28 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (PIE)      : 28 bitów jakości (oszacowane)
    Test randomizacji bibliotek współdzielonych        : 28 bitów jakości (oszacowane)
    Test randomizacji VDSO                  : 20 bitów jakości (oszacowane)
    Test randomizacji stosu (SEGMEXEC)      : 30 bitów jakości (oszacowane)
    Test randomizacji stosu (PAGEEXEC)      : 30 bitów jakości (oszacowane)
    Test randomizacji argumentów/środowiska (SEGMEXEC)    : 22 bity jakości (oszacowane)
    Test randomizacji argumentów/środowiska (PAGEEXEC)    : 22 bity jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_EXEC): 28 bitów jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_DYN) : 28 bitów jakości (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @~0: 29 bitów (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @0 : 29 bitów (oszacowane)

    linux-lts 4.19.101-1-lts

    Test randomizacji mapowania anonimowego     : 28 bitów jakości (oszacowane)
    Test randomizacji sterty (ET_EXEC)        : 28 bitów jakości (oszacowane)
    Test randomizacji sterty (PIE)            : 28 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (ET_EXEC)  : 28 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (PIE)      : 28 bitów jakości (oszacowane)
    Test randomizacji bibliotek współdzielonych        : 28 bitów jakości (oszacowane)
    Test randomizacji VDSO                  : 19 bitów jakości (oszacowane)
    Test randomizacji stosu (SEGMEXEC)      : 30 bitów jakości (oszacowane)
    Test randomizacji stosu (PAGEEXEC)      : 30 bitów jakości (oszacowane)
    Test randomizacji argumentów/środowiska (SEGMEXEC)    : 22 bity jakości (oszacowane)
    Test randomizacji argumentów/środowiska (PAGEEXEC)    : 22 bity jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_EXEC): 28 bitów jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_DYN) : 28 bitów jakości (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @~0: 28 bitów (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @0 : 28 bitów (oszacowane)

##### Procesy 32-bitowe (na jądrze x86_64)

    linux-hardened

    Test randomizacji mapowania anonimowego     : 16 bitów jakości (oszacowane)
    Test randomizacji sterty (ET_EXEC)        : 22 bity jakości (oszacowane)
    Test randomizacji sterty (PIE)            : 27 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (ET_EXEC)  : Brak randomizacji
    Randomizacja głównego pliku wykonywalnego (PIE)      : 18 bitów jakości (oszacowane)
    Test randomizacji bibliotek współdzielonych        : 16 bitów jakości (oszacowane)
    Test randomizacji VDSO                  : 16 bitów jakości (oszacowane)
    Test randomizacji stosu (SEGMEXEC)      : 24 bity jakości (oszacowane)
    Test randomizacji stosu (PAGEEXEC)      : 24 bity jakości (oszacowane)
    Test randomizacji argumentów/środowiska (SEGMEXEC)    : 28 bitów jakości (oszacowane)
    Test randomizacji argumentów/środowiska (PAGEEXEC)    : 28 bitów jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_EXEC): 18 bitów jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_DYN) : 16 bitów jakości (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @~0: 18 bitów (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @0 : 18 bitów (oszacowane)

    linux

    Test randomizacji mapowania anonimowego     : 8 bitów jakości (oszacowane)
    Test randomizacji sterty (ET_EXEC)        : 13 bitów jakości (oszacowane)
    Test randomizacji sterty (PIE)            : 13 bitów jakości (oszacowane)
    Randomizacja głównego pliku wykonywalnego (ET_EXEC)  : Brak randomizacji
    Randomizacja głównego pliku wykonywalnego (PIE)      : 8 bitów jakości (oszacowane)
    Test randomizacji bibliotek współdzielonych        : 8 bitów jakości (oszacowane)
    Test randomizacji VDSO                  : 8 bitów jakości (oszacowane)
    Test randomizacji stosu (SEGMEXEC)      : 19 bitów jakości (oszacowane)
    Test randomizacji stosu (PAGEEXEC)      : 19 bitów jakości (oszacowane)
    Test randomizacji argumentów/środowiska (SEGMEXEC)    : 11 bitów jakości (oszacowane)
    Test randomizacji argumentów/środowiska (PAGEEXEC)    : 11 bitów jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_EXEC): 8 bitów jakości (oszacowane)
    Przesunięcie randomizacji bibliotek (ET_DYN) : 13 bitów jakości (oszacowane)
    Randomizacja przy wyczerpaniu pamięci @~0: Brak randomizacji
    Randomizacja przy wyczerpaniu pamięci @0 : Brak randomizacji

### Ograniczanie dostępu do wskaźników jądra w systemie plików proc

Ustawienie `kernel.kptr_restrict` na 1 spowoduje ukrycie adresów symboli jądra w pliku `/proc/kallsyms` przed zwykłymi użytkownikami bez nieposiadającymi uprawnienia `CAP_SYSLOG`, utrudniając exploitom jądra dynamiczne rozwiązywanie adresów/symboli. Nie pomoże to zbytnio w przypadku prekompilowanego jądra Arch Linux, ponieważ zdeterminowany atakujący może po prostu pobrać pakiet jądra i ręcznie uzyskać symbole stamtąd, ale jeśli kompilujesz własne jądro, może to pomóc w ograniczeniu lokalnych exploitów root. Spowoduje to, że niektóre polecenia perf przestaną działać podczas używania ich przez użytkowników niebędących rootami (ale wiele funkcji perf i tak wymaga dostępu root). Więcej informacji można znaleźć w FS#34323.

Ustawienie `kernel.kptr_restrict` na 2 spowoduje ukrycie adresów symboli jądra w `/proc/kallsyms` niezależnie od uprawnień.

    /etc/sysctl.d/51-kptr-restrict.conf

    kernel.kptr_restrict = 1

Uwaga linux-hardened domyślnie ustawia `kptr_restrict=2` zamiast `0`.

### Wzmocnienie BPF

BPF to system służący do dynamicznego ładowania i wykonywania kodu bajtowego w jądrze podczas działania systemu. Jest on wykorzystywany w wielu podsystemach jądra Linux, takich jak sieci (np. XDP, tc), śledzenie (np. kprobes, uprobes, tracepoints) i bezpieczeństwo (np. seccomp). Jest również przydatny do zaawansowanego bezpieczeństwa sieci, profilowania wydajności i dynamicznego śledzenia.

BPF było pierwotnie skrótem od Berkeley Packet Filter, ponieważ oryginalny klasyczny BPF był używany w narzędziach do przechwytywania pakietów dla BSD. Ostatecznie przekształciło się to w Extended BPF (eBPF), które wkrótce potem zostało przemianowane na BPF (nie jest to skrót). BPF nie należy mylić z narzędziami do filtrowania pakietów, takimi jak iptables lub netfilter, chociaż BPF może być używany do implementacji narzędzi do filtrowania pakietów.

Kod BPF może być interpretowany lub kompilowany przy użyciu kompilatora Just-In-Time (JIT). Jądro Arch jest zbudowane z `CONFIG_BPF_JIT_ALWAYS_ON`, co wyłącza interpreter BPF i wymusza użycie kompilacji JIT dla wszystkich BPF. Utrudnia to atakującym wykorzystanie BPF do eskalacji ataków wykorzystujących luki typu SPECTRE. Zobacz poprawkę jądra, która wprowadziła CONFIG_BPF_JIT_ALWAYS_ON.

Jądro zawiera funkcję wzmacniającą dla kompilowanego przez JIT BPF, która może złagodzić niektóre rodzaje ataków typu JIT spraying kosztem wydajności oraz możliwości śledzenia i debugowania wielu programów BPF. Można ją włączyć, ustawiając `net.core.bpf_jit_harden` na `1` (aby włączyć wzmocnienie kodu nieuprawnionego) lub `2` (aby włączyć wzmocnienie całego kodu).

Więcej szczegółów można znaleźć w ustawieniach `net.core.bpf_*` w dokumentacji jądra.

Wskazówka

- linux-hardened domyślnie ustawia `net.core.bpf_jit_harden=2` zamiast `0`.
- Domyślnie programy BPF mogą być uruchamiane nawet przez użytkowników bez uprawnień. Aby zmienić to zachowanie, ustaw `kernel.unprivileged_bpf_disabled=1`[9].

### Zakres ptrace

Wywołanie systemowe ptrace(2) zapewnia środek, dzięki któremu jeden proces („tracer”) może obserwować i kontrolować wykonywanie innego procesu („tracee”) oraz badać i zmieniać pamięć i rejestry tracee. `ptrace` jest powszechnie używane przez narzędzia do debugowania, w tym »'gdb«', »'strace«', »'perf«', »'reptyr«' i inne debuggery. Jednakże zapewnia ono również środek, za pomocą którego złośliwy proces może odczytywać dane z innych procesów i przejmować nad nimi kontrolę.

Arch domyślnie włącza Yama LSM, który zapewnia parametr jądra `kernel.yama.ptrace_scope`. Ten parametr jest domyślnie ustawiony na `1` (ograniczony), co uniemożliwia śledzącym wykonywanie wywołania `ptrace` na śladach poza ograniczonym zakresem, chyba że śledzący ma uprawnienia lub posiada `CAP_SYS_PTRACE` możliwości. Jest to znacząca poprawa bezpieczeństwa w porównaniu z klasycznymi uprawnieniami. Bez tego modułu nie ma rozdzielenia między procesami uruchomionymi jako ten sam użytkownik (przy braku dodatkowych warstw bezpieczeństwa, takich jak pid_namespaces(7)).

Uwaga Domyślnie nadal można używać narzędzi wymagających `ptrace`, uruchamiając je jako procesy uprzywilejowane, np. za pomocą sudo.

Jeśli nie ma potrzeby korzystania z narzędzi do debugowania, warto rozważyć ustawienie `kernel.yama.ptrace_scope` na `2` (tylko dla administratorów) lub `3` (brak możliwości `ptrace`), aby wzmocnić zabezpieczenia systemu.

### hidepid

This article or section needs expansion.

Reason: Linux 5.8 wdrożył prywatne instancje i nowe wartości dla `hidepid=`. (Discuss in Talk:Security (Polski))

The factual accuracy of this article or section is disputed.

Reason: Włączenie `hidepid` globalnie nie jest obsługiwanym sposobem działania przez systemd, ani nie zapewnia żadnych praktycznych korzyści pod względem bezpieczeństwa, gdy systemd działa jako menedżer usług. [10] (Discuss in Talk:Security (Polski))
Ostrzeżenie

- Może to powodować problemy w niektórych aplikacjach, takich jak aplikacje działające w piaskownicy i Xorg (zobacz rozwiązanie).
- Powoduje to problemy z D-Bus, Polkit, PulseAudio i bluetooth podczas korzystania z systemd > 237.64-1.

Jądro ma możliwość ukrywania procesów innych użytkowników, normalnie dostępnych poprzez `/proc`, przed użytkownikami bez uprawnień poprzez zamontowanie systemu plików `proc` z opcjami `hidepid=` i `gid=` opisanymi w https://docs.kernel.org/filesystems/proc.html.

To znacznie utrudnia intruzowi zbieranie informacji o uruchomionych procesach, np. czy jakiś demon działa z podwyższonymi uprawnieniami, czy inny użytkownik uruchamia jakiś wrażliwy program, czy inni użytkownicy w ogóle uruchamiają jakieś programy, uniemożliwia sprawdzenie, czy któryś z użytkowników uruchamia konkretny program (zakładając, że program nie ujawnia się poprzez swoje zachowanie), a dodatkowo, źle napisane programy przekazujące wrażliwe informacje poprzez argumenty programu są teraz chronione przed lokalnymi podsłuchiwaczami.

`proc` Grupa, udostępniana przez pakiet filesystem, pełni funkcję białej listy użytkowników uprawnionych do uzyskiwania informacji o procesach innych użytkowników. Jeśli użytkownicy lub usługi potrzebują dostępu do katalogów `/proc/<pid>` innych niż własne, należy dodać je do grupy.

Na przykład, aby ukryć informacje o procesie przed innymi użytkownikami z wyjątkiem tych z grupy `proc`:

    /etc/fstab

    proc	/proc	proc	nosuid,nodev,noexec,hidepid=2,gid=proc	0	0

Aby sesje użytkowników działały poprawnie, należy dodać wyjątek dla systemd-logind:

    /etc/systemd/system/systemd-logind.service.d/hidepid.conf

    [Service]
    SupplementaryGroups=proc

### Ograniczanie ładowania modułów

Domyślnie jądro Arch ma włączoną opcję `CONFIG_MODULE_SIG_ALL`, która podpisuje wszystkie moduły jądra skompilowane jako część pakietu linux. Dzięki temu jądro może ładować tylko moduły podpisane prawidłowym kluczem, co oznacza, że moduły spoza drzewa kompilowane lokalnie lub dostarczane przez pakiety takie jak virtualbox-host-modules-arch[broken link: replaced by virtualbox-host-dkms] nie mogą być ładowane. Możesz użyć `modinfo`, aby sprawdzić, czy aktualnie załadowane moduły mają podpisy; ręczne sprawdzanie podpisów jest nieco bardziej skomplikowane (zobacz ten przegląd).

Ładowanie modułów jądra można ograniczyć, ustawiając parametr jądra `module.sig_enforce=1`. Więcej informacji można znaleźć w dokumentacji jądra.

Ponadto niepotrzebne moduły można umieścić na czarnej liście, przykłady można znaleźć na stronie secureblue

### Wyłącz kexec

Kexec umożliwia zastąpienie aktualnie działającego jądra.

    /etc/sysctl.d/51-kexec-restrict.conf

    kernel.kexec_load_disabled = 1

Wskazówka kexec domyślnie wyłączony jest w linux-hardened.

### Tryb blokady jądra

Od wersji Linux 5.4 jądro zyskało opcjonalną dreamwidth.org/55105.html funkcje lockdownu, mającą na celu wzmocnienie granicy między UID 0 (root) a jądrem. Po włączeniu tej funkcji niektóre aplikacje, które wymagają niskopoziomowego dostępu do sprzętu lub jądra, mogą przestać działać.

Aby użyć blokady, należy zainicjować jej LSM i ustawić tryb blokady.

Wszystkie oficjalnie obsługiwane jądra inicjują LSM, ale żadne z nich nie wymusza trybu blokady.

Wskazówka Zainicjowane moduły LSM można zweryfikować, uruchamiając `cat /sys/kernel/security/lsm`.

Blokada ma dwa tryby działania:

- `integrity`: funkcje jądra, które umożliwiają użytkownikom modyfikowanie działającego jądra, są wyłączone (np. kexec, bpf).
- `confidentiality`: funkcje jądra, które umożliwiają użytkownikom uzyskanie poufnych informacji z jądra, są również wyłączone.

Zaleca się stosowanie `integrity`, chyba że konkretny model zagrożeń wymaga inaczej.

Aby włączyć blokadę jądra w czasie wykonywania, uruchom:

    # echo mode > /sys/kernel/security/lockdown

Aby włączyć blokadę jądra podczas uruchamiania, użyj opcji parametru jądra `lockdown=mode`.

Uwaga

- Blokady jądra nie można wyłączyć w trakcie działania systemu.
- Blokada jądra wyłącza hibernacje.

Zobacz kernel_lockdown(7).

### Linux Kernel Runtime Guard (LKRG)

LKRG (lkrg-dkmsAUR) jest modułem jądra, który sprawdza integralność jądra i wykrywa próby wykorzystania luk w zabezpieczeniach.

### Wyłącz powłokę awaryjną

The factual accuracy of this article or section is disputed.

Reason: Maskowanie `emergency.target` i `emergency.service` nie będzie miało wpływu na jednostki dodawane do initramfs i uruchamiane we wczesnej przestrzeni użytkownika. Nawet jeśli znajdują się one w initramfs, hak systemd mkinitcpio blokuje konto root.[11][12] ze względów bezpieczeństwa (patrz FS#70408). Rozwiązaniem problemu opisanego w artykule, o ile jest ono w ogóle potrzebne, byłoby zapobieganie dodawaniu `rescue.target`, `rescue.service`, `emergency.target` i `emergency.service` do obrazu initramfs. (Discuss in Talk:Security (Polski))

Powłoka awaryjna służy do interaktywnego rozwiązywania problemów z komputerem podczas procesu uruchamiania. Jest to jednak również narzędzie, które osoba atakująca może wykorzystać do uzyskania dostępu do zasobów zabezpieczonych, takich jak moduł TPM. Praktyczny przykład można znaleźć w tym artykule. Trudność ataków można zwiększyć, wyłączając powłokę awaryjną, co wiąże się jednak z rezygnacją z narzędzia do rozwiązywania problemów związanych z wczesnymi awariami podczas uruchamiania.

Aby wyłączyć powłokę awaryjną, zobacz systemd#Disable emergency mode on remote machine.

## Aplikacje w Piaskownicy

Zobacz Wikipedia:pl:Piaskownica (bezpieczeństwo informatyczne).

Aby poprawić bezpieczeństwo jednostek usług systemd, zobacz systemd/Sandboxing.

Uwaga Element konfiguracyjny przestrzeni nazw użytkownika `CONFIG_USER_NS` jest obecnie włączony w linux, linux-lts, linux-zen i linux-hardened. Jego brak może uniemożliwić udostępnienie aplikacjom niektórych funkcji piaskownicy.
Ostrzeżenie Wykorzystanie przestrzeni nazw użytkownika bez uprawnień (`CONFIG_USER_NS_UNPRIVILEGED`) jest domyślnie włączone w linux, linux-lts i linux-zen, co znacznie zwiększa powierzchnię ataku dla lokalnego podwyższenia uprawnień (zobacz AppArmor's Wiki i FS#36969).

Aby złagodzić ten problem, należy:

- Użyj jądra linux-hardened, które ma bezpieczne ustawienia domyślne, lub
- Ustaw `kernel.unprivileged_userns_clone` sysctl na `0`.

Należy pamiętać, że może to spowodować nieprawidłowe działanie aplikacji takich jak nsjail. Aplikacje oparte na Chromium wymagają bitu SUID, aby `chrome-sandbox` działało z tym ustawieniem.

### Firejail

Firejail to łatwe w użyciu narzędzie do tworzenia piaskownic dla aplikacji i serwerów. Pierwotnie zostało stworzone dla przeglądarek i aplikacji internetowych, ale obecnie obsługuje wiele różnych aplikacji. Aby stworzyć środowisko piaskownicy z różnorodnymi funkcjami, jest instalowane jako plik binarny suid i tworzy środowisko uruchomieniowe piaskownicy dla docelowej aplikacji w oparciu o czarne i białe listy.

### bubblewrap

bubblewrap to aplikacja typu sandbox opracowana dla narzędzi kontenerowych bez uprawnień, takich jak Flatpak, charakteryzująca się znacznie mniejszym zużyciem zasobów i mniejszą złożonością niż Firejail. Chociaż brakuje jej niektórych funkcji, takich jak biała lista ścieżek plików, bubblewrap oferuje montowanie bindów, a także tworzenie przestrzeni nazw użytkowników/IPC/PID/sieci/cgroup i może obsługiwać zarówno proste, jak i złożone piaskownice. W przypadku jądra linux-hardened należy użyć bubblewrap-suid.

Piaskownica Bubblejail jest oparty na bubblewrap i zapewnia model uprawnień zorientowany na zasoby z graficznym interfejsem do dostosowywania uprawnień.

### Portable

Portable jest frameworkiem typu sandbox, który wykorzystuje bubblewrap i wiele innych narzędzi do blokowania uruchomionych aplikacji. Został zaprojektowany tak, aby był prosty dla pakujących i wydajny dla użytkowników, a jednocześnie domyślnie eliminuje luki w zabezpieczeniach i monitoruje procesy działające w tle.

Zobacz portable-arch, aby zapoznać się z repozytorium aplikacji izolowanych przez portable.

Jeśli aplikacja w piaskownicy nie korzysta z selektora plików portalu, portable może przekazać pliki do piaskownicy (przekazując `--actions share-files`).

Portable działa w pełni na GNOME, podczas gdy inne środowiska graficzne mogą nie posiadać niektórych funkcji, takich jak zaawansowane monitorowanie w tle i portal ScreenShot.

### chroots

Ręczne środowiska chroot mogą być również tworzone w celu budowania środowisk procesów typu sandbox. Są one znacznie bardziej ograniczone niż inne technologie sandboxingu; zakres ich działania ogranicza się do izolacji ścieżek plików.

### Kontenery Linux

Kontenery Linux są kolejną dobrą opcją, gdy potrzebujesz większej separacji niż zapewniają inne opcje (z wyjątkiem pełnej wirtualizacji systemu[broken link: invalid section]). LXC działa na istniejącym jądrze w pseudo-chroot z własnym sprzętem wirtualnym.

### Pełne opcje wirtualizacji

Korzystanie z opcji pełnej wirtualizacji, takich jak VirtualBox, KVM, Xen lub Qubes OS (oparte na Xen), może również poprawić izolację i bezpieczeństwo w przypadku planowania uruchamiania ryzykownych aplikacji lub przeglądania niebezpiecznych stron internetowych.

## Sieć i zapory sieciowe

### Zapory sieciowe

Chociaż standardowe jądro Arch jest w stanie korzystać z Netfilter's iptables i nftables, usługi te nie są domyślnie włączone. Zaleca się skonfigurowanie jakiejś formy zapory sieciowej w celu ochrony usług działających w systemie. Wiele zasobów (w tym ArchWiki) nie określa wyraźnie, które usługi warto chronić, więc włączenie zapory sieciowej jest dobrym środkiem ostrożności.

- Ogólne informacje można znaleźć w sekcjach iptables i nftables.
- Instrukcje dotyczące konfiguracji zapory iptables można znaleźć w sekcji Simple stateful firewall
- Inne sposoby konfiguracji netfilter można znaleźć w sekcji Category:Firewalls.
- Informacje na temat list blokujących adresy IP, takich jak te z Bluetack, można znaleźć w sekcji Ipset.
- opensnitch to konfigurowalna zapora sieciowa dla ruchu przychodzącego i wychodzącego, obsługująca konfigurowalne reguły według aplikacji, portu, hosta itp.

#### Otwarte port

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: „Otwarte porty” nie jest dobrym tytułem, ponieważ pomija interfejsy i adresy, z którymi aplikacja może być powiązana. Z punktu widzenia zapór sieciowych porty mogą być „otwarte”, nawet jeśli żadna aplikacja nie nasłuchuje na nich w danym momencie. (Discuss in Talk:Security (Polski))

Niektóre usługi nasłuchują ruchu przychodzącego na otwartych portach sieciowych. Ważne jest, aby usługi te były powiązane wyłącznie z adresami i interfejsami, które są absolutnie niezbędne. Zdalny atakujący może wykorzystać wadliwe protokoły sieciowe, aby uzyskać dostęp do odsłoniętych usług. Może się to zdarzyć nawet w przypadku procesów powiązanych z lokalnym hostem.

Ogólnie rzecz biorąc, jeśli usługa musi być dostępna tylko dla systemu lokalnego, należy ją powiązać z gniazdem domeny Unix (unix(7)) lub adresem pętli zwrotnej, takim jak `localhost`, zamiast z adresem niebędącym adresem pętli zwrotnej, takim jak `0.0.0.0/0`.

Jeśli usługa musi być dostępna dla innych systemów za pośrednictwem sieci, należy kontrolować dostęp za pomocą ścisłych reguł firewall i skonfigurować uwierzytelnianie, autoryzację i szyfrowanie, gdy tylko jest to możliwe.

Możesz wyświetlić listę wszystkich aktualnie otwartych portów za pomocą polecenia `ss -l`. Aby wyświetlić wszystkie procesy nasłuchujące oraz ich numeryczne numery portów tcp i udp:

    # ss -lpntu

Zobacz ss(8) dla większej ilości opcji.

### Parametry jądra

Parametry jądra, które mają wpływ na działanie sieci, można ustawić za pomocą Sysctl. Aby dowiedzieć się, jak to zrobić, zobacz Sysctl#TCP/IP stack hardening.

### SSH

Aby ograniczyć skutki ataków brute-force, zaleca się stosowanie uwierzytelniania opartego na kluczach. W przypadku OpenSSH więcej zaleceń można znaleźć w sekcji OpenSSH#Protection. Alternatywnie, Fail2ban lub Sshguard oferują mniejszą ochronę poprzez monitorowanie logów i dynamiczne dodawanie reguł do firewall, ale narażają na potencjalny atak typu denial of service, ponieważ atakujący może spoofować pakiety tak, jakby pochodziły od administratora po zidentyfikowaniu jego adresu. Spoofing IP ma linie obrony, takie jak filtrowanie ścieżki zwrotnej i wyłączenie przekierowań ICMP.

Możesz chcieć jeszcze bardziej utwardzić uwierzytelnianie używając uwierzytelniania dwuskładnikowego. Autoryzator Google zapewnia dwuetapową procedurę uwierzytelniania przy użyciu jednokrotnego hasła (OTP).

Zablokowanie logowania roota jest również dobrą praktyką, zarówno do śledzenia włamań i dodaje dodatkową warstwę bezpieczeństwa przed dostępem roota. Dla OpenSSH, zobacz OpenSSH#Deny.

Mozilla publikuje poradnik konfiguracji OpenSSH, który obejmuje bardziej szczegółowe logowanie audytu (w trybie verbose) oraz ograniczenie algorytmów szyfrowania do bezpiecznych opcji.

### DNS

Domyślna konfiguracja rozdzielczości nazw domen (DNS) jest wysoce kompatybilna, ale ma słabe zabezpieczenia. Więcej informacji można znaleźć w prywatny i bezpieczny DNS.

### Proxies

Proxy są powszechnie wykorzystywane jako dodatkowa warstwa pomiędzy aplikacjami a siecią, filtrując dane z niezaufanych źródeł. Powierzchnia ataku małego proxy z niższymi uprawnieniami jest znacznie mniejsza niż złożona aplikacja z uprawnieniami użytkownika końcowego.

Na przykład resolver DNS jest implementowany w glibc, który jest połączony z aplikacją (mogącą działać jako root), więc błąd w resolver DNS może prowadzić do zdalnego wykonania kodu. Można temu zapobiec poprzez zainstalowanie serwera buforowego DNS, takiego jak dnsmasq, który działa jako pośrednik. [13]

### Zarządzanie certyfikatami TLS

Zobacz TLS#Trust management.

## Fizyczna ochrona

Fizyczny dostęp do komputera to dostęp root z wystarczającą ilością czasu i zasobów. Jednak wysoki praktyczny poziom bezpieczeństwa można osiągnąć poprzez wprowadzenie wystarczających barier.

Atakujący może uzyskać pełną kontrolę nad twoim komputerem w następnym uruchomieniu, po prostu dołączając złośliwy IEEE 1394 (FireWire), Thunderbolt lub PCI Urządzenie ekspresowe, ponieważ domyślnie daje im pełny dostęp do pamięci. [14] Dla Thunderbolt, można ograniczyć bezpośredni dostęp pamięci całkowicie lub do znanych urządzeń, zobacz Thunderbolt#User device authorization. Dla FireWire i PCI Express niewiele można zrobić bez modyfikacji sprzętu, aby temu zapobiec. Jednak zdecydowana większość atakujących nie będzie dysponowała taką wiedzą ani determinacją.

#Szyfrowanie danych w spoczynku uniemożliwi dostęp do twoich danych, jeśli komputer zostanie skradziony, ale złośliwy firmware może być zainstalowane w celu uzyskania tych danych przy następnym logowaniu przez zaradnego atakującym.

### Utwardzenie BIOS'u

Dodanie hasła do BIOS uniemożliwia komuś uruchomienie komputera z pendrive, co w zasadzie jest takie, jak posiadanie dostępu do komputera. Należy upewnić się, że Twój dysk jest pierwszy w kolejności startowej i wyłączyć inne dyski z bootable, jeśli można.

### Boot loaders

Bardzo ważne jest, aby chronić boot loader. Niezabezpieczony boot loader może obejść wszelkie ograniczenia logowania, np. poprzez ustawienie opcji `init=/bin/sh` parametr jądra, aby uruchomić bezpośrednio do powłoki.

#### Syslinux

Syslinux wspiera ustawienie hasła na boot loader. Pozwala ustawić albo hasło pozycji per- menu- lub globalne hasło loadera.

#### GRUB

GRUB również obsługuje hasła dla programu rozruchowego (boot loadera). Szczegóły znajdziesz w Ochrona hasłem GRUB menu. Posiada także obsługę zaszyfrowanego /boot, co pozostawia niezaszyfrowane jedynie niektóre części kodu programu rozruchowego. Konfiguracja GRUB-a, kernel i initramfs są zaszyfrowane.

#### systemd-boot

systemd-boot wyłącza edycję parametrów jądra (kernela), gdy włączona jest funkcja #Secure Boot. Alternatywnie, zobacz systemd-boot#Kernel parameters editor with password protection dla bardziej tradycyjnej opcji opartej na haśle.

### Secure Boot

Secure Boot (Bezpieczny Rozruch) to funkcja UEFI, która umożliwia uwierzytelnienie plików, z których uruchamia się komputer. Pomaga to zapobiegać niektórym atakom "złej pokojówki", takim jak podmiana plików wewnątrz partycji rozruchowej. Zazwyczaj komputery są dostarczane z kluczami, które są zarejestrowane przez dostawców (OEM). Można je jednak usunąć, co pozwala komputerowi wejść w tryb konfiguracji (Setup Mode), umożliwiający użytkownikowi rejestrowanie i zarządzanie własnymi kluczami.

Strona Secure Boot przeprowadzi Cię przez proces konfiguracji bezpiecznego rozruchu poprzez użycie własnych kluczy.

### Trusted Platform Module (TPM)

Moduły TPM to sprzętowe mikroprocesory, które mają wbudowane klucze kryptograficzne. Stanowi to fundamentalne źródło zaufania dla większości nowoczesnych komputerów i umożliwia kompleksową weryfikację łańcucha rozruchowego. Mogą być używane jako wewnętrzne karty inteligentne, poświadczać oprogramowanie układowe (firmware) działające na komputerze oraz umożliwiać użytkownikom przechowywanie poufnych danych w odpornym na manipulacje i ataki siłowe magazynie.

### Partycja rozruchowa na wymiennym dysku flash

Jednym z popularnych pomysłów jest umieszczenie partycji rozruchowej na dysku flash, aby uniemożliwić uruchomienie systemu bez niego. Zwolennicy tego pomysłu często używają jednocześnie pełnego szyfrowania dysku[broken link: invalid section], a niektórzy również stosują odłączane nagłówki szyfrujące umieszczone na partycji rozruchowej.

Tę metodę można również połączyć z szyfrowaniem /boot.

### Automatyczne wylogowywanie

Jeśli używasz Bash lub Zsh, możesz ustawić `TMOUT`, by automatycznie wylogowywał się z powłoki po ustalonym czasie.

Na przykład, poniższy kod spowoduje automatyczne wylogowanie z wirtualnych konsol (ale nie z emulatorów terminala w X11):

    /etc/profile.d/shell-timeout.sh

    TMOUT="$(( 60*10 ))";
    [ -z "$DISPLAY" ] && export TMOUT;
    case $( /usr/bin/tty ) in
    	/dev/tty[0-9]*) export TMOUT;;
    esac

Jeśli naprawdę chcesz, aby KAŻDY prompt Bash/Zsh (nawet wewnątrz X) miał limit czasu (timeout), użyj:

    $ export TMOUT="$(( 60*10 ))";

Zauważ, że nie zadziała to, jeśli w powłoce (shellu) działa jakieś polecenie (np. sesja SSH lub inna powłoka bez obsługi `TMOUT`). Ale jeśli używasz VC (konsoli wirtualnej) głównie do restartowania zamrożonego GDM/Xorg jako root, to jest to bardzo przydatne.

### Ochrona przed niebezpiecznymi urządzeniami USB

Jądro systemu (kernel) posiada ustawienia, które dezaktywują porty USB, aby chronić Twój komputer przed niebezpiecznymi urządzeniami USB (znanymi również jako BadUSB, PoisonTap lub LanTurtle). Można je ustawiać w czasie działania systemu i automatyzować za pomocą sysctl.

Aby uzyskać większą kontrolę, zainstaluj USBGuard, który jest frameworkiem programowym implementującym podstawowe możliwości białych (whitelisting) i czarnych list (blacklisting) w oparciu o atrybuty urządzenia.

### Gromadzenie danych ulotnych (Volatile data collection)

Włączony komputer może być podatny na gromadzenie danych ulotnych. Dobrą praktyką jest całkowite wyłączanie komputera, gdy nie potrzebne jego działanie, lub gdy jego fizyczne bezpieczeństwo jest tymczasowo naruszone (np. podczas przechodzenia przez punkt kontroli).

## Pakiety

### Bezpieczeństwo AUR

AUR (Arch User Repository) zawiera pakiety tworzone i utrzymywane przez społeczność, nie są one weryfikowane przez deweloperów Arch Linux. Instalacja z AUR odbywa się na własne ryzyko.

Ostrzeżenie W 2025 roku odnotowano przypadki złośliwych PKGBUILD-ów w AUR (np. CHAOS RAT, podawane jako patch do przeglądarki). Zawsze sprawdzaj kod przed instalacją.

#### Zalecane praktyki

- Sprawdź PKGBUILD i pliki .install, szukaj podejrzanych poleceń: `rm -rf`, `curl ... | sh`, `wget ... -O- | sh`.
- Zweryfikuj sumy kontrolne (`sha256sums`, `b2sums`) i adresy URL, muszą prowadzić do oficjalnych źródeł upstream.
- Mile widziane, jest zgłaszanie złośliwych pakietów, warto zostawić komentarz pod takim pakietem, gdyż mogą uchronić mniej doświadczonych użytkowników przed instalacją złośliwego pakietu.

#### Pomocnicy AUR

Narzędzia takie jak yayAUR, czy paruAUR ułatwiają instalację takich pakietów, ale nie są oficjalnie wspierane, mogą mieć luki, lub pomijać wyświetlenie skryptu instalacyjnego.

Zobacz: Pomocnicy AUR

### Uwierzytelnienie

Ataki na menedżerów pakietów są możliwe bez właściwego stosowania podpisywania pakietów i mogą mieć wpływ nawet na menedżerów pakietów z sprawnymi systemami podpisu. Arch używa domyślnie podpisywania pakietów i opiera się na sieci zaufania z 5 zaufanych kluczy głównych. Szczegółowe informacje znajdują się w Pacman-key.

### Aktualizacje

Niezbędnym jest regularne aktualizowanie systemu.

### Obserwuj aktualne podatności

Subskrybowanie aktualizacji "Common Vulnerabilities and Exposure" (CVE) Security Alert, udostępnianych przez National Vulnerability Database i dostępnych na stronie pobierania NVD. Arch Linux Security Tracker służy jako szczególnie użyteczne źródło, ponieważ łączy zestawy danych Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) i CVE w formacie tabelarycznym. Narzędzie arch-audit może być używane do sprawdzania luk w zabezpieczeniach dotykających uruchomiony system. Można również użyć graficznej ikony na pasku systemowym, arch-audit-gtk. Zobacz także Arch Security Team.

Powinieneś również rozważyć subskrybowanie powiadomień o nowych wydaniach dla używanego oprogramowania, zwłaszcza jeśli instalujesz oprogramowanie za pomocą innych środków niż główne repozytoria lub AUR. Niektóre programy mają listy mailingowe, które możesz subskrybować, aby otrzymywać powiadomienia dotyczące bezpieczeństwa. Witryny hostujące kod źródłowy często oferują kanały RSS dla nowych wydań.

### Przebudowa pakietów

Pakiety można ponownie budować, usuwając z nich niepożądane funkcje i cechy, co jest sposobem na zmniejszenie powierzchni ataku. Na przykład, pakiet bzip2 można przebudować bez `bzip2recover`, próbując obejść lukę CVE-2016-3189. Niestandardowe flagi utwardzające (hardening flags) można również zastosować ręcznie lub za pomocą specjalnego wrappera.

This article or section is a candidate for merging with Arch package guidelines/Security.

Notes: Flagi kompilatora związane z bezpieczeństwem mają swój własny artykuł. (Discuss in Talk:Security (Polski))

The factual accuracy of this article or section is disputed.

Reason: kopiowano i wklejono z bloga sprzed 3 lat. Flagi kompilatora są specyficzne dla GCC, a niektóre z nich są ledwo związane z bezpieczeństwem. (Discuss in Talk:Security (Polski))

### Ponowne budowanie pakietów (Rebuilding packages)

Flag | Purpose
--- | ---
-D_FORTIFY_SOURCE=2 | Wykrywanie przepełnienia bufora w czasie działania programu (run-time)
-D_GLIBCXX_ASSERTIONS | Sprawdzanie granic w czasie działania (run-time bounds checking) dla ciągów i kontenerów C++
-fasynchronous-unwind-tables | Zwiększona niezawodność śladów stosu (backtraces)
-fexceptions | Włącza anulowanie wątku w oparciu o tabele (table-based thread cancellation)
-fpie -Wl,-pie | Pełne ASLR dla plików wykonywalnych
-fpic -shared | Brak relokacji tekstu dla bibliotek współdzielonych
-fplugin=annobin | Generowanie danych dla kontroli jakości utwardzania (hardening quality control)
-fstack-clash-protection | Zwiększona niezawodność wykrywania przepełnienia stosu (stack overflow detection)
-fstack-protector, -fstack-protector-all or -fstack-protector-strong | Ochrona przed rozbiciem stosu (Stack smashing protector)
-grecord-gcc-switches | Przechowywanie flag kompilatora w informacjach debugowania
-mcet -fcf-protection | Ochrona integralności przepływu sterowania (Control flow integrity protection)
-Werror=format-security | Odrzucanie potencjalnie niebezpiecznych argumentów formatujących ciągi (format string arguments)
-Werror=implicit-function-declaration | Odrzucanie brakujących prototypów funkcji
-Wl,-z,defs | Wykrywanie i odrzucanie niepełnego łączenia (underlinking)
-Wl,-z,now | Wyłączanie leniwego wiązania (lazy binding)
-Wl,-z,relro | Segmenty tylko do odczytu po relokacji (Read-only segments after relocation)

- Flags and info source

## Zobacz też

- Arch Linux Security Tracker
- CentOS Wiki: OS Protection
- Hardening the Linux desktop
- Hardening the Linux server
- Linux Foundation: Linux workstation security checklist
- privacyguides.org Privacy Resources
- Red Hat Enterprise Linux 7 Security Guide
- Securing Debian Manual
- The paranoid #! Security Guide

Categories:

- Security (Polski)
- File systems (Polski)
- Networking (Polski)

Hidden categories:

- Pages or sections flagged with Template:Accuracy
- Pages with broken package links
- Pages or sections flagged with Template:Merge
- Pages or sections flagged with Template:Expansion
- Pages with broken section links
- Pages or sections flagged with Template:Style

Security (Polski)
Add topic