@tbordaz, I see there is a new CLI tool (ds-keyring.py), but would it be very difficult to add this to dsctl? Then from the instance name you can automatically get the dse.ldif location, etc.

"Keyring is not used because pin.txt exists"

@mreynols, merging ds-keyring.py into dsctl looks a very good idea. Initially it was keyring focus but later had to gather more and more data from the instance (serverId, security, pin file). Thanks for this idea, I will implement (try) it.

@tbordaz I have a concern about use of this functionality in containers. Keyring is not namespaced, so you should be able to disable its use in a container. The patch, as it is now, doesn't allow that. Once you built with keyring support, there is no fallback to use of systemd services, for example.

@abbra, at the moment, if pin.txt exists it assumes that the admin accepts the risk and then there is no need to store the password in keyring.
It could be an option, to store it even if pin.txt exist and even to remove the pin.txt.

@abbra, would it be acceptable to use pin.txt (so no keyring) in container ?
If you build with keyring flag, the server will try to retrieve the password from keyring but if it is not available it will fallback to pin.txt and then to systemd prompt.

My understanding exactly the fallback is not happening because you made it compile time #ifdef, not a runtime 'if'.

also, I see in Fedora 31 that dirsrv has both pwdfile.txt and pin.txt, with pretty much the same password in both.

@abbra you are right. IIRC pwdfile.txt is produced by dscreate or lib389 (from pin.txt) when creating NSS db/keys/ssca . I think it is a leftover from security initialization and could/should likely be removed.

