Zabezpeceni mikrosluzby

Jan Kasprzak kas na fi.muni.cz
Čtvrtek Srpen 5 12:56:09 CEST 2021


	Zdravim,

dotaz na best practices: cim dneska zabezpecujete "neduveryhodny" program?

Konkretne: mam nejakou mikrosluzbu, ktera zpracovava uzivateluv
(neduveryhodny) vstup. Cilem je zpracovat korektni vstupy, ale nedovolit
uzivateli, aby neco rozbil, nebo sahal kam nema.

Priklady:
- umoznit uzivateli vlozit a vyhodnotit vstup pro bc(1).
- umoznit uzivateli vlozit TeXovy zdrojak, obrazky, styly, whatever,
  prelozit TeXem podle jeho vyberu, a vratit vystup (PDF, DVI) a pripadne logy

Historicky jsem s pomerne velkym usilim napsal modul do SELinuxove politiky,
kterym jsem omezil jak server te mikrosluzby, tak potom zvlast ty spoustene
programy. Neni to uplne primocare, protoze kdyz je cast programu psana
ve skriptovacich jazycich (shell, Perl, whatever), tak to saha na spousty
dalsich veci. Zabezpecit treba LibreOffice spoustenou nad Xvfb jsem nakonec
vzdal, protoze to saha na fakt hodne veci.

U SELinuxu je vyhoda, ze to omezi fakt striktne (modulo chyba v kernelu).
Nevyhoda je, ze se rozhrani SELinuxu obcas meni, a neni jasne (nebo aspon
ja to nevim), kde prehledne zjistit vsechny vlastnosti a jejich zmeny
- jakoze muzu psat

allow server_t soubor_t:file open;
allow server_t soubor_t:file read;

atd, ale ono existuje i makro

allow server_t soubor_t: file read_file_perms;

Podobne existuji vysokourovnova makra pro "toto je PIDfile",
"toto je vstupni program domeny", a vselijaka dalsi, ktera ale audit2allow
neumi vyabstrahovat a vypsat.

Dalsi moznosti jsou:

AppArmor, s tim nemam moc zkusenosti.

Jen namespaces: systemd umi pro sluzbu udelat namespaces a rict, ktere cesty
jsou citelne a ktere i zapisovatelne. Neresi to uplne pristup k siti
a tak vubec.

Ruzne opravdove kontejnery (systemd-nspawn, podman, docker, whatever).
Ja ale nechci mit na disku jeste jednu kopii OS, kterou bych musel zvlast
udrzovat, a kterou by ta mikrosluzba mela vlastne celou k dispozici.
Navic teda nedavne chyby v kernelu (sequoia nebo jak to nazvali)
umoznovaly dostat se ven z kontejneru.

Seccomp - coz by bylo treba kombinovat s namespaces, a odhaduju, ze konfigurace
by byla podobne zdlouhava jako u toho SELinuxu.

Jak tohle resite? Co se dneska pouziva? Zavrit oci, vybuildovat kontejner,
poslat do Kubernetu a mit hotovo?

Diky,

-Y.

-- 
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| http://www.fi.muni.cz/~kas/                         GPG: 4096R/A45477D5 |
    We all agree on the necessity of compromise. We just can't agree on
    when it's necessary to compromise.                     --Larry Wall


Další informace o konferenci Linux