Logging user actions - with an AAA service

[Joseph Reynolds]

On 5/28/2018 7:26 AM, openbmc-request at lists.ozlabs.org wrote:
> Message: 2
> Date: Mon, 28 May 2018 15:00:06 +0300
> From: Alexander Amelkin<a.amelkin at yadro.com>
> To:<openbmc at lists.ozlabs.org>
> Subject: Logging user actions
> Message-ID:<c0569989-b52d-745e-06fb-e92cbb1234c8 at yadro.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
Yes.  This topic came up in yesterday's OpenBMC security working group 
meeting.  My impression of the main idea is to enhance OpenBMC with an 
AAA (authentication, authorization, and accountability/auditing) 
management interface.  When enabled, all external security-related 
requests would use the AAA service to authenticate, authorize, and audit 
the function.  That is, they would pass in the user's credentials 
(userid&password, certificate, etc) along with a request to perform an 
operation (example operations: read host server part inventory, reboot 
the host) and get a yes/no answer from the AAA service.  Then either 
deny the request or perform it.

A very basic AAA service would be to use the Linux username/password 
checker (/etc/passwd, PAM, LDAP), allow all operations, and write no 
audit records.  A more advanced AAA service provider might contact a 
separate AAA server to perform this function.  The advantages with the 
remote server approach is that user credentials would not have to be 
stored on the BMC, and audit records would not take up space on the BMC.

To make this work, OpenBMC would have to:
1. Create an AAA interface (from an open source project?) and create a 
very basic AAA service provider.
2. Define the operations the the AAA service recognizes and the external 
interfaces use.
3. Change all external interfaces (REST APIs, IPMI, etc.) to invoke the 
AAA service

I've started to outline some of the security considerations for this 
approach in the security docs, current being reviewed in 
https://gerrit.openbmc-project.xyz/#/c/10443/ in file 
obmc-protection-profile-modules section named "AAA Management service".

- Joseph Reynolds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180601/9a97f726/attachment.html>