On Fri, 2020-02-21 at 11:22 +0100, Pavel Březina wrote:
> On 2/20/20 6:27 PM, 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?
>
> See below.
>
> > > 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?
>
> We need to distinguish method calls and signals. Method calls are
> (usually) unicast - client send method call to message bus and it is
> routed to the destination. In this case the destination knows who the
> sender was.
>
> Signals are broadcasted messages and do not have destination. They are
> emitted by the sender and message bus resend it to anyone who is
> listening. The sender does not know who received it.
>
> See:
> https://dbus.freedesktop.org/doc/dbus-tutorial.html#signalprocedure
>
> In theory, it is possible to send signal to a particular destination:
> https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-routing
> but we would have to know the destination name. But I am not aware of
> any way to obtain list of listeners.
>
> But perhaps, we could create a dedicated message bus with our sbus that
> would be publicly available. It could be able to emit the signal only
> for connections with particular uid. Clients could still use standard
> dbus api.
Do we actually have to send a signal?
I was thinking if it is possible for client instead to create a service
with the username in it. Then KCM could be their "client" and call a
method to pass data (which ccache was updated ?) to the service.
No signal involved.
The only problem is that I guess there is no way to restrict paths wo
we would still need to double check that the service name whatever-
whatever-<uid number> is really owned by <uid number> before sending
data.
Can a user create a service on the system bus? Or does it require
privileges ?
> > > 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 am not aware of such interface.
Se above what I mean, it is about reversing the client-server paradigm,
where KCM is the system bus client, and interested parties are actual
"services" ? I guess one issue is that you can only have on service
doing this, but that one service could be a gnome component that then
can rebroadcast the information on the session bus via a signal?
> > > 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.
>
> Yes, I agree.
>
> > > 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 ?
>
> Pretty much yes. KCM is currently stateless responder that stops once it
> is idle.
>
> (*) Perhaps we could make clients to send their name to kcm if they want
> to receive kcm signals and store this information in cache. UID can be
> associated with name. I'm not yet sure if we can tell if the name is
> still available but this could be doable.
This is potentially an idea, are you hinting here at something like
what I proposed above ?
>
> > > 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.
>
> AFAIK KCM runs as root. So we could created /var/lib/sss/kcm/$uid
> directory accessible only by $uid and store files there. But it is
> certainly not ideal.
I thought about this as well but definitely not ideal, unless we do
this only if the interested daemon has somehow signaled explicitly that
notifications are wanted, so that we do not litter the directory with
useless notification files.
However I would still use a file like:
/run/user/<uid number>/.kcm-ccache-notify or similar
But not in /var/lib/sss, /run/user files are removed dynamically when
the user logs out and the session is terminated and won't persist on a
system after reboots and such.
> > > 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
> > wonder if it is possible to just reconnect to the system bus and learn
> > who is listening and just target those listeners as appropriate.
>
> I am not aware of such thing. There is only AddMatch/RemoveMatch to
> start/stop listening but we can't get the list of listeners AFAIK. But
> we could perhaps implement it ourselves (*)
Sounds like too much work, we should try to find a mechanism that
requires as little implementation as possible.
> > Is the system bus stateful? Do clients have to reconnect whenever a
> > daemon restarts?
>
> daemon means dbus daemon? AFAIK if it drops clients need to reconnect.
> At least that is what we do in SSSD.
No, by daemon I meant the service offering services on the system bus
(KCM?), however if we can reverse the service/client direction as I
mention above, this is not really important anymore.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
