Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2013-06-25 22:47:08

  loop - Członek DUG

loop
Członek DUG
Zarejestrowany: 2013-02-23

Selinux - początki

No więc naoglądałem się i naczytałem tutoriali i mnie zebrało na postawienie Selinuxa.
Instalacja według wiki debiana, pliki poetykietowane, ale juz na dobry początek check-selinux-installation wywala:

Kod:

The directory /selinux is missing.
/etc/pam.d/login is not SELinux enabled
FSCKFIX is not enabled - not serious, but could prevent system from booting...

O ile to z pam.d to według wiki Debiana fałszywy alarm - to o dwóch pozostałych nic nie piszą...przejmować się czy nie?

Offline

 

#2  2013-06-26 07:09:49

  marcin'82 - Użytkownik

marcin'82
Użytkownik
Zarejestrowany: 2011-10-02

Re: Selinux - początki

Tutaj masz na temat pierwszego komunikatu:
http://www.billauer.co.il/selinux-policy-module-how … 0000000000000 .

Offline

 

#3  2013-06-26 09:19:47

  pasqdnik - Pijak ;-P

pasqdnik
Pijak ;-P
Skąd: Wrocław
Zarejestrowany: 2006-03-06

Re: Selinux - początki

Jeśli SELinux to raczej w rodzinie RH, tam domyślne polityki działają ;-)

pasqdnik@nx7300:~ # uname -a
Linux nx7300.k_53_13 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
pasqdnik@nx7300:~ # sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted


Dum spiro - spero ...
pozdrawiam, pasqdnik

Offline

 

#4  2013-06-26 11:50:27

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Selinux - początki

SELINUX - to  w ogóle jest zabawka dla RHEL.

W innych dystrybucjach wsparcie jest prawie żadne, a błędów tony.
Ja już się przebiłem przez konteksty Selinux, polityki Selinux, a wystarczy włączyć u mnie targeted permisive, żeby GDM się wysypywał, Nautilus się wywalał na właściwościach pliku, itp, bez choćby przecinka na ten temat w logach.
A wszystko na Gentoo, który teoretycznie do Selinuxa ma bardzo solidne wsparcie w projekcie hardened.

Jak ktoś chce pancernych zabezpieczeń, to zamiast się certolić  z Selinuxem, 50 razy szybciej postawi Grsecurity z potężnym systemem ACL, przewyższającym możliwości trybu Selinux strict, a jak chcesz selektywnie niektóre programy ochraniać, to do takiej zabawy najlepszy jest Apparmor.
Ten ma dość wygodny sposób generowania profili dla programu, można też je łatwo edytować ręcznie.

Jedne miejsce, gdzie Selinux jeszcze ma sens, to jeśli komuś zależy na podpisywaniu plików mechanizmem IMA/EVM, to sensowne użycie IMA jest ściśle związane z atrybutami Selinuxa.

Praktycznie we wszystkich dystrybucjach poza RHEL/Fedora/CentOS, Selinuxa można jako tako użyć na serwerze, jak się ktoś uprze, natomiast środowisko graficzne  to bardziej teoria niż realna opcja.

Kiedyś testowałem Selinuxa na Squeeze, na permisive wstawał, jak włączyłem enforce po kompletnym uruchomieniu, działały już uruchomione programy, większość nowo włączonych nie, jak włączyłem enforce w konfigu Selinuxa (tryb targeted, nie strict), to po następnym uruchomieniu była tylko czarna konsola.
Na stabilnym  Debianie.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2015-07-13 04:04:22)


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

Offline

 

#5  2013-06-26 19:23:19

  grzesiek - Użytkownik

grzesiek
Użytkownik
Skąd: Białystok
Zarejestrowany: 2009-03-06
Serwis

Re: Selinux - początki

"SELINUX - to  w ogóle jest zabawka dla RHEL."

SELinux to mechanizm jądra Linux, a te używane jest w każdej dystrybucji. Różnica polega tylko na tym, że w dystrybucjach z pod znaku RH polityka jest dopracowana - i to jest cała różnica - polityka, a nie sam mechanizm SELinux.


