ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Mar 6, 2014 at 7:16 PM, Ryan Lortie <desrt@xxxxxxxx> wrote:
> hi,
>
> On Thu, Mar 6, 2014, at 12:19, Sebastien Bacher wrote:
>> 1. using accountsservice there as well, maybe adding support for
>> "volatile" informations which wouldn't get store.
>
> I don't like this.
>
> The reason that we ever started to put information in accountsservice
> was pretty simple: because we needed access to certain information when
> the user is not logged in and therefore we don't have access to their
> home directory (possibly due to encryption or NFS).
>
> This was never meant as a bridge between the session and the greeter.
> This was always explicitly because we needed a place for data when the
> user is _not_ logged in.
>
> This is also quite a bad approach for dynamic information because such
> information could become stale when the user logs out (unless we add
> hooks to logind to tell accountsservice when to flush this information).
>  From a slightly less practical and more theoretical side it also "feels
> wrong" to be storing information such as MPRIS media player stuff inside
> of anything that has any kind of state at all (volatile or otherwise)
> because we would need something in the session to monitor the state and
> push it into the service, and this information could very easily get
> stale if something stopped working properly.
>

We also have to make sure that we account for lifecycle implications
here: In a locked session, we will likely stop all running
applications and only (trusted) helpers in the user session stay
active. With that, we already have parts of the monitoring components
in place.

To make sure we are on the same page:

  (1.) What means stale here? My assumption here is that any update to
AS is timestamped.
  (2.) In the "lightdm on session-bus"-case we wouldn't experience
staleness due to lightdm knowing that the user logged out?

> Storing the information in accountsservice also has the highest overhead
> of all of the mentioned approaches, even if we mark the data as volatile
> and avoid saving it to disk.  First we need a component in the session
> to do the monitoring of whatever state we want to update in the greeter.
>  Then we have to have this component send a message to a process on the
> system D-Bus and this process has to do polkit checks (more D-Bus
> messages) in order to ensure that the sender has the right to make the
> request.  It then has to update its internal state and fire a signal
> across the system D-Bus information others that the change has taken
> place.
>
>> 2. get lightdm to connect to the user-session bus and send back selected
>> informations to the greeter.
>>
>> That seems like the most flexible/powerful solution, giving access to
>> the user session might be a concern for security though.
>
> In a sense, this is the "best approach".
>
> I think having lightdm come onto the user's session bus as soon as the
> user has logged in has a lot of appeal for quite some reasons.  If we
> are having lightdm handle the locking then this could allow lightdm to
> communicate with the session (and its contents) about things like
> inhibit, for example.
>
> This would also be the best approach to allowing us to model dynamic
> information (such as the state of MPRIS music players).  It would not be
> subject to stale data about the playing song, for example, because the
> information would not be persistently stored anywhere at all -- only
> proxied.  It would be lightdm actively monitoring things, rather than a
> utility component in the user's session (which all other approaches
> would require).
>
> The drawback here is security of course.  Attaching a privileged
> component to the user's session bus exposes a lot of surface area to
> possible attack.  Even with system level D-Bus components running as
> root we don't see this level of exposure because they are hidden behind
> the D-Bus daemon, which provides an additional level of protection.  In
> this case, the user controls the D-Bus daemon, so they can inject
> whatever junk they want directly into this component.
>
> If we feel that we can manage the security implications of this (like,
> having it not run as root, for example) then I think this is the best
> approach.  I think it might be difficult to convince ourselves of this,
> however.
>
>> 3. having a subdirectory in the user's XDG_RUNTIME_DIR, which is visible
>> to the greter via a privileged protocol in lightdm (lightdm opening
>> files and sending content, or using fds are possible options)
>>
>> that should do the job, be easy enough and not risk exposing too much
>> from the user session
>
> This is a balanced approach.  It removes the ills of abusing
> accountsservice for something that it has no logical business doing and
> it provides protection against staleness because of how strictly logind
> manages the directory (blowing it away at logout, guaranteed fresh at
> new login, etc.).
>
> In common with the accountssevice approach, it would still require an
> extra component in the session, but this component would be a lot easier
> to write and would have far lower overhead (since it only writes files
> to a tmpfs -- almost free).
>
> On the lightdm side, the interface could be very simple (and therefore
> quite safe).  Lightdm would grow an API on the greeter socket protocol
> that would look like one of two things:
>
>  1) API to read a file from a restricted subdirectory of a user's XDG
>  runtime dir, plus a change notification API (probably based on inotify
>  directly).  This is the bigger of the two possible APIs, but more
>  traditional and sane.
>
>  2) API to have an open file handle to the directory sent to the greeter
>  directly.  The greeter could then inotify() on this file handle for
>  itself and also openat() files contained within it.  Escaping via ".."
>  would not work because the runtime directory is guaranteed to have
>  permissions 0700.  This is a very small API but it has a weird flavour.
>   I think it's quite fine, though.
>
> In either case, the idea of placing a socket in this directory may also
> be interesting.  In both cases, we would need a separate call to support
> this.  The reason for that in case 2 is because there is no *at()
> equivalent for the connect() system call as used on AF_UNIX.
>
> Some other possibilities are worth mentioning:
>
> Michael Terry tells of a directory that is already shared between the
> user and the lightdm greeter.  This is used for storing bulk data not
> appropriate for the accountsservice (such as the user's face photo).  In
> fact, in light of this, one wonders why we have the accountsservice
> storing any information at all -- it could all go here.
>
> I do not consider this an appropriate place for the transient state that
> we're talking about here though, for the above-mentioned concerns about
> staleness.
>
> A final possibility is that we find a simple way to create a socket that
> can be shared between the session and the greeter and write a small
> program to shuffle data across it.  This shares the problem that we need
> a component in the session (as with all of the cases above except the
> one where lightdm gets directly on the session bus).  We also have to
> figure out a way to share the socket, but this doesn't seem like it's a
> particularly difficult problem to solve.
>
>

So why wouldn't we just put a monitoring/infographics component
outside of the session and hook it up to the session bus? It could
expose a very limited API to the session with a very small attack
surface. The greeter then communicates with that component outside of
the session (via a different API) and we just leverage it as a proxy.
The greeter knows when the user logs out, so any sort of staleness
should be accounted for.

Cheers,

  Thomas
>
>
> Cheers
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp