DAOS-15849 control: Add client uid map to agent config

[mjmac]

Allow daos_agent to optionally handle unresolvable client
uids via custom mapping. In deployments where the agent
may not have access to the same user namespace as client
applications (e.g. in containerized deployments), the
client_user_map can provide a fallback mechanism for
resolving the client uids to known usernames for the
purpose of applying ACL permissions tests.

Example agent config:

credential_config:
  client_user_map:
    default:
      user: nobody
      group: nobody
    1000:
      user: joe
      group: blow

Features: control
Required-githooks: true
Change-Id: I72905ccc5ddee27fc2101aa4358a14e352c86253
Signed-off-by: Michael MacDonald mjmac@google.com

[github-actions]

Ticket title is 'Provide a mechanism for mapping unknown client uids to user/group names'
Status is 'In Review'
https://daosio.atlassian.net/browse/DAOS-15849

[daosbuild1]

Test stage Unit Test on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-14381/1/display/redirect

[daosbuild1]

Test stage Functional Hardware Medium UCX Provider completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14381/4/execution/node/1378/log

[daosbuild1]

Test stage Functional Hardware Medium MD on SSD completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-14381/4/testReport/

[kjacque]

I wouldn't block on any of my suggestions. This is pretty cool. Nice work.

I find myself wondering if there might be some benefit to making use of interface types for this scenario. Having two different data sources for user/group/etc., it seems like a good fit for the concept.

[tanabarr]

Are we sure this change won't enable any undesired security consequences outside container environments? The prospect of nefarious mappings seems like something we really should think about, but perhaps it has? Is the assumption that the mappings can only be applied by an administrator who has write access to the configuration files and there aren't any other vectors that we need to be concerned about?

Also the Commit message seems to me to imply that the changes are only required for testing purposes: "...client_user_map can provide a fallback mechanism for resolving the client uids to known usernames for the purpose of applying ACL permissions tests.". I assume that this is a typo (or me misunderstanding) and the changes are indeed needed for production deployments?

[kjacque]

Are we sure this change won't enable any undesired security consequences outside container environments? The prospect of nefarious mappings seems like something we really should think about, but perhaps it has? Is the assumption that the mappings can only be applied by an administrator who has write access to the configuration files and there aren't any other vectors that we need to be concerned about?

I thought about this for a bit, too. As long as the admin secures their DAOS config files and certificates from unauthorized users, I think we should be OK. If the admin has secured the system with certificates with appropriate permissions (private key readable by daos_agent only), attackers will not be able to start their own private daos_agent to interface with the system with a custom config either. I see these as the two main attack vectors. @dpquigl can you think of anything else?

[tanabarr]

Concerns assuaged by @dpquigl 's comments elsewhere:

So if I understand this correctly you have a multi-container environment where the socket for daos-agent is exported from one container and used in another. So when you check the sender’s credentials on the socket you’re getting he euid and egid from the process in the other container. However since the daos-agent container probably only has the users needed for the applications running in the container you can’t do a lookup on the users and groups. This seems like a reasonable solution. NFSv4 has a similar mechanism where it will translate a local uid to a name and back into a local uid on the remote side because of just this issue. The agent is a trusted entity in the security architecture so I agree that as long as you keep the agent integrity its ok for it to take on the additional responsibility of performing the translation. Is the reason this is in the same config file just for convenience? It might be a good idea to have it in a separate file for manageability.

I think moving the new section to a separate file is probably something we don't have bandwidth for currently so I'm happy to merge this now.

[mjmac]

Are we sure this change won't enable any undesired security consequences outside container environments? The prospect of nefarious mappings seems like something we really should think about, but perhaps it has? Is the assumption that the mappings can only be applied by an administrator who has write access to the configuration files and there aren't any other vectors that we need to be concerned about?

As Kris & David have pointed out, the agent is considered a trusted component, and only the admin should be able to modify its configuration. As long as the agent trust is maintained, then there's no concern that malicious mappings could be created. If the agent trust is broken (due to file permissions or whatever), then pretty much anything could happen.

Also the Commit message seems to me to imply that the changes are only required for testing purposes: "...client_user_map can provide a fallback mechanism for resolving the client uids to known usernames for the purpose of applying ACL permissions tests.". I assume that this is a typo (or me misunderstanding) and the changes are indeed needed for production deployments?

Perhaps there's a better term, but I was using "test" in the sense that an access request is tested by applying the ACL and either accepting or rejecting the request. Maybe "check" would have been clearer.

[daltonbohning]

FYI a fix for the DEB build just landed to master