Re: Database password encryption in dbmail.conf

Thomas Raschbacher <[email protected]> Mon, 02 Jul 2018 07:15:37 +0200
Newsgroups gmane.mail.imap.dbmail
Message-ID <[email protected]>
Hi.

If you used a symetric encryption you'd still have the decryption 
available within the dbmail binaries, and - since it is open source - 
you'd be able to look at the algorithm and still somehow decrypt the 
key.
Asymetric might be slightly better, but still the same applies in the 
end if someone has root on your system ...
Best would be if you added some other security measures to make 
dbmail.conf inaccessible to your admins (selinux or something should be 
able to do that somehow i think )

or to make it even easier: just give your dbmail admins non-root access 
with sudo configured to only run dbmail-users and dbmail-util (or 
whatever is needed):

https://superuser.com/questions/767415/limit-user-to-execute-selective-commands-linux#767419

that way your mail-admins cannot access dbmail.conf directly -- and make 
sure you do not have things like strace or gdb on your servers to be 
safe..

Regards

On 2018-06-29 20:35, Mauro Mozzarelli wrote:
> Hello Reindl,
> 
> Please see my follow-up below. I find dbmail has great potential.
> 
> On 27/06/18 22:22, Reindl Harald wrote:
>> 
>> Am 27.06.2018 um 20:46 schrieb Mauro Mozzarelli:
>>> That is correct. I was looking to secure DB access by encrypting the
>>> credentials in the configuration file.
>> how do you imagine that to start with?
>> 
>> dbmail needs to authenticate against the database and so it needs the
>> credentials - frankly - even if you would be able to enter encrypted
>> passwords in "dbmail.conf" the dbmail processes would need the
>> password/key to decrypt it and so you just move it from A to B
> 
> Correct. Dbmail should include a tool to encrypt the password (the
> tool provides encryption only), to then save it into the configuration
> file in encrypted form. If you are familiar with JEE Application
> servers like JBoss or Websphere, for example, this is the basic
> security offered. More advanced security involves a third party key
> store.
> 
> Going for the basic, the tool encrypts the password using a 2 way
> encryption and then the dbmail server reads the encrypted password and
> decrypts it using the reverse process.
> 
> Why should we encrypt the password? This is not only for protections
> from malicious access, but so that the dbmail "administrator" role is
> not provided un-necessarily with database credentials that would allow
> the administrator to gain access to confidential emails. This way a
> small/medium/large company can achieve customers' confidential
> information protection through separation of concerns. It is a
> necessary step to grade a product as adoptable by commercial
> organizations.
> 
> Technically the encryption algorithm and seed/keys are stored inside
> the dbmail software package and obfuscated.
> The password encryption tool typically would not necessarily be
> deployed on the server running dbmail.
> 
>>> I know about setting permissions, but that is quite a lightweight and
>>> ineffective measure.
>>> 
>>> Unix sockets implies a single tier hardware deployment. That as well
>>> does not suit the multi-tiered, firewall protected deployment to 
>>> protect
>>> the Database tier. Clearly if I protect the DB tier, and then write 
>>> the
>>> password in clear in the configuration file of the tier directly 
>>> exposed
>>> to users, then the security of the DB is also reduced.
>>> 
>>> This is a security issue.
>> it is not - dbmail starts as root, reads the config and drops
>> privileges, if someone can read "/etc/dbmail.conf" which can only be
>> accessed by root you have lost anyways
> 
> Please see above. This isn't only to protect from malicious access,
> but also to protect customers' and users' privacy in business
> organizations, and thus to protect the brand from the damage caused by
> confidential information leaks.
> You need to think like a business.
> 
>>> On 27/06/18 07:23, Thomas Raschbacher wrote:
>>>> I think Mauro meant if it is possible to have the Database 
>>>> credentials
>>>> themselves encrypted in dbmail.conf. - To answer that: I don't think
>>>> that is possible, but if you configure permissions properly (0600 or
>>>> maybe 0660 then noone but the dbmail user and root should have 
>>>> access
>>>> to it) - or depending on which Database you use you could look into
>>>> using unix sockets instead of tcp/ip
>>>> 
>>>> Regards
>>>> 
>>>> On 2018-06-25 08:24, Andrea Brancatelli wrote:
>>>> 
>>>>> Password encryption is mostly transparent on the application side,
>>>>> you just have to choose an encryption method when you create an 
>>>>> user
>>>>> with dbmail-users - the password will be encrypted on the db and
>>>>> DBMail will handle it transparently
>> _______________________________________________
>> DBmail mailing list
>> [email protected]
>> http://lists.nfg.nl/mailman/listinfo/dbmail
> 
> _______________________________________________
> DBmail mailing list
> [email protected]
> http://lists.nfg.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
[email protected]
http://lists.nfg.nl/mailman/listinfo/dbmail
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE62Mx48XBif2bZfwnzmuFS0rK9ToFAls5tPoACgkQzmuFS0rK
9TriYBAAlPtOczhjtlYmE3mFqfz/e3ZmVayYfx2v3WCQSFXBqzLqohwCOopFCCEX
zWXndRNiD6iMpu/zeIKjxoKbm5mfweoM8nSKLv1TOxxvpkCPXw36kTRlWdFzyCuv
j67Z95qhK5wbJz4NWdQTrUL/WfYFNk20pGa7Jzvmm2RHgFXw/eaq0z9uoag0RfSu
ouCPpmZP1TczSfSKdELQUZB618fX0epOvs2DNntp+G4DUsy+gSEumcYW7fmRCKTO
FzEjJcqHsA3hWUf/whYmYl+7FJJ7nQTplA1jq7vpdjEpeveYOXl3p1U/aResv5A3
07dU0vBoeyASTEX7JHTySyserDi1yQHI81an7k91Uo/aqPgeTw90nZjB9vQy9cQb
PXQ446kNxAhgLQWxiorw16DbVni1KZ79IB1C59uUWuO22WmRnDFht2+DgGhtA3pt
iBA5G+6ckJM3gWqpMyAl5Kc6E5gCXCK4mpHmfN8Sz8HR6xJr5Obj2GjrlaJT5jSU
6yMt3+gJo7xzTkpm2Lv8f9bU095n1odJzG5bxDkMt4ix5Wit0d2wPNAOAQM6b6g8
hD7wbIpQadnfHWvdnkv9Vvz2Hk89Nkr8wJSbysmDHHEt0Cf8jXJC/kKUinBxsr7m
KjKgmF69fqDU7uPH1SHrHdEjvb02byolfHmWkZ0ExejclgoEMm4=
=ubvf
-----END PGP SIGNATURE-----