Forum Debian Users Gang

To zależy od konkretnej maszyny, na pojedynczym serwerze spokojnie wystarczy ACL jak np Apparmor albo Selinux, względnie Grsec ACL.
Jak ktoś koniecznie chce chrooty, to też ma kilka opcji, jest standardowy chroot, który już dawno wyczerpał większość swoich zalet, i praktycznie nie wykracza poza to, co można osiągnąć Apparmorem czy SElinuxem, jest Chroot wzmocniony funkcjami Grsec:

CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
# CONFIG_GRKERNSEC_CHROOT_INITRD is not set
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y

które z niego robią klatkę twardszą, niż LXC, i wreszcie jest wirtualizacja.

Ja osobiście zazwyczaj używam Grsec/Apparmor, i jeszcze problemów z tymi modułami nie miałem, powyżej tego brałbym od razu wirtualizację KVM, zamiast zawracać sobie głowę chrootami na sterydach w typie LXC.

Pozdro
;-)

A ja mam pytanie: po co?
Jeśli ma się trochę lepszą maszynę, to czy nie lepiej wykorzystać pełną wirtualizację, np qemu?

Pavlo950 napisał(-a):

A ja mam pytanie: po co?
Jeśli ma się trochę lepszą maszynę, to czy nie lepiej wykorzystać pełną wirtualizację, np qemu?

Myślę, że lepiej i to w firmie stosujemy. Jednak mam braki w kwestii lxc, grsec itd., bo nigdy nie miałem potrzeby tego stosować, teraz też nie -od tak, robię testy na kebabie od ovh.
A gdy na jednym serwerze pracuje wiele aplikacji (np. nginx+phpfpm, mysql)+do tego logują się na niego zwykli użytkownicy, aby przesyłać pliki do stron; czy zastosowanie chroot+grsec dla każdej z aplikacji z osobna oraz dodatkowy chroot+grsec dla samych użytkowników oraz całkowite porzucenie lxc wydaje się dobrym rozwiązaniem?

Ostatnio edytowany przez HaPe (2014-07-10 10:55:50)

Robiąc odrębnego chroota na aplikacje web (nginx, php) lepiej skopiować tylko potrzebne liby, binarki czy lepiej postawić przez debootstrap debiana w debianie i na nim z paczek zainstalować odpowiednią aplikację? Stosując debootstrap w pewnym stopniu ułatwiam sobie pracę w systemie, ponieważ nie ma potrzeby kopiowania plików, co jest dobre w przypadku wykonania ewentualnych aktualizacji.

HaPe - ubuntu bardzo dobrze wspiera LXC. Z chrootem bedziesz mial duzooo roboty. LXC bardzo dobrze sie sprawdza z grsec, rbackiem i apparmorem, ktory nadzoruje prace programow za pomoca LXC, ktory pokaze ci to wklepujac aa-status, dlatego bralbym ubuntu bo maja wlasne templatki pod LXC. Jezeli nie bedziesz nikomu dawal roota w lxc to nie bedziesz mial zadnych problemow. Niestety do nie dawna z LXC mozna bylo wyjsc do hosta tym ktorzy mieli roota w lxc. Ja bym szedl w ta strone tym bardziej, ze projekt zapowiada sie interesujaco, napewno bedzie wsparcie ze strony devow Grsecurity dla LXC co zreszta wspominali cos tam na Twiterze, wiec chyba nie ma sie nad czym zastanawiac. Nastepnie instalowany jest minimalistyczny system, w ktorym nie ma nawet nano, wiec burdelu tam nie uswiadczysz. Mozesz robisz snapshoty i je powielac, nie ma co sie pier... z chrootem, ktorego przeznaczenie nie sluzylo do separacji z dostepem do shella jak to autor napisal. Dodam, ze instalacja pod ubuntu jest trywialna, poradzisz sobie bez problemu.

P.S
Jest jeszcze vserver-grsecurity :D

Ostatnio edytowany przez bryn1u (2014-07-10 23:55:12)

884

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:54:41)

Jeśli dla userów stworzę odrębny lxc to czy będę mógł dla nich też stosować reguły rbac?

nie wiem czy rbac nie jest wspolny dla wszystkich. Nie daje sobie reki obciac. Po drugie RBAC obsluguje tylko userow a nie grupy, wiec dla kazdego usera bedziesz musial pisac nowa regulke albo powielac od starego usera.

