                  =================
                  |  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 klientw
w programie GNU Anubis, wersja 4.x.

*** Problem

Dotychczasowa metoda polegaa na autoryzacji uytkownika za pomoc
usugi AUTH, popularnego demona o nazwie Ident, ktry nasuchuje
na porcie TCP 113. Zalet tego rozwizania bya szybko ustalenia
z kim do czynienia ma serwer, tj. nazwy klienta (user name) lub jego
identyfikatora (UID). Metoda ta pozwala na dokonanie waciwej
autoryzacji zanim klient wyle swj "pierwszy bajt". Ponadto pozwala
na przetwarzanie caej koperty SMTP. Wad natomiast jest konieczno
posiadania w systemie dziaajcego demona Ident, co nie zawsze jest
moliwe (urzdzenia mobilne), bd obniajc nieco bezpieczestwo
systemu (konieczno otwartej transmisji poprzez sie identyfikatora
uytkownika).

*** Rozwizanie

Podzia na dwa tryby pracy:
1) tradycyjny (a.k.a. `Pixie')
2) nowy (a.k.a. `Dixie')

* Krtka charakterystyka:

1) `Pixie'

   - Serwer dokonuje autoryzacji na podstawie usugi AUTH.
   - Moliwo natychmiastowego przetwarzania caej koperty SMTP.
   - Tunelowanie w locie pocze midzy MUA a MTA.

2) `Dixie'

W tym trybie Anubis musi obsugiwa wasn baz uytkownikw i hase,
dodatkowo "tumaczy loginy" (o tym pniej), oraz przechowywa pliki
konfiguracyjne uytkownikw (jako dodatkowa opcja i zaleta -- o tym
take pniej).

Tryb `Dixie' dokonuje autoryzacji poprzez protok ESMTP AUTH.
W tym trybie NIE MONA dokona wczesnego przetwarzania koperty SMTP
(np. "if command[EHLO]"). Przetwarzanie koperty mona dokona dopiero
po udanej autoryzacji uytkownika. W tym trybie wystpuje OPӬNIENIE
przy czeniu si z MTA (poniewa najpierw trzeba poczeka na ESMTP AUTH,
a dopiero pniej, po ustaleniu tosamoci i ewentualnie szczliwej
autoryzacji, wczyta plik konfiguracyjny klienta i poczy si
z wybranym MTA). W tym trybie klient nie moe take rozpocz wysyania
listw dopki nie zostanie prawidowo rozpoznany i zaakceptowany przez
program serwera.

* Szczegy:

Istnieje ogromna rnica midzy 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 dziaa ze strony
uytkownika. Tymczasem tryb `Dixie' musi najpierw symulowa
zachowanie agenta pocztowego (MTA), aby dokona autoryzacji
ESMTP AUTH.

Przedstawi teraz prost sytuacj dla `Dixie', gdzie wystpuje
Maszyna-A, na ktrej pracuje "nowy" Anubis oraz Maszyna-B,
z ktrej czy si klient (MUA). Ustalmy take, e Anubis
przechowuje specjaln baz uytkownikw (ich loginy/hasa).

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>
(przesanie specjalnego loginu i hasa do Anubisa)

W tym momencie po stronie Anubisa nastpio dokonanie autoryzacji
klienta na podstawie danych z wasnej Bazy. Chciabym aby taka Baza
zawieraa poza waciwym loginem i hasem take nazw uytkownika
na Maszynie-A wraz z hasem. Zakrcone? Powiedzmy, e w Bazie
istnieje wpis:

 JohnSmith:ZAKODOWANE-HASO-1, John

Klient poprzez ESMTP AUTH wysa JohnSmith:ZAKODOWANE-HASO-1
a to zgodzio si z wpisem w Bazie Anubisa. Nastpnie Anubis,
ktry w tym momencie jeszcze pracuje jako superuytkownik
dokonuje translacji i dalej stosuje uprawnienia uytkownika "John".
Takie rozwizanie moe take pozwoli na bardzo elastyczn Baz,
ktrej admin nie musi nawet kontrolowa, tzn. e kady moe
dopisa tam SWOJE dane lub je usun (oczywicie kady kto bdzie
mia prawo dokonywania takich zmian w Bazie). Na przykad ODBC, SQL?

Ale wracajc do naszej sesji -- ustalmy, e wszystkie dane zostay
zweryfikowane i teraz Anubis pracuje ju jako zwyky uytkownik,
po czym wczytuje plik `~/.anubisrc'. W tym momencie na podstawie
pliku konf. uytkownika Anubis czy si z MTA i dalej zachowuje si
ju w tradycyjny sposb jako tunel/proxy i procesor poczty,
po czym wysya do klienta:

A: 220 OK, Welcome. Continue sending your mail!


* Dalsze szczegy:

Pene zrozumienie nowego trybu pozwoli take uzmysowi sobie,
e nie jest moliwa praca dwch trybw jednoczenie.
To administrator Anubisa bdzie musia ustali, z ktrego
trybu bdzie chcia skorzysta. By moe uda si zaprogramowa
przejcie z jednego trybu do drugiego bez koniecznoci restartu
demona... Aczkolwiek nie jest to absolutna konieczno.
Restart demona w celu zmiany trybu dziaania bdzie rwnie
waciwym rozwizaniem. W tym miejscu przedstawi dla kogo
i jaki tryb bdzie przeznaczony.

