Peryferie z GRSECURITY

[Pryka]

Witam wszystkim, wie ktoś czemu po spatchowaniu vanilla-soruces za pomocą fbcondecor a następnie grsecurity.

Gdy tylko skonfiguruję grsce znika mi od razu:

Code: Select all

Device Driver---->
Connector - unified userspace <-> kernelspace linker

I nie jestem dzięki temu w stanie wkompilować w jądro:

Code: Select all

Graphics support ---> Support for frame buffer devices ---> Userspace VESA VGA graphics support

Bo go po prostu nie ma jak i Connectora o którym mówiłem... Patrzyłem czy jakaś konkretna opcja w grsecurity się z tym nie wiąże, ale dopiero całkowite wyłączenie go w jajku sprawia, że wyżej wymienione opcje stają się dostępne.

O co chodzi?


ps. Przy okazji dodam, że na przy budowaniu jądra na koniec wypluwa mi:

Code: Select all

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

Przebudowałem jajko jeszcze raz z podaną opcją, żeby zobaczyć o co chodzi, ale wtedy całkiem sypie ostrzeżeniami, to przez grsecurity?

[Jacekalex]

A które jajo i która łata?
pies zjadł te informacje?

Poza tym o uvesa przy grsec raczej radziłbym albo zapomnieć, albo się nie przyzwyczajać, ostatnie jajo z uvesą i grsec u mnie, to było 2.6.36-r4 hardened-sources.

Potem u mnie szła tylko vesa, ale na vesie działał splash-manager tak samo, jak na uvesie, co mnie nawet dość mocno zdziwiło.
I tak aż do kernela 2.6.38.2, od 2.6.38.4 nie mogłem dojść do ładu z ACPI, także do tej pory mam 2.6.37.
Właśnie robię nowy konfig na jajo 3.0, i tam mam jeden problem, tylko że to na razie wersja rc4, także do stabilnego jeszcze chwila czasu, do grsecurity na jajo 3.0 trochę więcej niż chwila.

A z resztą jak robileś ankietę o kernelach, to ja tam chyba dalem linka do konfigu na jajo 2.6.37-tic - moje najbardziej udane do tej pory, z łatą Autogroup, TOI, Grsec/Paxem, L7 i IMQ.
Sznurek: http://pastebin.com/SmZYAYTw

Także możesz do niego zajrzeć, tylko uprzedzam:
konflikt Paxa ze sterem Nvidii dalej aktualny, pomaga wyłączenie paxa przez pax-softmode, nawet na forum grsecurty nie znalazlem info, jak skonfigurować paxa, zeby nvidii nie blokował.

Nawet z wyłączonym paxem zaczęło mi coś blokować Skype, po którejś aktualiazacji systemu, w dodatku bez żadnego śladu w logach.
Sprawca - na 100% grsecurity, nie wyczaiłem, która funkcja, bo w międzyczasie system mi się posypał, i stawiałem go na nowo.
Przy Gentoo hardened - z (kompilatorem hardened) radzę się trzymać stabilnej wersji kompilatora.
U mnie, po zmianie na testowy gcc-4.5.1-r1 z każdym miesiącem rosła liczba programów, które albo się nie kompilowały tą wersją, albo nie działały.
Póki używalem gcc 4.4 - praktycznie cały system chodził podręcznikowo, może z wyjątkiem webkita-gtk - wyraźnie nie przepada za kompilatorem hardened, i Virtualboxem, którego ubijał zarówno grsec, jak i pax.
Nie przejmowalem się tym zbytnio, bo doszedlem do wniosku, że czas poznać bliżej kvm i xena.
Kvm muliło niemiłosiernie (w porównaniu z Vboxem), Xena spróbuję w w jaju 3.0 - jest już pełny support Dom0.

To by było na tyle

[Pryka]

Jajko:

Code: Select all

sys-kernel/vanilla-sources-2.6.39.2

a patch grsecurity-2.2.2-2.6.39.2-201106251441.patch

Co do tego czy uvesafb pójdzie czy nie zobaczymy, może coś wydumam, a jak nie to się zacznę wtedy martwić

