Linux a bezpecnost

Alexandr Malusek malusek na hroch.ujf.cas.cz
Čtvrtek Březen 19 12:11:55 CET 1998


Hynek Med <xmedh02 na manes.vse.cz> writes:

> BTW, co se tyce Solarisu 2.x -- je tam v souvislosti s /tmp mila chyba, ze
> po instalaci se nikdy nenastavi sticky bit (+t) v /tmp a /var/tmp.

Pokud vim, tak se to tykalo pouze jedne verze Solarisu (myslim 2.3),
pricemz se nejednalo o opomenuti, ale o zamerny workaround, ktery mel
umoznit korektni fungovani nejakeho programu (pry to souviselo s
emailem). Nasledujici verze jiz sticky bit pri instalaci nastavovaly a
i pro Solaris 2.3 byly nakonec patches. Ocividne se nekdo snazil
dostat tuto verzi do vyroby co nejdrive (Solaris 2.0, 2.1, 2.2 totiz
nestal za nic, 2.3 se povazovala za prvni stabilnejsi verzi Solarisu
2.x)

> Myslim ze opravene to nema vetsina Solarisu na svete.

Neopravene systemy jsou vyjimkou a svedci o ignoranci administratora
(Dovolim si to tvrdit, nebot jsem pro Sun pracoval 2 roky ;-) )

> Exploit na tuto diru uz pak neni vubec slozity.. (Zmineny
> soubor_admintoolu si muzu vymazat a nahradit svym. Brr.)

Tak jednoduche to neni. Pokud ma admintool ten soubor otevreny a vy
jej vymazete, pak pouze odstranite jednu polozku v adresari /tmp, ale
admintool ma nadale tento (jiz pres jmeno nepristupny) soubor otevreny
a muze do nej zapisovat (Je to obecna vlastnost Unixu). Na pripadne
vytvoreni souboru se stejnym jmenem v adresari /tmp vubec nebere
ohled. Link se proto musi vytvorit pred spustenim admintoolu. (Pozn.:
admintool tento soubor po svem ukonceni maze, takze na jeho vytvoreni
neni potreba mod 777 pro /tmp.)

Horsi je to u skriptu. Pokud napr. pouzivam konstrukci

while true; do
  echo cosi >> /tmp/file_$$
  sleep 1
done

pak je soubor /tmp/file_$$ pri kazdem volani echo znovu oteviran.  V
tomto pripade skutecne staci soubor vymazat (ma-li /tmp mod 777) a
nastrcit tam vhodny link.

--
A. Malusek  (malusek na ujf.cas.cz)
UJF AV CR


Další informace o konferenci Linux