Received-SPF: pass (google.com: domain of linux-kernel+bounces-137236-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Tue, 9 Apr 2024 17:32:33 +0200
From: Michal =?utf-8?Q?Koutn=C3=BD?= <mkoutny@suse.com>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, Alexei Starovoitov <ast@kernel.org>, 
	Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, 
	Martin KaFai Lau <martin.lau@linux.dev>, Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>, 
	Yonghong Song <yonghong.song@linux.dev>, John Fastabend <john.fastabend@gmail.com>, 
	KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, 
	Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>, 
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, bpf@vger.kernel.org, 
	linux-kselftest@vger.kernel.org
Subject: Re: Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf
Message-ID: <eosbqsdycwdaezg6huqwpjvttxdxgbu6ptjmpxesy6i2rl276i@72w2orzveyes>
References: <20240327-ccb56fc7a6e80136db80876c@djalal>
 <20240327225334.58474-1-tixxdz@gmail.com>
 <ex2uipr54lb2odxwzwp22ycvlwplsy4mm3shx26hczo3mjtkvz@uuzyk6535prw>
 <705d7180-aced-46ba-80a6-84ac4e2b96b9@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ur57wvgvflsnrnty"
Content-Disposition: inline
In-Reply-To: <705d7180-aced-46ba-80a6-84ac4e2b96b9@gmail.com>


--ur57wvgvflsnrnty
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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 */
?


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

Killing of an offending process could be caught by its supervisor (like
container runtime or systemd) and propagated accordingly to the whole
cgroup.

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

> Today some container/pod operations are performed at bpf level, having
> the freeze and kill available is straightforward to perform this.

It seems to me like an extra step when the same operation can be done from
(the managing) userspace already.

> For generalizing this, haven't thought about it that much. First use
> case is to try to get freeze and possibly kill support, and use a common
> interface as requested.

BTW, I notice that there is bpf_sys_bpf() helper that allows calling an
arbitrary syscall. Wouldn't that be sufficient for everything?

(Based on how I still understand the problem: either you must respond
immediately and then the direct return from LSM is appropriate or timing
is not sensitive but you want act on whole cgroup.)

Thanks,
Michal

--ur57wvgvflsnrnty
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQpEWyjXuwGT2dDBqAGvrMr/1gcjgUCZhVfjwAKCRAGvrMr/1gc
jmVSAP4gnoRPzcuJjgOFfGrNmt82AS07TT6+tvtaPHXyLoEMYwEAs1rsSXY7Zfk5
YFlpQWdguwO5nJDKXK8YvYS7+wcTlQM=
=0Hv1
-----END PGP SIGNATURE-----

--ur57wvgvflsnrnty--