O Nvidi wiem, softmode mam włączony, bo inaczej nie idzie, ale teraz mam czarny screen zamiast ekranu logowania, ponoć pomaga wyłączenie UDEREF ale już tego nie sprawdziłem, bo zauważyłem wyżej opisywany problem i staram się najpierw z nim uporać.

Co do kompilatora to cisnę na:

Code: Select all

 [1] x86_64-pc-linux-gnu-4.5.2 *

I jak na razie nigdy nie miałem z nim żadnych problemów. A jeśli ewentualne wystąpiły to na pewno nie wiedziałem, że przez niego poza tym wszystko ustępowało zawsze.

[Jacekalex]

Z tym gcc problemów nie miałeś, bo to jest kompilator standardowy, a nie hardened:
Tu masz wynik u mnie stabilny 4.4.5 i testowy 4.6:

Code: Select all

gcc-config -l
 [1] i686-pc-linux-gnu-4.4.5 *
 [2] i686-pc-linux-gnu-4.4.5-hardenednopie
 [3] i686-pc-linux-gnu-4.4.5-hardenednopiessp
 [4] i686-pc-linux-gnu-4.4.5-hardenednossp
 [5] i686-pc-linux-gnu-4.4.5-vanilla
 [6] i686-pc-linux-gnu-4.6.0
 [7] i686-pc-linux-gnu-4.6.0-hardenednopie
 [8] i686-pc-linux-gnu-4.6.0-hardenednopiessp
 [9] i686-pc-linux-gnu-4.6.0-hardenednossp
 [10] i686-pc-linux-gnu-4.6.0-vanilla

Nawet, jak kompilujesz program wersją vanilla, to czasami nie zyskasz wiele, jeśli bibioteki, z których ten program korzysta sa kompilowane wersją podstawową.
Kompilator poza tym od razu oznacza skompilowane pliki znacznikiem paxa, przydatnym do dzialania
grsecurity/pax.
Poza tym, co do gotowości do paxa, popatrz na to: http://forums.grsecurity.net/viewtopic.php?f=3&t=2131

Bo traktujesz grsecurity, jak antywirusa na Win$, tymczasem użycie mechanizmów bezpieczeństwa znanych z grsecurity zaczyna się na poziomie kompilatora, - konkretnie flag zabezpieczajacych takich jak ASLR/PIE/SPP/RELRO/fortify/bind-now.
W tej chwili wdrożyli je nawet w Ubutu, ale chyba w wyraźnie mniejszym zakresie, niż zapewniany przez grsec/pax, skoro stosowany w Ubuntu ASLR już został pokonany.

Właśnie dlatego stage hardened -to jest inna wersja instalatora.
Sznurek: http://www.gentoo.org/proj/pl/hardened/ ... kstart.xml

To by bylo na tyle

[Pryka]

Nie nie traktuje jak antywirusa tylko nie mam, czasu wszystkiego przeczytać. Jakbym go tak traktował to skończył bym na clamav

vanilla-sources zainstalowałem tydzień temu... leżały nietknięte do wczoraj, złapałem chwilę czasu zrobiłem upgrade do 39.2 połatałem jajko ustawiłem, skompilowałem. Potem softmode bo wcześniej mówiłeś, i na tym się skończyła zabawa. Bo i czas mi się skończył.

Nic nie czytałem o żadnych kompilatorach, bo po prostu nie mam kiedy, dziś znowu pewnie się nie dotknę do niczego. Mam nadzieję, że ktoś będzie wiedział o co chodzi i mi pomoże.

A co do tego, że mój nie sypie błędami... to wiem dlaczego nie... nie bierz mnie za idiotę


PS. Swoją drogą skąd masz te kompilatory? Łatałeś ten z portage czy jakiś overlay? Bo nie widzę ich w drzewie.

[Jacekalex]

Stage hardened ma gcc w wersji hardened.

Jeśli chcesz konwertować zwykłe Gentoo, to zmieniasz profil; eselectem, i kompilujesz gcc z flagami hardened.
A dalej standardowo, budujesz paczki nowym kompilatorem.
Listę dostępnych profili masz w:

Code: Select all

eselect profile list

