🚀 go-pugleaf

> Chce udostepnic znajomemu konto shelowe z dostepem tylko do paru polecen.
> Czy da sie zabiezpieczyc konto zeby user nie chodzil po innych katalogach i
> nie uruchamial innyc programow?
> Oczywiscie z pewnych wzgledow odpada zmiana uprawnien na wszytskich plikach
> ;)
> shell to sh lub bash lub csh - praktycznie obojetnie  - oby latwo dalo to
> sie zrobic.

mozesz sprobowac napisac regolki do cerba.


-- 
        Pawel Rutkowski                   Centauri RSC
        +48 22 847 68 52                http://www.rsc.pl

Hi!

Najprosciej i najskuteczniej bedzie odpalic shella w trybie restricted mode
(niestety sposob ten nie jest POSIX compatibile , ale dziala z BASHem -
sprawdzone:).
Kopiujesz i zmieniasz nazwe (linkujesz, robisz jak chcesz) shella
zgloszeniowego dodajac literke r na poczatku, np. rsh i zmieniasz stosownie
wpis w pliku hasel (/etc/passwd) uzytkownikow. User po zalogowaniu nie
bedzie mogl m.in.:

zmieniac katalogu (cd) - bardzo istotne :),
podac sciezki do odpalenia jakiejs komendy,
przekierowywac wyjscie > , >>,
zmieniac zmiennych srodowiskowych m.in. PATH, SHELL,
odpalac programow poprzez exec.

To chyba tyle ;)

Pozdrawiam,
Grzegorz Stanczyk aka gRzEnIu


Użytkownik "rex" <robikus@op.pl> napisał w wiadomości
news:c4e8dv$1di$1@atlantis.news.tpi.pl...
> Witam,
>
> Chce udostepnic znajomemu konto shelowe z dostepem tylko do paru polecen.
> Czy da sie zabiezpieczyc konto zeby user nie chodzil po innych katalogach
i
> nie uruchamial innyc programow?
> Oczywiscie z pewnych wzgledow odpada zmiana uprawnien na wszytskich
plikach
> ;)
> shell to sh lub bash lub csh - praktycznie obojetnie  - oby latwo dalo to
> sie zrobic.
>
> Pozdrawiam
>
>

> Najprosciej i najskuteczniej bedzie odpalic shella w trybie restricted mode
> (niestety sposob ten nie jest POSIX compatibile , ale dziala z BASHem -
> sprawdzone:).
  ^^^^^^^^^^
> bedzie mogl m.in.:
>
> zmieniac katalogu (cd) - bardzo istotne :),
> podac sciezki do odpalenia jakiejs komendy,
> przekierowywac wyjscie > , >>,
> zmieniac zmiennych srodowiskowych m.in. PATH, SHELL,

AFAIR to ten mechanizm nie jest wcale bezpieczny.
na szybko zrobilem konto z bash -r. ftpem wrzucilem skrypt:
#!/usr/local/bin/bash
cd /
pwd
cd /etc
pwd
/sbin/ping -c 5 127.0.0.1

zrobilem chmod 755 a.sh ( z FTPa).

Wynik:
/
/etc/
/
/etc
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.052 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.059 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.060 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.075 ms

To byl chyba najprostszy sposob.

Inna metoda jest (chyba!!!) wrzucenie na konto skompilowanego programu
ktory odala shella bez restrykcji.

Cos pewnie jeszcze mozna zamotac z LD_PRELOAD.

 
PS. FUT -> pl.comp.os.bsd

-- 
        Pawel Rutkowski                   Centauri RSC
        +48 22 847 68 52                http://www.rsc.pl

Nie ma co wywazac otwartych drzwi. Jest patch na sshd ktory pozwala
chrootowac uzytkownika w konkretnym katalogu. To co skopiujesz mu do
uzytkowania bedzie mial i fajrant. Ja takich shelli uzywam jakos scp.

pozdrawiam
kadzbi

Użytkownik "rex" <robikus@op.pl> napisał w wiadomości
news:c4e8dv$1di$1@atlantis.news.tpi.pl...
> Witam,
>
> Chce udostepnic znajomemu konto shelowe z dostepem tylko do paru polecen.
> Czy da sie zabiezpieczyc konto zeby user nie chodzil po innych katalogach
i
> nie uruchamial innyc programow?
> Oczywiscie z pewnych wzgledow odpada zmiana uprawnien na wszytskich
plikach
> ;)
> shell to sh lub bash lub csh - praktycznie obojetnie  - oby latwo dalo to
> sie zrobic.
>
> Pozdrawiam
>
>

Kadzbi <kac@ksieze.one.pl> wrote:
> Nie ma co wywazac otwartych drzwi. Jest patch na sshd ktory pozwala
> chrootowac uzytkownika w konkretnym katalogu. To co skopiujesz mu do
> uzytkowania bedzie mial i fajrant. Ja takich shelli uzywam jakos scp.

Zamiast patchować sshd, lepiej chyba będzie użyć pam_chroot(8).

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

On Wed, 31 Mar 2004 11:22:58 +0000 (UTC), Pawel Rutkowski wrote:

> mozesz sprobowac napisac regolki do cerba.

