On Tue, Apr 9, 2024 at 5:32 PM Michal Koutný mkoutny@suse.com wrote:
Hi.
On Tue, Apr 02, 2024 at 07:20:45PM +0100, Djalal Harouni tixxdz@gmail.com wrote:
Thanks yes, I would expect freeze to behave like signal, and if one wants to block immediately there is the LSM override return. The selftest attached tries to do exactly that.
Are you refering to this part:
int BPF_PROG(lsm_freeze_cgroup, int cmd, union bpf_attr *attr, unsigned int size) ... ret = bpf_task_freeze_cgroup(task, 1); if (!ret) { ret = -EPERM; /* reset for next call */?
Yes.
Could be security signals, reading sensitive files or related to any operation management, for X reasons this user session should be freezed or killed.
What can be done with a frozen cgroup after anything of that happens? Anything besides killing anyway?
Some users would like to inspect.
Killing of an offending process could be caught by its supervisor (like container runtime or systemd) and propagated accordingly to the whole cgroup.
Most bpf technologies do not run as a supervisor.
The kill is an effective defense against fork-bombs as an example.
There are several ways how to prevent fork-bombs in kernel already, it looks like a contrived example.
I doubt if they are as effective, flexible and reflect today's workflow as the cgroup way.
Thanks