Moje flagi gcc:

qlist -ICvU sys-devel/gcc
sys-devel/gcc-4.4.5 (fortran gtk hardened mudflap nls nptl openmp)
sys-devel/gcc-4.6.0 (fortran go gtk hardened lto mudflap nls nptl openmp)
sys-devel/gcc-config-1.4.1-r1

Fortran nie jest konieczny, ale do czegoś go kiedyś potrzebowałem, więc został.

Krótko pisząc, dokumentacja się kłania.

Sznurek: http://en.wikibooks.org/wiki/Grsecurity

PS:
Osobiście wolałbym stawiać od zera system hardened,niż konwertować już zainstalowany do tego formatu. Ale to tylko moja opinia.

Edyta:
udało mi się odpalić jajo 2.6.39.2 z grsec, a na nim ster Nvidii, tylko wyłaczyłem conieco w paxie, stosując się do zaleceń z wiki grsecurity nt fglrx.

To by było na tyle

[Pryka]

Mi też udało się uruchomić nvidię a słuchaj odpala Ci się nvidia-settings? Bo ja nie mogę go zmusić do współpracy, wywala ciągle:

Code: Select all

/usr/bin/nvidia-settings: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Operation not permitted

Jak wrócę to sam poszukam rozwiązania, ale pomyślałem, że napiszę bo może też się z tym borykasz?



Dziś zostaje mi jeszcze emerge -e world a potem bardziej dogłębna konfiguracja.


ps. Czemu niektóre dość ważne flagi są zminusowane? np. -mmxext, -ssse3, -unicode i sporo innych, dogrzebałem się do buga o tym i tam zadałem pytanie, ale może prędzej tutaj mi ktoś odpowie na to.

[Jacekalex]

Ster Nvidia 270.*.* jak widzę - ta wersja gryzie się z paxem.
Spróbuj wyłączyć paxa:

Code: Select all

sysctl -w kernel.pax.softmode=1

Albo zmień ster na 275.*.*

U mnie ten ster:

Code: Select all

 qlist -ICv nvidia-drivers
x11-drivers/nvidia-drivers-275.09.07

działa normalnie, na 270.41.19 mialem to samo, z wieloma programami.
Było o tym na forum grsecurity.

Co do zamaskowanych flag, są odmaskowane w profilu, w pliku:

Code: Select all

/usr/portage/profiles/hardened/amd64/use.mask

Być może gdzieś glębiej w profilu są gdzieś zamaskowane, ale po to mam

Code: Select all

/etc/portage/profile/use.mask

- żeby się tym nie zajmować.
U mnie na profilu:

Code: Select all

 [8]   hardened/linux/x86/selinux *

wchodzą czysto.
Za to w hardened są zamaskowane nvidia i vdpau, trzeba je odmaskować w /etc/portage/profile/use.mask.

To by było na tyle

[SlashBeast]

Pewnie wystarczy uzyc paxctl i zdjac MPROTECT z libGL z nvidia-drivers.

[Jacekalex]

Pewnie wystarczy uzyc paxctl i zdjac MPROTECT z libGL z nvidia-drivers.

Próbowałem, u mnie żadne flagi paxa nie pomogły, za to pomógł sterownik 275.09.07.

Wcześniej wyjściem było pax-softmode.

Pozdrawiam

[Pryka]

Dzięki za rady panowie odmaskowałem to co trzeba w

Code: Select all

/etc/portage/profile/use.mask 
/etc/portage/profile/make.defaults

i zainstalowałem najnowsze stery nvidi

Pax soft mode jest wyłączone, ale nie startuje mi tak Firefox-5.0, wywala to:

Code: Select all

###!!! ABORT: JS_NewRuntime failed.: file /var/tmp/portage/www-client/firefox-5.0/work/mozilla-release/js/src/xpconnect/src/xpcjsruntime.cpp, line 1359
###!!! ABORT: JS_NewRuntime failed.: file /var/tmp/portage/www-client/firefox-5.0/work/mozilla-release/js/src/xpconnect/src/xpcjsruntime.cpp, line 1359

Zdjąłem wszystko z Javy myśląc, że to coś pomoże:

Code: Select all

chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*

Ale dalej lipa tylko pax soft mnie ratuje


EDIT:
Po updacie przeszło nie wiem czemu

[Jacekalex]

Code: Select all

zgrep -i pax /proc/config.gz 
# PaX
CONFIG_PAX_ENABLE_PAE=y
CONFIG_PAX=y
# PaX Control
CONFIG_PAX_SOFTMODE=y
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
# CONFIG_PAX_NOEXEC is not set
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_UDEREF=y
CONFIG_PAX_REFCOUNT=y
# CONFIG_PAX_USERCOPY is not set

Code: Select all

grep -i pax /etc/sysctl.conf 
kernel.pax.softmode=0

Code: Select all

qlist -IvUqC firefox
www-client/firefox-5.0-r1 alsa bindist custom-optimization dbus hardened ipc linguas_en linguas_pl webm

Pisze wlaśnie z firefoxa

Code: Select all

glxinfo | grep -i nvidia
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation
OpenGL version string: 3.3.0 NVIDIA 275.09.07
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

Nvidia, jak widać, chodzi.

SOA #1

[Pryka]

Firefox działa jak już mówiłem za to padła znowu nVidia ze swoim libGL.so.1 na:

Code: Select all

Available kernel symlink targets:
  [1]   linux-2.6.39-hardened-r3
  [2]   linux-2.6.39-hardened-r4 *

config PaX ma taki sam jak Twój prócz opcji CONFIG_PAX_ENABLE_PAE=y w ogóle tego u siebie nie widzę.

[Jacekalex]

.....
config PaX ma taki sam jak Twój prócz opcji CONFIG_PAX_ENABLE_PAE=y w ogóle tego u siebie nie widzę.

PAE jest w systemie 32 bitowym, w 64 bitowym go nie ma, dlatego w Paxie tej opcji też nie ma.

Ja parę dni temu kompilowałem 2.6.39.2 z testową łatą grsec i nvidia chodzi dobrze.
Z hardened-sources miałem kiedyś trochę kłopotów, teraz jedno spróbuję, żeby zobaczyć, jak rozwiązali ten profil virtualizacji, bo na moim konfigu Virtualbox ani myśli ruszyć.

Ja mam system x86.

Code: Select all

uname -a
Linux box 2.6.39.2-gr2 #5 SMP PREEMPT Tue Jun 28 13:46:32 CEST 2011 i686...

Pozdrawiam

[Pryka]

Rekompilowałem kernel i sterowniki nvidia i poszło nie mam pojęcia jak.

Mam do Ciebie takie pytanie, czy ten konfig który dawałeś do grsecurity na dug jest jeszcze aktualny?

Jeśli nie to czy możesz dać wynik:

Code: Select all

grep -i grker /usr/src/linux/.config

albo jak wolisz

Code: Select all

zgrep -i grker /proc/config.gz 

ps. mam już za sobą przebudowę systemu na gcc hardened jedyny problem jaki dalej mam to niemożność zbudowania nowszej wersji nspluginwrapper

Code: Select all

Iluvatar pryka # 
 [1] x86_64-pc-linux-gnu-4.5.2 *
 [2] x86_64-pc-linux-gnu-4.5.2-hardenednopie
 [3] x86_64-pc-linux-gnu-4.5.2-hardenednopiessp
 [4] x86_64-pc-linux-gnu-4.5.2-hardenednossp
 [5] x86_64-pc-linux-gnu-4.5.2-vanilla

Nie spotkałem problemów o których pisałeś na 4.5.2

[Jacekalex]

Mniej więcej podobny:

Code: Select all