fatalne jest, że cerb stoi w rozwoju, może już sięnie wiesza tak jak
kiedyś, ale np. po kilku razach załadowania/rozładowania pojawia się błąd
"device busy", i jedynym sposobem jaki znam na rozwiązanie tego jest
restart systemu, co nie jest miłym dla użytkowników. :(

-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*

>> mozesz sprobowac napisac regolki do cerba.
> fatalne jest, że cerb stoi w rozwoju, może już sięnie wiesza tak jak
> kiedyś, ale np. po kilku razach załadowania/rozładowania pojawia się błąd
> "device busy", i jedynym sposobem jaki znam na rozwiązanie tego jest
> restart systemu, co nie jest miłym dla użytkowników. :(

Zglaszales to do PJD ? Dorzuciles jakies dump, gdb itd ? 
U mnie taki problem sie nie pojawia. 

-- 
        Pawel Rutkowski                   Centauri RSC
        +48 22 847 68 52                http://www.rsc.pl

Dariusz Kuliński / TaKeDa <dp4declo02@nsonsepaakmemail.com> wrote:
> On Wed, 31 Mar 2004 11:22:58 +0000 (UTC), Pawel Rutkowski wrote:
> 
> > mozesz sprobowac napisac regolki do cerba.
> 
> fatalne jest, że cerb stoi w rozwoju, może już sięnie wiesza tak jak
> kiedyś, ale np. po kilku razach załadowania/rozładowania pojawia się błąd
> "device busy", i jedynym sposobem jaki znam na rozwiązanie tego jest
> restart systemu, co nie jest miłym dla użytkowników. :(

Generalnie to zabezpieczenia takie jak cerb powinny być ładowane z
/boot/loader.conf'a i nigdy nie odładowywane:) Co nie zmienia faktu,
że sytauacja, którą obserwujesz jest błędna.
Musisz sobie również zdawać sprawę, że nie będziesz w stanie odładować
cerba gdy przychwyciłeś syscalla kldunload(2), ponieważ zasada działania
jest taka:

<wejście do kernela>
	<operacje cerba>
		<wykonanie oryginalnego syscalla>
	<operacje cerba>
<wyjście do userlandu>

Jeśli odładujesz cerba w trakcie wykonywania syscalla, nie było by gdzie
wrócić, i Page Fault. Cerb się jednak przed tym broni, aczkolwiek nie
wiem czy problem, który obserwujesz jest z tym związany.

Co do przyszłości cerba.

Nie sądzę, że będę rozwijał jego wersję na FreeBSD 4.x - nie mam środowiska
do tego. Zostały mi może z dwie maszyny na 4.x, ale produkcyjne.
Bardzo chciałbym przenieść cerba na FreeBSD 5.x, ale tutaj jest trochę
nowych problemów i troche starych problemów, które chciałbym rozwiązać
w sposób kompletny i ładny.

Nowe problemy to np. wątki kernelowe - ciężko jest manipulować uprawnieniami
samego wątku by nie dotykać uprawnień całego procesu i nie dopuścić do
wyścigu. Można używać skeszkowanych uprawnień w polu td_ucred, ale nie były
przewidziane do takich zadań, tylko by uniknąć lockowania procesu. Jest to
jednak jakaś droga.

Ze starych problemów można wymienić wyścig z argumentami syscalla.
Polega to na tym, że proces wywołująć syscalla, np. open() przekazuje do
niego adres na string z nazwą pliku. Wyścig może nastąpić, gdy cerb
sprawdzi ten argument, przekaże wykonanie do kernela i w tym czasie
drugi wątek tego procesu zmodyfikuje ten ciąg w pamięcie procesu.
Teraz cerb broni sie przed tym stosując metodę copy-on-read. Argument
jeśli ma byc sprawdzony, jest dla niego alokowana pamięć w pamięci
procesu, dane są tam kopiowane, obszar pamięci zaznaczany jest jako
read-only po czy jeszcze raz sprawdzana jest integralność argumentu przez
porównanie wartości. Jeśli ok, to jest on użyty przez cerba i w syscallu
zmieniany jest adres danych w argumencie syscalla, tak, by syscall
również pobrał argument z pamięci read-only.
Nie rozwiąznym problemem są tutaj argumenty read-write, czyli takie,
które przekazujemy do syscalla z jakąś wartością, a syscall zwraca nam
dane w tym samym miejscu. Nie ma natomiast takich syscalli wiele lub
jeśli są to ich dane nie bardzo nadają się do sprawdzenia. Mogę się
jednak tutaj mylić.
Anyway, tego typu race condidtion istniał, np. w systrace'ie i istnieje
w wielu tego typu wrapperach.
Najlepszym wyjście z tej sytuacji było by lockowanie w odpowiedni
sposób pamięcie procesu, gdzie są newralgiczne dane. Nie można jednak
zabraniać dostępu do tych danych innym wątkom.
Moim pomysłem jest lockowanie takiej pamięci w następujący sposób:
Zalockowana pamięć może być modyfikowane ciągle przez kernel, natomiast
jeśli spróbuje ją zmodyfikować userland, pamięć jest kopiowana i
dopiero modyfikowana w nowym obszarze. Co się stanie jeśli kernel
zwolni blokadę? Możliwości są 4:
1. Zablokowana pamięć nie była modyfikowana ani przez kernel ani przez
   userland.
2. Zablokowana pamięć była modyfikowana przez kernel.
3. Zablokowana pamięć była modyfikowana przez userland.
4. Zablokowana pamięć była modyfikowana i przez kernel, i przez userland.
Oprócz zwolnienia blokady dzieje się:
1. Nic.
2. Nic.
3. Usuwana jest wersja kernelowa tej pamięci i zostaje wersja userlandowa.
4. Usuwana jest wersja userlandowa, a wersja kernelowa tego obszaru pamięci
   staje się wersją obowiązującą.
Z uwagi na fakt, że punkty 3 i 4 praktycznie nie powinny wystepować,
poza bezpiecznym operowaniem na argumentach, nie musimy kopiować danych,
co powinno sporo przyspieszyć część syscalli. Teraz kernel najpierw
kopiuje dane z userlandu do pamięci jądra i dopiero je interpretuje.

Kolejnym mozliwością wyścigu, z którą musimy sobie radzić są modyfikacje
namespace file systemu.
Przykładowo process wywołuje syscalla open("/tmp/foo/bar"), gdzie
"foo" lub "bar" są linkami symbolicznymi. I teraz cerb moze sprawdzić
taki plik, przekazać kontrolę do syscalla, ale przed tym inny proces
zmodyfikuje ten link symboliczny. Cerb broni sie przed tym w regułach,
wykonując arg[0] = realpath(arg[0]) przed przekazaniem działania do
syscalla.

Inną mozliwością wyścigu, są modyfikacje deskryptorów.
Proces wywołuje syscalla, np. fchmod(5, ...), gdzie 5 jest deskryptorem
do otwartego pliku "/tmp/foo", który proces ma prawo modyfikować.
Natomiast znowu przed przekazaniem działania do syscalla, inny wątek
w procesie może zamknąć ten deskryptor i otworzyć inny plik.
Cerb radzi sobie z tym przy użyciu mechanizmu fdguard. Wszelkie
deskryptory, które są używane przez kernel (w tym przypadku
deskryptor 5) lądują na specjalnej liście. Gdy proces próbuje wywołać
syscalla close(2) lub dup2(2) na używanym deskryptorze, cerb to
wykryje i na to nie pozwoli.

Inny problem (uciążliwy nie tylko dla cerba) jest nasz VFS.
Nie ma teoretycznie możliwość znalezienia nazwy pliku mając deskryptor,
ponieważ vnode'a plikowy nie może zagwarantować jednoznaczności,
ponieważ plik może mieć wiele dowiązań (hard linków). Praktycznie
można próbować wyciągać nazwę pliku z cache'u, ale to bardzo zawodny
mechanizm. Dlatego cerb zapamiętuje nazwy otwieranych plików i operuje
na nich. Na przykład w Darwinie jest obsługiwane w vnodzie pole
wskazujące na katalog, w którym znajduje się plik (lub inny file
systemowy obiekt) co pozwala na uzyskanie nazwy pliku w każdej chwili.
Zarządzenie takim pointerem jednak wprowadza inne komplikacje.

Nie do ukrycia problemem jest też spory narzut na wydajność.

Skoro już się tak rozpisałem to może kilka słów o Mandatory Access Control
we FreeBSD 5.x. Tam Rebert Watson radzi sobie znakomicie z takimi
problememi (co w przypadku cerba nie było by możliwe, ze względu na to,
że jest modułem do jądra). Wszelkie obiekty przekazywane do odpowiednich
policy, są juz odpowiednio zalockowane, więc mozliwości wyścigu nie ma.
Czyli np. plik nie jest przekazywany po nazwie, tylko znajdowany lub
tworzony jest jego vnode'a, odpowiednio lockowany i dopiero przekazywany do
sprawdzenia. Nie ma oczywiście wtedy możliwości operowania na nazwach
plików, no ale cos za coś.

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

On Thu, 1 Apr 2004 08:42:50 +0000 (UTC), Pawel Jakub Dawidek wrote:

>>> mozesz sprobowac napisac regolki do cerba.
>> fatalne jest, że cerb stoi w rozwoju, może już sięnie wiesza tak jak
>> kiedyś, ale np. po kilku razach załadowania/rozładowania pojawia się błąd
>> "device busy", i jedynym sposobem jaki znam na rozwiązanie tego jest
>> restart systemu, co nie jest miłym dla użytkowników. :(
> Generalnie to zabezpieczenia takie jak cerb powinny być ładowane z
> /boot/loader.conf'a i nigdy nie odładowywane:) Co nie zmienia faktu,
> że sytauacja, którą obserwujesz jest błędna.

No wiem, tyle ze to jest naprawde uciazliwe, ja mam serwer niby
produkcyjny, tzn. maszyna domowa, ale jako ze pracuje jako router z
internetu nie tylko ja korzystam dodatkowo mam kilka uslug, to naprawde nie
fajne jest kiedy trzeba czesto restartowac, a jak sie pracuje nad nowymi
regolkami to taka sytuacja to b. czesto jest. Wystarczajaca aby zniechecic
do uzywania.

> Musisz sobie również zdawać sprawę, że nie będziesz w stanie odładować
> cerba gdy przychwyciłeś syscalla kldunload(2), ponieważ zasada działania
> jest taka:
> 
> <wejście do kernela>
> 	<operacje cerba>
> 		<wykonanie oryginalnego syscalla>
> 	<operacje cerba>
> <wyjście do userlandu>
> 
> Jeśli odładujesz cerba w trakcie wykonywania syscalla, nie było by gdzie
> wrócić, i Page Fault. Cerb się jednak przed tym broni, aczkolwiek nie
> wiem czy problem, który obserwujesz jest z tym związany.

Przypuszczam ze niedawno (pojecie wzgledne :) wprowadziles to
zabezpieczenie i od tego czasu zaczely sie moje problemy, w jakiejs
sytuacji cerb najwidoczniej nie odejmuje licznika (wydaje mi sie ze to jest
zwiazane z ladowaniem/rozladowywaniem regolek, bo wlasnie po takich
operacjach to mi sie dzialo (innymi slowy chcialem poprawic jakas regolke i
troche reloadowania bylo)

> Co do przyszłości cerba.
> 
> Nie sądzę, że będę rozwijał jego wersję na FreeBSD 4.x - nie mam środowiska
> do tego. Zostały mi może z dwie maszyny na 4.x, ale produkcyjne.
> Bardzo chciałbym przenieść cerba na FreeBSD 5.x, ale tutaj jest trochę
> nowych problemów i troche starych problemów, które chciałbym rozwiązać
> w sposób kompletny i ładny.

Aktualnie skoro stabilne 5.x jest juz blisko, moze faktycznie warto dac
sobie spokoj z 4.x.

Jeszcze jedna uwaga, co do dzialania cerbera, nie wiem czy sobie po prostu
nie komplikujesz sprawy, tym calym pseudojezykiem i wszystkimi poleceniami
w nim, wiem ze to daje wieksze mozliwosci, ale czy jest tak naprawde
potrzebne?

Czy nie uprosciloby sprawy to zeby np to zeby po prostu zamiast programu w
pseudo jezyku byl tylko spis regolek dla kazdego programu. Np ze moze
czytac te i te pliki do tych i tych moze zapisywac. Otworzyc tylko takie
sockety itp. Nie ulatwilo by to sprawe zarowno dla programisty jak i
uzytkownika?

Aktualnie, w sumie w tym metliku (wiem starasz sie aby regolki byly
przejzyste, ale jednak do konca nie sa) zauwazylem (no tak, watson ze mnie
;) ze to jest jedna wielka regolka, tzn. jezeli da sie return w zlym
miejscu to mozna przy okazji zepsuc cos innego.
Nie wiem czy to kolejny bug w cerbie, ale wkurzylem sie troche na
openssh.cb dlatego ze przy poleceniu w, pokazuje tylko userow w grupie
wheel, pewnei brakuje dostepu do jakiegos pliku, dodatkowo przy last nie
uwzglednia wylogowan sie userow, tzn pokazuje ze sie zalogowali, ale juz
nie widac kiedy sie rozlaczyli, system pokazuje ze nadal sa.
Odladowalem openssh.cb, po paru minutach userzy mi krzycza ze ident nie
dziala, w ruchu desperacji, proboje kldunload cerber.ko (a tu wczesniej
wspomniane "device busy"), wiec pozostaje reboot, robie reboot (moze ten
ident sie przy okazji naprawi) nadal to samo, ale tym razem udalo mi sie
rozladowac cerbera bez problemow (pewnie dlatego ze nie przeladowywalem
regolek). Ale co chcialem zaznaczyc to ze rozladowanie openssh.cb w teorii
nie powinno w zaden sposob miec wplyw na ident.cb, zreszta porownywalem
pliki i nie znalazlem nic podejzanego. Moze kolejny bug...

> Nowe problemy to np. wątki kernelowe - ciężko jest manipulować uprawnieniami
> samego wątku by nie dotykać uprawnień całego procesu i nie dopuścić do
> wyścigu. Można używać skeszkowanych uprawnień w polu td_ucred, ale nie były
> przewidziane do takich zadań, tylko by uniknąć lockowania procesu. Jest to
> jednak jakaś droga.
> 
> Ze starych problemów można wymienić wyścig z argumentami syscalla.
> Polega to na tym, że proces wywołująć syscalla, np. open() przekazuje do
> niego adres na string z nazwą pliku. Wyścig może nastąpić, gdy cerb
> sprawdzi ten argument, przekaże wykonanie do kernela i w tym czasie
> drugi wątek tego procesu zmodyfikuje ten ciąg w pamięcie procesu.
> Teraz cerb broni sie przed tym stosując metodę copy-on-read. Argument
> jeśli ma byc sprawdzony, jest dla niego alokowana pamięć w pamięci
> procesu, dane są tam kopiowane, obszar pamięci zaznaczany jest jako
> read-only po czy jeszcze raz sprawdzana jest integralność argumentu przez
> porównanie wartości. Jeśli ok, to jest on użyty przez cerba i w syscallu
> zmieniany jest adres danych w argumencie syscalla, tak, by syscall
> również pobrał argument z pamięci read-only.
> Nie rozwiąznym problemem są tutaj argumenty read-write, czyli takie,
> które przekazujemy do syscalla z jakąś wartością, a syscall zwraca nam
> dane w tym samym miejscu. Nie ma natomiast takich syscalli wiele lub
> jeśli są to ich dane nie bardzo nadają się do sprawdzenia. Mogę się
> jednak tutaj mylić.

Moze po prostu nie rozumiem dokladnie sytuacji (stroktory takie jak
tc_ucred to tylko moge sie domyslac od czego sa) ale czy nie robisz sobie
sztucznych problemow.
Czy naprawde bedzie taka sytuacja gdy dwa thready, beda uzywac ten sam
obszar pamieci, beda wtedy wykonowac _jednoczesnie_ dwa rozne syscalle na
tym jednym obszarze pamieci? Raczej taki program bez cerba moglby miec
nieprzewidziane wyniki.

No ale faktycznei race conditions sie zdazaja. W przypadku plikow probrem
rozwiazano poprzez tzw. locking, czy nie mozesz tego samego zaimplementowac
w cerbie? Nigdy nie programowalem na poziomie kernela, ale czy nie dalo by
sie po prostu czegos takiego zaimplementowac. Tzn zablokowac (w momencie
operacji) dany obszar pamieci, proces ktory bedzie chcial odczytac/zapisac
po prostu bedzie czekal az locking zostanie zdjete i zacznie robic swoje.
Jezeli freebsd tego nie ma, to moze patch na kernel? Wydaje mi sie ze takie
rozwiazanie byloby chyba najbardziej eleganckie, i rozwiazalo by inne
problemy.

> Anyway, tego typu race condidtion istniał, np. w systrace'ie i istnieje
> w wielu tego typu wrapperach.
> Najlepszym wyjście z tej sytuacji było by lockowanie w odpowiedni
> sposób pamięcie procesu, gdzie są newralgiczne dane. Nie można jednak
> zabraniać dostępu do tych danych innym wątkom.

hehe, ehh powinienem byl czytac caly post zanim zabieral sie na
odpowiadanie.

> Moim pomysłem jest lockowanie takiej pamięci w następujący sposób:
> Zalockowana pamięć może być modyfikowane ciągle przez kernel, natomiast
                                           ^^^^^^^^^^^^^^^^^^^
czy nie bedzie problemow z kernelowymi threadami ktore sa w 5.x?
5.x nie uzywam ale cos o tym wspomniales na poczatku postu.
 
> jeśli spróbuje ją zmodyfikować userland, pamięć jest kopiowana i
> dopiero modyfikowana w nowym obszarze. Co się stanie jeśli kernel
> zwolni blokadę? Możliwości są 4:
> 1. Zablokowana pamięć nie była modyfikowana ani przez kernel ani przez
>    userland.
> 2. Zablokowana pamięć była modyfikowana przez kernel.
> 3. Zablokowana pamięć była modyfikowana przez userland.
> 4. Zablokowana pamięć była modyfikowana i przez kernel, i przez userland.
> Oprócz zwolnienia blokady dzieje się:
> 1. Nic.
> 2. Nic.
> 3. Usuwana jest wersja kernelowa tej pamięci i zostaje wersja userlandowa.
> 4. Usuwana jest wersja userlandowa, a wersja kernelowa tego obszaru pamięci
>    staje się wersją obowiązującą.
> Z uwagi na fakt, że punkty 3 i 4 praktycznie nie powinny wystepować,
> poza bezpiecznym operowaniem na argumentach, nie musimy kopiować danych,
> co powinno sporo przyspieszyć część syscalli. Teraz kernel najpierw
> kopiuje dane z userlandu do pamięci jądra i dopiero je interpretuje.

a czy po prostu przystopowanie procesu w przypadku blokady, i odblokowanie
po zakonczeniu zmiany nie wyeliminowalo by punktow 3 i 4?
Jak dobrze rozumiem, ty planujesz po prostu na robieniu kopii z obu stron i
pozniej odpowiednim nanoszeniu zmian.
 
> Kolejnym mozliwością wyścigu, z którą musimy sobie radzić są modyfikacje
> namespace file systemu.
> Przykładowo process wywołuje syscalla open("/tmp/foo/bar"), gdzie
> "foo" lub "bar" są linkami symbolicznymi. I teraz cerb moze sprawdzić
> taki plik, przekazać kontrolę do syscalla, ale przed tym inny proces
> zmodyfikuje ten link symboliczny. Cerb broni sie przed tym w regułach,
> wykonując arg[0] = realpath(arg[0]) przed przekazaniem działania do
> syscalla.
> 
> Inną mozliwością wyścigu, są modyfikacje deskryptorów.
> Proces wywołuje syscalla, np. fchmod(5, ...), gdzie 5 jest deskryptorem
> do otwartego pliku "/tmp/foo", który proces ma prawo modyfikować.
> Natomiast znowu przed przekazaniem działania do syscalla, inny wątek
> w procesie może zamknąć ten deskryptor i otworzyć inny plik.
> Cerb radzi sobie z tym przy użyciu mechanizmu fdguard. Wszelkie
> deskryptory, które są używane przez kernel (w tym przypadku
> deskryptor 5) lądują na specjalnej liście. Gdy proces próbuje wywołać
> syscalla close(2) lub dup2(2) na używanym deskryptorze, cerb to
> wykryje i na to nie pozwoli.

tzn close zwroci blad, czy po prostu poczeka? Bo jak zwroci blad to raczej
nie jest zbyt dobre z punktu widzenia programu (jakos mam wrazenie ze
programy beda bardziej awaryjne)
 
> Inny problem (uciążliwy nie tylko dla cerba) jest nasz VFS.
> Nie ma teoretycznie możliwość znalezienia nazwy pliku mając deskryptor,
> ponieważ vnode'a plikowy nie może zagwarantować jednoznaczności,
> ponieważ plik może mieć wiele dowiązań (hard linków). Praktycznie
> można próbować wyciągać nazwę pliku z cache'u, ale to bardzo zawodny
> mechanizm. Dlatego cerb zapamiętuje nazwy otwieranych plików i operuje
> na nich. Na przykład w Darwinie jest obsługiwane w vnodzie pole
> wskazujące na katalog, w którym znajduje się plik (lub inny file
> systemowy obiekt) co pozwala na uzyskanie nazwy pliku w każdej chwili.
> Zarządzenie takim pointerem jednak wprowadza inne komplikacje.

nie wystarczy patch na kernel, ktory dodalby do filedeskryptorow miejsce na
przechowywanie nazwy pliku?

> Nie do ukrycia problemem jest też spory narzut na wydajność.

wydaje mi sie ze to zbedne kopiowanie oraz pseudojezyk (czy jest on w ogole
kompilowany) to duzy narzut.

> Skoro już się tak rozpisałem to może kilka słów o Mandatory Access Control
> we FreeBSD 5.x. Tam Rebert Watson radzi sobie znakomicie z takimi
> problememi (co w przypadku cerba nie było by możliwe, ze względu na to,
> że jest modułem do jądra). Wszelkie obiekty przekazywane do odpowiednich
> policy, są juz odpowiednio zalockowane, więc mozliwości wyścigu nie ma.
> Czyli np. plik nie jest przekazywany po nazwie, tylko znajdowany lub
> tworzony jest jego vnode'a, odpowiednio lockowany i dopiero przekazywany do
> sprawdzenia. Nie ma oczywiście wtedy możliwości operowania na nazwach
> plików, no ale cos za coś.

tzn co to jest dokladniej ten MAC, cos jak inny cerb?


-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*

On Thu, 1 Apr 2004 07:49:40 +0000 (UTC), Pawel Rutkowski wrote:

>>> mozesz sprobowac napisac regolki do cerba.
>> fatalne jest, że cerb stoi w rozwoju, może już sięnie wiesza tak jak
>> kiedyś, ale np. po kilku razach załadowania/rozładowania pojawia się błąd
>> "device busy", i jedynym sposobem jaki znam na rozwiązanie tego jest
>> restart systemu, co nie jest miłym dla użytkowników. :(
> 
> Zglaszales to do PJD ? Dorzuciles jakies dump, gdb itd ? 
> U mnie taki problem sie nie pojawia.

Raczej AFAIR wspominalem dawno temu na liscie ale bez echa,
wydawalo mi sie ze to byla wina ostatnich zmian.

-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*

Dariusz Kuliński / TaKeDa <dp4declo02@nsonsepaakmemail.com> wrote:
> No wiem, tyle ze to jest naprawde uciazliwe, ja mam serwer niby
> produkcyjny, tzn. maszyna domowa, ale jako ze pracuje jako router z
> internetu nie tylko ja korzystam dodatkowo mam kilka uslug, to naprawde nie
> fajne jest kiedy trzeba czesto restartowac, a jak sie pracuje nad nowymi
> regolkami to taka sytuacja to b. czesto jest. Wystarczajaca aby zniechecic
> do uzywania.

Wolisz kernel panic zamiast EBUSY?:)

> Jeszcze jedna uwaga, co do dzialania cerbera, nie wiem czy sobie po prostu
> nie komplikujesz sprawy, tym calym pseudojezykiem i wszystkimi poleceniami
> w nim, wiem ze to daje wieksze mozliwosci, ale czy jest tak naprawde
> potrzebne?
> 
> Czy nie uprosciloby sprawy to zeby np to zeby po prostu zamiast programu w
> pseudo jezyku byl tylko spis regolek dla kazdego programu. Np ze moze
> czytac te i te pliki do tych i tych moze zapisywac. Otworzyc tylko takie
> sockety itp. Nie ulatwilo by to sprawe zarowno dla programisty jak i
> uzytkownika?

No właśnie. Weź pod uwagę fakt, że cerb nie musi operować na konkretnych
procesach, tj. np. systrace. Jeśli zostałby zaimplementowany tak jak mówisz
nie mógłbys pisać reguł ogólnych, tj. "Zabroń wszystkim dostepu do pliku X",
albo "Pozwól na hardlinki tylko właścicielom plików".

> Aktualnie, w sumie w tym metliku (wiem starasz sie aby regolki byly
> przejzyste, ale jednak do konca nie sa) zauwazylem (no tak, watson ze mnie
> ;) ze to jest jedna wielka regolka, tzn. jezeli da sie return w zlym
> miejscu to mozna przy okazji zepsuc cos innego.

Tak, mam świadomośc, że reguły nie są najprostsze, ale to kosz możliwości
niestety.

> Nie wiem czy to kolejny bug w cerbie, ale wkurzylem sie troche na
> openssh.cb dlatego ze przy poleceniu w, pokazuje tylko userow w grupie
> wheel, pewnei brakuje dostepu do jakiegos pliku, dodatkowo przy last nie
> uwzglednia wylogowan sie userow, tzn pokazuje ze sie zalogowali, ale juz
> nie widac kiedy sie rozlaczyli, system pokazuje ze nadal sa.
> Odladowalem openssh.cb, po paru minutach userzy mi krzycza ze ident nie
> dziala, w ruchu desperacji, proboje kldunload cerber.ko (a tu wczesniej
> wspomniane "device busy"), wiec pozostaje reboot, robie reboot (moze ten
> ident sie przy okazji naprawi) nadal to samo, ale tym razem udalo mi sie
> rozladowac cerbera bez problemow (pewnie dlatego ze nie przeladowywalem
> regolek). Ale co chcialem zaznaczyc to ze rozladowanie openssh.cb w teorii
> nie powinno w zaden sposob miec wplyw na ident.cb, zreszta porownywalem
> pliki i nie znalazlem nic podejzanego. Moze kolejny bug...

Widzisz, z silnym narzedziem przychodzą ciężkie problemy.
Nie jest wcale łatwo pisać reguł w dowolnym tego typu systemie
zabezpieczającym, gdyz zawsze się może zdarzyć sytuacja, której przy
komponowaniu reguł nie przewidzisz (jakiś plik jest otwierany tylko
w wyjątkowych sytuacjach, itp.).

> Moze po prostu nie rozumiem dokladnie sytuacji (stroktory takie jak
> tc_ucred to tylko moge sie domyslac od czego sa) ale czy nie robisz sobie
s/tc_/td_/
> sztucznych problemow.
> Czy naprawde bedzie taka sytuacja gdy dwa thready, beda uzywac ten sam
> obszar pamieci, beda wtedy wykonowac _jednoczesnie_ dwa rozne syscalle na
> tym jednym obszarze pamieci? Raczej taki program bez cerba moglby miec
> nieprzewidziane wyniki.

Taka sytuacja w normalnym działaniu może nie wystapić, ale atakujący
może ja wykorzystać, by oszukać cerba. Robert Watson pomyślnie sploitował
tego typu wyścigi w innych syscallowych wrapperach.

> czy nie bedzie problemow z kernelowymi threadami ktore sa w 5.x?
> 5.x nie uzywam ale cos o tym wspomniales na poczatku postu.

Chodziło mi raczej o to, że teraz w kernelu process nie jest widziany
jako najmniejszy obiekt, teraz jest nim wątek, we FreeBSD 4.x wątki
były jedynie symulowane w usrlandzie, ale kernel o nich nic nie wiedział.
Natomiast teraz dwa (lub więcej) wątki jednego mogą wykonywać się
jednocześnie w przestrzeni jądra.

> > jeśli spróbuje ją zmodyfikować userland, pamięć jest kopiowana i
> > dopiero modyfikowana w nowym obszarze. Co się stanie jeśli kernel
> > zwolni blokadę? Możliwości są 4:
> > 1. Zablokowana pamięć nie była modyfikowana ani przez kernel ani przez
> >    userland.
> > 2. Zablokowana pamięć była modyfikowana przez kernel.
> > 3. Zablokowana pamięć była modyfikowana przez userland.
> > 4. Zablokowana pamięć była modyfikowana i przez kernel, i przez userland.
> > Oprócz zwolnienia blokady dzieje się:
> > 1. Nic.
> > 2. Nic.
> > 3. Usuwana jest wersja kernelowa tej pamięci i zostaje wersja userlandowa.
> > 4. Usuwana jest wersja userlandowa, a wersja kernelowa tego obszaru pamięci
> >    staje się wersją obowiązującą.
> > Z uwagi na fakt, że punkty 3 i 4 praktycznie nie powinny wystepować,
> > poza bezpiecznym operowaniem na argumentach, nie musimy kopiować danych,
> > co powinno sporo przyspieszyć część syscalli. Teraz kernel najpierw
> > kopiuje dane z userlandu do pamięci jądra i dopiero je interpretuje.
> 
> a czy po prostu przystopowanie procesu w przypadku blokady, i odblokowanie
> po zakonczeniu zmiany nie wyeliminowalo by punktow 3 i 4?
> Jak dobrze rozumiem, ty planujesz po prostu na robieniu kopii z obu stron i
> pozniej odpowiednim nanoszeniu zmian.

Dyskutowałem na ten temat swego czasu z kilkoma osobami i to jest raczej
niedopuszczalne, chociaż warto to jeszcze pobadać.

> > Inną mozliwością wyścigu, są modyfikacje deskryptorów.
> > Proces wywołuje syscalla, np. fchmod(5, ...), gdzie 5 jest deskryptorem
> > do otwartego pliku "/tmp/foo", który proces ma prawo modyfikować.
> > Natomiast znowu przed przekazaniem działania do syscalla, inny wątek
> > w procesie może zamknąć ten deskryptor i otworzyć inny plik.
> > Cerb radzi sobie z tym przy użyciu mechanizmu fdguard. Wszelkie
> > deskryptory, które są używane przez kernel (w tym przypadku
> > deskryptor 5) lądują na specjalnej liście. Gdy proces próbuje wywołać
> > syscalla close(2) lub dup2(2) na używanym deskryptorze, cerb to
> > wykryje i na to nie pozwoli.
> 
> tzn close zwroci blad, czy po prostu poczeka? Bo jak zwroci blad to raczej
> nie jest zbyt dobre z punktu widzenia programu (jakos mam wrazenie ze
> programy beda bardziej awaryjne)

Zwróci błąd. Generalnie zachowanie takie jest nie jest normalne,
także jeśli ktoś próbuje tak zrobić, to raczej cos kombinuje.
Natomiast rzeczywiście istnieje ryzyko namawiania programu do wycieków,
ponieważ niestety jest dużo stereotypów, które sa powszechnie sotosowane,
jak np. nie sprawdzanie co zwraca close(2). A to bardzo źle, ponieważ
może np. zwrócić EINTR. EINTR i problemy z nim zwiazane to w ogóle
odrębna bajka.

> > Inny problem (uciążliwy nie tylko dla cerba) jest nasz VFS.
> > Nie ma teoretycznie możliwość znalezienia nazwy pliku mając deskryptor,
> > ponieważ vnode'a plikowy nie może zagwarantować jednoznaczności,
> > ponieważ plik może mieć wiele dowiązań (hard linków). Praktycznie
> > można próbować wyciągać nazwę pliku z cache'u, ale to bardzo zawodny
> > mechanizm. Dlatego cerb zapamiętuje nazwy otwieranych plików i operuje
> > na nich. Na przykład w Darwinie jest obsługiwane w vnodzie pole
> > wskazujące na katalog, w którym znajduje się plik (lub inny file
> > systemowy obiekt) co pozwala na uzyskanie nazwy pliku w każdej chwili.
> > Zarządzenie takim pointerem jednak wprowadza inne komplikacje.
> 
> nie wystarczy patch na kernel, ktory dodalby do filedeskryptorow miejsce na
> przechowywanie nazwy pliku?

Wierzysz, że ktoś by się na to zgodził?:)
Generalnie daje to olbrzymi narzut na pamięć i straszne opóźnienia.
Przede wszystkim czy interesuje nas zmiana nazwy pliku?
Po drugie plik przed zapisaniem w takim buforze trzeba by potraktować
funkcją realpath() by uniknąć problemów ze zmianą namespace, o których
wspominałem wsześniej.

> > Nie do ukrycia problemem jest też spory narzut na wydajność.
> 
> wydaje mi sie ze to zbedne kopiowanie oraz pseudojezyk (czy jest on w ogole
> kompilowany) to duzy narzut.

Zgadza się, bardzo dużo.

Reasumując: Dużo tematów wygląda na łatwe dopóki się w nie nie wgłębi:)

> > Skoro już się tak rozpisałem to może kilka słów o Mandatory Access Control
> > we FreeBSD 5.x. Tam Rebert Watson radzi sobie znakomicie z takimi
> > problememi (co w przypadku cerba nie było by możliwe, ze względu na to,
> > że jest modułem do jądra). Wszelkie obiekty przekazywane do odpowiednich
> > policy, są juz odpowiednio zalockowane, więc mozliwości wyścigu nie ma.
> > Czyli np. plik nie jest przekazywany po nazwie, tylko znajdowany lub
> > tworzony jest jego vnode'a, odpowiednio lockowany i dopiero przekazywany do
> > sprawdzenia. Nie ma oczywiście wtedy możliwości operowania na nazwach
> > plików, no ale cos za coś.
> 
> tzn co to jest dokladniej ten MAC, cos jak inny cerb?

Oj nie:) Poczytaj na http://www.TrustedBSD.org, ewentualnie manuale
z FreeBSD 5.x: mac(4), mac_biba(4), mac_lomac(4), mac_mls(4), itp.

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

On Thu, 1 Apr 2004 13:00:03 +0000 (UTC), Pawel Jakub Dawidek wrote:

>> No wiem, tyle ze to jest naprawde uciazliwe, ja mam serwer niby
>> produkcyjny, tzn. maszyna domowa, ale jako ze pracuje jako router z
>> internetu nie tylko ja korzystam dodatkowo mam kilka uslug, to naprawde nie
>> fajne jest kiedy trzeba czesto restartowac, a jak sie pracuje nad nowymi
>> regolkami to taka sytuacja to b. czesto jest. Wystarczajaca aby zniechecic
>> do uzywania.
> Wolisz kernel panic zamiast EBUSY?:)

Wcześniej w takim razie miałem sporo szczęścia, zreszta przy EBUSY też
musze zrestartować :P

>> Jeszcze jedna uwaga, co do dzialania cerbera, nie wiem czy sobie po prostu
>> nie komplikujesz sprawy, tym calym pseudojezykiem i wszystkimi poleceniami
>> w nim, wiem ze to daje wieksze mozliwosci, ale czy jest tak naprawde
>> potrzebne?
>> Czy nie uprosciloby sprawy to zeby np to zeby po prostu zamiast programu w
>> pseudo jezyku byl tylko spis regolek dla kazdego programu. Np ze moze
>> czytac te i te pliki do tych i tych moze zapisywac. Otworzyc tylko takie
>> sockety itp. Nie ulatwilo by to sprawe zarowno dla programisty jak i
>> uzytkownika?
> No właśnie. Weź pod uwagę fakt, że cerb nie musi operować na konkretnych
> procesach, tj. np. systrace. Jeśli zostałby zaimplementowany tak jak mówisz
> nie mógłbys pisać reguł ogólnych, tj. "Zabroń wszystkim dostepu do pliku X",
> albo "Pozwól na hardlinki tylko właścicielom plików".

Może w takim razie jakiś cerber-lite? ;)

