Logging user actions

Logging user actions

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 1179 bytes --]

Hi all!

Customers ask us for extensive user action logging. That is, they want
to log everything that a user may change in the system. They want to
know who, how (via which interface) and when changed what. That includes
but is not limited to network configuration, host power on/off, reboots,
power restoration policy changing, firmware updates, user
addition/deletion and password changing, et al. 

We could listen for dbus signals and log most of that, but that way we
wouldn't know whether a user made a change or that was some internal
work. Additionally, that would yield an enormous amount of data logged
if we just log every property change. We could limit logging to a
predefined subset of properties, but when later the community adds a new
crucial property, we could miss it in our logs.

We could log requests at each user interface (thankfully, we don't allow
shell access for users), but that would mean having copies of the same
logic in different subsystems, which is error prone, plus those copies
will definitely diverge with time.

Does anyone have any idea on how to best implement such a requirement?

Alexander Amelkin
YADRO



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Logging user actions

[Deepak Kodihalli]

On 28/05/18 5:30 pm, Alexander Amelkin wrote:
> Hi all!
> 
> Customers ask us for extensive user action logging. That is, they want
> to log everything that a user may change in the system. They want to
> know who, how (via which interface) and when changed what. That includes
> but is not limited to network configuration, host power on/off, reboots,
> power restoration policy changing, firmware updates, user
> addition/deletion and password changing, et al.
> 
> We could listen for dbus signals and log most of that, but that way we
> wouldn't know whether a user made a change or that was some internal
> work. Additionally, that would yield an enormous amount of data logged
> if we just log every property change. We could limit logging to a
> predefined subset of properties, but when later the community adds a new
> crucial property, we could miss it in our logs.
> 
> We could log requests at each user interface (thankfully, we don't allow
> shell access for users), but that would mean having copies of the same
> logic in different subsystems, which is error prone, plus those copies
> will definitely diverge with time.
> 
> Does anyone have any idea on how to best implement such a requirement?


phosphor-dbus-monitor has event monitoring support. You can specify via 
build-time config (YAML files) what D-Bus interfaces/properties you're 
interested in, and a corresponding "event" D-Bus object is created under 
the /events/<event_category>/ namespace. This was implemented via
https://github.com/openbmc/openbmc/issues/2254.

This doesn't address all of the concerns you've mentioned above in terms 
of the amount of data that can be logged. It helps specify the 
properties of interest though, and the event D-Bus objects are persisted 
upto a certain limit.

> Alexander Amelkin
> YADRO
> 
> 

Regards,
Deepak

Re: Logging user actions

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 2723 bytes --]

30.05.2018 17:09, Deepak Kodihalli wrote:
> On 28/05/18 5:30 pm, Alexander Amelkin wrote:
>> Hi all!
>>
>> Customers ask us for extensive user action logging. That is, they want
>> to log everything that a user may change in the system. They want to
>> know who, how (via which interface) and when changed what. That includes
>> but is not limited to network configuration, host power on/off, reboots,
>> power restoration policy changing, firmware updates, user
>> addition/deletion and password changing, et al.
>>
>> We could listen for dbus signals and log most of that, but that way we
>> wouldn't know whether a user made a change or that was some internal
>> work. Additionally, that would yield an enormous amount of data logged
>> if we just log every property change. We could limit logging to a
>> predefined subset of properties, but when later the community adds a new
>> crucial property, we could miss it in our logs.
>>
>> We could log requests at each user interface (thankfully, we don't allow
>> shell access for users), but that would mean having copies of the same
>> logic in different subsystems, which is error prone, plus those copies
>> will definitely diverge with time.
>>
>> Does anyone have any idea on how to best implement such a requirement?
>
>
> phosphor-dbus-monitor has event monitoring support. You can specify
> via build-time config (YAML files) what D-Bus interfaces/properties
> you're interested in, and a corresponding "event" D-Bus object is
> created under the /events/<event_category>/ namespace. This was
> implemented via
> https://github.com/openbmc/openbmc/issues/2254.
>
> This doesn't address all of the concerns you've mentioned above in
> terms of the amount of data that can be logged. It helps specify the
> properties of interest though, and the event D-Bus objects are
> persisted upto a certain limit.
In fact it doesn't address even more. D-Bus doesn't have any accounting
information in its events/signals. phosphor-dbus-monitor is a great
thing, but it has no clue as to who (which user from which IP address)
has requested a HostTransition to 'off', etc.

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: Logging user actions

[Tanous, Ed]

> 
> 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.  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.

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.

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.

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.

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

Re: Logging user actions

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 5381 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]