Re: Database password encryption in dbmail.conf

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--===============2039394815==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	boundary="=_80bbc5d8717312c730748d303a3de7b3"; micalg=pgp-sha256

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_80bbc5d8717312c730748d303a3de7b3
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

Hmm ..

I guess you could write a patch for that, but you would need to make 
sure that seed is stored somewhere the admins cannot access it, 
otherwise the whole thing would be pointless (or only making it a bit 
more complicated for someone who really wants to do it).
Alternatively what would probably be easier would be to write a patch to 
load the database config from a different location, and make that file 
not readable by your admins (through whichever means) but only readable 
by root / the dbmail process

That said .. do your mail admins have full root access on these systems? 
Do you have SELinux or anything on there too?

Regards

On 2018-07-04 15:34, Mauro Mozzarelli wrote:
> Hello Thomas,
> 
> 
> Perhaps I was not clear. Admins have to have access to dbmail.conf.
> But they cannot be be handed the DB credentials in clear.
> 
> Preventing admin access to dbmail.conf should not be necessary and it
> is not acceptable.
> 
> JBoss is open source too, but they appear to be having resolved the
> problem. One could introduce a variable encryption seed at
> installation time which is only valid for that deployment.
> 
> 
> On 02/07/18 06:15, Thomas Raschbacher wrote:
>> 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
>> 


--=_80bbc5d8717312c730748d303a3de7b3
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Disposition: attachment;
 filename=signature.asc;
 size=833
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE62Mx48XBif2bZfwnzmuFS0rK9ToFAls8z3kACgkQzmuFS0rK
9TrZcw//Uhrpwos7dN050PbymAw3kuUAR7ooVWZtRPO3/XH6r8E5a1IIk5+niZLv
aELTUNJhjpecPWZapEfKEeKa8OnNKN/8rRSCzmjKUh1rUIedvJ8+iV3+jYfh8cIY
udIlA++ovMVF/SciiavwXFoG36KVXnOv4THwrv7lA3NHLk/z84T1R3HnLBr9XEl7
nTW12HtjKh2yMjWzhjmejNR9RH2m4UqKdWi3pHIE0Y8nF7dV09xxrnsSukMA0TIR
BaYXlukb0vmuRdYF/125LivpTaGvmaJhpidHLUEXd4VktWR8rkEx9W02F/1U3Gtk
gZhbJMOy0kDPhvbDYA3O+oEpD35pcESmG6QItnYDe8+pJJzE36SDj9CiRPUHcQQI
c6Z75a0m/Ty14IjrWHfjyF6SZjhJP3XGIsEL0/2a32LDn/UVI3cDoOnqFdcOJfCr
fZustjd0k6bj6gUw/JbdJCDAzsasHzwgGPVsMdN/yifI+RVpt5EeXXd2aZzs7Ud+
ZgN7DyeLaDrLO1oWl0cedKD5j7cxFMo2jb3/+Nv6Jlumxg0JER///sYEnr2DR3u5
3wUYmMuk5gqRw82XlVS8GzxFPAzMJUb3IZpGY5UfdVx64vM5Zy/i2sTzFZwukL7V
cvDCQokX6IR7rcsCFtUMcG7WjmSq48qXBj3s54Olc0vw5fnUcZo=
=PLo/
-----END PGP SIGNATURE-----

--=_80bbc5d8717312c730748d303a3de7b3--

--===============2039394815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
DBmail mailing list
[email protected]
http://lists.nfg.nl/mailman/listinfo/dbmail

--===============2039394815==--