>> Moze po prostu nie rozumiem dokladnie sytuacji (stroktory takie jak
>> tc_ucred to tylko moge sie domyslac od czego sa) ale czy nie robisz sobie
> s/tc_/td_/
>> sztucznych problemow.
>> Czy naprawde bedzie taka sytuacja gdy dwa thready, beda uzywac ten sam
>> obszar pamieci, beda wtedy wykonowac _jednoczesnie_ dwa rozne syscalle na
>> tym jednym obszarze pamieci? Raczej taki program bez cerba moglby miec
>> nieprzewidziane wyniki.
> Taka sytuacja w normalnym działaniu może nie wystapić, ale atakujący
> może ja wykorzystać, by oszukać cerba. Robert Watson pomyślnie sploitował
> tego typu wyścigi w innych syscallowych wrapperach.

Wydaje mi się, że blokowanie rozwiązało by ten problem.
Gdy jeden proces wykonuje operacje, a drugi potrzebuje dostępu do tego
samego obszaru pamięci to musi czekać aż syscall oraz regułki cerba skończą
swoje i wtedy zaczyna kontynuować. To by całkowicie rozwiązało problem z tą
sytuacją. Sam mówisz, że taka sytuacja jest niezmienie rzadka, czyli ten
mechanizm raczej nawet rzadko zatrzymywał by inne thready.

