Arch package guidelines (Magyar)/Security (Magyar) - ArchWiki

Jump to content

# Arch package guidelines (Magyar)/Security (Magyar)

From ArchWiki
< Arch package guidelines (Magyar)
Fordítás állapota: Ez az oldal az angol Arch package guidelines/Security című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.05.28. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb módosítások, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.

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

Tipp A namcap szintén megmutat néhány biztonsági problémát, amelyek le vannak írva ezen az oldalon.

## 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

This article or section is a candidate for moving to systemd/Sandboxing.

Notes: Ugyanazt a témát fedi le, mint a systemd#Sandboxing application environments. Mindkettő egyesíthető és áthelyezhető egy különálló oldalra. Tekintse meg a User:NetSysFire/systemd sandboxing oldalt egy javasolt tervezetért. (Discuss in Talk:Security#systemd unit hardening and system.conf tweaks)

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

Categories:

- Arch package guidelines (Magyar)
- Security (Magyar)

Hidden category:

- Pages or sections flagged with Template:Move

Arch package guidelines (Magyar)/Security (Magyar)
Add topic