From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from markus.defensec.nl (markus.defensec.nl [45.80.168.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94FE84CDDD6 for ; Mon, 28 Sep 2026 13:34:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.80.168.93 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790602486; cv=none; b=upfvlBJnWrmf5Yl6Gra8KH4wmGhRUOdUGestcCiEYSpZKcai72MXiNkrC6u3Cc3/T93pi2A511C1gaN3ydWz6J0Tpk73GHYyoP0YZxM3d+BQJUXA3gtdHczFj2NVoZF9cXRY7YoU5B7k8B7wZ+bfLgB6wFj+IXDwFeCkNXWQeQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790602486; c=relaxed/simple; bh=5n1U/fxseV75aL2v5RlAp3Ot/s364tx21PNf4vEW7SE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=VargDZ+zTJCphMFKzc4dKtQd91c+wPpT9fcPEQmPcu6bsMYGkeyvi+PdrHA/J4zC32NePPcFSw7sBDp0bPDKRFJ1HVVlxCij/Ai31XRyMw/7a1LMciTncgxiOayZh38PPlrhB5lbbV9J106dn/Dlt5u1hh4ypmXh++K5QBNq5tA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl; spf=pass smtp.mailfrom=defensec.nl; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b=CaSojCaC; arc=none smtp.client-ip=45.80.168.93 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=defensec.nl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b="CaSojCaC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=defensec.nl; s=default; t=1790602482; bh=5n1U/fxseV75aL2v5RlAp3Ot/s364tx21PNf4vEW7SE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CaSojCaChsHYvHnEdBi7dRLFjJECHH5tXxgE2X/fRFVeqewTMKrxWDQTyFpW9GWe5 TGCYSgBc5I63TmTkE39yb5zmTqfiXkusgtJtfzO/rJag4jaLluXTBUTXFI71RE/Hiv wfSDQ1j3uBFFX/JwHszNyE8r1tL1UdUTHVYwLqQ0= Received: from nimbus (nimbus.defensec.nl [IPv6:2a10:3781:2099::514]) by markus.defensec.nl (Postfix) with ESMTPSA id B25092F243A; Mon, 28 Sep 2026 15:34:42 +0200 (CEST) From: Dominick Grift To: Russell Coker Cc: selinux-refpolicy@vger.kernel.org Subject: Re: /dev/full In-Reply-To: (Russell Coker's message of "Mon, 28 Sep 2026 23:18:32 +1000") References: <877bk54ldf.fsf@defensec.nl> Date: Mon, 28 Sep 2026 15:34:42 +0200 Message-ID: <8733ut4hzh.fsf@defensec.nl> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Russell Coker writes: > On Monday, 28 September 2026 22:21:32 AEST Dominick Grift wrote: >> >> Thanks for that, it was a default trans rule. I'll add a named >> >> transition >> >> for /dev/full >> > >> > That doesn't seem to work. >> > >> > root@ami:~# sesearch -T -c chr_file|grep null >> > type_transition kernel_t device_t:chr_file null_device_t full; >> > root@ami:~# dmesg|grep event_device_t >> > [ 3.269252] audit: type=1400 audit(1790597162.343:4): avc: denied { >> > write } for pid=330 comm="modprobe" name="full" dev="devtmpfs" ino=7 >> > scontext=system_u:system_r:kmod_t:s0 >> > tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 >> > [ 3.272938] audit: type=1400 audit(1790597162.343:5): avc: denied { >> > write } for pid=332 comm="modprobe" name="full" dev="devtmpfs" ino=7 >> > scontext=system_u:system_r:kmod_t:s0 >> > tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0 >> >> What is the context associated with the init sid? Maybe that is actually >> creating it then? > > That's an interesting question, I get the following message in dmesy. > > [ 10.940969] systemd[1]: Failed to transition into init label > 'system_u:system_r:init_t:s0', ignoring: Permission denied Interesting but I dont think that is related. Maybe a setcurrent/dyntransition is missing there. > > The following is the policy line you are probably interested in: > > policy/modules/kernel/kernel.te:sid init > gen_context(system_u:system_r:init_t,mls_systemhigh) You could try: type_transition kernel_t device_t:chr_file null_device_t full; My reasoning: 1. whatever creates that /dev/full with event_device_t is very early because otherwise udev and pid1 would have relabeled it by the time the event happened. 2. That leaves either kernel_t or init_t. Some stuff that now runs in init_t used to run in kernel_t previously. If its not kernel_t then that leaves us with init_t. -- gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@defensec.nl