Ja to widzę tak, że gdy cerber działa, to syscall i jego argumenty są
wykonywane jako jedność (nic nie może wkroczyć w momencie gdy te operacje
są wykonywane). Nic nie może odczytać/zapisać używanej pamięci w danym
momencie, jeżeli będzie taka potrzeba, to po prostu poczeka aż syscall +
cerb zakończy daną operację i kontynuuje dopiero po niej.
To wydaje mi się najbardziej logiczne rozwiązanie inaczej to będziesz miał
masę kłopotów. 

>> czy nie bedzie problemow z kernelowymi threadami ktore sa w 5.x?
>> 5.x nie uzywam ale cos o tym wspomniales na poczatku postu.
> Chodziło mi raczej o to, że teraz w kernelu process nie jest widziany
> jako najmniejszy obiekt, teraz jest nim wątek, we FreeBSD 4.x wątki
> były jedynie symulowane w usrlandzie, ale kernel o nich nic nie wiedział.
> Natomiast teraz dwa (lub więcej) wątki jednego mogą wykonywać się
> jednocześnie w przestrzeni jądra.

Tzn jest możliwość że dwa syscalle w freebsd mogą być wykonane
równocześnie, czy może w sytuacji gdy pojawią się syscalle jednocześnie
freebsd wykona pierwszy następnie drugi.
Patrz co by było gdyby jeden wątek w tym samym momencie stworzył plik a
drugi wątek zrobil unlink(). Wydaje mi się, że freebsd też musi robić takie
blokowanie. A Ty w cerberze po prostu musiałbyś zrobićtak, aby syscall +
kod cerbera było traktowane jako jedność.