"a wystarczy włączyć u mnie targeted permisive, żeby GDM się wysypywał"

W trybie permissive SELinux nie blokuje niczego.



"...Grsecurity z potężnym systemem ACL, przewyższającym możliwości trybu Selinux strict"

hahaha x2 (czytaj http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf)

Natomiast co do AppArmor to on nie kontroluje programów tylko pliki. Kontrolować proces to on może w taki sposób, że ktoś go może uruchomić albo nie, ale po uruchomieniu jego działania (poza dostępem do innych plików) nie są kontrolowane. W ścisłym znaczeniu AppArmor nie jest mechanizmem modelu MAC. (czytaj: http://w3.linux-magazine.com/issue/69/AppArmor_vs_SELinux.pdf)

Offline

 

#6  2013-06-26 20:35:28

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Selinux - początki

grzesiek napisał(-a):

"SELINUX - to  w ogóle jest zabawka dla RHEL."

SELinux to mechanizm jądra Linux, a te używane jest w każdej dystrybucji. Różnica polega tylko na tym, że w dystrybucjach z pod znaku RH polityka jest dopracowana - i to jest cała różnica - polityka, a nie sam mechanizm SELinux.

Tylko w dystrybucjach zgodnych z RHEL, w innych już nie.

grzesiek napisał(-a):

"a wystarczy włączyć u mnie targeted permisive, żeby GDM się wysypywał"

W trybie permissive SELinux nie blokuje niczego.

Obserwacje z mojego kompa - Gentoo hardened.

"...Grsecurity z potężnym systemem ACL, przewyższającym możliwości trybu Selinux strict"

hahaha x2 (czytaj http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf)

Grsecurity po włączeniu trybu poprzez Gradm zapewnia całkowitą kontrolę ACL plików i gniazd sieciowych w całym systemie, do takiego poziomu ochrony w Selinuxie trzeba odpalić tryb strict.

Systemu RHEL, CentOS czy Fedory z Selinuxem w trybie strict jeszcze w życiu nie spotkałem, poza demo Selinuxa w internecie.
Nie wiem, czy w Polsce jest chociaż jeden serwer czy stacja robocza tak chroniona.

Proponuję zawody, ja postawię serwer  chroniony przez gradm ba Gentoo, a grzesiek przez selinux strict na Centos, czas wykonania - 24 godziny, konfiguracja? Nginx lub Apache, Postifix, SSH, Proftpd, Ejabberd, Spamassassin, filtry spamowe.
Ciekawe, kto wcześniej skończy:D

Natomiast co do AppArmor to on nie kontroluje programów tylko pliki. Kontrolować proces to on może w taki sposób, że ktoś go może uruchomić albo nie, ale po uruchomieniu jego działania (poza dostępem do innych plików) nie są kontrolowane. W ścisłym znaczeniu AppArmor nie jest mechanizmem modelu MAC. (czytaj: http://w3.linux-magazine.com/issue/69/AppArmor_vs_SELinux.pdf)

Apparmor tak samo jak Selinux w trybie targeted i Gardm jest systemem ACL, kontroluje dostęp do plików, należy jednak pamiętać, że w Linuxie wszystko jest plikiem.
Wszystkie urządzenia sieciowe, dyski, sterowniki dźwieku, obrazu, tpm, i cala reszta urządzeń jest reprezentowana w /dev, konfiguracja sterowników w /sys a procesy w /proc.

Pod tym względem wszystkie systemy ACL działają jednakowo, natomiast SElinux w swojej najpotężniejszej postaci nie dorobił się żadnego mechanizmu zapewniającego ochronę przed expolitami działającymi w pamięci RAM, co łatka Grsecurity załatwia obecnością PAX_MPROTECT  i kilkoma innymi mechanizmami.

Standardowy Red Hat na jaju 2.6.32 miał niedawno nawet dziurę pozwalającą z dowolnego konta manipulować procesami roota przez pliki w /proc, jak na aktywnego SElinuxa, to niezłe osiągnięcie.
Sznurek:
http://www.securityfocus.com/bid/46567
Dla porównania w Grsecurity restrykcje /proc są dostępne z buta bez żadnej specjalnej konfiguracji, wystarczy zaznaczyć 2 opcje  w konfigu kernela.

SElinux, to jest mocna przewaga formy na treścią, obecnie jednym mocnym atutem SElinuxa jest  to,
że bez niego nie da się decydować, które pliki mają być weryfikowane przez mechanizm IMA, a które nie.
A IMA z EVM - to całkiem przyjemny mechanizm sprawdzania podpisów cyfrowych dla plików.
W innych kwestiach SElinux  jest 5 razy trudniejszy w konfiguracji przy porównywalnej  lub niższej skuteczności, niż Grsecurity.
Faktem jest jednak, ze jak ktoś chce się bawić, albo firma, która chce zarabiać miliony na komercyjnym supporcie, jak RH, ma w SElinuxie idealne narzędzie, którego nikt nie jest w stanie ogarnąć całościowo.
Wystarczy wykombinować np konteksty SElinuxa dla każdego pakietu przechodzącego przez tablicę SECURITY netfiltera, zamiast zdecydować, który program ma prawo słuchać na porcie docelowym

W Grsec wystarcza moduł gradm netfiltera oraz opcje  bind i connect w /etc/grsec/policy, skuteczność jest w praktyce taka sama w obu rozwiązaniach, stopień skompilowania konfiguracji nieporównywalny.

I jeszcze support:
W grsec wygląda tak:
http://forums.grsecurity.net/viewtopic.php?f=3&t=3394
Ile kosztuje?

A jak wygląda support w Selinuxie?
Ile kosztuje?

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2013-06-26 20:50:05)


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

Offline

 

#7  2013-06-26 21:02:19

  Yampress - Imperator

Yampress
Imperator
Zarejestrowany: 2007-10-18

Re: Selinux - początki

Tak się składa , że Mr  Grzesiek ma taką maszynę z Selinuxem do testowania http://grzesieklog.blogspot.com/p/selinux.html
Dostajesz roota i możesz się pobawić -> przejąć nad nią kontrole, używać exploitów -> no wsjo co chcesz. 


Ja już się bawiłem  ]:->

