Forum Debian Users Gang

life · 2014-05-28 14:09:39

Zastanawiam się nad użyciem LXC zamiast chroot czyli usługi wydzielić i tak np. każdą z nich (poczta, www, SQL) stała by na oddzielnym kontenerze LXC.
W sumie testowo częściowo to zrobiłem i póki co działa ale wiadomo środowisko testowe a produkcyjne (pod obciążeniem w realu) to co innego :)

Maszyna na której będę to stawiał też nie jest demonem prędkości więc "pełna" wirtualizacja nie wchodzi w grę.
Jeśli ktoś ma jakieś doświadczenie w tej materii prosiłbym o wypowiedz :)

Jacekalex · 2014-05-28 14:23:14

Jak maszyna jest za słaba na wirtualizację, to raczej profile Apparmora lub Grsecurity ACL.

LXC to jest taki sam "chroot na sterydach" jak OpenVZ.

Ostatnio edytowany przez Jacekalex (2014-05-28 14:33:04)

morfik · 2014-05-28 16:28:32

Ja tam sobie wydzieliłem apacha i mysql na jeden lxc, odłączając tym samym swój pseudo serwer od normalnej maszyny klienckiej. Jak potrzebuje serwera www to po prostu sobie odpalam lxc i działam. xD

life · 2014-05-28 17:03:19

Czym jest LXC i wiem jak wypada w porównaiu z OpenVZ mi bardziej chodzi o działanie w środowisku produkcyjnym 24/7. Czy zdażają się jakieś problemy. Bo potencjalnie jest ciekawie.
przez cgroup można dać ograniczniena na CPU i pamięć więc nawet w przypadku gdy z jakichś powodów demon www się wyłoży i zacznie pożerać zasoby to nie padnie wszystko tylko dana usługa.

Jacekalex · 2014-05-28 22:04:43

Ciekawie może i jest, ale LXC to pełny obraz systemu, także na dyziu weźmie tyle co KVM, obciążenie też będziesz miał podobne, choć LXC wisi na jaju gospodarza, a KVM odpala system na osobnym jaju.

Jeśli chcesz stawiać serwer, ale z minimalnym narzutem na wydajność systemu, to każdy kontener i wirtualka będzie bardziej obciążała RAM i procek, niż ACL.
Zwłaszcza RAM, bo przecież, podobnie jak w klasycznym chroocie
program wczytuje te same bibilioteki, które już w systemie głównym są w pamięci.

Dlatego, jeśli serwer jest za mały na wirtualizację, to zawsze masz takie wyjście:
http://jacekalex.sh.dug.net.pl/apparmor/usr.lib64.php54.bin.php-fpm.txt
http://jacekalex.sh.dug.net.pl/apparmor/usr.sbin.lighttpd.txt

Do tego można przekonać Apacha albo Nginxa, żeby nie wisiał, jako root,
i już cala cześć WWW jest dosyć grzeczna.
Oczywiście warto też ograniczyć zasoby przez cgroup, ale to trochę inna para kaloszy, w każdym razie nic trudnego:

Kod:

cat /proc/`pidof lighttpd`/cgroup
14:hugetlb:/
13:net_prio:/
12:perf_event:/
11:blkio:/serwer/lighttpd
10:net_cls:/serwer/lighttpd
9:freezer:/
8:devices:/
7:memory:/serwer/lighttpd
6:cpuacct:/
5:cpu:/serwer/lighttpd
4:debug:/
3:cpuset:/

Jeśli natomiast boisz się exploitów operujących w pamięci RAM, to tu chroot przed niczym nie chroni, nawet przy Xenie/KVM pojawiają się sytuacje, kiedy z VM można wyskoczyć na roota hosta gospodarza,
dlatego najlepiej zainteresuj się grsec/paxem, nic lepszego nie znajdziesz w takiej sytuacji, chociaż standardowy kernel też jest coraz lepiej zabezpieczony.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-05-28 22:22:09)

life · 2014-05-29 09:26:32