[...]
>> tzn close zwroci blad, czy po prostu poczeka? Bo jak zwroci blad to raczej
>> nie jest zbyt dobre z punktu widzenia programu (jakos mam wrazenie ze
>> programy beda bardziej awaryjne)
> 
> Zwróci błąd. Generalnie zachowanie takie jest nie jest normalne,

wiesz jak to pisałem było już późno, jakoś przeoczyłem słowa "używanym
deskryptorze". Blokowanie raczej rozwiązało by też ten problem.
Innymi słowy nie dopuścić aby dwa syscalle mogły działać równocześnie i
operować na tych samych obiektach. I przez słowo syscall rozyumiem syscall
+ kod cerba, całość powinna być traktowana jako jeden element. Blokować
tylko w przypadku gdy dwa syscalle używają tej samej pamięci tych samych
deskryptorów itp. Ewentualnie blokować zawsze, to by było skutecznienjsze,
ale jednak mogłoby zwolnić znacząco działanie.

> także jeśli ktoś próbuje tak zrobić, to raczej cos kombinuje.
> Natomiast rzeczywiście istnieje ryzyko namawiania programu do wycieków,
> ponieważ niestety jest dużo stereotypów, które sa powszechnie sotosowane,
> jak np. nie sprawdzanie co zwraca close(2). A to bardzo źle, ponieważ
> może np. zwrócić EINTR. EINTR i problemy z nim zwiazane to w ogóle
> odrębna bajka.

