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 77CF949AA3D for ; Mon, 28 Sep 2026 10:34:26 +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=1790591669; cv=none; b=MKVf9PRkJiRuVAYX40BB8pVqZR7d13/HhDLzE6xlInBNm8D0UBD8rjF9nLjLqapUslWI8vAv2n6D5qGggmO7/fhow2IUm9budoUQZzXplp9MEA3QBHn/XXWPG6FBfVZLQ2QPHQbwVnrrGBhrXDNXX/gLJ7dFaax2zdKQCl062uE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790591669; c=relaxed/simple; bh=hYINazaiAnWa8pfbXYxctuZFwZqllqw5xtql2k1gSTA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=E7bNDO7Hym2HZZz4JdW+G+QJA9zTQAoLbG9i3thsbK+KRd2+mbS9qR37neuhugwa/35yx9s2iO1R9XWW3js4w5TdQxPIcpOELAND+HjwA1OdzlIcDENwwL9iEoFd8HBg+IM5VjyKiEpPgJA6UYRnpXekYUmEUT+ngE6u/w4YVOQ= 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=hHIwJXVj; 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="hHIwJXVj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=defensec.nl; s=default; t=1790591664; bh=hYINazaiAnWa8pfbXYxctuZFwZqllqw5xtql2k1gSTA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hHIwJXVjxYTjp7exOm6WnixZG2HJjHmtUqTd8dZnuk5Lf51XSSGEY8Z3jwf/LU/J7 Pbg6RgT4y0VqXS+wd7TIfG29j6DRCVqdPNHhUUshj6DMYIW5o0AjxTEHUH8MKbywFm N2hadkcfIlks/56uKASe9zSWlldYNYPbabhYpBQw= Received: from nimbus (nimbus.defensec.nl [IPv6:2a10:3781:2099::514]) by markus.defensec.nl (Postfix) with ESMTPSA id 761B32F2430; Mon, 28 Sep 2026 12:34:24 +0200 (CEST) From: Dominick Grift To: Russell Coker Cc: selinux-refpolicy@vger.kernel.org Subject: Re: /dev/full In-Reply-To: <87fqyt4qyp.fsf@defensec.nl> (Dominick Grift's message of "Mon, 28 Sep 2026 12:20:46 +0200") References: <87ld8m3spg.fsf@defensec.nl> <87fqyt4qyp.fsf@defensec.nl> Date: Mon, 28 Sep 2026 12:34:23 +0200 Message-ID: <87bj9h4qc0.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 Dominick Grift writes: > Russell Coker writes: > >> On Monday, 28 September 2026 14:28:27 AEST Dominick Grift wrote: >>> I noticed similar. I suspect this is due to how userspace_initial_sid >>> polcap is implemented in refpolicy (refpolicy does leverage it does it >>> not?). Misssing an appropriate auto type transition because the scenario >>> changed. > > The fact that it ends up event_device_t means that the wrong type > transition applies (theres a default for chr_file event_device_t which > is triggered instead of the proper name-based transition > > the polcap mentioned can be used to implement a different context for > userspace processes in initrd. Depending on how its implemented it could > introduce issues like these (I encountered similar but my implementation > of that polcap is more intrusive. > > For example: any transitions associated with kernel_t would no longer > apply to userspace in initrd if that is now given a private context. Could also be that the name-based transition for /dev/full was never added because the event was not reproduced after name-based transitions became available. Bottom line: missing (name-based) type transition rule > >> >> The below is in current refpolicy, is this what you mean? >> >> # Enable separate user space context for processes started before first >> # policy load. >> # Requires libsepol 3.7 and kernel 6.8. >> # >> # Added checks: >> # (none) >> policycap userspace_initial_context; >> >> How do you think it could be affecting the issue I saw? -- 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