Tradycyjny tryb `Pixie' przewiduj dla osb, ktre planuj
uywa Anubisa w obrbie jednej maszyny lub zamknitej sieci
i pozwalaj na uycie Identd. W takim przypadku uycie Ident
jest cakowicie bezpieczne.

Za nowy tryb `Dixie' przewiduj dla osb, ktre uruchomi
GNU Anubisa na jednej maszynie, za wszelkie poczenia
bd dokonywane z innych komputerw. A wic wszystko zdalnie
i zakadamy tutaj, e adna maszyna zdalna nie bdzie miaa
usugi 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 zdyem opisa :^). Mianowicie, Baza
Anubisa drugi login potrzebuje aby przej w tryb uytkownika
i wczyta lokalny `~/.anubisrc'. Ja natomiast zaoyem,
ze Baza moe przechowywa take (uwaga!) pliki konfiguracyjne
poszczeglnych klientw. A wic w Bazie musi si znale dodatkowa
flaga dla kadego uytkownika, ktra bdzie informowaa o tym czy
dokona translacji i wczyta lokalny `~/.anubisrc', czy te wczyta
tylko plik znajdujcy si w Bazie. Oczywicie dla bezpieczestwa
GNU Anubis mimo braku translacji nadal bdzie musia przej
w tryb uytkownika, ale moe to zrobi zwyczajnie na podstawie
`user-notprivileged'.


Zapewne zauwaye/a, e `Dixie' po wysaniu EHLO zwrci
take 250-XDATABASE... No wanie, wysyajc XDATABASE
chciabym aby mona byo dokona operacji na Bazie
(po wczeniejszym dokonaniu autoryzacji ESMTP AUTH).

Dostpne operacje to: ADD, MODIFY, REMOVE,
gdzie odpowiednio byoby to dodanie/zmodyfikowanie/usunicie
wpisu uytkownika z Bazy oraz UPLOAD -- moliwo wysania
wasnego pliku `~/.anubisrc'.

Dziki takiemu rozwizaniu na zdalnym komputerze nie byby potrzebny
nawet `~/.anubisrc' i pierwszy raz zdalny klient mgby NAPRAWD
posiada wasny plik konfiguracyjny. Obecnie (przed 4.x) wszelkie
pliki musz si wczeniej znajdowa na maszynie, gdzie Anubis pracuje,
co oczywicie wymaga uwagi admina. Bo przecie jeeli zdalny
klient chce zmieni co w swoim pliku, to potem musi to oczywicie
zainstalowa na Maszynie-A (tak jest obecnie i tak bdzie dla
trybu `Pixie'). Nowy tryb `Dixie' rozwie ten problem i uwolni
klienta od koniecznoci kontaktu z administratorem Maszyny-A.
Oczywicie wbudowany silnik obsugujcy Baz Anubisa sprawdzi
czy przesyany plik konf. jest prawidowy (--check) i poinformuje
o tym klienta, sprawdzi take MD5 tego pliku i porwna z tym,
ktry jest wysyany... Po co?

* May program, ktry wysya plik konf. klienta

Wanie, ju prawie fina. Po stronie klienta istnie bdzie
may specjalny program, napisany niemal w dowolnym jzyku
(C, Java, C#), ktrego zadaniem byoby tylko wysanie pliku
konfiguracyjnego klienta do Bazy. Taki may program mgby
pracowa nawet w urzdzeniu mobilnym, ale to tylko opcjonalny
program. Klient nie musiaby z niego korzysta. Wyobraziem
sobie jednak sytuacj, gdy:

1) klient loguje si na swoje konto na Maszynie-B
2) w `~/.profile' znajdowaby si wpis, ktry wywoa
"specjalny-may-program" i ktry obliczy MD5 pliku `~/.anubisrc'
i jeeli wpis w Bazie rni si, to aktalny plik zostanie
wysany do Bazy...
3) "specjalny-may-program" oczywicie poczy si z Baz
poprzez ESMTP (TLS/AUTH) i XDATABASE.

Oczywicie taki program byby dodatkowym atutem i przydatny
jako, e aden obecny MUA nie potrafiby skorzysta z Bazy
Anubisa, ale by moe w przyszoci w ramach projektu GNU,
GNU Hydrant mgby wspiera GNU Anubisa (tzn. XDATABASE)...

*** Fina

A klientowi pozostanie ju tylko skorzysta z wasnego MUA
i nic wicej... adnego Identd :).

Waciwie jedyny wymg dla trybu `Dixie' to obsuga ESMTP AUTH
w MUA u klienta. Niestety, ale cz MUA nawet pod Unix nadal
nie potrafi obsugiwa ESMTP AUTH. Czyby trzeba byo uy
Anubisa podwjnie (take na maszynie klienta)? ;-).
I ostatni szczeg to oczywicie co zrobi jeeli dalszy MTA
take wymaga ESMTP AUTH, a przecie jeden ju zosta "zuyty"
na Anubisa. I tu odpowied jest prosta, poniewa GNU Anubis
sam potrafi doskonale obsugiwa "esmtp-auth".

* Podsumowanie dla trybu `Dixie':

- nieco "wolniejszy" ni `Pixie', bo poczenie z MTA
  jest moliwe dopiero po udanej autoryzacji klienta.
- nie wymaga Identd!
- pozwala na "zdalne" uywanie pliku konfiguracyjnych klientw.
- opniona moliwo przetwarzania koperty SMTP
  (dopiero po udanym ESMTP AUTH).

* P.S. Jeszcze odnonie przechowywania plikw w Bazie...

Mona je przechowywa w specjalnym katalogu jako
osobne pliki o specjalnie zakodowanych nazwach (hashed),
za w Bazie doda pole, ktre bdzie wizao wpis
uytkownika w Bazie z danym plikiem konfiguracyjnym.

  - KONIEC -