Rola domyślna dla wszystkich:
http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System#Default_Role

Rola dla grupy:
http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System#Group_Roles

RTFM


Kłopot polega tylko na tym, że grsec ze względów bezpieczeństwa nie obsługuje zmiennych $USER i $HOME w RBAC.

Inna sprawa, że to problem dla kogoś, kto nie wie o istnieniu standardowych uprawnień i ACL w Linuxie, i chce stosować RBAC, jakby nie było poleceń chmod, setfacl i chattr.

Do tego można dla pacjentów wyłączyć:

CAP_FOWNER
CAP_SETPCAP
CAP_LINUX_IMMUTABLE
CAP_CHOWN
CAP_SETUID
CAP_SETGID
CAP_SYS_ADMIN

w roli Default,
i ustawić 

umask 0077

w /etc/profile wtedy żaden pacjent nawet kijem od szczotki nie ruszy plików innego pacjenta.

W ogóle dla pacjentów najlepiej wyłączyć zdecydowaną większość, o ile nie wszystkie uprawnienia capabilities.

Sznurki:
http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_Sy … _Restrictions
http://www.gentoo.org/proj/pl/hardened/capabilities.xml

W RBAC i Apparmorze dla każdego procesu z osobna można wyłączać capabilities, można też dla każdej binarki na dyziu ustalić osobne uprawnienia capabilities używając polecenia

setcap

np:

ls -l `which tcpdump`
-rwxr-xr-x 1 root root 942720 06-14 03:10 /usr/sbin/tcpdump
getcap `which tcpdump`
/usr/sbin/tcpdump = cap_net_raw+ep

Jak pacjenci mają np trzy dostępne powłoki systemowe, bash, zsh i csh, to można też te powłoki ogarnąć profilami Apparmora, w którym można się bawić regexami zgodnymi z pcre,  zmienną ${HOME} czy instrukcją owner.

Mając razem Apparmora i RBAC, macie taką plastelinę, że można cuda robić, a konfiguracja jest jakieś 5 razy prostsza, niż SElinuxa. ;)

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-07-11 15:26:05)

Oczywiście, Grsecurity istnieje obok domyślnego system LSM a nie zamiast.
LSM - czyli Linux Security Modules, tam można używać Apparmora, Smack, Tomoyo lub SElinuxa.
Jedyny wyjątek, to użycie [SElinuxa|TOMOYO] i RBAC, nie polecany (choć możliwy),
bo po prostu jest z tym ciężki bajzel, dublują się poszczególne właściwości i oba systemy mogą się łatwo tak zapętlić, że system operacyjny potem jest nie do użytku.

Sznurek:
http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_Sy … ontrol_System

Elegancko można zrobić globalną domyślną politykę w RBAC, a dla poszczególnych procesów dopieścić ją szczegółowo profilami Apparmora, które zapewniają dużo większą elastycznosć, niż RBAC, ale praktycznie nie ma w Apparmorze łatwej opcji globalnej polityki dla całego systemu.
Przy okazji na poziomie RBAC możemy mocno ograniczyć, ale nie wyeliminować całkowicie możliwości zarządzania polityką apparmora przez roota.
Po prostu zarządzanie Apparmorm może wymagać roli Admin w RBAC,
a do niej potrzebne jest osobne hasło, obrabiane i przechowywane przez Grsecurity.

Należy tylko pamiętać, ze obecnie Apparmor sięgnął wersji 3.0 w jaju, ale userspace jest w wersji Apparmor 2.4 (niezależnie od numerka), także działa tam tylko podstawowa funkcjonalność, nie działa przez to jeszcze między innymi network_rules i ipc_rules.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-07-11 15:49:10)

W LXC z tym może być problem, bo to nowy "chroot na sterydach",
w KVM maszyna wie tylko o takiej pamięci, jaką dostała przy uruchomieniu.

Względnie w zwykłym durnym chroocie możesz nie  montować /proc,
i masz taki rezultat:

free -m
Error: /proc must be mounted
  To mount /proc at boot you need an /etc/fstab line like:
      proc   /proc   proc    defaults
  In the meantime, run "mount proc /proc -t proc"

Możesz też zablokować w RBAC  dostęp do pliku /proc/meminfo, z takim samym skutkiem.
Wtedy system w LXC w ogóle nie będzie wiedział, ile ma RAM.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-07-13 15:35:58)