Offline

 

#8  2013-06-26 21:35:58

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Selinux - początki

Już raz się bawiłem demo selinuxa w trybie strict.
Wyglądało to tak samo, jak u mnie, jak odpaliłem gradm.

Jak natomiast próbowałem tak samo skonfigurować maszynkę u mnie, to po trzech tygodniach studiowania dokumentacji i kombinowania, na poziomie konsoli nawet to działało i w Gentoo i w Debianie, niezależnie czy strict czy targeted, natomiast, na Squeeze nie udało mi się w ogóle podnieść Xorga w trybie targeted  enforce, w Gentoo nawet Gnome  działało, ale przez kilka błędów poległem. :D

Jedyna różnica jest tak na poziomie konsoli, że na samym selinuxie kilka exploitów potrafiło mi powiesić kompa, na Grsec nie mają na to żadnych szans.

Najlepsza heca była z opcją Active-Exploit-Respose, wywaliło mnie z konta użytkownika, nie mogę się zalogować, po trzeciej probie sprawdzam logi..... aha, zapomniałem. :D

Ostatnio edytowany przez Jacekalex (2013-06-26 21:36:57)


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

Offline

 

#9  2013-06-27 08:46:48

  grzesiek - Użytkownik

grzesiek
Użytkownik
Skąd: Białystok
Zarejestrowany: 2009-03-06
Serwis

Re: Selinux - początki

Nie mogę się oprzeć aby sprostować wypisywane przez Ciebie teorie :)

Grsecurity po włączeniu trybu poprzez Gradm zapewnia całkowitą kontrolę ACL plików i gniazd sieciowych w całym systemie, do takiego poziomu ochrony w Selinuxie trzeba odpalić tryb strict.

