================= | GNU Anubis 4 | ================= Tytuł projektu: "Pixie & Dixie" Status: Szkic Opracował: Wojciech Polak , (C) 2003. Rewizja 1.1: 22 V 2004 *** Wprowadzenie Niniejsze opracowanie przedstawia nowy schemat autoryzacji klientów w programie GNU Anubis, wersja 4.x. *** Problem Dotychczasowa metoda polegała na autoryzacji użytkownika za pomocą usługi AUTH, popularnego demona o nazwie Ident, który nasłuchuje na porcie TCP 113. Zaletą tego rozwiązania była szybkość ustalenia z kim do czynienia ma serwer, tj. nazwy klienta (user name) lub jego identyfikatora (UID). Metoda ta pozwala na dokonanie właściwej autoryzacji zanim klient wyśle swój "pierwszy bajt". Ponadto pozwala na przetwarzanie całej koperty SMTP. Wadą natomiast jest konieczność posiadania w systemie działającego demona Ident, co nie zawsze jest możliwe (urządzenia mobilne), bądź obniżającą nieco bezpieczeństwo systemu (konieczność otwartej transmisji poprzez sieć identyfikatora użytkownika). *** Rozwiązanie Podział na dwa tryby pracy: 1) tradycyjny (a.k.a. `Pixie') 2) nowy (a.k.a. `Dixie') * Krótka charakterystyka: 1) `Pixie' - Serwer dokonuje autoryzacji na podstawie usługi AUTH. - Możliwość natychmiastowego przetwarzania całej koperty SMTP. - Tunelowanie w locie połączeń między MUA a MTA. 2) `Dixie' W tym trybie Anubis musi obsługiwać własną bazę użytkowników i haseł, dodatkowo "tłumaczyć loginy" (o tym później), oraz przechowywać pliki konfiguracyjne użytkowników (jako dodatkowa opcja i zaleta -- o tym także później). Tryb `Dixie' dokonuje autoryzacji poprzez protokół ESMTP AUTH. W tym trybie NIE MOŻNA dokonać wczesnego przetwarzania koperty SMTP (np. "if command[EHLO]"). Przetwarzanie koperty można dokonać dopiero po udanej autoryzacji użytkownika. W tym trybie występuje OPÓŹNIENIE przy łączeniu się z MTA (ponieważ najpierw trzeba poczekać na ESMTP AUTH, a dopiero później, po ustaleniu tożsamości i ewentualnie szczęśliwej autoryzacji, wczytać plik konfiguracyjny klienta i połączyć się z wybranym MTA). W tym trybie klient nie może także rozpocząć wysyłania listów dopóki nie zostanie prawidłowo rozpoznany i zaakceptowany przez program serwera. * Szczegóły: Istnieje ogromna różnica między tymi dwoma trybami. Przede wszystkim tryb `Pixie' jest tunelem "w locie" (proxy), w sensie takim, że łączy program pocztowy klienta z agentem pocztowym i nie wymaga żadnych specjalnych działań ze strony użytkownika. Tymczasem tryb `Dixie' musi najpierw symulować zachowanie agenta pocztowego (MTA), aby dokonać autoryzacji ESMTP AUTH. Przedstawię teraz prostą sytuację dla `Dixie', gdzie występuje Maszyna-A, na której pracuje "nowy" Anubis oraz Maszyna-B, z której łączy się klient (MUA). Ustalmy także, że Anubis przechowuje specjalną bazę użytkowników (ich loginy/hasła). A: 220 Maszyna-A (GNU Anubis vX.X [Dixie]) ESMTP time; send your identity! B: EHLO Maszyna-B A: 250-Maszyna-A Hello ID 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN 250-XDATABASE 250 HELP B: STARTTLS A: 220 2.0.0 Ready to start TLS B: AUTH (przesłanie specjalnego loginu i hasła do Anubisa) W tym momencie po stronie Anubisa nastąpiło dokonanie autoryzacji klienta na podstawie danych z własnej Bazy. Chciałbym aby taka Baza zawierała poza właściwym loginem i hasłem także nazwę użytkownika na Maszynie-A wraz z hasłem. Zakręcone? Powiedzmy, że w Bazie istnieje wpis: JohnSmith:ZAKODOWANE-HASŁO-1, John Klient poprzez ESMTP AUTH wysłał JohnSmith:ZAKODOWANE-HASŁO-1 a to zgodziło się z wpisem w Bazie Anubisa. Następnie Anubis, który w tym momencie jeszcze pracuje jako superużytkownik dokonuje translacji i dalej stosuje uprawnienia użytkownika "John". Takie rozwiązanie może także pozwolić na bardzo elastyczną Bazę, której admin nie musi nawet kontrolować, tzn. że każdy może dopisać tam SWOJE dane lub je usunąć (oczywiście każdy kto będzie miał prawo dokonywania takich zmian w Bazie). Na przykład ODBC, SQL? Ale wracając do naszej sesji -- ustalmy, że wszystkie dane zostały zweryfikowane i teraz Anubis pracuje już jako zwykły użytkownik, po czym wczytuje plik `~/.anubisrc'. W tym momencie na podstawie pliku konf. użytkownika Anubis łączy się z MTA i dalej zachowuje się już w tradycyjny sposób jako tunel/proxy i procesor poczty, po czym wysyła do klienta: A: 220 OK, Welcome. Continue sending your mail! * Dalsze szczegóły: Pełne zrozumienie nowego trybu pozwoli także uzmysłowić sobie, że nie jest możliwa praca dwóch trybów jednocześnie. To administrator Anubisa będzie musiał ustalić, z którego trybu będzie chciał skorzystać. Być może uda się zaprogramować przejście z jednego trybu do drugiego bez konieczności restartu demona... Aczkolwiek nie jest to absolutna konieczność. Restart demona w celu zmiany trybu działania będzie również właściwym rozwiązaniem. W tym miejscu przedstawię dla kogo i jaki tryb będzie przeznaczony. Tradycyjny tryb `Pixie' przewiduję dla osób, które planują używać Anubisa w obrębie jednej maszyny lub zamkniętej sieci i pozwalają na użycie Identd. W takim przypadku użycie Ident jest całkowicie bezpieczne. Zaś nowy tryb `Dixie' przewiduję dla osób, które uruchomią GNU Anubisa na jednej maszynie, zaś wszelkie połączenia będą dokonywane z innych komputerów. A więc wszystko zdalnie i zakładamy tutaj, że żadna maszyna zdalna nie będzie miała usługi AUTH. Jedynym tutaj ZALECENIEM (dla tego trybu) jest posiadania unixowego konta na maszynie, gdzie pracuje Anubis. Ale uwaga: nawet i to nie jest wymagane! Jeszcze tej cechy nie zdążyłem opisać :^). Mianowicie, Baza Anubisa drugi login potrzebuje aby przejść w tryb użytkownika i wczytać lokalny `~/.anubisrc'. Ja natomiast założyłem, ze Baza może przechowywać także (uwaga!) pliki konfiguracyjne poszczególnych klientów. A więc w Bazie musi się znaleźć dodatkowa flaga dla każdego użytkownika, która będzie informowała o tym czy dokonać translacji i wczytać lokalny `~/.anubisrc', czy też wczytać tylko plik znajdujący się w Bazie. Oczywiście dla bezpieczeństwa GNU Anubis mimo braku translacji nadal będzie musiał przejść w tryb użytkownika, ale może to zrobić zwyczajnie na podstawie `user-notprivileged'. Zapewne zauważyłeś/aś, że `Dixie' po wysłaniu EHLO zwrócił także 250-XDATABASE... No właśnie, wysyłając XDATABASE chciałbym aby można było dokonać operacji na Bazie (po wcześniejszym dokonaniu autoryzacji ESMTP AUTH). Dostępne operacje to: ADD, MODIFY, REMOVE, gdzie odpowiednio byłoby to dodanie/zmodyfikowanie/usunięcie wpisu użytkownika z Bazy oraz UPLOAD -- możliwość wysłania własnego pliku `~/.anubisrc'. Dzięki takiemu rozwiązaniu na zdalnym komputerze nie byłby potrzebny nawet `~/.anubisrc' i pierwszy raz zdalny klient mógłby NAPRAWDĘ posiadać własny plik konfiguracyjny. Obecnie (przed 4.x) wszelkie pliki muszą się wcześniej znajdować na maszynie, gdzie Anubis pracuje, co oczywiście wymaga uwagi admina. Bo przecież jeżeli zdalny klient chce zmienić coś w swoim pliku, to potem musi to oczywiście zainstalować na Maszynie-A (tak jest obecnie i tak będzie dla trybu `Pixie'). Nowy tryb `Dixie' rozwiąże ten problem i uwolni klienta od konieczności kontaktu z administratorem Maszyny-A. Oczywiście wbudowany silnik obsługujący Bazę Anubisa sprawdzi czy przesyłany plik konf. jest prawidłowy (--check) i poinformuje o tym klienta, sprawdzi także MD5 tego pliku i porówna z tym, który jest wysyłany... Po co? * Mały program, który wysyła plik konf. klienta Właśnie, już prawie finał. Po stronie klienta istnieć będzie mały specjalny program, napisany niemal w dowolnym języku (C, Java, C#), którego zadaniem byłoby tylko wysłanie pliku konfiguracyjnego klienta do Bazy. Taki mały program mógłby pracować nawet w urządzeniu mobilnym, ale to tylko opcjonalny program. Klient nie musiałby z niego korzystać. Wyobraziłem sobie jednak sytuację, gdy: 1) klient loguje się na swoje konto na Maszynie-B 2) w `~/.profile' znajdowałby się wpis, który wywoła "specjalny-mały-program" i który obliczy MD5 pliku `~/.anubisrc' i jeżeli wpis w Bazie różni się, to aktalny plik zostanie wysłany do Bazy... 3) "specjalny-mały-program" oczywiście połączy się z Bazą poprzez ESMTP (TLS/AUTH) i XDATABASE. Oczywiście taki program byłby dodatkowym atutem i przydatny jako, że żaden obecny MUA nie potrafiłby skorzystać z Bazy Anubisa, ale być może w przyszłości w ramach projektu GNU, GNU Hydrant mógłby wspierać GNU Anubisa (tzn. XDATABASE)... *** Finał A klientowi pozostanie już tylko skorzystać z własnego MUA i nic więcej... żadnego Identd :). Właściwie jedyny wymóg dla trybu `Dixie' to obsługa ESMTP AUTH w MUA u klienta. Niestety, ale część MUA nawet pod Unix nadal nie potrafi obsługiwać ESMTP AUTH. Czyżby trzeba było użyć Anubisa podwójnie (także na maszynie klienta)? ;-). I ostatni szczegół to oczywiście co zrobić jeżeli dalszy MTA także wymaga ESMTP AUTH, a przecież jeden już został "zużyty" na Anubisa. I tu odpowiedź jest prosta, ponieważ GNU Anubis sam potrafi doskonale obsługiwać "esmtp-auth". * Podsumowanie dla trybu `Dixie': - nieco "wolniejszy" niż `Pixie', bo połączenie z MTA jest możliwe dopiero po udanej autoryzacji klienta. - nie wymaga Identd! - pozwala na "zdalne" używanie pliku konfiguracyjnych klientów. - opóźniona możliwość przetwarzania koperty SMTP (dopiero po udanym ESMTP AUTH). * P.S. Jeszcze odnośnie przechowywania plików w Bazie... Można je przechowywać w specjalnym katalogu jako osobne pliki o specjalnie zakodowanych nazwach (hashed), zaś w Bazie dodać pole, które będzie wiązało wpis użytkownika w Bazie z danym plikiem konfiguracyjnym. - KONIEC -