Sending the FD over D-bus

[William Kennington]

On Tue, Apr 9, 2019 at 11:16 PM Ratan Gupta <ratagupt at linux.vnet.ibm.com> wrote:
>
>
> On 10/04/19 10:28 AM, Deepak Kodihalli wrote:
> > On 10/04/19 10:23 AM, Deepak Kodihalli wrote:
> >> On 10/04/19 7:43 AM, William Kennington wrote:
> >>> What is the issue with just sending them over d-bus? The only party
> >>> that can view the messages outside of the normal unicast partner is
> >>> the dbus-broker process. You are still trusting the dbus-broker in the
> >>> file descriptor case. On top of that you are probably still trusting
> >>> the mapper to give you the correct service name prior to sending the
> >>> secrets.
> >>
> >>
> Ed, Richard mention that sending the secrets over D-bus is a security
> concern like some compromised application on the
>
> bmc can watch the D-bus traffic and get the secrets.
>
Yes, if you are root you can monitor the system bus and read the
secrets, but you can also load kernel modules and read process memory
for any process on the system. If we just ran daemons as unprivileged
users with access to the hardware resources they needed we wouldn't
have this problem. Untrusted, unprivileged programs can write into the
objectmapper right now anyway. I just don't want to see us create a
more complicated system that gives no actual security benefit.
> >> +1
> >>
> >>
> >> Ratan,
> >>
> >> In case bmcweb makes a D-Bus method call to phosphor-user-manager,
> >> and one of the args of that method call is the password, is the value
> >> of that argument even visible to other processes connected to the
> >> system bus?
>     yes whether it is a D-Bus method call or the D-Bus object having
> properties both are same, any application can watch it.
> >> If it is, two processes can talk to each other directly using
> >> libdbus, that wouldn't even involve the system d-bus
> >> daemon/dbus-broker I guess.
> I have to experiment that over libdbus, I haven't done that but seems
> p2p binding is there with Qt, not sure witrh sd-bus.
> >>
> >> Regards,
> >> Deepak
> >
> >
> > https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/19409/1/xyz/openbmc_project/User/Ldap/Config.interface.yaml
> > - the password here is a property, I guess that's the concern. Could
> > the API instead be a method call taking the password - with that it
> > would just be the two processes (and d-bus broker) that would have
> > visibility to this.
> >
> > Regards,
> > Deepak
> >
> >>> On Tue, Apr 9, 2019 at 12:49 PM Ratan Gupta
> >>> <ratagupt at linux.vnet.ibm.com> wrote:
> >>>>
> >>>> Hi All,
> >>>>
> >>>> As Discussed in yesterday community call, I did some POC to send the
> >>>> unix FD object over the D-Bus.
> >>>>
> >>>> BackGround: We are exploring the possibilities how to send the secrets
> >>>> from one process to other process,
> >>>>
> >>>> a) If the IPC is D-bus
> >>>>
> >>>> b) Calling process doesn't have the root permission to write the
> >>>> secrets
> >>>> in the configuration file.
> >>>>
> >>>> One of the proposal came, Can the calling process  send the unix fd
> >>>> over
> >>>> the D-Bus instead of sending the actual password
> >>>>
> >>>> and receiving process reads the data from the sent fd.?
> >>>>
> >>>> There was a confusion if some other app can snoop the D-bus message
> >>>> and
> >>>> get the FD and read it.I tried to simulate the same
> >>>>
> >>>> behavior in the POC but not sure whether it is correct or not.
> >>>>
> >>>> This POC has two files which is attached with this mail.
> >>>>
> >>>> Dbus-Service(dbus-service-fd-test.py):  Method(readFD) which takes the
> >>>> unix fd as parameter reads it and send the data back
> >>>>
> >>>> Dbus-Client(dbus-client-fd-test.py): Writes dummy data in the file,
> >>>> then
> >>>> opens the file and send the fd over D-bus.
> >>>>
> >>>>
> >>>> After sending the data over D-bus , I introduced a sleep of 15 sec so
> >>>> that I can try to open the same fd from other
> >>>>
> >>>> process,I open the python shell and try to open the shared FD but
> >>>> couldn't open it.
> >>>>
> >>>> Ratan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>