                  =================
                  |  GNU Anubis 4 |
                  =================

Tytuł projektu:   "Pixie & Dixie"
Status:           Szkic
Opracował:        Wojciech Polak <polak@gnu.org>, (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
<TLS>
B: AUTH <WYBRANA METODA>
(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 -

