* Daniel Brown <[EMAIL PROTECTED]> [20030929 21:59]: wrote:
> Wrote Odhiambo Washington:
> 
> > * Alan Hicks <[EMAIL PROTECTED]> [20030929 13:33]: wrote:
> >
> [...]
> > > You need to set the user permission for the process that will be
> > > delivering the mail.  In my setup I have dbmail owner set to 'mail'
> > > and in my exim.conf have the delivery as follows:
> > > 
> > > local_delivery:
> > >   driver = pipe
> > >   command = "/usr/local/sbin/dbmail-smtp -d [EMAIL PROTECTED]"
> > >   return_fail_output
> > >   user = mail
> > > 
> > > If you have the dbmail owner set to anything else, just set the
> > >   user = anything else
> > 
> > ;)
> > 
> > 
> > > PS Setting the user to nobody would allow the user nobody (such as apache
> > > or other low level users) to submit mail.


The question that I raised was actually concerned with the above statement.
It was more to do with mail submission that the security on the config files.


> Since the DBMail config files also includes the SQL username and
> password to get to the DBMail system's database, anyone able to view
> it can thus access the SQL server, and then proceed to:
> 
>  * Read, delete, or alter existing messages
>  * Forge new messages
>  * See or change user passwords
>  * Delete user accounts or create new ones (ex: temporary spam-reply
>    mailboxes)
>  * Redirect messages from one mailbox to another (ex: the attacker's
>    so they can continue reading someone else's mail)
>  * Trash your DBMail tables and cause DBMail to fail completely
>    (assuming enough access is granted to that SQL username)
> 
> All of those possibilities is serious.  There may be more I haven't
> even touched on yet, too.
> 
> To mitigate these risks, it's best to install the DBMail config files
> with a unique username, and then set the permissions on the DBMail
> config files (at minimum the file containing the SQL user/pass)
> to only allow read-access from that username.
> 
> ANY access granted to a user used for any other purpose, for example
> Apache's "nobody" user, then programs also running under that user
> (such as normal PHP scripts!) would be able to read your DBConf file,
> and then do the harm I listed above.
> 
> I hope this thoroughly explains the security aspects. :)

yes, a brilliant lesson in security (refresher course ;)), but I think
the only place we failed to understand one another was on the statement
above -- the one you wrote with PS -.

The rejoinder by Paul J. Stevens made this all too clear.



Thank you.

-Wash

-- 
Odhiambo Washington   <[EMAIL PROTECTED]>  "The box said 'Requires
Wananchi Online Ltd.  www.wananchi.com      Windows 95, NT, or better,'
Tel: +254 2 313985-9  +254 2 313922         so I installed FreeBSD."   
GSM: +254 72 743223   +254 733 744121       This sig is McQ!  :-)

It was a book to kill time for those who liked it better dead.

Reply via email to