Całkowita kontrolę mówisz, ciekaw jestem czy w grsecurity prawo obiektu "a" wyklucza "r" - innymi słowy mówiąc, czy "a" nie oznacza automatycznie również czytania?

W SELinux wszystkie gniazda są kontrolowane nawet w polityce typu targeted (nie trybie, tryby są 3: disabled, permissive i enforcing). A wiesz dlaczego, bo SELinux to implementacja modelu MAC, a MAC oznacza wymuszoną kontrolę i stosuje wymuszone etykietowanie i wymuszone sprawdzanie wszystkiego.

Apparmor tak samo jak Selinux w trybie targeted i Gardm jest systemem ACL, kontroluje dostęp do plików, należy jednak pamiętać, że w Linuxie wszystko jest plikiem.

AppArmor jak już pisałem nie jest tym samym co SELinux, a już na pewno SELinux nie jest mechanizmem typu ACL! A gradm też nie jest mechanizmem tylko narzędziem do zarządzania Grsecurity. Więc SELinux nie kontroluje tylko dostępu do plików, a w systemie GNU/Linux nie wszystko jest plikiem - np. proces, komunikacja pomiędzy nimi.
Załóżmy, że użytkownik U ma dwa procesy A i B, oba zajmują się innymi zadaniami. Czy w Grsecurity można zrobić tak, aby procesy te nie miały dostępu nawzajem do swoich danych mimo iż pracują w ramach tego samego użytkownika? Bo w DAC proces A może np. czytać dane procesu B, ba może nawet zmienić ich prawa, tak aby wszyscy mogli usuwać dane procesu B :)

Pod tym względem wszystkie systemy ACL działają jednakowo, natomiast SElinux w swojej najpotężniejszej postaci nie dorobił się żadnego mechanizmu zapewniającego ochronę przed expolitami działającymi w pamięci RAM, co łatka Grsecurity załatwia obecnością PAX_MPROTECT  i kilkoma innymi mechanizmami.

Co za głupota. Wszystkie programy działają w pamięci RAM w tym i exploity, przed którymi "w swojej najpotężniejszej postaci" SELinux chroni :)

Standardowy Red Hat na jaju 2.6.32 miał niedawno nawet dziurę pozwalającą z dowolnego konta manipulować procesami roota przez pliki w /proc, jak na aktywnego SElinuxa, to niezłe osiągnięcie.
Sznurek:
http://www.securityfocus.com/bid/46567
Dla porównania w Grsecurity restrykcje /proc są dostępne z buta bez żadnej specjalnej konfiguracji, wystarczy zaznaczyć 2 opcje  w konfigu kernela.

heheh nie wiem czy dam rade do końca to prostować... ale ok
Co za głupoty ;)

a) użytkownik ograniczony w SELinux nie może zmieniać plików w katalogu /proc
b) w tym linku co podałeś nie ma słowa o SELinux
c) ale skoro już, to pewnie że nie broni, bo domyślnie po instalacji SELinux wszyscy użytkownicy pracują w domenie unconfined_t i trzeba o tym wiedzieć ;) a wiesz czemu tak jest, bo tacy jak ty o tym nie wiedzą i potem by wystawiali opinię dla systemu, że nie działa.

SElinux, to jest mocna przewaga formy na treścią...

Nie zawsze najprostsze rozwiązania są najlepsze.
Nie zawsze skomplikowane rozwiązania są złe.

A jak wygląda support w Selinuxie?
Ile kosztuje?

Jak dla Ciebie 4000 PLN ;)

Powiem tak, co do Twoich wypowiedzi na temat SELinux to wynika z nich, że po prostu nie rozumiesz modelu MAC.
Tym bardziej dalej nie rozumiem czemu w to brniesz...

Offline

 

#10  2013-06-27 17:50:30

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Selinux - początki

Prostować?

Daremny wysiłek.
Złożoność Selinuxa powoduje, że nieraz go jeszcze zobaczę lub postawię na serwerze, ale nigdy nie zobaczę trybu strict na desktopie.

