sssd-devel July 2016

sssd-devel@lists.fedorahosted.org

18 participants
103 discussions

Tlog integration and packages
by Nikolai Kondrashov 10 Mar '17

10 Mar '17

Hi everyone, I'd like to continue the discussion of tlog integration, and also present you the first release of tlog - a development preview, which has the configuration interface necessary to implement the integration: https://github.com/spbnick/tlog/releases/tag/v1 You're more than welcome to download RPMs, install, read tlog-rec(8) and tlog-rec.conf(5), and experiment! Building from the Git tree and the tarball works as well, if you're so inclined. I'm also attaching those manpages for convenience. Here are the integration plans so far, as discussed with Jakub on our devconf.cz trip meetings and before on the list. Jakub, please correct me or add details. * We follow the route similar to that taken by SELinux rule control implementation [1][2]. I.e. store the configuration in LDAP HBAC rules, write to files on the client side and then specify them to tlog upon user login. However, I'm also rather fond of the idea of specifying the whole configuration through an environment variable instead of through a file referenced by an environment variable - it's not big at all, and we'll avoid the hassle of managing the files. I implemented support for both in tlog (was easy). * We'll have to make nss_sss report user's shell as tlog-rec (how?) and specify the actual shell to tlog-rec via an environment variable, through pam_sss (with SSS_PAM_ENV_ITEM messages). I.e.: * Nss_sss would always report tlog-rec as the user's shell. * During login (e.g. through "login" or "sshd") pam_sss would add a variable to the user environment, containing, or pointing at, a tlog-rec configuration (TLOG_REC_CONF_TEXT or TLOG_REC_CONF_FILE). That configuration would contain the user's actual shell. I can also implement support for a separate variable just for the shell (TLOG_REC_SHELL?) to simplify the implementation for the start. * Tlog-rec would read the system-wide configuration and overlay it with the one specified in the environment, adding the specific user shell, and then would spawn it. Please also see the draft integration design page [3] for reference. I hope to refine and extend it in the coming weeks to match FreeIPA standards. Please chime in and suggest, object, discuss! Also, please report tlog bugs at https://github.com/spbnick/tlog/issues Thank you! Nick [1]: http://www.freeipa.org/page/SELinux_user_mapping [2]: http://www.freeipa.org/images/b/b9/Freeipa30_SELinuxUserMap.pdf [3]: http://www.freeipa.org/page/Session_Recording

5 22

[RFC] NSS tlog integration
by Nikolai Kondrashov 09 Dec '16

09 Dec '16

Hi everyone, Please find attached proof-of-concept patches for a part of NSS integration with tlog. Namely, addition of shell substitution for getpwnam requests. The code is supposed to replace a user's shell with /usr/bin/tlog-rec, if session recording is enabled for all users, if it is enabled for that particular user, or for a group that it belongs to. The configuration is done in a dedicated section of sssd.conf named "session_recording", which can contain three options "scope", "users", and "groups". Those correspond to the scope of session recording: "none", "some", and "all", corresponding in order to: disabled session recording, session recording enabled for the specified users/groups, and session recording enabled for all users handled by SSSD. An example of a configuration can be: [session_recording] ; Disabled scope = none or [session_recording] ; Enabled for everyone scope = all or [session_recording] ; Enabled for some users and groups scope = some users = user1, user2 groups = group1, group2 The parts to be done still are adding support for getpwuid and getpwent requests, exporting of the original shell in pam_sss, and of course cleaning it up and doing it according to your comments and requirements. The code has some documentation in doxygen format, which I can change later if we decide on some other format, or no documentation at all. Please, tell me if I'm doing anything wrong this far already, or suggest better ways to do it. Thank you! Nick P.S. I'm on PTO for two weeks starting next week, so might not be able to answer quickly.

3 15

[PATCH] Unit tests for pam_sss using pam_wrapper (need help with CI..)
by Jakub Hrozek 08 Dec '16

08 Dec '16

Hi, the attached patches implement unit tests for the pam_sss module using pam_wrapper and libpamtest. In my testing, the coverage is around 75% with mostly the parts that require running as root being untested. I worked on this patchset even though the features for 1.14 are in full swing because there are several tickets that will require us to patch pam_sss, so it's important to have the code that changes tested. In addition, when we merge Dan's patches to use TLS with integration tests, then we'll be able to also test authentication in integration tests easily using libpamtest-python. However, our CI fails for me constantly: http://sssd-ci.duckdns.org/logs/job/42/75/fedora_rawhide/ci.html The strange thing is that running CI locally works fine and so does make check. Can anyone help point me in the right direction as to what should I check next? I suspect some of the environment variables might not be set correctly, but I don't see why..

2 8

[PATCHES] views: properly override group member names
by Sumit Bose 08 Nov '16

08 Nov '16