A co z np. AppArmor? ostatnio się nim nieco bawiłem.
można ciekawie ustawiać to co uruchamiana aplikacja może robić, jakie pliki otwierać/modyfikować itp. czyli potencjalnie można ustawić że lighttpd (bo jego używam) może mieć dostęp tylko do /www w /etc tylko do plików konfiguracyjnych oraz /var/run dla plików pid ni pewnie jeszcze kilka polityk jeśli jest php itp.

ale z grubsza ogranicza to dostęp do innych zasobów.

Z grsec jeszcze nie kombinowałem, może to zadanie na weekend :P z tego co czytałem to PAX zabezpiecza przed wykonywaniem kodu w pamięci ale wówczas trzeba kompilować samemu z odpowiednimi flagami.

A jak sytucaja wygląda z jajkiem w debianie dla grsec? trzeba samemu je robić czy są gdzieś dostępone zbudowane paczki?

Ostatnio edytowany przez life (2014-05-29 09:30:55)

Jacekalex · 2014-05-29 11:02:27

Kiedyś było jajo z grsec w paczce Debiana, ale nie wiem, czy ten projekt jest aktualny.
Ja łatkę nakładam zawsze z palca, bardzo grzecznie działa, grsec/pax rozszerza standardowe funkcje jajka w zakresie bezpieczeństwa.

Grsecurity ma własny RBAC - czyli ACL, który nie ma tak rozbudowanych regexów jak Apparmor, ale za to zapewnia bezpieczeństwo w taki sposób, żeby nawet root nie mógł modyfikować systemu bez uwierzytelniania jego roli w RBAC.
To odpowiednik trybu strict SELINUXA.

Apparmor natomiast jest do zabezpieczania poszczególnych usług, pozwala dowolnie definiować to, co dany program może zrobić w systemie, i to niezależnie, czy ten program chodzi jako użyszkodnik, czy jako root. Apparmor natomiast nie zapewnia ochrony globalnej (polityki domyślnej dla wszystkich istniejących w systemie programów), jak Grsec-RBAC.

Profile Apparmora są dość proste w stosowaniu, natomiast kernel grsec/pax, to najmocniejsza z dostępnych wersja zabezpieczeń systemu Linux na poziomie powyżej konta root, dzięki czemu nawet napastnik, który wbije się na roota, nie mógł uszkodzić systemu (do ustawienia w RBAC).

Pax w Debianie działa, choć ze względu na sposób budowania ciągle jeszcze większości pakietów, jego skuteczność w Debianie jest mniejsza niż w Gentoo hardened, gdzie do Paxa jest dostosowany system na poziomie kompilatora gcc, glibc i binutils.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-05-29 11:03:59)

Time (s)	Query
0.00014	SET CHARSET latin2
0.00006	SET NAMES latin2
0.00120	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.22.249.229' WHERE u.id=1
0.00093	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.22.249.229', 1732748822)
0.00071	SELECT * FROM punbb_online WHERE logged<1732748522
0.00125	SELECT topic_id FROM punbb_posts WHERE id=268397
0.00110	SELECT id FROM punbb_posts WHERE topic_id=25897 ORDER BY posted
0.00059	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25897 AND t.moved_to IS NULL
0.00009	SELECT search_for, replace_with FROM punbb_censoring
0.00078	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25897 ORDER BY p.id LIMIT 0,25
0.00104	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25897
Total query time: 0.00789 s

Forum Debian Users Gang

Ogłoszenie

#1 2014-05-28 14:09:39

life - Użytkownik

Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

#2 2014-05-28 14:23:14

Jacekalex - Podobno człowiek...;)

Re: Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

#3 2014-05-28 16:28:32

morfik - Cenzor wirtualnego świata

Re: Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

#4 2014-05-28 17:03:19

life - Użytkownik

Re: Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

#5 2014-05-28 22:04:43

Jacekalex - Podobno człowiek...;)

Re: Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

Kod:

#6 2014-05-29 09:26:32

life - Użytkownik

Re: Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

#7 2014-05-29 11:02:27

Jacekalex - Podobno człowiek...;)

Re: Kontenery LXC - czy ktoś używa w środowisku produkcyjnym?

Stopka forum

Informacje debugowania