lol, tak jak by ktoś o mnie pisał :P
 
>>> Inny problem (uciążliwy nie tylko dla cerba) jest nasz VFS.
>>> Nie ma teoretycznie możliwość znalezienia nazwy pliku mając deskryptor,
>>> ponieważ vnode'a plikowy nie może zagwarantować jednoznaczności,
>>> ponieważ plik może mieć wiele dowiązań (hard linków). Praktycznie
>>> można próbować wyciągać nazwę pliku z cache'u, ale to bardzo zawodny
>>> mechanizm. Dlatego cerb zapamiętuje nazwy otwieranych plików i operuje
>>> na nich. Na przykład w Darwinie jest obsługiwane w vnodzie pole
>>> wskazujące na katalog, w którym znajduje się plik (lub inny file
>>> systemowy obiekt) co pozwala na uzyskanie nazwy pliku w każdej chwili.
>>> Zarządzenie takim pointerem jednak wprowadza inne komplikacje.
>> nie wystarczy patch na kernel, ktory dodalby do filedeskryptorow miejsce na
>> przechowywanie nazwy pliku?
> Wierzysz, że ktoś by się na to zgodził?:)
> Generalnie daje to olbrzymi narzut na pamięć i straszne opóźnienia.
> Przede wszystkim czy interesuje nas zmiana nazwy pliku?
> Po drugie plik przed zapisaniem w takim buforze trzeba by potraktować
> funkcją realpath() by uniknąć problemów ze zmianą namespace, o których
> wspominałem wsześniej.

Tutaj nie widzę innego rozwiązania, jak to które jest aktualne w cerbie.
Ale czy nazwa pliku nie jest przydatna tylko w momencie gdy się otwiera
plik? (zezwolić lub nie na otwarcie danego pliku).

>>> Nie do ukrycia problemem jest też spory narzut na wydajność.
>> wydaje mi sie ze to zbedne kopiowanie oraz pseudojezyk (czy jest on w ogole
>> kompilowany) to duzy narzut.
> Zgadza się, bardzo dużo.
> Reasumując: Dużo tematów wygląda na łatwe dopóki się w nie nie wgłębi:)

przy zaimplementowaniu blokowania dużo problemów się rozwiąże IMHO :)

-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*

Dariusz Kuliński / TaKeDa <dp4declo02@nsonsepaakmemail.com> wrote:
> >> No wiem, tyle ze to jest naprawde uciazliwe, ja mam serwer niby
> >> produkcyjny, tzn. maszyna domowa, ale jako ze pracuje jako router z
> >> internetu nie tylko ja korzystam dodatkowo mam kilka uslug, to naprawde nie
> >> fajne jest kiedy trzeba czesto restartowac, a jak sie pracuje nad nowymi
> >> regolkami to taka sytuacja to b. czesto jest. Wystarczajaca aby zniechecic
> >> do uzywania.
> > Wolisz kernel panic zamiast EBUSY?:)
> 
> Wcześniej w takim razie miałem sporo szczęścia, zreszta przy EBUSY też
> musze zrestartować :P

Przede wszystkim możesz czysto zamknąć system. Poza tem to powinna być
kwestia reguł ewentualnie. Powinna być możliwość usunięcia reguł i wtedy
odładowania cerba.

> >> Moze po prostu nie rozumiem dokladnie sytuacji (stroktory takie jak
> >> tc_ucred to tylko moge sie domyslac od czego sa) ale czy nie robisz sobie
> > s/tc_/td_/
> >> sztucznych problemow.
> >> Czy naprawde bedzie taka sytuacja gdy dwa thready, beda uzywac ten sam
> >> obszar pamieci, beda wtedy wykonowac _jednoczesnie_ dwa rozne syscalle na
> >> tym jednym obszarze pamieci? Raczej taki program bez cerba moglby miec
> >> nieprzewidziane wyniki.
> > Taka sytuacja w normalnym działaniu może nie wystapić, ale atakujący
> > może ja wykorzystać, by oszukać cerba. Robert Watson pomyślnie sploitował
> > tego typu wyścigi w innych syscallowych wrapperach.
> 
> Wydaje mi się, że blokowanie rozwiązało by ten problem.
> Gdy jeden proces wykonuje operacje, a drugi potrzebuje dostępu do tego
> samego obszaru pamięci to musi czekać aż syscall oraz regułki cerba skończą
> swoje i wtedy zaczyna kontynuować. To by całkowicie rozwiązało problem z tą
> sytuacją. Sam mówisz, że taka sytuacja jest niezmienie rzadka, czyli ten
> mechanizm raczej nawet rzadko zatrzymywał by inne thready.
> 
> Ja to widzę tak, że gdy cerber działa, to syscall i jego argumenty są
> wykonywane jako jedność (nic nie może wkroczyć w momencie gdy te operacje
> są wykonywane). Nic nie może odczytać/zapisać używanej pamięci w danym
> momencie, jeżeli będzie taka potrzeba, to po prostu poczeka aż syscall +
> cerb zakończy daną operację i kontynuuje dopiero po niej.
> To wydaje mi się najbardziej logiczne rozwiązanie inaczej to będziesz miał
> masę kłopotów. 

Wiesz, kłopotów uniknąć się nie da i tak. Nawet zaimplementowanie takiego
blokowania nie musi być łatwe. Programowanie VM-a nie jest raczej trywialne.
Jest sporo ograniczeń, których może się nie dać łatwo przeskoczyć.
Generalnie takie blokowanie musiało by polegać na markowaniu obszaru
jako read-only i czekaniu na page faulty i ich obsłudze. Wtedy musimy
stwierdzić który to wątek próbuje dokonać zapisu i czy mu wolno, itp.
Bez zmian w kernelu raczej się nie obędzie.