Hi, this is my suggestion to solve https://fedorahosted.org/sssd/ticket/2948 "Handle overriden name of members in the memberUid attribute". The first two patches are for the IPA provider and make sure that all ghost members in a group get resolved because otherwise we cannot determine if the name is overridden or not. This adds an overhead to group lookups, especially for larger groups but I think it is an requirement which cannot be skipped. The third patch adds a sysdb call to recursively resolve all user-members of a group. Since the groups in SSSD's cache are hierarchically organized the member attribute only contains direct user and group members. To get all users the group members must be resolved recursively. Finally the forth patch applies the code-path which is already used for non-default views to the default case as well and adds a new list of members, with correctly overridden names (hopefully :-) which is then used in fill_grmem(). This adds some overhead to the overall group processing in the NSS responder (as can be seen in the test changes because the members are returned in different order in some cases). But I think because the of memory cache this is acceptable and might even help to remove the memberuid attribute in future and make the memberof plugin simpler. I worked on an alternative approach as well which tried to make the memberof plugin aware of the defaultOverrideName attribute. My wip tree is at https://fedorapeople.org/cgit/sbose/public_git/sssd.git/log/?h=memberof_def… but so far it does not work properly. Additionally I would prefer to not touch the memberof plugin. bye, Sumit

3 20

[PATCHES] Fix warnings Wsign-compare
by Lukas Slebodnik 17 Oct '16

17 Oct '16

ehlo, I found few warnings on rawhide when I build sssd-1.13.2 https://kojipkgs.fedoraproject.org//work/tasks/8618/11918618/build.log LS

2 6

[PATCH] sss_override: improve --debug description
by Pavel Březina 24 Sep '16

24 Sep '16

https://fedorahosted.org/sssd/ticket/2813 I wanted to split include/debug_levels.xml into more files so we don't duplicate information, but I didn't figure out how to use xi:include in files that are already beeing included. I always managed to fail on dtd validation. Maybe someone more familiar with docbook may chime in.

4 12

[PATCH] SPEC: Rename python packages using macro %python_provide
by Lukas Slebodnik 22 Sep '16

22 Sep '16

ehlo, SSSD python packages were renamed in fedora few months ago. python-* -> python2-* But we didn't rename packages in upstream spec file and therefore upgrade from fedora 24 -> sssd master is not possible. Attached patch shoudl fix the issue. BTW here are provides and obsoletes for current master sh$ rpm -qp --provides python-libipa_hbac-1.13.92-0.fc24.x86_64.rpm libipa_hbac-python = 1.13.92-0.fc24 python-libipa_hbac = 1.13.92-0.fc24 python-libipa_hbac(x86-64) = 1.13.92-0.fc24 sh$ rpm -qp --obsoletes python-libipa_hbac-1.13.92-0.fc24.x86_64.rpm libipa_hbac-python < 1.12.90 and after renaming sh$ rpm -qp --provides python2-libipa_hbac-1.13.92-0.el6.x86_64.rpm libipa_hbac-python = 1.13.92-0.el6 python-libipa_hbac = 1.13.92-0.el6 python2-libipa_hbac = 1.13.92-0.el6 python2-libipa_hbac(x86-64) = 1.13.92-0.el6 sh$ rpm -qp --obsoletes python2-libipa_hbac-1.13.92-0.el6.x86_64.rpm libipa_hbac-python < 1.12.90 python-libipa_hbac < 1.13.92-0.el6 LS

2 6

[PATCH] ssh: skip invalid certificates
by Sumit Bose 22 Sep '16

22 Sep '16

Hi, currently the code which generates ssh key from the public keys in the user certificates fails if one certificate cannot be validated and terminates the whole request. It is of course valid that the user entry might contain certificates which SSSD cannot validate and since we just won't generate a ssh-key in this case SSSD should just skip those entires and return ssh-keys for every valid certificate. You can test the patch even without a real certificate by e.g. adding a ssh-key to an IPA user object. Then 'sss_ssh_authorizedkeys username' should return this key. If you now add some random data the the userCertificate object of the same user, call 'sss_cache -E' and call 'sss_ssh_authorizedkeys username' again, you get nothing because the random data cannot be validated and hence the whole request is aborted. With the attached patch sss_ssh_authorizedkeys should return the ssh-key again. bye, Sumit

3 7

[PATCHES] p11: add no_verification option
by Sumit Bose 19 Sep '16

19 Sep '16

