[09:44:21] not an endorsement but I wonder if sth like this would be useful for our auditing/security purposes https://falco.org/docs/ [10:48:35] from my PoV instead of investing to shape policies to _monitor_ the behaviour it's much more beneficial to rather spend the time and _restrict_ the applications at hands, e.g. things like "A non-device file is written to /dev" can just as well be prevented with a systemd unit directive [10:48:59] falco seems directed at cloud providers, but we have control over our applications (sans Cloud VPS) [10:55:41] moritzm: if we put the restrictions in systemd is it correct that the journal will show any attempts to circumvent theses restrictions would apear in the journal and give us an audit log as well [10:56:15] yeah that's fair, restrict vs monitor [13:28:04] jbond42: yeah, IIRC it's possible to configure the failure scenatio, to terminate the application and/or log [13:29:29] ack thanks [13:36:50] ideally, what you did with the cas.service unit and e.g. what Traffic team did with ATS will slowly also trickle into other services (and ideally we upstream some of that to the service units shipped in Debian (and even more ideally to the upstream ones)) [13:37:33] yes that sounds good to me [13:37:47] once it becomes a upstream feature it's can also become part of upstream CI etc, so the risk of regressions in new releases (if e.g. a new release of a daemon uses new syscalls which trip the Seccomp filter) minimises and everyone profits