> >> czy nie bedzie problemow z kernelowymi threadami ktore sa w 5.x?
> >> 5.x nie uzywam ale cos o tym wspomniales na poczatku postu.
> > Chodziło mi raczej o to, że teraz w kernelu process nie jest widziany
> > jako najmniejszy obiekt, teraz jest nim wątek, we FreeBSD 4.x wątki
> > były jedynie symulowane w usrlandzie, ale kernel o nich nic nie wiedział.
> > Natomiast teraz dwa (lub więcej) wątki jednego mogą wykonywać się
> > jednocześnie w przestrzeni jądra.
> 
> Tzn jest możliwość że dwa syscalle w freebsd mogą być wykonane
> równocześnie, czy może w sytuacji gdy pojawią się syscalle jednocześnie
> freebsd wykona pierwszy następnie drugi.

Więc tak. We FreeBSD 4.x SMP realizowane jest jedynie na poziomie
userlandu. Przy wejściu do kernela, łapany jest Giant-lock i tylko
jeden proces wykonuje się w przestrzeni kernela jednocześnie.
Oczywiście może on być przerwany w wyniku, np. przerwania.
Jedną z największych rewolucji (powiedzmy to: największą) we FreeBSD 5.x
było wprowadzenia w pełni SMP kernela. Pociąga to za sobą konieczność
sychronizacji dostępu do wszystkich współdzielonych zasobów.
Pociągnęło to też za sobą opóźnienie o ponad rok wydania 5.0,
ale warto było.

> Patrz co by było gdyby jeden wątek w tym samym momencie stworzył plik a
> drugi wątek zrobil unlink(). Wydaje mi się, że freebsd też musi robić takie
> blokowanie. A Ty w cerberze po prostu musiałbyś zrobićtak, aby syscall +
> kod cerbera było traktowane jako jedność.

Ochroną takich wypadków zajmuje się VFS i synchronizacja tam
zaimplementowana. Obiekty file systemu też można blokować.
Zresztą jeśli otworzysz plik i go usuniesz, to możesz z niego korzystać
bez żadnych problemów dopóki nie zamkniesz deskryptora.
Tak się czasem robi z plikami tymczasowymi. Otwierasz plik tymczasowy,
dostajesz deskryptor, usuwasz plik i korzystasz z niego do woli, nie
przejmując się o jego skasowanie przy wyjściu.

> > Generalnie daje to olbrzymi narzut na pamięć i straszne opóźnienia.
> > Przede wszystkim czy interesuje nas zmiana nazwy pliku?
> > Po drugie plik przed zapisaniem w takim buforze trzeba by potraktować
> > funkcją realpath() by uniknąć problemów ze zmianą namespace, o których
> > wspominałem wsześniej.
> 
> Tutaj nie widzę innego rozwiązania, jak to które jest aktualne w cerbie.
> Ale czy nazwa pliku nie jest przydatna tylko w momencie gdy się otwiera
> plik? (zezwolić lub nie na otwarcie danego pliku).

Ależ skąd. W cerbie masz możliwość pobrania nazwy pliku po numerze
deskryptora. Dzięki temu możesz kontrolować syscalle takie jak:
fchmod(2), fchown(2), fchflags(2), ioctl(2), i inne, operujące na
deskryptorach po nazwie pliku. Co jest niesamowicie wygodne.

> > Zgadza się, bardzo dużo.
> > Reasumując: Dużo tematów wygląda na łatwe dopóki się w nie nie wgłębi:)
> 
> przy zaimplementowaniu blokowania dużo problemów się rozwiąże IMHO :)

Budujący jest Twój optymizm:)

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

Pawel Jakub Dawidek wrote:
> 
> Chodziło mi raczej o to, że teraz w kernelu process nie jest widziany
> jako najmniejszy obiekt, teraz jest nim wątek, we FreeBSD 4.x wątki
> były jedynie symulowane w usrlandzie, ale kernel o nich nic nie wiedział.
> Natomiast teraz dwa (lub więcej) wątki jednego mogą wykonywać się
> jednocześnie w przestrzeni jądra.
> 

na marginesie: watkowanie w 4.x nie jest "symulowane"; prawda jest, ze 
kernel nic o nich nie wie, ale takie jest wlasnie zalozenie dla czystych 
userland-owych watkow (posix threads).

r

Rafal Jaworowski <arj004@motorola.com> wrote:
> Pawel Jakub Dawidek wrote:
> > 
> > Chodziło mi raczej o to, że teraz w kernelu process nie jest widziany
> > jako najmniejszy obiekt, teraz jest nim wątek, we FreeBSD 4.x wątki
> > były jedynie symulowane w usrlandzie, ale kernel o nich nic nie wiedział.
> > Natomiast teraz dwa (lub więcej) wątki jednego mogą wykonywać się
> > jednocześnie w przestrzeni jądra.
> > 
> 
> na marginesie: watkowanie w 4.x nie jest "symulowane"; prawda jest, ze 
> kernel nic o nich nie wie, ale takie jest wlasnie zalozenie dla czystych 
> userland-owych watkow (posix threads).

POSIX nie mówi o wątkach userlandowych czy kernelowych, tylko specyfikuje
interfejs pthreads, to wszystko.

Może "symulowanie" nie było najwłaściwszym słowem tutaj, ale z punktu
widzenia kernela to jest "symulowanie"/"emulowanie" wątków.

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

Pawel Jakub Dawidek wrote:
>>>Chodziło mi raczej o to, że teraz w kernelu process nie jest widziany
>>>jako najmniejszy obiekt, teraz jest nim wątek, we FreeBSD 4.x wątki
>>>były jedynie symulowane w usrlandzie, ale kernel o nich nic nie wiedział.
>>>Natomiast teraz dwa (lub więcej) wątki jednego mogą wykonywać się
>>>jednocześnie w przestrzeni jądra.
>>>
>>
>>na marginesie: watkowanie w 4.x nie jest "symulowane"; prawda jest, ze 
>>kernel nic o nich nie wie, ale takie jest wlasnie zalozenie dla czystych 
>>userland-owych watkow (posix threads).
> 
> 
> POSIX nie mówi o wątkach userlandowych czy kernelowych, tylko specyfikuje
> interfejs pthreads, to wszystko.
> 

wiec skoro 4.x spelnia wymagania tej specyfikacji, to znaczy, ze nie 
jest to ani symulacja ani emulacja, tylko implementacja pthreads.

> Może "symulowanie" nie było najwłaściwszym słowem tutaj, ale z punktu
> widzenia kernela to jest "symulowanie"/"emulowanie" wątków.
> 

jezeli kernel (dokl. scheduler) nic nie wie o tych watkach, to w ogole 
nie ma sensu mowic tu o "punkcie widzenia" kernela na to co dzieje sie 
wewnatrz procesu, w szczegolnosci na to czy wykonuje on jakies wlasne 
szeregowanie po przelaczeniu don kontekstu; podobnie jak nie istnieje 
"p.widzenia" kernela np. na strukture pliku.

nie chcialem sie czepiac slowek: po prostu implementacja watkow z 4.x 
(jakkolwiek czysto userland-owa, wiec z wadami ale i zaletami tego 
modelu) jest b.dobra i okreslenie "symulacja/emulacja" jest moim zdaniem 
niesprawiedliwe:)

r

On Fri, 2 Apr 2004 07:50:04 +0000 (UTC), Pawel Jakub Dawidek wrote:

>> Wcześniej w takim razie miałem sporo szczęścia, zreszta przy EBUSY też
>> musze zrestartować :P
> Przede wszystkim możesz czysto zamknąć system. Poza tem to powinna być
> kwestia reguł ewentualnie. Powinna być możliwość usunięcia reguł i wtedy
> odładowania cerba.

Wiem, że jak z tym reloadowaniem przesadziłem to dochodziło do takiej
sytuacji że albo nie mogłem rozładować starych regułek albo załadować
nowych, już dokładnie nie pamiętam. (raczej chyba to drugie, bo wydaje mi
się że mogłem załadować do danego slotu ale nie mogłem go zrobić aktywnym)

> Wiesz, kłopotów uniknąć się nie da i tak. Nawet zaimplementowanie takiego
> blokowania nie musi być łatwe. Programowanie VM-a nie jest raczej trywialne.
> Jest sporo ograniczeń, których może się nie dać łatwo przeskoczyć.
> Generalnie takie blokowanie musiało by polegać na markowaniu obszaru
> jako read-only i czekaniu na page faulty i ich obsłudze. Wtedy musimy
> stwierdzić który to wątek próbuje dokonać zapisu i czy mu wolno, itp.
> Bez zmian w kernelu raczej się nie obędzie.

Nie programowałem nic na poziomie kernela, więc dla mnie takie rzeczy nie
są oczywiste, najpewniej masz rację. Ale czy modyfikacja kernela byłaby aż
taka zła? Tzn jak już by do tego doszło to polecałbym zmienić tylko
minimum. Porobić np odpowiednie mechanizmy, dodać pewne informacje i
wszystko obsługiwać z modułu.

