Re: [Exim] exim & intetd

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Kai Henningsen
Datum:  
To: exim-users
Betreff: Re: [Exim] exim & intetd
ph10@??? (Philip Hazel) wrote on 09.01.02 in <Pine.SOL.4.33.0201092125010.10252-100000@???>:

> On 9 Jan 2002, Kai Henningsen wrote:
>
> > > Does anybody have any good ideas for detecting "called from inetd"?
> >
> > Why do you *need* that?
> >
> > > "stdin is a socket" on its own is not good enough - any user could set
> > > that up.
> >
> > And why is that a problem?
> >
> > Seems to me Exim should react the same to "I'm being fed mail via a pre-
> > connected socket" regardless who did it.
>
>
> This would mean that a user could run a program which listened on some
> non-privileged port, waited for a connection, and passed it on to Exim.
> Exim would behave as if called from inetd, doing the host checking etc.


Yup.

> This means that an unprivileged user could open up the server to
> non-privileged ports. I think this is probably a bit of a security
> exposure that some people would not like.


I don't see any problem, here.

What security is lost when you can do the exact same thing you can do over
port A also via port B, with the exact same security once connected?
Especially as any firewall would only let port A through anyway.

Now, if you're talking a TCP forwarder instead of a inetd-like setup,
that's a little different; you no longer have any info about the original
host. You can, OTOH, recognize that it comes from the local host. And if
you happen to have identd, you can also find out which local user is
responsible. Of course, there's no difference between forwarding and
originating, here.

Remember, with a TCP connection, you can always find out the port and ip
address of both sides (modulo masquerading and so on, of course). You
could, for example, make Exim reject any connection whose local port
wasn't the SMTP port, assuming the SMTP port to be guarded by the
priviledge necessary to open it. (Configurable, of ourse.) Or if not
rejecting it, handling it like an unpriviledged local submission if that
is feasible, with the envelope sender like what is given to -f. (Might
need to have a way to locate the responsible local user for that. Real
user id on start? Isn't that the same local submission does anyway?)

MfG Kai