Hi,
I'm trying to run SSSD inside docker container without root user. The container is executed in OpenShift cluster which does not allow running as root inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment.
Hi,
On Thu, Nov 26, 2020 at 5:24 PM Tero Saarni tero.saarni@gmail.com wrote:
Hi,
I'm trying to run SSSD inside docker container
Could you please describe your use case in greater details?
Who is the consumer of services provided by sssd? What backends (data sources) do you plan to use?
without root user. The container is executed in OpenShift cluster which does not allow running as root inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment.
-- Tero _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Could you please describe your use case in greater details?
Who is the consumer of services provided by sssd? What backends (data sources) do you plan to use?
Thank you for your response.
The consumer is a custom (existing) application that depends on PAM libraries. The data source is LDAP backend.
On Thu, Nov 26, 2020 at 5:52 PM Tero Saarni tero.saarni@gmail.com wrote:
Could you please describe your use case in greater details?
Who is the consumer of services provided by sssd? What backends (data sources) do you plan to use?
Thank you for your response.
The consumer is a custom (existing) application that depends on PAM libraries.
(sorry for probably lame question but my knowledge about containers is very limited)
Does it mean your application is run within the same container as sssd? If this is the case, this might be not the best idea, as due to caching in every instance (and other reasons) this might turn out to be a very "heavy" solution...
The data source is LDAP backend.
-- Tero _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Does it mean your application is run within the same container as sssd? If this is the case, this might be not the best idea, as due to caching in every instance (and other reasons) this might turn out to be a very "heavy" solution...
Yes the application runs in the same container as sssd, but there is no intention to run that many instances. Caching locally at each pod / container is OK, and this setup has worked for quite some time, but now the application should be ported to run on OpenShift and I bumped into the problem of SSSD not starting as non-root.
On (26/11/20 16:21), Tero Saarni wrote:
Hi,
I'm trying to run SSSD inside docker container without root user. The container is executed in OpenShift cluster which does not allow running as root inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have most critical parts executed as root and have it drop privileges for other parts but this now completely blocks using SSSD in the above environment.
There is a way how to run sssd as non-root but /usr/sbin/sssd still require bunch of linux capabilities to achieve that.
Here is the list: audit_write chown dac_override dac_read_search fowner ipc_lock kill net_admin setgid setuid sys_admin sys_nice sys_resource
# sys_resource is optional and not needed with default configuration
And openshift unprivileged pod has jsut following capabilities chown, dac_override, fowner, fsetid, setpcap, net_bind_service, net_raw, sys_chroot, audit_write, setfcap
Folowing two are the most problematic: setgid setuid but they are removed from default set in the openshift by default.
You would need to run sssd with differet security context than restricted https://www.openshift.com/blog/introduction-to-security-contexts-and-sccs
HTH
LS
Lukas Slebodnik wrote:
There is a way how to run sssd as non-root but /usr/sbin/sssd still require bunch of linux capabilities to achieve that.
One more question, which I should have mentioned in my previous reply.
Since there are few places in the code that check explicitly for root and exit with error if getuid() != 0 for example here https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L2449. Since these checks do not seem to be optional, adding capabilities alone do not help.
How do the maintainers feel about making sssd run on OpenShift? Would this be something to pursue / possibly contribute to?
-- Tero
On (01/12/20 08:59), Tero Saarni wrote:
Lukas Slebodnik wrote:
There is a way how to run sssd as non-root but /usr/sbin/sssd still require bunch of linux capabilities to achieve that.
One more question, which I should have mentioned in my previous reply.
Since there are few places in the code that check explicitly for root and exit with error if getuid() != 0 for example here https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L2449. Since these checks do not seem to be optional, adding capabilities alone do not help.
It is not just about `if getuid() != 0` in the monitor code. there are also other places in {krb5/ldap}_child which try to escalate privileges if they run as unprivileged user and it woudl not be allwed due to missing CAP_SETGID, CAP_SETUID And bunch of other places.
How do the maintainers feel about making sssd run on OpenShift? Would this be something to pursue / possibly contribute to?
As I mentioned in previous email you can run sssd in OpenShift but not with restricted scc.
If you really want to run it in restricted scc you can use LD_PRELOAD to pretend execution as root e.g. fakeroot https://nixdoc.net/man-pages/Linux/man1/fakeroot.1.html
It is used in sssd CI for some testing but it is not meant for production. But feel free to use it if you feel brave enough :-)
LS
We are also trying to run as a non-root user with minimal capabilities in production. Has anymore work been done on this since?
Hi David,
Plan for the full support of SSSD running as a non-root user is in scope of interest of the SSSD dev team. I can't provide you a precise time frame for this but some preparation already started. This transition is not trivial as by design SSSD was alway running as a root. Keep in mind that on top of the code changes a lot of testing needs to be done to confirm that the final result will be secure and perform well.
After fast check those are some of already existing upstream issues related to SSSD running without root: https://github.com/SSSD/sssd/issues/3412 https://github.com/SSSD/sssd/issues/5508 https://github.com/SSSD/sssd/issues/5536 https://github.com/SSSD/sssd/issues/5443
Best regards, Pawel
On Thu, Apr 1, 2021 at 6:06 PM David Mather davidmather@live.ie wrote:
We are also trying to run as a non-root user with minimal capabilities in production. Has anymore work been done on this since? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
sssd-users@lists.fedorahosted.org
-
Alexey Tikhonov -
David Mather -
Lukas Slebodnik -
Pawel Polawski -
Tero Saarni