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:
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
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
* We follow the route similar to that taken by SELinux rule control
implementation . I.e. store the configuration in LDAP HBAC rules,
write to files on the client side and then specify them to tlog upon user
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  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
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:
scope = none
; Enabled for everyone
scope = all
; 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.
P.S. I'm on PTO for two weeks starting next week, so might not be able to
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:
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..
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
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
I worked on an alternative approach as well which tried to make the
memberof plugin aware of the defaultOverrideName attribute. My wip tree
but so far it does not work properly. Additionally I would prefer to not
touch the memberof plugin.
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.
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
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
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
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
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.
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.