Tryb targeted natomiast jest wyraźnie słabszy od Grsecurity.

Z fajnych rzeczy dla desktopa, w okolicach produktów RH jest sandbox dla programów graficznych, można do niego wpakować np Firefoxa czy Skype.
Inną jest wspomniany przez mnie mechanizm IMA, zintegrowany na razie tylko z SElinuxem.

Przywołany przeze mnie błąd nie dotyczy SElinuxa?
Dotyczy RHEL, który po instalacji ma aktywny tryb targeted.

Kod:

CONFIG_GRKERNSEC_PROC=y

znaczy więcej, niż całe twoje opowieści o domenie unconfirmed.

Ten drobiazg:

Kod:

CONFIG_GRKERNSEC_BRUTE=y

też jest skuteczniejszy od całego SElinuxa, w przypadku siłowego łamania hasła.

Innym bardzo sympatycznym drobiazgiem jest:

Kod:

CONFIG_GRKERNSEC_TPE=y

Takich drobiazgów jest w Grsecu i Paxie trochę. ;)

Oczywiście SElinux i Grsecurity, to dwa różne sposoby realizacji polityki bezpieczeństwa, które w kwestii uprawnień systemowych pozwalają osiagnąć podobne rezultaty, natomiast  alternatywy dla  Paxa w SElinux nie ma i nie było.

I chyba jest ten SElinux niezwykle "skuteczny" skoro do separacji uprawnień  w FreeBSD wystarcza jail, przy Grsecurity nawet  chroot z GRKERNSEC_CHROOT, za to przy SElinuxie jedyny skuteczny sposób, to podobno wirtualizacja lub LXC - który to LXC też jest "chrootem na sterydach" jak nieśmiertelny OpenVZ.

Całkowita kontrolę mówisz, ciekaw jestem czy w grsecurity prawo obiektu "a" wyklucza "r" - innymi słowy mówiąc, czy "a" nie oznacza automatycznie również czytania?

Nie wyklucza i nie przyznaje, a oznacza dopisywanie, r odczyt, nadaje się je osobno.
W polityce grsec te dwa uprawnienia traktowane są osobno (mam na myśli konfigurację).
Tu masz opis:
http://grsecurity.net/gracldoc.htm
http://www.gentoo.org/proj/pl/hardened/grsecurity2.xml?style=printable

Z resztą pisało o tym w dokumentach, które linkowałeś wcześniej.

Pozdro
;-)


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

Offline

 

#11  2013-06-27 18:12:37

  Yampress - Imperator

Yampress
Imperator
Zarejestrowany: 2007-10-18

Re: Selinux - początki

Chyba nie wiesz do końca po co i do czego jest jail.

16.3. Introduction

Since system administration is a difficult and perplexing task, many powerful tools were developed to make life easier for the administrator. These tools mostly provide enhancements of some sort to the way systems are installed, configured and maintained. Part of the tasks which an administrator is expected to do is to properly configure the security of a system, so that it can continue serving its real purpose, without allowing security violations.

One of the tools which can be used to enhance the security of a FreeBSD system are jails. Jails were introduced in FreeBSD 4.X by Poul-Henning Kamp <phk@FreeBSD.org>, but were greatly improved in FreeBSD 5.X to make them a powerful and flexible subsystem. Their development still goes on, enhancing their usefulness, performance, reliability, and security.
16.3.1. What is a Jail

BSD-like operating systems have had chroot(2) since the time of 4.2BSD. The chroot(8) utility can be used to change the root directory of a set of processes, creating a safe environment, separate from the rest of the system. Processes created in the chrooted environment can not access files or resources outside of it. For that reason, compromising a service running in a chrooted environment should not allow the attacker to compromise the entire system. The chroot(8) utility is good for easy tasks which do not require much flexibility or complex, advanced features. Since the inception of the chroot concept, however, many ways have been found to escape from a chrooted environment and, although they have been fixed in modern versions of the FreeBSD kernel, it was clear that chroot(2) was not the ideal solution for securing services. A new subsystem had to be implemented.