>> Tzn jest możliwość że dwa syscalle w freebsd mogą być wykonane
>> równocześnie, czy może w sytuacji gdy pojawią się syscalle jednocześnie
>> freebsd wykona pierwszy następnie drugi.
> Więc tak. We FreeBSD 4.x SMP realizowane jest jedynie na poziomie
> userlandu. Przy wejściu do kernela, łapany jest Giant-lock i tylko
> jeden proces wykonuje się w przestrzeni kernela jednocześnie.
> Oczywiście może on być przerwany w wyniku, np. przerwania.
> Jedną z największych rewolucji (powiedzmy to: największą) we FreeBSD 5.x
> było wprowadzenia w pełni SMP kernela. Pociąga to za sobą konieczność
> sychronizacji dostępu do wszystkich współdzielonych zasobów.
> Pociągnęło to też za sobą opóźnienie o ponad rok wydania 5.0,
> ale warto było.

dla cerba to pewnie: D'oh! ;P
A ja i tak go głównie lubię bo potrafi logować execve.

> Ochroną takich wypadków zajmuje się VFS i synchronizacja tam
> zaimplementowana. Obiekty file systemu też można blokować.
> Zresztą jeśli otworzysz plik i go usuniesz, to możesz z niego korzystać
> bez żadnych problemów dopóki nie zamkniesz deskryptora.
> Tak się czasem robi z plikami tymczasowymi. Otwierasz plik tymczasowy,
> dostajesz deskryptor, usuwasz plik i korzystasz z niego do woli, nie
> przejmując się o jego skasowanie przy wyjściu.

tego nie wiedziałem, hmm ale jak to wygląda dla usera czy podczas działania
programu plik jest nadal widoczny, czy już w momencie unlink znika
magicznie?

>> Tutaj nie widzę innego rozwiązania, jak to które jest aktualne w cerbie.
>> Ale czy nazwa pliku nie jest przydatna tylko w momencie gdy się otwiera
>> plik? (zezwolić lub nie na otwarcie danego pliku).
> Ależ skąd. W cerbie masz możliwość pobrania nazwy pliku po numerze
> deskryptora. Dzięki temu możesz kontrolować syscalle takie jak:
> fchmod(2), fchown(2), fchflags(2), ioctl(2), i inne, operujące na
> deskryptorach po nazwie pliku. Co jest niesamowicie wygodne.

Tzn. cerb po prostu ma tabilce:
dekryptor - nazwa pliku

i przechwytuje wszystkie syscalle otwierajace i zamykajace filedeskryptory,
przy okazji uaktualniajac daną tablicę?

Bo chyba jedynie tak można to w miarę normalnie zrobić...

>> przy zaimplementowaniu blokowania dużo problemów się rozwiąże IMHO :)
> Budujący jest Twój optymizm:)

Najpewniej dlatego, że moja wiedza jest nadal mała :P

-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*

Dariusz Kuliński / TaKeDa <dp4declo02@nsonsepaakmemail.com> wrote:
> >> Tzn jest możliwość że dwa syscalle w freebsd mogą być wykonane
> >> równocześnie, czy może w sytuacji gdy pojawią się syscalle jednocześnie
> >> freebsd wykona pierwszy następnie drugi.
> > Więc tak. We FreeBSD 4.x SMP realizowane jest jedynie na poziomie
> > userlandu. Przy wejściu do kernela, łapany jest Giant-lock i tylko
> > jeden proces wykonuje się w przestrzeni kernela jednocześnie.
> > Oczywiście może on być przerwany w wyniku, np. przerwania.
> > Jedną z największych rewolucji (powiedzmy to: największą) we FreeBSD 5.x
> > było wprowadzenia w pełni SMP kernela. Pociąga to za sobą konieczność
> > sychronizacji dostępu do wszystkich współdzielonych zasobów.
> > Pociągnęło to też za sobą opóźnienie o ponad rok wydania 5.0,
> > ale warto było.
> 
> dla cerba to pewnie: D'oh! ;P
> A ja i tak go głównie lubię bo potrafi logować execve.

Jeśli interesuje Cię głównie logowanie execve(2), to może spróbuj lrexec?

	http://garage.freebsd.pl/lrexec.tbz

Jest dużo, dużo lżejszy niż cerb.

> > Ochroną takich wypadków zajmuje się VFS i synchronizacja tam
> > zaimplementowana. Obiekty file systemu też można blokować.
> > Zresztą jeśli otworzysz plik i go usuniesz, to możesz z niego korzystać
> > bez żadnych problemów dopóki nie zamkniesz deskryptora.
> > Tak się czasem robi z plikami tymczasowymi. Otwierasz plik tymczasowy,
> > dostajesz deskryptor, usuwasz plik i korzystasz z niego do woli, nie
> > przejmując się o jego skasowanie przy wyjściu.
> 
> tego nie wiedziałem, hmm ale jak to wygląda dla usera czy podczas działania
> programu plik jest nadal widoczny, czy już w momencie unlink znika
> magicznie?

No właśnie trik polega na tym, że w momencie unlink(2), dla użytkownika
nic się nie zmienia, miejsce na dysku zostaje zwolnione w momencie gdy
ostatni konsumer zamknie deskryptor.

> >> Tutaj nie widzę innego rozwiązania, jak to które jest aktualne w cerbie.
> >> Ale czy nazwa pliku nie jest przydatna tylko w momencie gdy się otwiera
> >> plik? (zezwolić lub nie na otwarcie danego pliku).
> > Ależ skąd. W cerbie masz możliwość pobrania nazwy pliku po numerze
> > deskryptora. Dzięki temu możesz kontrolować syscalle takie jak:
> > fchmod(2), fchown(2), fchflags(2), ioctl(2), i inne, operujące na
> > deskryptorach po nazwie pliku. Co jest niesamowicie wygodne.
> 
> Tzn. cerb po prostu ma tabilce:
> dekryptor - nazwa pliku

Dokładnie to posortowaną listę.

> i przechwytuje wszystkie syscalle otwierajace i zamykajace filedeskryptory,
> przy okazji uaktualniajac daną tablicę?
> 
> Bo chyba jedynie tak można to w miarę normalnie zrobić...

Między innymi. Przechwytywane są również funkcje do obsługi deskryptorów.
Cały ten mechanizm zaimplementowany jest w pliku cerb_fdesc.[ch] jeśli
masz ochotę dowiedzieć się więcej.

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

On Sun, 4 Apr 2004 07:20:07 +0000 (UTC), Pawel Jakub Dawidek wrote:

> Jeśli interesuje Cię głównie logowanie execve(2), to może spróbuj lrexec?
> 	http://garage.freebsd.pl/lrexec.tbz
> Jest dużo, dużo lżejszy niż cerb.

Właśnie próbuję... Cerb ma zaletę z tym językiem, bo można było więcej
pokombinować :)

A właśnie, czym różni się rexec od lrexec?

> No właśnie trik polega na tym, że w momencie unlink(2), dla użytkownika
> nic się nie zmienia, miejsce na dysku zostaje zwolnione w momencie gdy
> ostatni konsumer zamknie deskryptor.

Ok, to już wszystko jasne :)

>> Tzn. cerb po prostu ma tabilce:
>> dekryptor - nazwa pliku
> Dokładnie to posortowaną listę.
>> i przechwytuje wszystkie syscalle otwierajace i zamykajace filedeskryptory,
>> przy okazji uaktualniajac daną tablicę?
>> 
>> Bo chyba jedynie tak można to w miarę normalnie zrobić...
> Między innymi. Przechwytywane są również funkcje do obsługi deskryptorów.
> Cały ten mechanizm zaimplementowany jest w pliku cerb_fdesc.[ch] jeśli
> masz ochotę dowiedzieć się więcej.

Jedyne co się boję to manipulować z tym, to już moduł do kernela, jak
zrobię błąd to cały system pada :P

-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*

> Witam,
>
> Chce udostepnic znajomemu konto shelowe z dostepem tylko do paru polecen.
> Czy da sie zabiezpieczyc konto zeby user nie chodzil po innych katalogach
i
> nie uruchamial innyc programow?
> Oczywiscie z pewnych wzgledow odpada zmiana uprawnien na wszytskich
plikach
> ;)
> shell to sh lub bash lub csh - praktycznie obojetnie  - oby latwo dalo to
> sie zrobic.
>
> Pozdrawiam
>

w innych odpowiedziach proponowali Ci cerb'a. ale z tego co wiem to po 5.x
nie pojdzie wiec jesli masz 5.x to papa... a rozwiązaniem jest MAC :]
moze jest malo dokumentacji, ale w sumie duzo nie potrzeba, a jak zrozumiesz
konfiguracje to hehe.... szok :).
man -k mac.
wszystko masz na miejscu....