[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Schaufler, Casey casey.schaufler at intel.com
Fri Oct 11 16:30:23 GMT 2013


Dominique and I discussed the underlying problem in some detail
and believe that we have a cleaner solution.

The plan is to have one launcher that services all requests.

The launcher will have to be privileged, but will reduce the
capabilities required to the extent possible.

The launcher will accept a message from the user session
handling portion of systemd that contains the environment
information assigned to the user when the session is started.
The launcher will accept a similar tear-down message from
the systemd user session manager as well.

In the future the set of messages accepted by the launcher
may be expanded to accommodate modification of the
user environment.

The systemd user session initialization and tear-down will
be modified (extended?) to send the user environment
information to the launcher.

This is a saner approach than attempting to glean the
information from another process. It provides a clean
interface and assurance that the information is accurate.
It allows for future extension. It works with the systemd
model, rather than at odds with it.


> -----Original Message-----
> From: Jussi Laako [mailto:jussi.laako at linux.intel.com]
> Sent: Friday, October 11, 2013 2:04 AM
> To: Schaufler, Casey
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID
> issue
> 
> On 10.10.2013 19:15, Schaufler, Casey wrote:
> > Only if you look, and you still don't know if the other side broke the
> connection and is still running or if it died and there's a different process
> running with the same pid.
> 
> For example in gsignond we have p2p socket for D-Bus, so in case the other end
> broke the connection, by doing so it also ceased to receive any services and all
> it's remote objects were destroyed.
> 
> If it's a different process under same PID, then the socket descriptor cannot be
> valid anymore.
> 
> > Except that the original process could have close()d the socket and still be
> running, so the test in (3) yields a false negative. And, how do you do validate
> that "(1) is still intact"?
> 
> If it did so, then we wouldn't perform any action for it either anymore.
> It can get the request done at phase (1) completed only by being around at (3)
> too, since it is anyway required in order to receive reply to the D-Bus message.
> 
> You get error if the socket's other end was terminated at least latest when you
> try to read() or write() to it. IMO, getsockopt(SO_PEERCRED) should also fail if
> the peer has closed the socket and terminated the process (I have not verified
> this yet though, but it is easy to do).
> 
> 
> The way I implemented ACL in gSSO for standard Linux desktop (just DAC
> enabled, no MAC support) is that we have a p2p D-Bus over socket between
> client application and gsignond (works also with session&system bus).
> When request is received over the socket, SO_PEERCRED is used to fetch
> callers PID and then /proc/PID/exe symlink is dereferenced to binary path of
> the caller which is then compared against the ACL defined for stored credential
> and then response is performed and sent back over the same socket. So in case
> the application terminated meanwhile and the process got replaced with
> something else, the application wouldn't be able to receive the response it
> wanted. Or at least it had voluntarily given up it's privileges to someone else...
> If someone has better ideas how to do it with D-Bus I'd be more than happy to
> hear about it!
> 
> 
> --- 8< --- (maybe OT)
> In these cases databases are also protected from the user, gsignond is running
> with setgid to "gsignond" group, but running with users' uid.
> Then databases are stored in a directory that is only accessible to uid=root
> gid=gsignond while per-user database is only accessible to uid=user
> gid=gsignond. User is not member of "gsignond" group. This way user cannot
> access the database directory, while gsignond cannot accidentally access
> databases of other users even if it had a bug...



More information about the Dev mailing list