[PATCH] Workaround for dyndns_test_ok failiure on mips(el). Child part has finished before the child handler was created.
by Jurica Stanojkovic
Hello,
Package sssd_1.11.5.1-1 on Debian FTBFS for mips and mipsel.
https://buildd.debian.org/status/fetch.php?pkg=sssd&arch=mips&ver=1.11.5....
https://buildd.debian.org/status/fetch.php?pkg=sssd&arch=mipsel&ver=1.11....
dyndns_test_ok is failing with following log:
[ RUN ] dyndns_test_ok(Tue Jul 8 15:53:55:004476 2014) [sssd] [be_nsupdate_args] (0x0200): (Tue Jul 8 15:53:55:004521 2014) [sssd] [child_handler_setup] (0x2000): nsupdate auth type: GSS-TSIGSetting up signal handler up for pid [21397](Tue Jul 8 15:53:55:004693 2014) [sssd] [__wrap_execv] (0x0200): nsupdate success test case(Tue Jul 8 15:53:55:004825 2014) [sssd] [__wrap_execv] (0x1000): Child exiting with status 0(Tue Jul 8 15:53:55:005275 2014) [sssd] [child_handler_setup] (0x2000): Signal handler set up for pid [21397](Tue Jul 8 15:54:55:837623 2014) [sssd] [write_pipe_handler] (0x0020): write failed [32][Broken pipe].(Tue Jul 8 15:54:55:837801 2014) [sssd] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete(Tue Jul 8 15:54:55:837869 2014) [sssd] [nsupdate_child_stdin_done] (0x0040): Sending nsupdate data failed [32]: Broken pipe(Tue Jul 8 15:54:55:837947 2014) [sssd] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed(Tue Jul 8 15:54:55:837985 2014) [sssd] [dyndns_test_ok] (0x1000): Child request returned [1432158228]: Unknown error 14321582280x555d0014 != 0../src/tests/cmocka/test_dyndns.c:222: error: Failure![ FAILED ] dyndns_test_okChild part has finished before the child handler was created.
I have created and attached a patch which is workaround for this issue.
Could someone please take a look and comment this?
Thank you!
Sincerely,
Jurica
7 years, 8 months
[PATCH] DYNDNS: Add a new option dyndns_server
by Jakub Hrozek
Hi,
one of our users ran into an interesting problem -- her AD
infrastructure was different from the DNS server. Because by default, we
perform update against the server we're connected to, the DNS update
didn't work.
Per Simo's suggestion, I've implemented a new option that allows the
administrator to override the DNS server used for DNS updates.
7 years, 10 months
[patch] Python 3 support for sssd
by Bohuslav Kabrda
Hey all,
for past few days, I've been working on python3-compat patch for sssd. The patch [1] is attached to the issue that requests this feature [2].
Some comments:
- The patch tries to maintain backward compatibility for Python 2.6 and 2.7 - I admit I only tested 2.7 so far, but it seemed to work ok.
- I didn't yet solve the build part - for now, I just handedit configure.ac to set "PYTHON=python3" and src/external/python.m4 to set "AC_PATH_PROG(PYTHON, python3)" and compile with that.
- I managed to run Python tests in src/tests except python-test.py itself (it says "OSError: [Errno 5] Could not initialize connection to the confdb" and I didn't yet investigate why that happens).
- To run tests, one must modify the hashbangs to /usr/bin/python3 (I now see that I left one of these in the actual patch, so please disregard that).
I'd like to ask you, sssd devels, to give me some comments on the patch (or ask questions) and if you have some time to spare, doing more extensive testing would also be very welcome.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedorahosted.org/sssd/attachment/ticket/2017/sssd-python3-compat....
[2] https://fedorahosted.org/sssd/ticket/2017
8 years, 4 months
[PATCHES] Sig handlers cleanups
by Simo Sorce
While checking if our custom signal handlers properly handle errno, I
stumbled on a few cleanups, they are attached.
turns out our few signal hanlders are errno safe, and tevent signal
handling function is also fine.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8 years, 4 months
[PATCH] simple access provider - don't fail on non-existing objects
by Pavel Reichl
Hello,
I noticed that if using simple access provider and having non-existing
group or user in access/deny list then access will be denied and "su:
System error" will be printed.
I think it's OK to simply skip non-existing objects on allow_list.
I'm not so sure what to do in case of deny lists. Should we also just
skip them or should we deny the user and print more appropriate message
("su: Permission denied")?
Thanks,
PR
8 years, 6 months
[PATCH] krb5: Check return value of sss_krb5_princ_realm
by Lukas Slebodnik
ehlo,
yet another warning from clang static analyser.
sss_krb5_princ_realm set output parameter realm to NULL and len to 0
in case of failure. Clang static analysers repoted warning
"Null pointer passed as an argument to a 'nonnull' parameter"
in function match_principal. It was possible, that realm_name with value NULL
could be used in strncmp.
Function sss_krb5_princ_realm is used on other places for printing(formatting)
realm_name and NULL can be safely used as a argument for printf-like
functions.
Patch is attached.
LS
8 years, 6 months
Design discussion: SSSD running as a non-root user
by Jakub Hrozek
Hi,
we'd like the SSSD in 1.12.1 to run as a non-privileged user. To
summarize the discussions we had, I created the following design page:
https://fedorahosted.org/sssd/wiki/DesignDocs/NotRootSSSD
For your convenience, the text of the page is also included below.
I'll be glad for comments and another round of discussion.
= Running SSSD as a non-root user =
Related ticket(s):
* https://fedorahosted.org/sssd/ticket/2370
=== Problem statement ===
Currently, all SSSD processes run as the root user. However, if one of the processes was compromised, this might lead to compromising the whole system, especially if additional measures like SELinux were not enabled. It would improve security if instead SSSD was running as its own private user, This design page summarizes what would be needed to run sssd as a non-privileged user and all the cases that currently require a root user.
== Scope of the changes ==
At a higher level, the changes would amount to:
* A new system user would be created. This user must be added in sssd.spec during the `%pre` section.
* Files that were used by sssd and previously owned by root should now be owned as the sssd user. This includes the LDB databases.
* It is important that no code linked from libkrb5 runs as root. This has consequences for accessing the system keytab, which must be readable by the sssd user.
* Responders and back ends would drop privileges and become the sssd user as soon as possible, ideally as the first action after startup.
* Short-lived processes that are spawned by `sssd_be` but might still require elevated privileges would be setuid root.
* Places that blindly check for UID==0 must be converted to handling EPERM/EACCESS gracefully.
The changes to individual binaries and files are described in more detail
below. After the changes are implemented, the code that runs as root will
be reduced to the monitor process and the krb5_child.
== A new system user ==
The sssd will run as a new system user called simply `sssd`. We do not need to have the UID fixed across systems as no files owned by SSSD are shared among different systems. The user will be simply added during the `%pre` phase:
{{{
%pre
getent group sssd >/dev/null || groupadd -r sssd
getent passwd sssd >/dev/null || useradd -r -g sssd -d / -s /sbin/nologin -c "User for sssd" sssd
}}}
As it's common practice for system users, the shell will be `/sbin/nologin` so the user cannot log in into the system.
The name of the user should be configurable at configure-time as different distributions might decide on using different users.
== Dropping privileges of the SSSD processes ==
The goal is for the "worker" processes (that is, both responders and
providers) to drop the root privileges as soon as possible - typically right
after startup, or alternatively after completing any work that requires
root privileges such as opening a file. Because the processes might have to keep the root
privileges after startup, the monitor process would still be running as root.
=== Using libcap-ng to drop the privileges ===
Even though we already have some code to drop privileges in the `krb5`provider, we should leverage the [https://people.redhat.com/sgrubb/libcap-ng/ libcap-ng] project for privilege drop. The added benefits over doing the privilege drop ourselves are:
* libcap-ng is tested and used by many other packages already. For security-sensitive code, it's advisable to re-use existing code rather than hit the same mistakes someone else did already.
* libcap-ng also allows to work with capabilities. For some cases, this might be beneficial in future, for instance, we might need to retain the auditing capability.
The downside is obviously the extra dependency, but libcap-ng has a small footprint and is already used by packages that are present on most, if not all, modern Linux installations, such as dbus.
We should keep the existing code around as a fallback for environments that don't have the libcap-ngs library available, such as non-Linux systems or embedded systems. Because the code wouldn't be enabled by default, it's important to have unit tests for the privilege drop. For unit testing both options (libcap-ng and our own code), [http://cwrap.org/uid_wrapper.html uid_wrapper] and [http://cwrap.org/nss_wrapper.html nss_wrapper] are the best choice.
=== Monitor (sssd) ===
The monitor process would keep running as root. This is in order to be
able to fork and exec processes that are initially privileged without
making them all setuid. As a future enhancement, the process management
functionality of the monitor will be delegated to systemd (see ticket #2243).
=== Responders ===
The responder processes are by nature 'readers' that mostly read data from
cache and request cache updates from the back end processes.
==== NSS responder ====
The NSS responder can drop privileges after startup. The files that the
NSS responder reads (sysdb, confdb, NSS pipe) and writes (memory cache,
debug logs, NSS pipe) will be owned by the sssd user.
==== PAM responder ====
The PAM responder can drop privileges after startup. The files that the PAM
responder reads (sysdb, confdb, PAM public pipe) and writes (debug logs,
PAM pipe) will be owned by the sssd user.
In order to keep the privileged pipe only owned by the root user, we
would open the pipe prior to becoming user and pass the file descriptor.
==== !InfoPipe responder ====
The !InfoPipe responder can drop privileges after startup. The files that the !InfoPipe
responder reads (sysdb, confdb) and writes (debug logs,
PAM pipe) will be owned by the sssd user.
Contrary to other responders, the !InfoPipe responder doesn't have a public
pipe. The !InfoPipe responder also binds to the system bus, we must also
convert the bus policy file to allow the sssd user to bind to the bus.
Moreover, as the !InfoPipe responder allows to change the configuration
(this functionality is used by the OpenLMI SSSD provider), the !InfoPipe
responder should be able to write to the `sssd.conf` file. Therefore, the
`sssd.conf` file should be writable by the sssd user, too. Alternatively,
another setuid helper can be created to write the configuration changes
with augeas calls.
==== Autofs, SUDO and SSH responders ====
The Autofs, SUDO and SSH responders only read from the sysdb, confdb and
their respective UNIX public pipes. These responders also only write to
the debug logs and the public pipe, all of which would be owned by the
sssd user. This means the Autofs, SUDO and SSH responders can drop privileges
right after startup.
=== Providers ===
The providers are dynamically loadable libraries that are loaded by the
`sssd_be` process. After startup, the sssd_be process dlopens the provider
library and dlsyms the handlers. During sssd operation, the `sssd_be` process
mostly unpacks requests arriving on the SBUS and calls the provider-specific
handlers.
We have two options here - either drop the privileges in the provider library
itself or directly in the `sssd_be` process. Dropping privileges in the
`sssd_be` process has the advantage of modifying only one place and being
sure that no matter the back end, the privileges would always be dropped.
On the other hand, becoming user in the library itself might be
beneficial for scenarios where the back end requires root access for
initialization. Also, if some third-party proprietary module absolutely
requires to run as root, we shouldn't enforce the privilege drop.
If we don't care about the third party modules, we could take an approach
where the provider would drop privilege as soon as it can and after all
the initialization was completed, the sssd_be process would ensure the
privileges are indeed dropped. Because there are no third party back ends
so far and there was no attempt to write one, this is currently safe.
=== Short-lived processes ===
The purpose of the short-lived processes is to avoid blocking calls by performing an otherwise blocking action in a completely separate process.
==== ldap_child ====
The ldap_child subprocess primes the credential cache used to establish
GSSAPI-encrypted connection. In order to do so, the ldap_child process needs
to be able to read the keytab, which needs to have its group ownership set
to the sssd group and have the appropriate access rights. The ldap_child
process does not have to be setuid. The resulting ccache would be owned
by the sssd user and thus accessible to the rest of the SSSD.
==== krb5_child ====
The krb5_child would be split into two parts - one that would perform most
of the Kerberos-related tasks, such as reading the keytab or creating the
ccache on behalf of the sssd user. Another part, that would be setuid root
would change the ccache ownership to the user who logs in. The new process
(krb5_child_user perhaps) would have the permissions and ownership set to
4750 and root.sssd respectively. That way only the sssd user would be able
to run the new helper.
==== proxy_child ====
The proxy child performs the PAM conversation with the module being
proxied. Normally there is no restriction on the UID to initiate the PAM
conversation, so the proxy child can run unprivileged.
==== gpo_child ====
The gpo_child process connects to a SMB share, downloads a GPO policy file
and stores it locally, by default in `/var/lib/sss/gpo_cache`. The gpo_child
authenticates to the SMB share using Kerberos; the ccache, as created by
ldap_child is already accessible to the sssd user. Since that directory would
be owned by the sssd user, the gpo_child could run unprivileged.
==== ssh helpers ====
The SSH helpers already run non-privileged. `sss_ssh_knownhostsproxy` runs
as the user who initiated the SSH session. `sss_ssh_authorizedkeys` runs as
the user specified with the !AuthorizedKeysCommandUser directive in sshd_config.
=== Command line tools ===
There are two general kinds of command line tools we ship with the SSSD - tools that manage accounts in the local backend and SSSD management
tools. All tools check if they are executed by root currently. I think
this check makes sense and should stay because all the tool are intended
for administrative purposes only.
==== Local back end tools ====
The tools either write (`sss_useradd, userdel, usermod, sss_groupadd,
groupdel, groupmod`) or read (`sss_groupshow`) the `sssd.ldb` file. Since
the file will be owned by the sssd user, the tools can also run as sssd.
==== sss_seed and sss_cache ====
These two tools function similarly to the local backend management tools,
except they manipulate the domain cache. The cache is also owned and
writable by the sssd user, so it's safe to drop privileges here, too.
==== sss_debuglevel ====
The sss_debuglevel tool changes the debug level of sssd on the fly. The
tool writes new debug level values to the confdb (owned by sssd) and
touches sssd.conf (owned and writable by sssd as well). The tool can drop
privileges to sssd after startup.
==== sss_obfuscate ====
The sss_obfuscate tool is written in Python and manipulates the
sssd.conf file by obfuscating the input and using it as a value of the
`ldap_default_authtok` configuration option. For dropping privileges of
the sss_obfuscate tool, we can use the python bindings of libcap-ng.
== External resources currently requiring root access ==
This part of the design page summarizes which external resources, typically
file system objects currently require SSSD to have elevated privileges.
For filesystem objects, we can either change their owner to the sssd
local user, add an ACL or open them as the privileged process and pass
the file descriptor.
=== SSSD configuration file ===
* Filesystem path: `/etc/sssd/sssd.conf`
* Current owner and permissions: root.root 0600
* Read by: The monitor process
* Written to by: The !InfoPipe responder and users of the configAPI, such as sss_obfuscate or authconfig
* ''Change: In order to allow the !InfoPipe responder to make changes to the config file, the file must be owned by sssd.sssd and made writable by the sssd user''
* ''New owner and permissions: sssd.sssd 0600''
=== Debug logs ===
* Filesystem path: `/var/log/sssd/*.log`
* Current owner and permissions: root.root 0600
* Read by: N/A, only externally by admin
* Written to by: monitor, providers, responders, child processes
* ''New owner and permissions: sssd.sssd 0600''
=== The configuration database ===
* Filesystem path: `/var/lib/sss/db/config.ldb`
* Current owner and permissions: root.root 0600
* Read by: responders, providers, monitor, command-line tools
* Written to by: The monitor process, sssd-ad (a single confdb_set call), sss_debuglevel, sssd_ifp
* ''New owner and permissions: sssd.sssd 0600''
=== The on-disk cache (sysdb) ===
* Filesystem path: `/var/lib/sss/db/cache_$domain.ldb`
* Current owner and permissions: root.root 0600
* Read by: responders, providers, command-line tools
* Written to by: sssd_be, the CLI tools
* ''New owner and permissions: sssd.sssd 0600''
=== Memory Cache ===
* Filesystem path: `/var/lib/sss/mc/{passwd,group}`
* Current owner and permissions: root.root 0644
* Read by: The SSS NSS module
* Written to by: The NSS responder
* ''New owner and permissions: sssd.sssd 0600''
=== Kerberos keytab ===
* Filesystem path: configurable, `/etc/krb5.keytab` by default
* Current owner and permissions: root.root 0600
* Read by: LDAP, KRB5, IPA, AD providers, krb5_child, ldap_child
* Written to by: sssd_be, the CLI tools
* ''Change: Since no Kerberos code should run as root, the keytab must be readable by the sssd group''
* ''New owner and permissions: root.sssd 0640''
* Special care must be taken to make sure other the keytabs as specified in sssd.conf have the right ownership. We already have an upgrade script in %post, we can use it to chown the keytabs
=== Kerberos user credential cache ===
* Filesystem path: Configurable, only if FILE or DIR based cache is used, which is not the default anymore
* Current owner and permissions: the user who logged in, 0600
* Read by: KRB5, AD, IPA, krb5_child, libkrb5 externally
* Written to by: krb5_child
* ''Change: No change, the credential cache will still be written as the user in question''
=== Kerberos LDAP credential cache ===
* Filesystem path: `/var/lib/sss/db/ccache_$domain`
* Current owner and permissions: root.root 0600
* Read by: AD, IPA and LDAP providers (coded up in LDAP provider tree)
* Written to by: ldap_child
* No change needed since ldap_child will run as the sssd user in the new design
* ''New owner and permissions: sssd.sssd 0600''
=== Kerberos kdcinfo files ===
* Filesystem path: `/var/lib/sss/pubconf/*`
* Current owner and permissions: root.root. The directory has permissions of 0755, the files 0644
* Read by: libkrb5
* Written to by: LDAP, KRB5, IPA, AD providers, krb5_child, ldap_child
* ''New owner and permissions: Both directory and files will be owned by sssd.sssd, the permissions will stay the same''
=== SELinux user mappings ===
* Filesystem path: `/etc/selinux/targeted/logins`
* Current owner and permissions: root.root. The directory has permissions of 0755, the files 0644
* Read by: pam_selinux
* Written to by: IPA provider
* ''Change: We need to see if we can use libselinux to set the label first. Either way, the code to set the label needs to run privileged, the SELinux policy mainainer didn't like the idea of changing permissions of the directory''
=== UNIX pipes ===
* Filesystem path: `/var/lib/sss/pipes/`
* Current owner and permissions: root.root. The directory has permissions of 0755, the files 0666. There is one pipe per responder.
* Read by: client modules, all responders except !InfoPipe
* Written to by: client modules, responders
* ''New owner and permissions: Both directory and files will be owned by sssd.sssd, the permissions will stay the same''
=== UNIX PAM private pipe ===
* Filesystem path: `/var/lib/sss/pipes/private/pam`
* Current owner and permissions: root.root. The directory has permissions of 0700, the files 0600. Only the PAM responder uses the private pipe.
* Read by: PAM responder
* Written to by: PAM client module
* ''New owner and permissions: The directory will be owned by sssd.sssd, the file will stay the same''
=== Data Provider private pipes ===
* Filesystem path: `/var/lib/sss/pipes/private/sbus-dp_$domain`
* Current owner and permissions: root.root. The directory has permissions of 0700, the files 0600. Only the PAM responder uses the private pipe.
* Read by: Responders
* Written to by: Data Provider
* ''New owner and permissions: Both directory and files will be owned by sssd.sssd, the permissions will stay the same''
== Kerberos configuration file ==
* Filesystem path: `/etc/krb5.conf`
* Read by: libkrb5
* Written to by: The IPA and AD providers "touch" the file in order to make libkrb5 re-read it
* ''Change: The file can be opened before dropping privileges and we can keep the fd around. Alternatively, the modification can be performed with a setuid helper''
== How to test ==
Test ordinary SSSD operations. Everything must work as it used to before. Pay special attention to operations that involve the short-lived processes, like GSSAPI LDAP provider authentication or Kerberos user authentication.
Upgrade testing must be performed as well.
== Authors ==
* Sumit Bose <sbose(a)redhat.com>
* Jakub Hrozek <jhrozek(a)redhat.com>
* Simo Sorce <simo(a)redhat.com
8 years, 7 months
[PATCH] allowed_shells: using wildcard for any shell
by Denis Kutin
Dear friends,
Using sssd, for a long time, I have come across with a problem recently,
which I would like to solve with your help.
I provide centralized authentication and authorization service for a huge
heterogeneous network. And in my case it would be "nice and easy" if sssd
used only shells(5). I believe this mechanism is sufficient for
identification of an allowed shell.
I take a liberty to offer you this tiny patch, which will let use wildcard
(*) in param allowed_shells in sssd.conf
What do you think about it?
--
Denis Kutin
8 years, 7 months
[PATCHES] LDAP: SID-Mapping - Store non-POSIX users in cache if they have a SID
by Pavel Reichl
Hello,
please see attached patches.
I have briefly discussed with Jakub how to handle saving users with uid
0 whether to resurrect sysdb_add_fake_user or modify existing fuctions
for storing users. I decided to add wrapper function around existing
ones to minimize changes in code which calls them.
Thanks,
Pavel Reichl
8 years, 7 months
