On Fri, 2020-02-21 at 11:28 +0100, Sumit Bose wrote:
> 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.
The more I think of this idea of using files the more a file in
/run/user/<uid number>/ sounds like a quite decent idea.
Two limitations come to mind here, but they are probably ok for now:
1) I wonder if /run/user/<uid number> is always guaranteed to exist
when KCM operations for a specific user happen, if not though it is
unlikely that anything is wanting to get notified anyway, so it
probably does not matter.
(The directory will definitely not be there during initial
authentication, because KEYRING and KCM were created in part to
overcome the fact this directory is created only after the first
successful authentication, but this is not important, no user process
will listen before the user is authenticated)
2) One reason to use KCM is that the socket protocol can be proxied,
both across container boundaries and across even the network (I tested
doing that over a SSH connection), in both cases the filesystem that
KCM sees is not the filesystem the clients see. And the same can happen
if /run/user get namespaced in the future. But this is a limitation we
can deal with for now, it does not affect the primary use case (GOA).
Both point 1 and 2 make me think we may want to create notification
files only "on demand" ie a client would have to use a new kcm API call
to set up notifications.
If a client asks we respond with a payload that tells the client which
file they should monitor (this way in future we can change notification
mechanism by simply changing what we return), for example:
FILE:/run/user/1000/.kcm-notify
Internally we store a KCM entry that tells if notifications for that
ccache/user have been requested and we touch the file only if that
entry exists, this will avoid touching a lot of files all over the
place on machines where there are a lot of users but none of them cares
about notifications like an SSH bastion host.
The tricky part is to avoid unnecessary persistence of the notification
mechanism, ie after a reboot KCM should not recreate/touch the
notification file unless a client asked for it.
Perhaps the notification request triggers the creation of the file and
we only touch the file if it already exists.
If someone removes the file it will be the equivalent of requesting
notifications stop.
GOA can have a behavior to ask again for notifications if the file goes
away (and the cache still exists).
--
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
