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?

[quote=Pavlo950]A ja mam pytanie: po co?
Jeśli ma się trochę lepszą maszynę, to czy nie lepiej wykorzystać pełną wirtualizację, np qemu?[/quote]
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.[/quote]
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

[b]RTFM[/b]


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ń [b]chmod[/b], [b]setfacl[/b] i [b]chattr[/b].

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

Kod:

CAP_FOWNER
CAP_SETPCAP
CAP_LINUX_IMMUTABLE
CAP_CHOWN
CAP_SETUID
CAP_SETGID
CAP_SYS_ADMIN

w roli Default,
i ustawić 

Kod:

umask 0077

w [b]/etc/profile[/b] 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_System#Capability_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

Kod:

setcap

np:

Kod:

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ą [b]${HOME}[/b] czy instrukcją [b]owner[/b].

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)

---

W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)