Sumit Bose <sbose(a)redhat.com> writes:
On Thu, Feb 20, 2020 at 12:27:23PM -0500, Simo Sorce wrote:
> On Thu, 2020-02-20 at 11:18 +0100, Pavel Březina wrote:
>> 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
>
> Can you explain what this means?
>
>> 3) therefore we can't send the signal only to specific user
>
> Why not?
> We definitely should be able to know what user is listening on the
> other side of a bus, so we could simply only send back info related to
> that same user? Or are we blinded to which user is interacting with us?
>
>> 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.
>
> This means users can monitor each other, sounds bad.
>
>> 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.
>
> Looks quite bad, why do we need to broadcast to everyone?
> Isn't there an interface where a specific user can initiate a listening
> channel and we send back only info related to that user?
>
>> 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).
>
> It's more of a privacy reason to me, if we can find other ways that do
> not broadcast this to everyone I think it would be better.
>
>> 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).
>
> Is this (shortlivedness) why we can't use a listener ?
>
>> 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.
>
> But how will the daemon be able to do this?
> At the very least the file would need to be in /run/user because home
> directories could be on NFS where root can't write, and besides this is
> really temporary state and has no business in home directories.
>
>> 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.
>
> That is a good point, I still dislike actively broadcasting around I
Hi,
I'd also prefer the file/inotify based version. It would be also easier
for Gnome-Online-Accounts (GOA) to implement this since that already do
inotify on the FILE ccache.
However, this is a quite specific fix just for GOA I'm not sure if
there are other use cases as well.
Going back to the original issue, the constant activity/load which is
caused by GOA polling the KCM ccache state in regular, short
intervals. Iirc Simo suggested in the related ticket to implement a
rate-limitation. So if we detect a too many request in a short time
from a single PID we can just delay the response. This would not
require changes on the GOA side and might be useful in other cases as
well. But there is a drawback, KCM will still run constantly. With the
file/inotify solution KCM can shutdown itself when there is no
activity.
So if GOA team agrees with the needed changes on the GOA side the
file/inotify solution might be better.
CCing some GOA folks. I believe their preference was for the inotify
approach.
Moreover, I'd like to provide a consistent interface to all of the
ccaches from krb5. I'm not going to be able to do that if dbus becomes
involved (for a variety of reasons).
Thanks,
--Robbie
bye,
Sumit
> wonder if it is possible to just reconnect to the system bus and learn
> who is listening and just target those listeners as appropriate.
>
> Is the system bus stateful? Do clients have to reconnect whenever a
> daemon restarts?
>
>> Thanks,
>> Pavel.
>>
>> [1]
https://pagure.io/SSSD/sssd/issue/3568
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
>
>