it-swarm-eu.dev

přístupnost proměnné prostředí v Linuxu

Možná je to triviální otázka, ale jak dostupné jsou proměnné prostředí v Linuxu mezi různými uživateli?

např. pokud Alice popraví

export FAVORITE_FOOD=`cat /home/alice/fav_food.txt`

Může Eva říct, jaké je Alice oblíbené jídlo? (Za předpokladu, že Alice a Eva jsou normální uživatelé, a Eva nemá přístup ke čtení pro uživatele /home/alice/fav_food.txt)

43
Yoav Aner

Sledujme tok důvěrných dat. V této analýze se rozumí, že cokoli může Alice udělat, root může také dělat. Přístup k datům by mohl mít také externí pozorovatel „o úroveň výš“ (např. S ​​fyzickým přístupem k snoop na diskové sběrnici nebo v hypervizoru, pokud je kód spuštěn ve virtuálním stroji).

Nejprve jsou data načtena ze souboru. Za předpokladu, že pouze Alice má oprávnění ke čtení souboru a soubor není jinak uniknut, pouze Alice může volat cat /home/alice/fav_food.txt úspěšně. Data jsou pak v paměti procesu cat, kde k němu má přístup pouze tento proces. Data jsou přenášena potrubím z příkazu cat do volajícího prostředí; pouze dva zúčastněné procesy mohou vidět data na potrubí. Data jsou pak v paměti procesu Shell, opět soukromá pro tento proces.

V určitém okamžiku data skončí v prostředí Shell. V závislosti na prostředí se to může stát, když je proveden příkaz export, nebo pouze když prostředí provádí externí program. V tomto okamžiku budou data argumentem systémového volání execve . Po tomto volání budou data v prostředí podřízeného procesu.

Prostředí procesu je stejně soukromé jako zbytek paměti tohoto procesu (z mm->env_startmm->env_end na mapě paměti procesu). Je to sousedící s hromadou výchozích vláken . Existuje však zvláštní mechanismus, který umožňuje jiným procesům prohlížet kopii prostředí: soubor environ v /proc adresář (/proc/$pid/environ). Tento soubor je čitelný pouze jeho vlastníkem , kdo je živatel, který proces spouští (u privilegovaného procesu je to efektivní UID). (Všimněte si, že argumenty příkazového řádku v /proc/$pid/cmdline, na druhé straně, jsou čitelné pro všechny.) Můžete auditovat zdroj jádra a ověřit, že je to jediný způsob, jak uniknout prostředí procesu.

Existuje další potenciální zdroj úniku prostředí: během volání execve . Systémové volání execve přímo nevnikne do prostředí. Existuje však obecný mechanismus audit , který dokáže protokolovat argumenty každého systémového volání, včetně execve. Pokud je tedy auditování povoleno, lze prostředí poslat přes mechanismus audit a skončit v souboru protokolu. V slušně nakonfigurovaném systému má přístup k souboru protokolu pouze administrátor (v mé výchozí instalaci Debianu je to /var/log/audit/audit.log, čitelné pouze rootem a zapisováno démonem auditd spuštěným jako root).

Lhal jsem výše: napsal jsem, že paměť procesu nelze přečíst jiným procesem. Ve skutečnosti to není pravda: Linux stejně jako všechny unices implementuje systémové volání ptrace . Toto systémové volání umožňuje procesu zkontrolovat paměť a dokonce provést kód v kontextu jiného procesu. To umožňuje debuggerům existovat. Alici dokáže sledovat pouze Alice. Pokud je proces privilegován (setuid nebo setgid), může jej sledovat pouze root.

Závěr: prostředí procesu je k dispozici pouze uživateli (euid), který proces spouští .

Pamatujte, že předpokládám, že neexistuje žádný jiný proces, který by mohl data vytéct. Na normální instalaci systému Linux neexistuje žádný kořenový program setuid, který by mohl vystavit prostředí procesu. (U některých starších odvětví byl ps kořenový program setuid, který analyzoval nějakou paměť jádra; některé varianty by šťastně zobrazovaly prostředí procesu všem a všem. V Linuxu je ps bez oprávnění a získává jeho data z /proc jako každý jiný.).

(Všimněte si, že to platí pro rozumně aktuální verze Linuxu. Před velmi dlouhou dobou si myslím, že v 1.x jaderných dnech bylo prostředí čitelné na celém světě.)

Zpočátku jsem chtěl říct „ne“. Hodnoty proměnných prostředí jsou na uživatele a žádný jiný uživatel nemůže číst nebo zapisovat do env jiného uživatele. vars. Existuje však zajímavý přehled o SO), který naznačuje, že root je schopen tyto informace alespoň přečíst pomocí /proc/<pid>/environ. Až dosud jsem si nebyl vědom tohoto rozhraní pro Linux.

https://stackoverflow.com/a/532284/643314

Díky tomu se zdá, že toto rozhraní je pro ostatní uživatele stále nečitelné, i když jsou ve stejných skupinách. Oprávnění jsou nastavena na 400 pro soubor environment a/proc zabraňuje chmod, aby jej ovlivnil. Mám podezření, že doména zabezpečení pro separaci proměnných prostředí mezi uživateli je stále neporušená a nelze ji obejít běžnými prostředky.

4
logicalscope

Navzdory Gillesově teoreticky správné odpovědi: do proměnných prostředí bych nedal tajemství.

  • Proměnné prostředí jsou obvykle definovány v horní části stromu procesu (např. Prostřednictvím $HOME/.profile).
  • Uživatelé nepovažují obsah prostředí za tajemství.

Stačí, když jediný proces zaznamená proměnné prostředí do světově čitelného souboru: env >> env-traces.txt nebo podobné. Nemůžete to ovládat.

2
slowhand

Ve většině případů jiný uživatel nemůže číst proměnné prostředí. Lze však využít známou bezpečnostní díru, že instance programu setuid běží jako stejný uživatel jako jakákoli jiná instance programu setuid. To znamená, že pokud někdo spustí program setuid a někdo jiný může využít jiný program, který je setuid stejnému uživateli čten z /proc/<pid>/environ pak mohou číst proměnné prostředí programu. To je jeden z důvodů, proč byste měli použít nového uživatele pro každého démona, kterého píšete, místo aby zneužívali nikoho.

pokud neexistují žádné přísné zásady, existuje teoreticky způsob, jak se tento export provede v uživatelském skriptu pro přihlášení do basy pro Alice: Eva vytvoří skript pro tisk env a nastaví bity SETUIDGID v chmod a poté to podepíše Alice, pak provede. Skript bude spuštěn pod Alici a jeho bash autorun bude Alice. Pak to prosakuje data přes stdout =) Ale musí existovat velmi slabé nastavení systému, aby se takové triky mohly provést. Ve své forenzní praxi jsem viděl takové strašně nakonfigurované boxy, takže to není vtip.

0
Alexey Vesnin