Chakujemy Argante

Obublikowana niedawno a odkryta dawno dziura w jądrach z serii 2.x po raz kolejny postawiła pod znakiem zapytania bezpieczeństwo tradycyjnych systemów. Przypomnijmy: umożliwiała ona uzyskanie roota na maszynach na których posiada się konto shellowe, chyba że spełniony zostanie jeden z dwóch warunków: a) w systemie nie będzie ani jednego programu z suidem, lub b) zostanie wyłączone ptrace. Takie komputery można jednak policzyć na palcach… Poza tym wyłączenie ptrace czyni daną maszynę praktycznie bezużyteczną dla celów deweloperskich.
Czy więc dla administratorów nie ma innej drogi jak tylko czytanie list dyskusyjnych, wyłapywanie wszelkich pogłosek o błędach i życie w napięciu (proporcjonalnym do ilości udostępnianych usług)? Czy nie istnieje sposób, który raz na zawsze położyłby kres błędom wynikającym z samej konstrukcji systemów operacyjnych? Jak wiadomo, lcamtuf pewnego dnia stwierdził, że koniec z kompromisami, i zabrał się za Argante. Argante jest systemem o kilka klas bezpieczniejszym od tradycyjnych, nie tylko dlatego, że wprowadza dodatkową warstwę bezpieczeństwa, ale i dlatego, że nie pozwala programiście pisać a użytkownikowi uruchamiać „niebezpiecznych” programów.
W tej chwili jednak Argante, mimo świetnego designu, nie jest używana przez administratorów na całym świecie, a jedynie przez grupkę użytkowników, z których większość stanowią zapewne deweloperzy. Powodem jest brak aplikacji dla tego systemu. Dlatego w tym artykule postaram się przedstawić podstawowe zasady pisania nowych i modyfikacji istniejących aplikacji dla Argante.

W tej chwili deweloper rozwijający aplikacje dla Argante dysponuje trzema językami: asemblerem RSIS, językiem wysokiego poziomu AHLL oraz podzbiorem Muduli-3. Trudno mi sie wypowiadać na temat tego ostatniego z powodu braku jakiegokolwiek obeznania z tym zapewne pięknym językiem, natomiast dwa pierwsze działają i to całkiem dobrze. Kompilator AHLL zostanie przepisany, jednak z zachowaniem wstecznej kompatybilności, dlatego nie musimy sie martwić, że napisany przez nas program trzeba będzie w przyszłości przepisywać.
Tradycja nakazuje rozpocząć pierwszy program od „Mamusiu, jak tu pięknie!”. W asemblerze RSIS zadanie to jest trywialne:

  .DATA  :hi          "A gdzie są moje kredki?n"  .CODE      mov u0,:hi    mov u1,^hi    syscall $IO_PUTSTRING    halt  .END  

Każdy, kto kiedykolwiek napisał coś w asemblerze, poczuje się jak w domu. Kluczowymi elementami programu są wywołania systemowe (nie, nie mają wiele wspólnego z dosowymi przerwaniami ;)), odwołujące się do specyficznych funkcji, znajdujących się w modułach. W naszym przypadku $IO_PUTSTRING służy do wyświetlenia tekstu na konsoli (parametry i sposób wywołania każdego syscalla są opisane w dokumentacji).
Program zapisujemy jako hi.agt, po czym kompilujemy (agtc hi.agt). Powinnismy otrzymać plik hi.img, który ładujemy z poziomu konsoli Argante $hi.img.
No dobrze – pisanie w RSIS jest proste i przyjemne, w katalogu Examples/RSIS znajduje się wiele przykładów, dokumentacja jest bogata… ale co z AHLL? W przypadku AHLL jest dokładnie odwrotnie, choćby dlatego, że język ten powstał później i nigdy nie miał być (i nie jest) niczym w rodzaju oficjalnego języka Argante. Można natomiast przypuszczać, że powstające kompilatory dla innych języków będą raczej tworzyły kod RSIS a nie gotowe obrazy wykonywalne.
Nasze „hello world” w standardowym AHLL-u wygląda następująco:

  #include "include/stdinc.ahh"  #include "include/display.ahh"    #CString hi " nn A pani co tu robi? nn"      procedure Main () {      local {       mystring : Bounded_Chunk;    }        mystring.data := address hi;    mystring.len  := hi_bytelength;    Console_PutString  ( mystring );    }  

Od razu rzuca się w oczy kilka elementów znanych z Ady, jakkolwiek każdy programujący w C nie powinien mieć trudności z określeniem rezultatu wykonania tego programu. Kompilujemy go poleceniem acc programik.ahl i uruchamiamy jak poprzednio.
No dobrze. Mniej więcej wiemy już, czego można się spodziewać po RSIS i AHLL, potrafimy pisać proste programiki dla Argante – czas zabrać się za coś nieco trudniejszego. W skład dystrybucji Argante wchodzi miniserwer http – znajduje sie on w katalogu Examples/AHLL/http/. „W sumie mógłbym go używać” – myśłi User Kowalski, „ale brakuje mi logowania”. Spróbujemy więc zastanowić się nad modyfikacją httpd.ahl w taki sposób, by umozliwic logowanie (by uprościć sprawę – na konsolę, nie do pliku). Niestety logowanie IP łaczącego się nie będzie trywialną sprawą (można męczyć tego ktosia o dorobienie plików nagłówkowych .ahh), zajmiemy się natomiast rejestracja nazw dokumentów, do których będą odwoływali się klienci.
Przechodzimy do katalogu z serwerem i do pliku custom.ahh dodajemy linijki:

  #define  CLOG 1  #CString ConsLog "Console logger started"  

Oczywiście są to elementy opcjonalne – równie dobrze możemy zaszyć opcję logowania na sztywno – warto jednak pomyśleć o mającym powstac w przyszłości pliku httpd.conf ;).
Na samym początku procedury Main(), tuż po deklaracjach zmiennych, dodajemy fragemt:

      if CLOG {        Console_PutChar  ( 10 );        Attach_Bounded ( announce, address ConsLog, ConsLog_bytelength);        Console_PutString  ( announce );        Console_PutChar  ( 10 );        }    

(Oczywiście wcześniej powinniśmy zadeklarować announce jako Bounded_Chunk). nastepnie w procedurze Process_Request, po String_Append ( req, reqnew ); dodajemy:

      if CLOG {        Console_PutString  ( reqnew );        Console_PutChar  ( 10 );        }    

I gotowe ;). Oczywiscie tak prymitywnego loggera można szukać ze świeczką (a i tak szanse znalezienia są bliskie zeru), chodzi jednak o ukazanie, że modyfikacja programów AHLL-owych nie jest szczególnie trudna. Możemy teraz skompilować httpd.ahl i uruchomić httpd.img. Na wolnej konsoli uruchamiamy przeglądarkę (lynx localhost:1024) i po kolei próbujemy dostać się do różnych dokumentów – na konsoli Argante powinny pojawic się ich nazwy.
No cóż – Argante’owy serwer ftp czeka na chętnych 🙂
Archiwalny news dodany przez użytkownika: arturs.
Kliknij tutaj by zobaczyć archiwalne komentarze.