On Thu, 2022-01-06 at 20:01 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 06, 2022 at 01:17:01PM -0500, Simo Sorce wrote: > > On Thu, 2022-01-06 at 18:02 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, Jan 06, 2022 at 08:48:52AM -0800, Adam Williamson wrote: > > > > On Thu, 2022-01-06 at 16:16 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > > > I know that you said that the scripts are needed because of "magic stuff™" > > > > > that the scripts do, but sorry, that's not a justification: *everything* that > > > > > can be done using a shell script can also be reimplemented independently. > > > > > Right now audit pulls in the whole initscripts stack, this should all be replaced > > > > > by some small helper. (Maybe a separate binary, or a small shell script, or > > > > > maybe something in auditctl…. I don't know because I don't know audit.) > > > > > > > > As I understand the bug, it's not a question of whether the thing can > > > > be done, but whether it can be known *who did it*. > > > > > > There is no magic functionality in the kernel that specifically records that > > > something was executed by some specific script. If that scripts sends a signal > > > somewhere, you can send the same signal with the same sender info and the same privileges > > > using bash/python/C/Rust or even assembly. So the "who did it" information > > > can be provided in a different way without pulling in the initscripts stack, > > > or it is bogus, or maybe even both. > > > > In this case the "who" is the user, not the script. > > Yes, obviously the user is outside of the machine and "user" always > means some program running under the UID assigned to the user. > All I'm trying to say is that if you can make one implementation of this > program (e.g. a set of bash scripts) send some bit of information, you can > make another implementation send the same signal. > > > The problem of going through systemctl is that the "who" is lost > > because all the audit system can see is that systemd started the > > action. Basically the communication between systemctl and systemd masks > > the identity of the user that initiated the action. > > Yes, systemctl doesn't save this information. So audit uses some > alternative command to send this information somewhere. This > alternative command should just send this bit of information where appropriate > and then call systemctl. More-or-less as things are now, but without > the initscripts baggage. I believe the problem is that it is not just a fire and forget signal, any kernel syscall can be traced back to that user by this method, so anything the "scripts" do can be audited. > > I believe a solution needs to be found between systemd and the audit > > subsystem in general so that we remove this whole class of issues > > altogether. > > If there's a need to add something to systemctl or systemd, we can do > it. But it's never been clearly articulated afaik. I am afraid the hurdle, so far, is that there is a belief that the only way to get valid audit logs when systemd-init is involved is to trust the whole of it, which would require the development of a whole trusted audit subsystem/hand-off within systemd. I think that potentially one option would be to provide a kernel audit API that systemd could be trusted to use to set the user ids so that the audit subsystem is given those when there is the systemctl -> systemd hand-off. But that requires the audit and systemd teams to agree on what that trust and those controls means, and figure out how to comply to all regulations in the process of adding this stuff. This is probably no small feat. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