zgrep -i grker /proc/config.gz 
CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MEDIUM is not set
# CONFIG_GRKERNSEC_HIGH is not set
CONFIG_GRKERNSEC_CUSTOM=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_VM86=y
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_MODHARDEN=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_KERN_LOCKOUT=y
# CONFIG_GRKERNSEC_NO_RBAC is not set
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=100
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_SYSFS_RESTRICT=y
CONFIG_GRKERNSEC_ROFS=y
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_AUDIT_GROUP=y
CONFIG_GRKERNSEC_AUDIT_GID=907
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_PTRACE=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
CONFIG_GRKERNSEC_TPE_INVERT=y
CONFIG_GRKERNSEC_TPE_GID=100
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_BLACKHOLE=y
CONFIG_GRKERNSEC_SOCKET=y
CONFIG_GRKERNSEC_SOCKET_ALL=y
CONFIG_GRKERNSEC_SOCKET_ALL_GID=901
CONFIG_GRKERNSEC_SOCKET_CLIENT=y
CONFIG_GRKERNSEC_SOCKET_CLIENT_GID=902
CONFIG_GRKERNSEC_SOCKET_SERVER=y
CONFIG_GRKERNSEC_SOCKET_SERVER_GID=903
CONFIG_GRKERNSEC_SYSCTL=y
CONFIG_GRKERNSEC_SYSCTL_ON=y
CONFIG_GRKERNSEC_FLOODTIME=5
CONFIG_GRKERNSEC_FLOODBURST=10

i sysctl:

Code: Select all

sysctl -a | grep grsec
kernel.grsecurity.linking_restrictions = 1
kernel.grsecurity.fifo_restrictions = 1
kernel.grsecurity.execve_limiting = 1
kernel.grsecurity.ip_blackhole = 1
kernel.grsecurity.lastack_retries = 4
kernel.grsecurity.exec_logging = 0
kernel.grsecurity.signal_logging = 0
kernel.grsecurity.forkfail_logging = 0
kernel.grsecurity.timechange_logging = 0
kernel.grsecurity.chroot_deny_shmat = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_execlog = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = 100
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.tpe_restrict_all = 0
kernel.grsecurity.socket_all = 1
kernel.grsecurity.socket_all_gid = 901
kernel.grsecurity.socket_client = 1
kernel.grsecurity.socket_client_gid = 902
kernel.grsecurity.socket_server = 1
kernel.grsecurity.socket_server_gid = 903
kernel.grsecurity.audit_group = 1
kernel.grsecurity.audit_gid = 100
kernel.grsecurity.audit_chdir = 0
kernel.grsecurity.audit_mount = 0
kernel.grsecurity.dmesg = 1
kernel.grsecurity.chroot_findtask = 1
kernel.grsecurity.resource_logging = 0
kernel.grsecurity.audit_ptrace = 1
kernel.grsecurity.harden_ptrace = 1
kernel.grsecurity.grsec_lock = 0
kernel.grsecurity.romount_protect = 0

To by było na tyle

[Pryka]

Mam pytanie, czemu na hardened-r3 + CONFIG_PAX_NOEXEC + nvidia-drivers-275.09.07 + paxsoftmode=0 system działał sprawnie bez: libGL.so.1: failed to map segment from shared object: Operation not permitted

A teraz taki na jajku hardened-r4 taki sam konfig już nie przechodzi, system przy starcie od razu wywala problem z libGL.so.1 a samo paxsoftmode=1 nic nie daje, dodatkowo musiałem wyłączyć całkowicie CONFIG_PAX_NOEXEC dopiero wtedy znika problem z tą biblioteką.

Tam są ciągle aż takie zawirowania w nowych wersjach czy jak coś pochrzaniłem?

EDIT:
O widzę, że pokazało się r5, spróbuję włączyć NOEXEC dam znać co z tego wyjdzie.

EDIT:
r5 postawiony i z NOEXEC nie dopuściło GDM'a a dokładniej chyba CONFIG_PAX_MPROTECT_COMPAT go posadził, niechciało mi się bawić i wyłączać poszczególnych opcji nie wiem jak by było dalej.

Code: Select all

Jul  6 18:08:44 Iluvatar kernel: [   21.731410] grsec: denied RWX mprotect of /lib64/ld-2.13.so by /usr/sbin/gdm-binary
Jul  6 18:08:44 Iluvatar kernel: [   21.731434] grsec: Segmentation fault occurred at 00000369ea28b3e1 in /usr/sbin/gdm-binary
Jul  6 18:08:44 Iluvatar kernel: [   21.731446] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/sbin/gdm-binary

