🚀 go-pugleaf

> > Znacznie bezpieczniej kontrolowac to z poziomu bibliotek, np.
> > uzywajac http://zim.iq.pl/moje/code/libzlimits.c
> 
> Czemu uważasz, że w ten sposób jest bezpieczniej?
> Twardy limit ustawiony przez pam_limits jest mniej bezpieczny?

Przeciez nie wszystko uzywa PAMa.

> Jeśli użytkownik użyje np. wywołania systemowego syscall(SYS_fork)
> zamiast bezpośrednio fork(), to funkcja opakowująca z libzlimits już go
> nie będzie dotyczyć, więc to daje taki sam poziom bezpieczeństwa.

Tyle ze ten user przed wywolaniem sys_fork juz bedzie mial narzucone
ograniczenia, o tym zdaje sie zapominasz.

> Niedawno zastanawiałem się nad tym, że wymuszenie ładowania jakieś
> biblioteki przez ld.so(8) z własnymi wersjami różnych funkcji daje
> możliwość stworzenia dla użytkowników zupełnej iluzji w bardzo fajny
> i elastyczny sposób, bez schodzenia na poziom jądra.
> Ale to chyba niestety jest dość mało bezpieczne, bo użytkownik może
> w różny sposób kombinować, by to obejść. Może uruchomi statycznie
> zlinkowane programy, może zmieni LD_PRELOAD i załaduje swoją bibliotekę,
> która uniemożliwi odczytanie ld.so.preload, albo użyje bezpośrednio
> przerwania 0x80 itp.
> Wątpię, czy da się zrobić coś takiego bezpiecznie z poziomu bibliotek.

Oczywiscie - kombinowac moze, ale to samo dotyczy PAMow czy ulimit,
a o tym zdaje sie byla mowa?
ulimity mozna w banalny sposob ominac, np. bash --norc, PAMy nie sa
wykorzystywane przez wszystkie demony, a rozwiazanie typu setrlimit()
z poziomu bibliotek *utrudnia* w znaczny sposob dokonanie przeciazenia
systemu.
Przeciez nigdzie nie napisalem ze ta biblioteka jest doskonala...

-- 
..... Robert Jaroszuk - zim iq pl - [ IQ PL Sp. z o.o. ] .....
GCS/IT/O d? s: a-- C++ ULB++++$ P+ L++++$ E--- W- K- N+ DI+ V-
w M- PS+ PE Y(+) PGP-(+++) t-- 5? X- R tv-- b++>++++ D- y+ G++
.. http://zim.iq.pl/ . RJ735-RIPE . http://zim.iq.pl/photo/ ..
... The superior warrior wins without fighting -- Sun Tzu. ...
-- 
Archiwum grupy: http://niusy.onet.pl/pl.comp.security