How to Configure Qmail on Fedora Core 1 Server

Erik Espinoza erik.espinoza at gmail.com
Wed Jul 28 04:32:44 UTC 2004


The person asking why this was a security implication had already said
he was going to use pop3s, for those who don't know that is pop3 over
SSL. SSL, you know Secure Sockets Layer, 128 bit encryption just like
when you go to https instead of http. In other words, the user/pass is
far from plain text.

That said, the security problem lies in that the pop/imap server drops
priveleges to the user who is checking their mail after
authentication. Meaning that the concentration of security is to make
the authentication layer (and the subsequent drop of privs) solid.
Should there be a buffer overflow in the program that reads your mail
and hands it to you, it MAY execute a program by the simple act of
parsing your mbox. Having this done as root would be much more
disastrous than as a regular user. This also gives users another port
to try brute force attacks to get root on your machine. This is why i
do not permit root logins on anything internet facing or otherwise.

Erik


On Tue, 27 Jul 2004 20:48:50 -0500, Jeff Vian <jvian10 at charter.net> wrote:
> On Tue, 2004-07-27 at 13:54, Craig White wrote:
> > On Tue, 2004-07-27 at 11:15, Fritz Whittington wrote:
> > > >
> > > *Mail read with Mozilla on a Windows machine from a POP3 server doesn't
> > > have root's privileges either!*
> > > (And yes, you can do anything in vi that you might want to do in emacs,
> > > so let's just ship *one* editor with the system and force everyone to do
> > > it *that* way, just because!  OK with you?  I thought not.)  Of course,
> > > I guess I could set up the foo alias and then read foo's mail with
> > > Mozilla on a Windows machine from a POP3 server.  Can you prove that to
> > > be even a tiny bit more secure?
> > ---
> 
> MUCH more secure, since the user foo would not have root privledges.  If
> that account is cracked they still are restricted on privileges.  If the
> root account is cracked all bets are off.
> 
> Pop3 and imap protocols pass user name and password in plain text when
> logging in.
> 
> The issue is not the privileges of the mail client but the security of
> the accounts when using plain text to log in and the possible privileges
> when logging in to those accounts if someone gains access by obtaining
> the password.
> 
> > that isn't the point though. If root can retrieve email from his account
> > - be it local or remote is the issue. You are differentiating a system
> > that doesn't differentiate. Restricting root's access locally would
> > require something like hosts.allow/deny or iptables, both of which is
> > beyond the safeguards of dovecot or whichever pop/imap daemon you
> > employ.
> >
> > Proving that accessing mail from account foo or account root via POP3
> > remotely is inherently more secure is not relevant.
> >
> 
> The security issue with reading mail as root via pop3 or imap is the
> password.  With these clients the password/username is passed in plain
> text and for security that is not acceptable as root.
> 
> Sniffers to read plain text from the network are common.
> 
> 
> 
> > the topic of both vi and emacs doesn't correlate.
> > ---
> > >
> > > >Thus your argument about working
> > > >'with' or 'on' really doesn't hold water.
> > > >
> > > >
> > > That refers to something of an additional topic:  qmail versus
> > > sendmail/postfix/dovecot and the ease of installing without having to
> > > read (first finding) bunches of docs and becoming something of a guru on
> > > the subject.
> > >
> > > Also, be aware that (IMHO) once any security issues are removed, this
> > > becomes a "religious" (that is, personal preference) issue just like the
> > > choice of a text editor.
> > ---
> > I do not seek to engage in a debate of one editor over another, or one
> > MTA versus another. I fail to see how this impacts the topic anyway.
> >
> > Security issues being removed is between the user, his distro and
> > configuration. The distro makes assumptions of best use. The user can
> > override some of these decisions via configuration and the rest by
> > recompiling (they do provide the source code if you wish). This seems to
> > be a very logical system and when I want to work 'with' a system rather
> > than 'on' a system (your terms), I generally defer to the greater minds
> > than mine because I credit them for having foresight to consider the
> > security implications.
> >
> > Craig
> >
> 
> --
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>





More information about the fedora-list mailing list