Może zdjęcie mprotect by pomogło, nie wiem.


FINAL EDIT!!!
Niewytrzymałem, sprawdziłem jeszcze raz z NOEXEC, zdjąłem mprotect z gdm, ale nic nie dało, więc zainteresowałem się tym /lib64/ld-2.13.so, niestety jego się nie dało ruszyć bo był w użyciu, ubiłem wszystko co korzystało z tego pliku za pomocą fuse ale przy okazji wywalało mnie z konta a gdy się logowałem plik znowu był w użyciu i powstało błędne koło, nie chciało mi się chrootować i sobie odpuściłem... a przynajmniej na razie

Swoją drogą czy bez CONFIG_PAX_NOEXEC te wszystkie flagi PaX'a którymi można oznaczać, w ogóle działają? mprotect etc? Czy po prostu są aby być?


ps. Na cholerę jest plik /var/log/pax.log? Logował mi przez dwa dni ubijanie nspluginwrappera i na tym się skończyło, nic tam nie ma od tamtej pory.

[Jacekalex]

Pliku pax.log nie widziałem na oczy, u mnie zazwyczaj loguje w /var/log/messages, noexec na desktopie nie używam, za duży bajzel robi, i to zwłaszcza z Xorgiem i multimediami.

Poza tym mam moolighta, skype, conieco na wine, a noexec bardzo "lubi się" z tymi programami.

Jakbym stawiał serwer, na nim Nginxa, Php, Mysql, Ftp i Ssh, i wszystko skopilował na miejscu, to noexec bym właczył, tak samo jak:
CONFIG_GRKERNSEC_IO i CONFIG_PAX_USERCOPY.

Ale desktop z grafiką 3D i dźwiękiem, to nie serwer internetowy ani router.
Poza tym aż tak kombinować, to mi sie już nie chce
Flagi działają, przynajmniej te:

Code: Select all

paxctl -v /usr/lib/firefox/firefox-bin
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu>

- PaX flags: P-S-M--xE-R- [/usr/lib/firefox/firefox-bin]
	PAGEEXEC is enabled
	SEGMEXEC is enabled
	MPROTECT is enabled
	RANDEXEC is disabled
	EMUTRAMP is enabled
	RANDMMAP is enabled

Nie daje się tylko ustawić RANDEXEC.
Po za tym grsecurity trzymam nie ze strachu przed mrówkami, ale po to, żeby poznać trochę zabezpieczenia, w szczególności GRACL - z grsecurity.
Teraz przymierzam sie do wzbogacnia obecnej konfiguracji o selinuxa, ale mam z tym trochę kłopotów.

Pamiętaj też, że stabilna łata grseurity jest obecnie na jajo z serii 2.6.32.*, a powyżej są tylko łaty testowe, na tych łatach testowych powstaje też hardend-sources.
A łaty testowe miewają czasami różne błędy.

Pozdrawiam

[Pryka]

Wiesz był jeszcze czas kiedy sam usilnie próbowałeś uruchomić wszystko na kompie razem z EXEC pamiętam Twojego posta


Co do logów to ja mam całą rodzinkę w /var/log od grsec.log po kern.log

Co do Ciebie to pewnie nie masz tego ze względu na to, że w sysctrl masz wyłączone wszystko co jest związane z logami.

[Jacekalex]

Mam wyłączone, bo wszystko działa, jak zaczynają się jakieś cyrki, to maszynka do logowania idzie w ruch .
A wszystkie logi lądują u mnie zawsze w /var/log/massages - na testowej łacie + vanilla-sources.
Nie wyczaiłem, jak zmusić grsec do pax.log i grsec.log.

Tylko, że poza Virtualboxem, jakoś żadnych cyrków nie widzę, a mój okulista twierdzi, że jeszcze całkiem nie oślepłem

Za to działa Ci uvesa? bo widziałem w tym wątku, że conieco działałeś w tym zakresie, i sam Brad Spender po twojej interwencji conieco poprawił w łacie.

U mnie decor chodzi na Vesie, także się Uvesą specjalnie nie przejmowalem.
A noexec co jakiś czas włączam, i patrze , co dziala, a co nie, ostatnio nie wstawał w ogóle Xorg, i to na żadnym sterowniku, (jajo 2.6.38.2).

