Dotaz: Jak udělat bezpečný SSH chroot/jail na CentOS?

[11010011]

Ahoj. Na webovém serveru běží několik webů pro pár uživatelů. Ke správě souborů mají nyní přístup přes openssh s vynuceným SFTP chrootem. Chtěl bych to předělat tak, aby měli přístupné celé ssh a mohli si tak třeba měnit heslo, rozbalovat soubory apod. Chci, aby každý z nich měl vlastní chroot prostředí. Na internetu se dá najít spousta návodů, nicméně jak to udělat co možná nejbezpečnější? Je to již nějaký ten pátek, co jsem někde četl, že z většiny takových chrootů se dá snadno i vyskočit.

---

---

Odpovědi

[NN]

cgroups

[11010011]

Tím můžu omezit využití zdrojů, ale pokud vím, tak tohle neumí zvýšit izolaci. Zkoušel někdo selinux sandbox nebo firejail případně kombinaci firejail s ssh chrootem?

[NN]

Myslel jsem neco ve smyslu cgroups ie. lxc, open-vz a izolovat jednotlive weby na urovni kontejneru a "delej si co chces" s tim, ze zdroje a HW by byl pod tvou spravou. Podle meho nazoru je chroot uz minulost, SW narocnost je zanedbatelna a skalovatelnost bude pohodlnejsi.

[Punny]

Taky me LXC, nebo Docker napadl jako prvni, kdyz jsem cetl pozadavky

[11010011]

To jsem zvažoval čistě pro izolaci webů - nginx proxy a přesměrování požadavků do "apache" kontejnerů. Nicméně to mě tolik nepálí (není to velký nebo komerční hosting a chci šetřit zdroje) jako izolace toho SSH. Mám k dispozici jednu veřejnou IP adresu, takže kontejnerové ssh by znamenalo mít více docker instancí, každá s vlastním portem, co uživatel, to proces. To se mi nezdá moc efektivní. Zkoušel to tady někdo? Jak moc se to projeví na výkonu?

[11010011]

V podstatě všechny metody, které jsem našel používají upravený shell. Jak je bezpečnější ho vnutit? Přes definici v /etc/passwd nebo jako ForceCommand v sshd configu? Mám takový pocit, že defaultní shell šel obejít pomocí commandu definovaného u vygenerovaného veřejného klíče ... ???

[11010011]

Jen pro zajímavost tohle je docela pěkné: https://github.com/clevcode/docker-cmd, ale otázkou je jestli jsou taková řešení bezpečnější než chroot + selinux.

[2X4B-523P]

stale na spolecnem kernelu, mimochodem se tam o tom zminuje:

Note that a kernel vulnerability could obviously be abused in order to break out of the Docker container regardless. The only way to be fully secure is to not keep any sensitive data/services on the same host as you are letting people log in to, even when using this.

[zofrey]

mam skoro pocit ze chroot a "menit se heslo" nejde moc dohromady

jako zaklad bych nastavil uzivatele jako guest_u SELinux uzivatel, chroot /bin a /lib jen zaklad pro bash (ldd /bin/bash), no a mozna jeste privatni namespacy pro /tmp pres pam_namespace