@abbra I misunderstood your question regarding keyring fallback. I answered regarding svrcore fallbacks :(

Right it is currently compile option, I did not make keyring runtime option. Is it what you are asking for ?

@tbordaz yes, I think it needs to be a runtime option. Whether it would be driven by a configuration or by a runtime decision as a fallback, I don't know. Keyring access would not fail in container, the keyring storage is just not isolated so would theoretically be accessible from other containers.

I'm not going to oppose this feature because I think it comes from customer requests. But at a high level I'm going to say "it doesn't enhance security at all" and represents a communication issue where we are unable to express threat and risk models to our consumers so they can understand the value of their assets.

To explain, if someone has filesystem access to your directory server instance they don't care about "getting the TLS keys". If someone has filesystem access to your directory server they can access the database that contains every single user hash (pbkdf2, or md4 aka cleartext in ipa with adtrust enabled). They can also then modify this content, read dse.ldif, reset directory manager pw, and then do anything they like such as adding their own user account, insert them to admin groups, reset other account pws .... The risk of compromising an IDM system like 389 is that people target it because it grants access to everything ELSE of business value.

There is a difference between a theoretical risk (IE cryptographic attacks and people stealing TLS keys) and a real risk (gaining access to business applications of value, finding personal data etc). Any serious attacker wants access to your accounts and other business applications - and won't care about your TLS keys as gaining access to the LDAP server at all already represents a complete compromise of all attached applications and thus, game over.

So with this in mind, I'm going to point out - pin.txt on the same filesystem as the dirsrv db/dse.ldif, has low risk because everyone wants the dirsrv db not the TLS keys. Framed differently - your directory server is only as secure as the dirsrv db.

I'm also going to highlight linux's extensive record of failure to prevent priv esc on a machine, meaning that any serious business will isolate their LDAP on unique hardware or in a container in unique hardware. In a container the situation is actually somewhat better due to containers getting selinux/apparmor confinement labels to protect the dirsrv db too.

Now this isn't just my own opinion today - I contacted current sysadmins and pentesters who helped me to ensure this idea is grounded in reality.

I think that we really should be improving our understanding of threat and risk models, and improving our customer communication so that we can cut through the difference between "security" and "compliance checkboxes".

This usage needs to explain more about how /why to use this. Before I start ds? After? How does it interact with the .service script?

This whole command should likely be a part of dsctl and assocated to the instance that way, rather than adding "yet another tool".

I'm not sure I like this in main. If we still use svrcore, the point of svrcore is not just to get the password, but to make the decision about which password we use. I think that perhaps this should be in svrcore.

You need to test a pin of 4097 to show there isn't a buffer overflow in reading a pin that large.

So I think here something that really isn't clear in the logic and order of WHICH pin we'll use. SVRCore has logic to say "okay this source, then that, then this ....". I think there is a fair bit from main.c that you added that probably doesn't belong, and same with detach. I think this logic should have been in svrcore and it's up to svrcore to do the logic to get that material.

As well, youneed to define clearly what order we attempt various types of pin check in and their failure modes.

For example, currently we check for pin.txt and if not found we attempt ask-pass. Only both their failures, stops start up.

With this added what's the flow? keyring first? And if keyring fails do we check pin.txt?

Or do we do pin.txt, then if not found keyring, then ask pass?

I'm not going to oppose this feature because I think it comes from customer requests. But at a high level I'm going to say "it doesn't enhance security at all" and represents a communication issue where we are unable to express threat and risk models to our consumers so they can understand the value of their assets.
To explain, if someone has filesystem access to your directory server instance they don't care about "getting the TLS keys". If someone has filesystem access to your directory server they can access the database that contains every single user hash (pbkdf2, or md4 aka cleartext in ipa with adtrust enabled). They can also then modify this content, read dse.ldif, reset directory manager pw, and then do anything they like such as adding their own user account, insert them to admin groups, reset other account pws .... The risk of compromising an IDM system like 389 is that people target it because it grants access to everything ELSE of business value.
There is a difference between a theoretical risk (IE cryptographic attacks and people stealing TLS keys) and a real risk (gaining access to business applications of value, finding personal data etc). Any serious attacker wants access to your accounts and other business applications - and won't care about your TLS keys as gaining access to the LDAP server at all already represents a complete compromise of all attached applications and thus, game over.
So with this in mind, I'm going to point out - pin.txt on the same filesystem as the dirsrv db/dse.ldif, has low risk because everyone wants the dirsrv db not the TLS keys. Framed differently - your directory server is only as secure as the dirsrv db.
I'm also going to highlight linux's extensive record of failure to prevent priv esc on a machine, meaning that any serious business will isolate their LDAP on unique hardware or in a container in unique hardware. In a container the situation is actually somewhat better due to containers getting selinux/apparmor confinement labels to protect the dirsrv db too.
Now this isn't just my own opinion today - I contacted current sysadmins and pentesters who helped me to ensure this idea is grounded in reality.
I think that we really should be improving our understanding of threat and risk models, and improving our customer communication so that we can cut through the difference between "security" and "compliance checkboxes".

The point of this ticket is to remove password in clear on the file system (pin.txt). The purpose of that file is to allow automatic restart. This PR is just a solution for that.
I do agree that there are many others threats if someone has access to the file system.

It needs to be in main just before svrcore_setup is called. That way DS can read the password from keyring before setuid.

It is expected to retrieve the NSS password from svrcore. I do not get the meaning of 'which password' ?

So I think here something that really isn't clear in the logic and order of WHICH pin we'll use. SVRCore has logic to say "okay this source, then that, then this ....". I think there is a fair bit from main.c that you added that probably doesn't belong, and same with detach. I think this logic should have been in svrcore and it's up to svrcore to do the logic to get that material.
As well, youneed to define clearly what order we attempt various types of pin check in and their failure modes.
For example, currently we check for pin.txt and if not found we attempt ask-pass. Only both their failures, stops start up.
With this added what's the flow? keyring first? And if keyring fails do we check pin.txt?
Or do we do pin.txt, then if not found keyring, then ask pass?

The order is defined in SVRCORE_CreateStdKeyringPinObj: first svrcore cache, then keyring, then pin file, then ask-password.
theoretically we should not have keyring key if a pin.txt exist. But if it happens, keyring is returned first.

The point of this ticket is to remove password in clear on the file system (pin.txt). The purpose of that file is to allow automatic restart. This PR is just a solution for that.
I do agree that there are many others threats if someone has access to the file system.

Maybe a more constructive and actionable feedback is that it should be documented that other risks exist within these systems?

It needs to be in main just before svrcore_setup is called. That way DS can read the password from keyring before setuid.

Okay, I think my concern here is that the code in main.c seems to be what talks to the keyring, when it should be the module in svrcore. So either the call to svrcore_setup needs to be earlier when we are before the setuid so that svrcore is contacting the keyring, or we need to think about this differently. Or I'm really misunderstanding the code ....

The order is defined in SVRCORE_CreateStdKeyringPinObj: first svrcore cache, then keyring, then pin file, then ask-password.
theoretically we should not have keyring key if a pin.txt exist. But if it happens, keyring is returned first.

We need to make sure this order is well defined in docs :)

@tbordaz Is there anything else here?

@firstyear, this PR has been on hold for a while. Sorry for that. In addition to the remarks in this PR, it also need an improvement to be usable with containers (sharing keyring). I updated the doc but not this PR.
I hope to be back on this one soon but at the moment this feature is not that urgent.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3849

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.