Wcześniej raz odpalilem Xorga z noexec (jajo 2.6.36-hardened-r8 ), ale Skypa i Flasha diabli wzięli.

Także na desktopie noexec na razie nie używam, jednak jeśli kiedyś go włączę, i w miarę sprawnie, wszystkie najważniejsze rzeczy będą działać, to noexec zostanie na swoim miejscu.

To by było na tyle

[Pryka]

Faktycznie pisałem na ich forum o pewnym problemie, na początku podał mi obejście które też działało potem wszystko trafiło do patcha i powiem Ci, że uvesa śmiga jak na razie bez problemu(1680x1050), niestety bez splashutils grupa Hardened-Gentoo przerobiła patch fbcondecor tak, że nie ma w nim kluczowej opcji, mianowicie wywalili/ukryli "[*] Support for the Framebuffer Console Decorations"[/b] bez której raczej się nie da tego odpalić. Ale spróbuję to obejść, może coś zdziałam... o ile uruchomię splashutils bo najnowsza wersja nie kompiluje się na hardened, to samo z nspluginwrapper, w obu przypadkach zgłoszone są bugi.

[SlashBeast]

Nie wyczaiłem, jak zmusić grsec do pax.log i grsec.log.

Od tego masz logger.

Ja sobie dodalem do metaloga konfig na grseca.

Code: Select all

Grsecurity :
	facility	= "kern"
	regex		= "grsec"
	logdir		= "/var/log/grsec"
	postrotate_cmd = "/root/bin/metalog-compress.sh"
	break		= 1

[Jacekalex]

Dzięki spróbuję, tylko muszę to przerobić do rsysloga, albo go zmienić na metaloga (w sumie niezły pomysł).

@Pryka
Co do fbcondecora i hardened, to ja mam grsecurity, fbcondecor i vanilla-sources, i wsio działa na Vesie.
Na Uvesie dopiero zobaczę.

W hardened-sources, Developerzy wprowadzają swoje zmiany w grsecurity, dodają profile konfiguracji desktop, server, wirtualizacja, więc być może działają na starszej łacie, w której grsec wyłącza uvesę, a do tego fbdecor być może nie można zaznaczyć bez uvesy.

Co jest o tyle dziwne, że wcale mu uvesa nie jest do szczęścia potrzebna.
Ale generalnie radzę vanilla-sources i własne łatanie, grsecurity forums to trochę skuteczniejszy support, niż bugzilla.
W przypadku hardened-sources, ciężko z niego wydumać, który numer łaty grsec tam włożyli, i trochę trudniej potem sprawę na forum wyłożyć.

Pozdro

[Pryka]

@Jacekalex ja trzymam uvesę i czekam na tego splasha może coś wymodzę, chociaż Tobie z tego co wiem na vesie też działał, ale jak już postawiłem to uvesę to niech stoi

A co do łatek to przy instalowaniu źródeł jądra jak patch jest nanoszony to jego widać numerek jest, ewentualnie potem można to wyciągnąć z logów, no i w distfiles masz paczkę z tymi łatami, można przeczytać

A ja się dalej zastanawiam, czemu pax.log zdechł, a wracając jeszcze do tego, że nie masz tych plików z logami, całkiem możliwe że patche dodane do hardened coś tam majstrują jeszcze, bo poza samym grsecurity jest ich sporo. Przeglądałem je wyrywkowo i nic tam takiego nie widzę, ich nazwy też mówią co innego ale kto wie.

[Jacekalex]

primo:
2 posty wyżej @Slashbeast napisał, jak skonfigurować metaloga, żeby logi lądowały tam, gdzie trzeba.

Mnie do tej pory nie zawadzało lądowanie logów w messages, bo mam taki tajemniczy program, jak grep, i on sobe też z tym problemem radził całkiem znośnie.

A jak jakiś program sie sypie czy wyłącza, to jeśli to coś ważnego, to najpierw zapuszczam strace i gdb, żeby zobaczyć, co jest grane.

Pozdrawiam