inetdaemon

[Tomasz Kłoczko]

On Sun, 6 Oct 2002, Radosław Kintzi wrote:

> On Sun, Oct 06, 2002 at 04:28:54PM +0200, Radosław Kintzi wrote:
> > *** rlinetd 
> > w dokumentacji (man rlinetd.conf) jest napisane, że nie ma konieczności 
> > użycia zewnętrzengo wrapera (np. tcpd), ponieważ jego funkcjonalność
> > udostępnia wbudowana opcja tcpd. Niestety kontrola dostępu przez
> > wbudowane mechanizmy rlinetd nie działa. Rlinetd jest linkowany 
> > z libwrap jednak na pliki hosts.(deny|allow) nie raguje, a właściwie
> > raguje dziwnie: 
> > 
> > [root w dom tcpd]# cat hosts.deny
> > /usr/sbin/in.ntalkd: ALL
> > in.ntalkd: ALL
> > 
> > [root w dom tcpd]# cat hosts.allow
> > [root w dom tcpd]#
> > 
> > A połączenie normalnie jest realizowane. Gdy w hosts.deny jest tylko:
> > ALL: ALL, to rlinetd nie pozwala na połączenie.
> Sprawdziłem: na inetd powyższa konfiguracja działa poprawnie (tzw.
> w obu przypadkach uniemożliwia połączenie). Znaczy to tyle, że tcpd
> z tcp_wrappers działa poprawnie a rlinetd nie. Ciekawe dlaczego? Ktoś
> już słyszał o czymś takim?

Zdaje się że rónica wynika z tego że rlinetd używa nazw z services, a
inetd używa nazw plików wykonywanych od poszczeółnych usług i jakoś to 
pzrekazyje do środowiska tcp_wrappers (jakieś dwa alata temu już 
coś o tym było ale nie pamiętam szczegułów).

> > Nasza domyślna konfiguracja korzysta właśnie z wbudowanych mechanizmów
> > rlinetd. To IMHO sec dziura i to taka, za którą my jesteśmy odpowiedzialni. 
> > Powinniśmy to udokumentować, uzależnić rlinetd od tcp_wrapers i zmienić 
> > domyślną konfigurację (oczywiście jeżeli to ja gdzieś nie szczeliłem
> > gafy;).
> To jak z tym będzie? To pytanie do SecTeamu.

Wsensie że nie jest to jednolicie w inetd i rlinetd ?
To jest poprostu byk :)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*