Mailing List Archive

Database password encryption in dbmail.conf
Hi All,


I am new to this list, thus apologies if the question was asked before.

How do I configure securely the database authentication credentials in

dbmail.conf?


Is there a way to encrypt the password?


Thank you in advance,

Mauro

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
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.

---

Andrea Brancatelli

On 2018-06-23 14:05, Mauro Mozzarelli wrote:

> Hi All,
>
> I am new to this list, thus apologies if the question was asked before.
>
> How do I configure securely the database authentication credentials in
>
> dbmail.conf?
>
> Is there a way to encrypt the password?
>
> Thank you in advance,
>
> Mauro
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
Hi.

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.
>
> ---
>
> Andrea Brancatelli
>
> On 2018-06-23 14:05, Mauro Mozzarelli wrote:
>
>> Hi All,
>>
>> I am new to this list, thus apologies if the question was asked before.
>>
>> How do I configure securely the database authentication credentials in
>>
>> dbmail.conf?
>>
>> Is there a way to encrypt the password?
>>
>> Thank you in advance,
>>
>> Mauro
>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail@dbmail.org
>> http://lists.nfg.nl/mailman/listinfo/dbmail
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
That is correct. I was looking to secure DB access by encrypting the
credentials in the configuration file.

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.


On 27/06/18 07:23, Thomas Raschbacher wrote:
>
> Hi.
>
> 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.
>>
>> ---
>> *Andrea Brancatelli *
>>
>> On 2018-06-23 14:05, Mauro Mozzarelli wrote:
>>
>> Hi All,
>>
>>
>> I am new to this list, thus apologies if the question was asked before.
>>
>> How do I configure securely the database authentication credentials in
>>
>> dbmail.conf?
>>
>>
>> Is there a way to encrypt the password?
>>
>>
>> Thank you in advance,
>>
>> Mauro
>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail@dbmail.org <mailto:DBmail@dbmail.org>
>> http://lists.nfg.nl/mailman/listinfo/dbmail
>>
>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail@dbmail.org <mailto:DBmail@dbmail.org>
>> http://lists.nfg.nl/mailman/listinfo/dbmail
>
>
>
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
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

> 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

> 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
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
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
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
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
>> DBmail@dbmail.org
>> http://lists.nfg.nl/mailman/listinfo/dbmail
>
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
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
>>> DBmail@dbmail.org
>>> http://lists.nfg.nl/mailman/listinfo/dbmail
>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail@dbmail.org
>> http://lists.nfg.nl/mailman/listinfo/dbmail
>

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
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
>>>> DBmail@dbmail.org
>>>> http://lists.nfg.nl/mailman/listinfo/dbmail
>>>
>>> _______________________________________________
>>> DBmail mailing list
>>> DBmail@dbmail.org
>>> http://lists.nfg.nl/mailman/listinfo/dbmail
>>
Re: Database password encryption in dbmail.conf [ In reply to ]
Am 04.07.2018 um 15:34 schrieb Mauro Mozzarelli:
> Perhaps I was not clear. Admins have to have access to dbmail.conf. But
> they cannot be be handed the DB credentials in clear

it's not possible

> Preventing admin access to dbmail.conf should not be necessary and it is
> not acceptable.

what do they do all the time in dbmail.conf - i don't see any value
there which changes more than every few year if at all

-rw------- 1 root root 2.2K 2016-06-09 01:00 /etc/dbmail.conf

> 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

but you still can decrypt it in that deployment, it's just more work to
do so, if the service can decrypt it it needs to have access to the key
and so have i as root

if you use the same credentials for more than one deployment you are
doing it wrong to begin with

someone could introduce a "/etc/dbmail.conf.d/" folder with config
snippets merged (likely you need to provide a patch at your own becasue
it's something nobody else asked before all the years) but even with
sudoers it will be tricky to allow edit/watch files but not a sepcific
one with the credentials

> 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..
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Am 04.07.2018 um 15:45 schrieb Thomas Raschbacher:
> 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

can't work - dbmail-util needs to read it too and so the user invoking
dbmail-util is able to do the same

either i am admin for a service or not.....
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEEnStGzbwUCjZ1OuTXMxdNWliSt7gFAls80aUACgkQMxdNWliS
t7hALgwApqlzFtYs91cpQS+Hc2zisckmow9zKGdulleBpfaPTpm/J8cqeMaF9Ozv
VlBxKKmZXQqRskPJm3+bDjs+Jh/3JpEhuatK9v3nFl3y4H3P/0TMqn6sDZyFDUmM
NOCwWEujM7RMVZpiRjHvu/gi7GrWrYHRooj/9lro9RK9DLeDYj0jHCSyQoHVL1ST
T7LzlvqLhIgX5jhnI3sP85/iS/45LUrNzJARIUAi95lTDUG0MEozqh5vZJp049i9
4CwhrQVXknm9le7yknDxPTeu7K6+156QFNC+Zb2YDM7Wlj9k6ytV2GxIGv0gFCty
6SYMMysffiO+UovK310xScMqvSjHzI+BfPda8icOu07NArpIsSNSHi60isUZsxRD
Lxi0ZmKMeg3Fqot3NNnaGfEF/ALfIWMQxn/P8sTMYxqJcwp3D3kmv6O6E6mMh4D5
PYoCDIGU/ton9h9ER3+4xluBKgONZ9Dq42hhbWbcR6D9bvN6Hjw+Pf7Yo5J527xK
1xCIExz3
=fTzi
-----END PGP SIGNATURE-----
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail
Re: Database password encryption in dbmail.conf [ In reply to ]
On 2018-07-04 15:54, Reindl Harald wrote:
> Am 04.07.2018 um 15:45 schrieb Thomas Raschbacher:
>> 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
>
> can't work - dbmail-util needs to read it too and so the user invoking
> dbmail-util is able to do the same
>
Well I *think* you could probably only allow dbmail-util process
/executable to read the file and no others using SELinux or something
like that but that seems rather complex .

> either i am admin for a service or not.....
that is what I think too to be honest .. i mean with maildir based
servers the admins would still have access to all the mails too so ...