This is one of the main reasons why jails were developed.

Jails improve on the concept of the traditional chroot(2) environment in several ways. In a traditional chroot(2) environment, processes are only limited in the part of the file system they can access. The rest of the system resources (like the set of system users, the running processes, or the networking subsystem) are shared by the chrooted processes and the processes of the host system. Jails expand this model by virtualizing not only access to the file system, but also the set of users, the networking subsystem of the FreeBSD kernel and a few other things. A more complete set of fine-grained controls available for tuning the access of a jailed environment is described in Section 16.5, “Fine Tuning and Administration”.

A jail is characterized by four elements:


A directory subtree — the starting point from which a jail is entered. Once inside the jail, a process is not permitted to escape outside of this subtree. Traditional security issues which plagued the original chroot(2) design will not affect FreeBSD jails.


A hostname — the hostname which will be used within the jail. Jails are mainly used for hosting network services, therefore having a descriptive hostname for each jail can really help the system administrator.


An IP address — this will be assigned to the jail and cannot be changed in any way during the jail's life span. The IP address of a jail is usually an alias address for an existing network interface, but this is not strictly necessary.


A command — the path name of an executable to run inside the jail. The path is relative to the root directory of the jail environment.

Apart from these, jails can have their own set of users and their own root user. Naturally, the powers of the root user are limited within the jail environment and, from the point of view of the host system, the jail root user is not an omnipotent user. In addition, the root user of a jail is not allowed to perform critical operations to the system outside of the associated jail(8) environment. More information about capabilities and restrictions of the root user will be discussed in Section 16.5, “Fine Tuning and Administration” below.

Raczej chodzi Ci o MAC  Mandatory Access Control
http://www.freebsd.org/doc/handbook/mac.html

Offline

 

#12  2013-06-27 19:05:45

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Selinux - początki

Nie mam na myśli, do czego jest formalnie, i zgodnie z dokumentacją, tylko dlaczego i w jakim celu jest wybierany, w sensie czysto praktycznym.

Różnica między Przytoczonym przez Ciebie opisem, a klasycznym chrootem jest kosmiczna, między jailem BSD a chrootem + Grsec-chroot sprowadza się do tego, że jail ma własny adres IP i nazwę hosta.

Przykładowo w chroocie chronionym przez grsec masz takie małe niespodzianki:

Kod:

whoami
root

chmod +s /bin/su
chmod: nie można zmienić uprawnień do „/bin/su”: Brak dostępu

chattr +i /bin/su
chattr: Operacja niedozwolona podczas ustawiania flag /bin/su

ping wp.pl
ping: icmp open socket: Operation not permitted

lft wp.pl
ioctl: No such device

raw socket: Operation not permitted

to już diabelnie blisko jaila z BSD, w dodatku te uprawnienia dla chrootów są zarządzalne przez sysctl nawet bez specjalnej polityki grsec.
Natomiast w polityce masz możliwość ustawiania capabilities, uprawnień i dostępu do /dev,  /sysfs i /proc dla każdego programu i skryptu  z osobna.

Oczywiście możemy się latami kłócić o takie czy inne definicje, systemy bezpieczeństwa są różne, dla mnie natomiast liczy się totalna ochrona przy możliwie prostym zarządzaniu ustawieniami tej ochrony.
W  tym miejscu Grsec jest znacznie łatwiejszy od SElinuxa, jest też łatwiejszy od MAC w FreeBSD.

Z innych kwestii, czy jest jakaś konkurencja między tymi, jakże różnymi rozwiązaniami?
Chyba tak:
http://forum.dug.net.pl/viewtopic.php?pid=221074#p221074


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

Offline

 

#13  2013-06-27 19:52:01

  Yampress - Imperator

Yampress
Imperator
Zarejestrowany: 2007-10-18

Re: Selinux - początki

jail jest rodzajem zwirtualizowanego systemu szczelnie zamkniętego w więzieniu w systemie gospodarzu. Taki system w systemie  i z  bezpieczeństwem głównego systemu nie ma nic wspólnego. Jak chcesz utwardzac bsd http://www.trustedbsd.org/