Hi, the following 3 patches are related to the Smartcard authentication feature but imo can be tested even without having one. The first patch just adds some missing pieces. The second adds a new 'no_verification' switch to the 'certificate_verification' option, which is already tested by the unit tests. The third adds two new OCSP related switches. With OCSP a certificate can be validates online by talking to a server which is listed in the certificate. Of course it might not always be possible to directly talk to this server. We already have the 'no_ocsp' switch to disable OCSP completely. The two new switches allow SSSD to talk to a different server or a proxy. To see how it is working you can do to following: - call 'make check' to build and rung all the tests - call './pam-srv-tests' to run the PAM responder tests but do not let it complete but stop it with CTRL-C. This is needed to create the test nss database in /dev/shm/tp_pam_srv_tests-test_pam_srv/, it can be created differently but this way it is most easy :-) - add a OCSP signing cert with echo "MIIDaTCCAlGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlJUEEuREVWRUwxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNTA5MjMxMTI2MjBaFw0xNzA5MTIxMTI2MjBaMC0xEjAQBgNVBAoMCUlQQS5ERVZFTDEXMBUGA1UEAwwOT0NTUCBTdWJzeXN0ZW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDEXVzkTN9R03+hvAbkiCYqdKKe7Nr0YDlchny+IsJl5cYiFBtWqiVJK5N0L6uCS9bVBtuG7y9Vv1TJrv2U8hqjXYZFM6HzYwwmbE2tv1Yyx0dQyYiYTT0nVyXPrXDJe0PFdYTsAlw7C54wZuBsdDADUTA1ThAP22Z6Zy+UyQFtlqEfCErvHK+VolCfkTJ4dYlQb5x7Gs6fEmLbnaGpJXW1JnRzMZ4hM+/mV3xSsjFuYwwoFCHG6GQu/LJgosBX9M+OMavMOO/AzeUlHfUoyMUNn0iNeiDqeYPBCNf4czK0CpeJdE4qBBgu0vSfC0mzjKRuFQEAUuBGxGE+2BP09uXAgMBAAGjgYwwgYkwHwYDVR0jBBgwFoAU0aLh2me2OKzMbu3zckJNNu3Hd1swDgYDVR0PAQH/BAQDAgHGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL2lwYS1kZXZlbC5pcGEuZGV2ZWw6ODAvY2Evb2NzcDATBgNVHSUEDDAKBggrBgEFBQcDCTANBgkqhkiG9w0BAQsFAAOCAQEAAJzUjm39nsMlxc0ivEm77PN9ZFFWIfY6fOteNpJnOADlOatkXKq6PTFS0lRo/53HjYvmvrjnUTYHK3hmRlDvwr+49UqhSkKai8v6PSS4jYJplETME032OwGL17qCjoX2yU55Ovm3CIamUNNOSIvMBbS7HB0EBe/KHMhme5+Uhtfgjql9B9ihuwT1U3vXQP+cavxe37PJOCUuuATLyd0GX+Islkq2v1pEKX0dsXhMpDwLOYLqckBZHOoAKEo2VYZN0P1KZZkJd4kQHGsADYfuIrLACwzLxlEWmCIq4AOwpYtkMSx85DgT6lW3ECgfbFYVVUzqHUuTiogEsgJ0kouCJw==" | base64 -d | certutil -A -d sql:/dev/shm/tp_pam_srv_tests-test_pam_srv -t TC,TC,TC -n ocsp_cert the NSS library call check this certificate first before trying to connect to the OCSP responder, so a valid one with the right key usage must be added to make NSS try to reach the new OCSP responder - call strace -s 128 -f -esend .libs/lt-p11_child --debug-microseconds=1 --debug-timestamps=1 --debug-to-stderr --debug-level=10 --pre --nssdb sql:/dev/shm/tp_pam_srv_tests-test_pam_srv where you should see lines like send(7, "\313D\1\0\0\1\0\0\0\0\0\0\6ipa-ca\3ipa\5devel\0\0\1\0\1", 34, MSG_NOSIGNAL) = 34 from the DNS lookups for ipa-ca.ipa.devel which is the OCSP server from the ticket - call strace -s 128 -f -esend ./p11_child --debug-microseconds=1 --debug-timestamps=1 --debug-to-stderr --debug-level=10 --pre --nssdb sql:/dev/shm/tp_pam_srv_tests-test_pam_srv --verify 'ocsp_default_responder=http://oooo.cccc.ssss.pppp:80,ocsp_default_responder_signing_cert=ocsp_cert' where you should now see lines like send(7, "yO\1\0\0\1\0\0\0\0\0\0\4oooo\4cccc\4ssss\4pppp\0\0\1\0\1", 37, MSG_NOSIGNAL) = 37 from the DNS lookups for the OCSP responder from the command line. Of course all the validations will fail with "Certificate [SSSD Test Token:Server-Cert][CN=ipa-devel.ipa.devel,O=IPA.DEVEL] not valid [-8071], skipping" because none of the OCSP responders are available but I think this test is sufficient to see that the patch is working as expected. bye, Sumit

3 11

[PATCH] Failover to next server if authentication fails
by Pavel Březina 19 Sep '16

19 Sep '16

We can fail in sasl_bind_send() with ERR_AUTH_FAILED for basically unspecified reason but we do not failover to next server. This patch should fix it. As said on the meeting, I didn't reproduce it and I'm not sure if it will fix the customer issue unless they confirm it, but it seems to be a valid patch anyway.

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel July 2016