Logging user actions

[Alexander Amelkin]

01.06.2018 18:23, Tanous, Ed wrote:
>> It would be great if we weren't using D-Bus at all or if we had all user 
>> interfaces connected to some central hub so that accounting information 
>> was available to that hub and it could log all user requests before translating
>> them further to D-Bus.
>>
>> Don't IBM, Google, Intel and other big guys want to log user actions?
>> It's quite strange to not have this functionality in OpenBMC and, what is
>> more important, not have the architectural possibility to properly (in a single
>> place) implement it. It feels like I'm just missing something.
>>
>> Alexander.
> Does Intel want our systems to be able to log user actions?  Yes.
But your openbmc-based systems aren't yet capable of that, right?
> With that said, I'm not really following why this couldn't be done over dbus, and why a "central hub" as you call it would make the task any easier.  Also, so you're aware, dbus-daemon (the entity that connects / authenticates and authorizes all dbus connections and messages) could very easily be called a "central hub" and could be patched to log every dbus action if that was the route you wanted to go down.
As far as I understand, "dbus-daemon" only knows which other dbus daemon
sent the request. As you noted, today when every daemon is running as
root, there is little help in that. When a request comes to
phosphor-rest-server from phosphor-webui, the former doesn't forward the
authentication/accounting info to dbus-daemon (or at least not after it
has successfully created a session cookie for the user). Isn't it so?
> I don't really like DBus; I find it difficult to use, and more importantly difficult to teach to people.  But it's what we have today, and so far as I can tell, it is capable of serving the purposes we need it to serve, including the logging features we need to build in the future.  If you have a suggestion for a better IPC design, and are willing to move all of the existing daemons over to it, I'm sure some people would be willing to hear to you out, but I don't think logging being difficult to implement justifies that kind of major change for the project.
>
> I'm sure other have ideas on how to make this work.  In short, I would much rather spend resources on making the current solution we have work for all use cases, even if it's not a beautiful architecture, than attempting to recreate what we have using another IPC.
>
> -Ed
Ed, thank you so much for your clarification. I'm not proposing to
change the IPC as it apparently appeared to you probably due to my bad
English. I don't like DBus either for exactly the same reasons that you
named (and because I don't understand it well and don't feel confident
about it), but I'm not proposing to ditch it and replace with anything
else. At least not right now. I would prefer classic IPCs like shm and
named semaphores, but that's out of the scope of this topic, definitely.

> Can you expand a little on your comment that dbus doesn't have any accounting in its messages signals?  It has timing information, as well as user information.  Were you hoping for a "requested from interface" type field?  Today every daemon is running as root, and not authorizing as a specific system user, so that authorization info is not very useful, but that could be changed with a good understanding of the permissions system, and a good understanding of dbus, and by making the daemons run as non-root.  We are in the process of trying to do this anyway for bmcweb, albeit for different reasons, but the concept should be similar.
Yes, I was exactly hoping to have a "requested from interface" type
field as in "requested from WebUI by user 'john' coming from
172.17.31.12", not as in "requested from phosphor-foobar-daemon".

Can this be achieved in the existing architecture in any way? Maybe I
just don't know how to do it with dbus (or openbmc) and you can point me
to some documentation? That would be just great.

> Another design that could be attempted could be to add a new signal named "user action" that we could plumb into all the user facing daemons that would populate the information to the logging daemon.  All the user-facing daemons would then be required to send that signal (either automatically via the sdbusplus bindings, or manually) on a user action.  While not the ideal solution, it seems like it would solve the problem with generating too many system internal events, and would make what we're logging very explicit.  Also, we could attach whatever information we see fit.
This approach doesn't look much different to me than having separate
(direct) logging added to each of the user interfaces.
It has just the same problem: people __wil__ forget to add those "user
action" calls at all for newly added actions (or interfaces), or they
will add them to some user interface daemons and forget to add them to
others. Besides, almost every request to REST is a "user action", but
I'm not sure we'd like to see them all logged. Having a place where all
the requests from all possible (including future) user interfaces are
funneled through one point, filtered and logged in a uniform way would
solve that problem, but I'm not sure if that is feasible.

I really hope this discussion continues and we come up with some good
solution.

Thanks again.
Alexander.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180601/f84477a9/attachment.sig>