Arch package guidelines (Magyar)/Security (Magyar)
Ez az oldal a biztonság szemszögéből ismerteti az Arch Linux szoftvercsomagok létrehozásának irányelveit. C/C++ projektek esetén a kódfordító és a linker alkalmazhatnak biztonsági megerősítési opciókat. Az Arch Linux alapból alkalmazza a PIE opciót, a FORTIFY_SOURCE kódfordítási időben beállítható makrót, a veremvédelmet (stack protector), az NX (nem futtatható) bitet, és a RELRO írásvédelmet. (A "Position-Independent Executable" olyan futtatható bináris, amely nem fix memóriacímen indul, hanem bárhol betölthető a memóriában. Ez az Address Space Layout Randomization (ASLR) technikával együtt megnehezíti a támadók dolgát, mert nem tudják előre kiszámítani a kód vagy adatok pontos helyét a memóriában. A "RELRO" (Relocation Read-Only) egy bináris biztonsági védelem, amely a Global Offset Table (GOT) írásvédetté tételével akadályozza meg, hogy a támadók átírják a dinamikusan linkelt függvények címeit. Ez főleg Linux rendszereken használatos exploit enyhítési technika, angolul exploit-mitigation.)
Használat
A megerősített védelmek (hardening protections) ellenőrizhetők a checksec futtatásával.
$ checksec --file=/usr/bin/cat
RELRO
A RELRO egy általános exploit enyhítési technika, amely egy ELF bináris/program adat szekcióinak a megerősítésére szolgál. Egy program memóriába történő betöltésekor több ELF memória-szekcióba is írnia kell a linkernek, de ezek csak olvashatóvá tehetők, mielőtt a vezérlés átadásra kerülne a program számára. Ez megakadályozza, hogy a támadók felülírjanak bizonyos ELF szekciókat. Kettő különböző RELRO mód létezik:
- Részleges RELRO (
-Wl,-z,relro): Bizonyos szekciók csak olvashatóként kerülnek megjelölésre a program memóriába történő betöltése után, kivéve a GOT táblázatot (.got.plt), amely továbbra is írható marad. - Teljes RELRO (
-Wl,-z,now): A program betöltése során minden dinamikus szimbólum feloldásra kerül, lehetővé téve a teljes GOT táblázat csak olvashatóként történő megjelölését.
Ha egy alkalmazás részleges RELRO védelmet jelez, akkor vizsgálja meg, hogy a szoftverlétrehozási eszközlánc (build toolchain) átadja-e az LDFLAGS értékét, vagy lehetővé teszi-e az LDFLAGS felülbírálását. Go szoftvercsomagok esetén vizsgálja meg, hogy a szoftverlétrehozási metódus használ-e build.go-t tisztán golang alapú Makefile-helyettesítőként, amely nem teszi lehetővé az LDFLAGS átadását.
Haskell
Jelenleg nem egyértelmű, hogy miként lehet elérni a Full RELRO védelmet Haskell programozási nyelv esetén.
Go
Tekintse meg a Go szoftvercsomagolási irányelvek#Jelölőzászlók és szoftvercsomaglétrehozási opciók című leírást.
Stack canary
A kódfordító a veremkanári (stack canary) védelmet a vermen belül a puffer és a vezérlési adatok közé helyezi el. Ha ez az előre beállított (és éppen emiatt pontosan ismert) érték megsérül (megváltozik az értéke), akkor a veremben puffer túlcsordulás történt, és a futó program szegmentációs hibával leáll annak érdekében, hogy megakadályozza a lehetséges tetszőleges kódnak a lefutását. (A tetszőleges kód általában a hacker kártékony kódja, ami tartalmazza a neki hasznos payload programkódot is, vagy a memóriacímet tartalmazza ahol a payload megtalálható a számítógép memóriájában. Keressen rá a metasploit kifejezésre.)
A gcc kódfordító segédprogramban a veremvédelem alapértelmezett állapot szerint engedélyezve van a --enable-default-ssp kódfordítási opcióval.
NX
C/C++
A végrehajthatóterület-védelem a memóriarégiókat nem végrehajthatónak jelöli meg a számítógép memóriájában, így az ezekben a régiókban található gépi kód végrehajtására tett kísérlet kivételt fog okozni (megfog szakadni a kód lefutása). Olyan hardveres funkciókat használ, mint az NX bit (no-execute bit), vagy egyes esetekben ezen funkciók szoftveres emulációját.
PIE
C/C++
A gcc szoftvercsomag alapértelmezetten engedélyezi a PIE védelmet C/C++ esetén a --enable-default-pie jelölőzászló használatával.
Golang
Adja át a következő jelölőzászlót a go build számára:
export GOFLAGS='-buildmode=pie' export CGO_CPPFLAGS="-D_FORTIFY_SOURCE=3" export CGO_LDFLAGS="-Wl,-z,relro,-z,now"
Haskell
Adja át a következő jelölőzászlót a runhaskell Setup.hs configure számára:
--ghc-option='-pie'
RPATH/RUNPATH
A RUNPATH/RPATH további keresési útvonalakat biztosít ahhoz az objektumhoz, amelyben fel van sorolva (végrehajtható objektumok esetében is, és megosztott objektumok esetében is használható).
$ objdump -x /usr/bin/perl | grep -E 'RPATH|RUNPATH'
Ha az RPATH értéke egy támadó ellenőrzése alatt álló útvonalat tartalmaz, akkor a támadó esetleg kódot hajthat végre úgy, hogy rosszindulatú könyvtárat telepít abba a könyvtárba, például CVE-2006-1566 vagy CVE-2005-4280 esetén. Részletekért tekintse meg a Debian:RpathIssue című leírást.
Az RPATH bejegyzést a linker állítja be például a következő karakterlánc LDFLAGS változónak történő átadásával: -Wl,-rpath -Wl,/usr/local/lib. RUNPATH bejegyzés létrehozásához fűzze hozzá a --enable-new-dtags kapcsolót a linker kapcsolóihoz.
D_FORTIFY_SOURCE
A D_FORTIFY_SOURCE egy makró, amely puffertúlcsordulás elleni védelmet ad különféle, memórián és karakterláncokon műveleteket végző függvényekhez. Ellenőrzi, hogy egy támadó megpróbál-e több byte mennyiségű adatot másolni egy puffer túlcsordításának az érdekében, majd ha észrevette a támadást, akkor leállítja a program végrehajtását. Ez a védelem az alapértelmezett CPPFLAGS használatával van engedélyezve:
makepkg.conf
CPPFLAGS="-D_FORTIFY_SOURCE=3"
Tekintse meg a makepkg#Beállítás című leírást.
systemd services
Ha egy systemd szolgáltatásfájl a szoftvercsomag részeként kerül szállításra, mivel a felsőbb réteg (upstream) nem biztosít ilyet, akkor vizsgálja meg a következő systemd szolgáltatáserősítési funkciók alkalmazását. A systemd lehetőséget biztosít annak elemzésére, hogy egy szolgáltatás esetében mely biztonsági funkciók vannak engedélyezve.
$ systemd-analyze security reflector.service
Fájlelérés
Egy szolgáltatásfájl megerősíthető a fájlrendszer-hozzáférés korlátozása által.
Új fájlrendszernévteret állít be a végrehajtott folyamat számára, és privát /tmp és /var/tmp könyvtárakat csatol azon belül, amelyeket a névtéren kívüli folyamatok nem osztanak meg. Hasznos olyan programok esetén, amelyek adatokat írnak a /tmp könyvtárba.
PrivateTmp=true
A ProtectSystem három különböző módot biztosít könyvtárak csak olvashatóként történő felcsatolására a végrehajtott folyamat számára. A "full" opció a /usr, /boot és /etc könyvtárakat csak olvashatóként csatolja fel. A ProtectHome elérhetetlenné teszi a /home, /root és /run/user könyvtárakat a végrehajtott folyamat számára.
ProtectSystem=strict ProtectHome=true
Új /dev névteret állít be a végrehajtott folyamat számára, és csak API pszeudoeszközöket ad hozzá, mint például a /dev/null, /dev/zero vagy /dev/random, de nem ad hozzá fizikai eszközöket, rendszermemóriát, rendszerportokat és egyebeket. Ez hasznos a végrehajtott folyamat védelmére attól, hogy közvetlenül fizikai eszközökre írjon, a systemd emellett rendszerhívásszűrőt is hozzáad a @raw-io készleten belüli hívásokhoz.
PrivateDevices=true
Ezek az opciók megakadályozzák az, hogy a végrehajtott folyamat módosítsa a /proc/sys, /sys stb. útvonalakon keresztül elérhető kernelváltozókat. A ProtectControlGroups csak olvashatóvá teszi a /sys/fs/cgroup hierarchiát.
ProtectKernelTunables=true ProtectControlGroups=true
A fájlútvonalak elérhetetlenné tétele a következőképpen végezhető el:
InaccessiblePaths=/etc
Részletesebb információk a systemd.exec(5) man súgóban találhatók.
Felhasználó
Biztosítja azt, hogy a végrehajtott folyamat és annak gyermekfolyamatai soha ne szerezhessenek új jogosultságokat az execve(2) segítségével.
NoNewPrivileges=true
Memória
Megtiltja azokat a memórialeképezések létrehozására irányuló kísérleteket, amelyek egyszerre írhatók és végrehajthatók, a leképezések végrehajthatóvá tételét vagy végrehajtható megosztott memória létrehozását. Ez elszigeteli a folyamatot attól, hogy egy támadó olyan memóriába írhasson, amely végrehajtásra is kerül. Vegye figyelembe, hogy ennek engedélyezése nem minden olyan alkalmazással kompatibilis, amely a futásidejű kódfordítás használatára támaszkodik.
MemoryDenyWriteExecute=true
Rendszerhívások
Lezárja a personality(2) rendszerhívást annak érdekében, hogy a kernel végrehajtási tartománya ne legyen megváltoztatható.
LockPersonality=true
A rendszerhívások egy szolgáltatásban is korlátozhatók. A systemd képes megjeleníteni a szűrhető rendszerhívásokat:
$ systemd-analyze syscall-filter
Előre definiált csoportok is elérhetők, például a rendszer szolgáltatásokhoz ajánlott kiindulási alapként használt rendszerhívás-fehérlista alkalmazásához használja a következőt:
SystemCallFilter=@system-service
A rendszerhívások architektúra szerint is korlátozhatók, például annak megakadályozására, hogy 32 bites bináris programok fussanak 64 bites gépeken (nincsenek nem natív bináris programok):
SystemCallArchitectures=native
Hálózat
Ha a futó folyamatnak nincs szüksége hálózati hozzáférésre, akkor az teljesen letiltható egy új hálózati névtér (network namespace) létrehozásával a folyamat számára, és kizárólag egy loopback interfész beállításával.
PrivateNetwork=true
Ha szükséges a hálózat, akkor a használt címosztályok (address families) típusa korlátozható a socket(2) rendszerhívás esetében, például úgy, hogy kizárólag UNIX socketek legyenek engedélyezve.
RestrictAddressFamilies=AF_UNIX
Abban az esetben, amikor csak a localhost-hoz vagy meghatározott IP-tartományokhoz szükséges a hálózati hozzáférés, akkor egy folyamat korlátozható úgy, hogy kizárólag a localhost-hoz engedélyezett a hálózati hozzáférés.
IPAddressAllow=localhost IPAddressDeny=any
További információ a hálózati szűréssel kapcsolatban a systemd.resource-control(5) man súgóban található.
Egyéb
Létrehoz egy új UTS névteret a végrehajtott folyamathoz, és megtiltja a gépnév vagy a doménnév módosítását.
ProtectHostname=true