Question regarding domain-local groups filtering
by Samuel Cabrero
Hi,
I found the filtering of domain-local groups was implemented after a
change to query the group memberships from the LDAP server of the
domain the user belongs to instead of the global catalog, which had the
side effect of retrieving the DLGs of trusted domains [1].
This DLGs are cached but treated as non-POSIX gruops (no gid number
assigned and not returned), after the commit implementing the filter
[2].
I have found an use case where not filtering domain-local groups would
be useful. If you want to use group memberships in sudo rules to allow
temporary sudo access, the replication latency of global groups is very
high and can take up to 15 minutes, but using domain local groups
replication is done in less than one minute.
Would you willing to accept a patch adding a new parameter to disable
the filtering of DLGs?
Regards,
[1] https://pagure.io/SSSD/sssd/issue/2161
[2] https://pagure.io/SSSD/sssd/issue/2178
--
Samuel Cabrero / SUSE Labs Samba Team
GPG: D7D6 E259 F91C F0B3 2E61 1239 3655 6EC9 7051 0856
scabrero(a)suse.com
scabrero(a)suse.de
4 years, 1 month
KCM notifications
by Pavel Březina
Hi devs,
I'm thinking about ways to implement SSSD KCM notification that
something has changed (i.e. user called kinit/kdestroy) [1]. The main
use case is to notify Gnome Online Accounts (which is a daemon running
under logged-in user) when something has changed and it is already a
D-Bus service.
The basic idea is that we would use D-Bus signals that would be emitted
by SSSD KCM responder (sssd_kcm process). Signals are broadcasted
messages that are delivered to client that chose to listen to them.
The problem is that we
1) can't connect to specific user's session bus because KCM runs as
root/sssd and connecting to other user's bus is not allowed
2) can't specify which user is allowed to get the signal
3) therefore we can't send the signal only to specific user
So the solution is that KCM connects to system bus and sends
org.sssd.kcm.Changed(uid) signal where uid is uid of the user which
ccache has changed so the receiver can know which user is affected. This
signal is broadcasted to everyone who listens to it.
It is perfectly usable, however the question is whether we can broadcast
this information (that user A run kinit/kdestroy/other modification of
ccache) or it is a security leak that we must avoid and we should seek
other solution.
I asked this secalert and they reply that there is no security concern
"but":
> After looking at this issue, honestly I dont see an attack vector here, but i am afraid something like this could be used with some other security flaw to maybe gain privesc? For example a flaw which is some component which can be triggered only when kinit is run? where precise timing is required.
>
> So in conclusion if there is another "better" solution than it should be preferred. Or in worse case atleast have an option to disable this somehow via some config, so that such situations can be avoided.
I don't think a precise timing is necessary and we can send the signal
few miliseconds or a second later. That should eliminate this concern (I
asked this, waiting for an answer).
I can think of two more solutions currently:
1) Have client connect to KCM socket and await signal there. This
however would mean that connection between client and KCM need to be
always established and KCM responder would be running all the time
(currently it is only short-lived socket activated process).
2) Create a temporary file in a directory owned by user. User can then
setup inotify watch to the file and sssd would write to the file on
changes. Since it is in directory owned by user, other users would not
be able to setup the watch.
Note that it is possile to setup inotify watch on FILE ccache (keeping
distro settings out of the question the default ccache is
FILE:/tmp/krb5cc_%{uid} as per krb5.conf manpage) so perhaps we really
don't have to care about broadcasting this information.
Thanks,
Pavel.
[1] https://pagure.io/SSSD/sssd/issue/3568
4 years, 1 month
[sssd PR#918][comment] Add support for NSS hosts database lookup.
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/918
Title: #918: Add support for NSS hosts database lookup.
sumit-bose commented:
"""
Hi,
I think the following is missing to make the tests pass:
```
diff --git a/src/config/SSSDConfigTest.py b/src/config/SSSDConfigTest.py
index 74b4c8e..5e6de8e 100755
--- a/src/config/SSSDConfigTest.py
+++ b/src/config/SSSDConfigTest.py
@@ -845,9 +845,10 @@ class SSSDConfigTestSSSDDomain(unittest.TestCase):
'ipa': ['id', 'auth', 'access', 'chpass', 'sudo', 'autofs',
'session', 'hostid', 'subdomains'],
'ad': ['id', 'auth', 'access', 'chpass', 'sudo', 'autofs',
- 'subdomains'],
+ 'subdomains', 'resolver'],
'local': ['id', 'auth', 'chpass'],
- 'ldap': ['id', 'auth', 'access', 'chpass', 'sudo', 'autofs'],
+ 'ldap': ['id', 'auth', 'access', 'chpass', 'sudo', 'autofs',
+ 'resolver'],
'krb5': ['auth', 'access', 'chpass'],
'proxy': ['id', 'auth', 'chpass'],
'simple': ['access'],
@@ -1414,6 +1415,7 @@ class SSSDConfigTestSSSDConfig(unittest.TestCase):
'chpass_provider',
'sudo_provider',
'subdomains_provider',
+ 'resolver_provider',
'default_shell',
'fallback_homedir',
'cache_credentials',
```
About IPA, I think a dedicated resolver is not needed.
bye,
Sumit
"""
See the full comment at https://github.com/SSSD/sssd/pull/918#issuecomment-592586453
4 years, 1 month
[sssd PR#918][comment] Add support for NSS hosts database lookup.
by scabrero
URL: https://github.com/SSSD/sssd/pull/918
Title: #918: Add support for NSS hosts database lookup.
scabrero commented:
"""
Hi @sumit-bose
I have fixed the issues, but I have skipped adding the `ldap_iphost_*` options to `src/config/etc/sssd.api.d/sssd-ipa.conf` because the resolver provider is not implemented yet for the IPA backend. I don't know it very well and after having a quick look to `src/providers/ipa/ipa_common.c` I am not sure if the schema is compatible with RFC2307 iphosts and there are design decisions to make like the CN to place the hosts. I will be happy to implement it if required, but I would like to get this merged and implement the netwoks lookup before.
"""
See the full comment at https://github.com/SSSD/sssd/pull/918#issuecomment-592501897
4 years, 1 month