mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: tjdqudcks0424@naver.com
To: Micah Morton <mortonm@chromium.org>,
	Paul Moore <paul@paul-moore.com>,
	linux-security-module@vger.kernel.org
Cc: James Morris <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Thomas Cedeno <thomascedeno@google.com>,
	Shuah Khan <shuah@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	security@kernel.org
Subject: [PATCH 0/2] SafeSetID: use real GID for GID policy lookups
Date: Sat,  3 Oct 2026 19:34:14 +0900	[thread overview]
Message-ID: <cover.1791023194.git.tjdqudcks0424@naver.com> (raw)

From: Sung Byeongchan <tjdqudcks0424@naver.com>

SafeSetID GID policy enforcement first checks whether a policy applies to
the old real GID.  Its per-target helper then incorrectly constructs the
source lookup key from the old real UID.  When those numeric IDs differ,
the helper can miss the policy for the real GID and return the
unconstrained default.

The issue is present at Torvalds mainline commit
e767a4ea70a3992c37ed604157d32f0dfbf9b1e3.  In three clean QEMU boots, a
task with real UID 1000, real GID 2000 and only CAP_SETGID obtained
non-allowlisted GID 2002 despite a 2000:2001 policy.  The bypass covered
setgid(), setegid(), setregid(), setresgid(), setfsgid() and setgroups(),
including supplementary-group acquisition and access to a synthetic
group-protected resource.  The acquired group credentials also persisted
across exec.

This demonstrates a SafeSetID GID policy bypass and group privilege
expansion.  It does not demonstrate direct UID 0 elevation or a universal
local privilege escalation, and the CAP_SETGID prerequisite is explicit.
The security boundary is that SafeSetID was configured to constrain that
capability but failed to enforce its GID allowlist.

Patch 1 selects the old real UID for UID checks and the old real GID for
GID checks.  Patch 2 adds a focused regression test for mismatched real
IDs, covering both setresgid() and setgroups(), and records the SafeSetID
selftest path in MAINTAINERS.

The vulnerable and fixed kernels used identical debug configurations.
Across three clean boots per kernel, the vulnerable matrix reproduced all
tested forbidden transitions and the fixed matrix blocked all of them.
Allowed, existing-ID, no-policy, no-capability and UID-policy controls
behaved as expected.  The existing SafeSetID selftest passed on both, the
new regression test failed on the vulnerable kernel and passed on the
fixed kernel, and no KASAN, UBSAN, BUG, WARNING, Oops, panic, lockdep,
refcount, hung-task or kmemleak finding was observed.

A reproducer and the complete QEMU validation logs are available
privately on request. They are not included in this public posting.

This finding and patch preparation were assisted by OpenAI Codex.

Sung Byeongchan (2):
  security: safesetid: use real GID for GID policy lookup
  selftests/safesetid: test GID policy with mismatched real IDs

 MAINTAINERS                                   |   1 +
 security/safesetid/lsm.c                      |   8 +-
 tools/testing/selftests/safesetid/Makefile    |   4 +-
 .../safesetid/safesetid-gid-policy-test.c     | 252 ++++++++++++++++++
 .../safesetid/safesetid-gid-policy-test.sh    |  11 +
 5 files changed, 271 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/safesetid/safesetid-gid-policy-test.c
 create mode 100755 tools/testing/selftests/safesetid/safesetid-gid-policy-test.sh


base-commit: e767a4ea70a3992c37ed604157d32f0dfbf9b1e3
-- 
2.43.0


             reply	other threads:[~2026-10-03 10:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03 10:34 tjdqudcks0424 [this message]
2026-10-03 10:34 ` [PATCH 1/2] security: safesetid: use real GID for GID policy lookup tjdqudcks0424
2026-10-04 22:05   ` Serge E. Hallyn
2026-10-03 10:34 ` [PATCH 2/2] selftests/safesetid: test GID policy with mismatched real IDs tjdqudcks0424

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1791023194.git.tjdqudcks0424@naver.com \
    --to=tjdqudcks0424@naver.com \
    --cc=brauner@kernel.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mortonm@chromium.org \
    --cc=paul@paul-moore.com \
    --cc=security@kernel.org \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=thomascedeno@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®