Tlog integration and packages
by Nikolai Kondrashov
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
6 years, 9 months
[PATCH] Unit tests for pam_sss using pam_wrapper (need help with CI..)
by Jakub Hrozek
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..
7 years
[PATCHES] p11: add no_verification option
by Sumit Bose
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
7 years, 2 months
[PATCH] Failover to next server if authentication fails
by Pavel Březina
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.
7 years, 2 months
[PATCH] FO: Set port to NOT_WORKING when trying a next server
by Jakub Hrozek
Hi,
attached is a patch that I think is correct and it did solve a bug I was
seeing, but I'm not sure if it's the right thing to do since the code
was stable since 2009..
What I was seeing was a scenario where an LDAP server was listening on port
389, so we were able to connect there with a socket, but then all searches
timed out during rootDSE discovery.. What happened in the sdap_id_ops.c
code was that we hit this part:
810 switch (retval) {
811 case EIO:
812 ---> case ETIMEDOUT:
813 /* this currently the only possible communication error after connection is established */
814 communication_error = true;
815 break;
816
817 default:
818 communication_error = false;
819 break;
820 }
821
And then we went here, because the connection was already established:
822 if (communication_error && current_conn != 0
823 && current_conn == op->conn_cache->cached_connection) {
824 /* do not reuse failed connection */
825 op->conn_cache->cached_connection = NULL;
826
827 DEBUG(SSSDBG_FUNC_DATA,
828 "communication error on cached connection, moving to next server\n");
829 ----> be_fo_try_next_server(op->conn_cache->id_conn->id_ctx->be,
830 op->conn_cache->id_conn->service->name);
831 }
But I admit I don't understand why does be_fo_try_next_server() set the
port status to NEUTRAL. That caused the connection code to run again,
hit the same timeout issue and then cycle again and again..
Can anyone parse from the code why do we set the port to neutral instead
of not_working in be_fo_try_next_server() ?
7 years, 5 months
[PATCH] PAM: Allow to configure pam services for smartcards
by Lukas Slebodnik
ehlo,
attached patch should fix ticket #2926
The default case (no adding, no removing services) is tested
by pam-srv-tests.
If the patch is not ready for stable branch sssd-1-13
then we might merge this case with GPO code which uses slightly
modified way using hash tables.
LS
7 years, 5 months