Ostatnio edytowany przez Yampress (2013-06-27 20:02:45)

Offline

 

#14  2013-06-28 01:38:28

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Selinux - początki

Ok, wiem, czytałem.

Dla porównania GRACL jest formą zrobienia szczelnie zamkniętego więzienia z systemu gospodarza.
I jako jedyny system bezpieczeństwa, traktuje domyślnie roota jako tak samo podejrzanego użyszkodnika, jak każdy inny.
Dlatego w ogóle się nie włączy, jeśli root ma prawo zapisu w jakimkolwiek folderze z $PATCH lub $LIBRARYPATCH.

Po starannej konfiguracji Grsecurity ACL cały system wygląda, jak jail z BSD, dlatego starczają chrooty dla usług.

Nawiasem pisząc, tak się tu chwali SElinuxa, czy jaile z BSD, a np Microsoft zna się na bezpiecznych serwerach?
Tutaj widać - 1 maja 2012 że nawet nieźle. :D


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

Offline

 

#15  2013-06-28 09:13:10

  grzesiek - Użytkownik

grzesiek
Użytkownik
Skąd: Białystok
Zarejestrowany: 2009-03-06
Serwis

Re: Selinux - początki

Przywołany przeze mnie błąd nie dotyczy SElinuxa?

W końcu zrozumiałeś :)

CONFIG_GRKERNSEC_PROC=y

znaczy więcej, niż całe twoje opowieści o domenie unconfirmed.

unconfined_t a nie unconfirmed_t, ponad to domena ta oznacza małe ograniczenia, myślałem, że o tym wiesz :(

natomiast  alternatywy dla  Paxa w SElinux nie ma i nie było.

i nie miało być, to są dwa różne zagrożenia, SELinux chroni przed eskalacją a nie przed sztuczkami w przestrzeni procesu. SELinux nie jest all-in-one.

I chyba jest ten SElinux niezwykle "skuteczny" skoro do separacji uprawnień  w FreeBSD wystarcza jail, przy Grsecurity nawet  chroot z GRKERNSEC_CHROOT, za to przy SElinuxie jedyny skuteczny sposób, to podobno wirtualizacja

Nie wypisuj głupot, którymi tylko udowadniasz, że nie znasz SELinux, bo właśnie zaprzeczyłeś całej idei SELinux.


W  tym miejscu Grsec jest znacznie łatwiejszy od SElinuxa, jest też łatwiejszy od MAC w FreeBSD.

SELinux to właśnie pierwotna i najobszerniejsza implementacja modelu MAC.
Grsecurity jest łatwiejszy bo nie oferuje tak dużych możliwość i tyle. AppArmor też jest łatwiejszy, również kosztem możliwości. W bezpieczeństwie jaki i w łamaniu zabezpieczeń nie ma prostych dróg :)

The US military (and others) trust SELinux with their information, shouldn’t you?

SELinux – Because life is too simple.

Offline

 

#16  2013-06-28 10:48:14

  bryn1u - Użytkownik

bryn1u
Użytkownik
Zarejestrowany: 2009-04-17

Re: Selinux - początki

Grsecurity jest łatwiejszy bo nie oferuje tak dużych możliwość i tyle. AppArmor też jest łatwiejszy, również kosztem możliwości.

Zgadza sie !

SELinux:

- DAC - Discretionary access controll
- MAC - Mandatory access control
- RBAC - Role-Based Access Control
- TE - Type enforcement
- ACL - Access control list
- MLS - Multi-level security
- FLASK (Flux Advanced Security Kernel)

Powodzenia z konfiguracja, aby wszystko wspolgralo ze soba jak nalezy :P

Ostatnio edytowany przez bryn1u (2013-06-28 10:48:37)


E-Booki: FreeBSD, OpenBSD, Linux, Hacking, PHP, Catia, Perl_CGI, Mysql ...
http://unix-ebooki.neth.pl/

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)