From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 035DE26E6FA for ; Fri, 13 Mar 2026 06:12:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773382366; cv=none; b=QU+EEr0AFvUXaW3OLpmiXzMtBc0w6V4lxiMib0PZaXew3/0v92n/3fN/OtMHQDW0vO1MQ1uaEysrMv2D+rf+du5CnXUnTKJhOHDVOikSRrToCL+NUxrLO6XpoPSlYjXHwJ8QVkai1DgtCs+MA1GfIy7KsJ0YhuM4F3oqziCCam8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773382366; c=relaxed/simple; bh=zjUMUP/jhUWQj9vc8NbA7FsK4ClBZpOo7vY18B3X5Xg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=LU7hBx4eBPmW+HOYttoUhh26e9QKACY2YHaYskTGX4wu6WuV0UmdBxxMKwFJdfO03N1yP04o96XiB55dqBTHUZ28MLzcug51UjYXgY/7lD7dH7HrCxTQ8rQFW9wF+Ek9U8SHikpRIAn+5Ln9fCPkP2gPlGjDPXelxWTo4rtCGbk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dK0Z/Tli; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dK0Z/Tli" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4853bcdefd3so1186055e9.2 for ; Thu, 12 Mar 2026 23:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773382363; x=1773987163; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=oNYlvR+pw1Duu92PnhcUXSmqbSFDIxpNpqG8k4yEtb8=; b=dK0Z/Tli1PXAS6Lmnjvip7gL3zJXgv2cvm+/HR7gNxticqBEu+FB5NNVH96pdixRKa QRfcY6cQIfn547CbUvkwjLqymCtqqSacnCxfN9tH2Vcb93yPLXCYssxcIeM5la9XEW7w QXxQ4N3Atm5MFdTwfWQ7Z0eg5G6r7OZ6MZs1K8zmENHpYnerwxvBdL5RdEGNdrAITcrN FmbwsYu9xqSMDNUrbKxP91p49oDotAGIl5ZXTVNzCRkPdkT3EJwKsgGLNOBiEZKOYPqm aV9CrNBgAxWYr5NQXYn0LAEY4vH7lHSjqhZUYfhs66O6tauuNclS8AwnHr2XkCH/MlWB kbAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773382363; x=1773987163; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oNYlvR+pw1Duu92PnhcUXSmqbSFDIxpNpqG8k4yEtb8=; b=OVEOA8SPt2YHlRoKSp0hg0Y39fg3inqHt8eJM9U39qlwarGZ7LC8X+dxaQxn2vXMwR iTpd3xpGVJIutXlLIo5ukF8r5ieL0D7Iyz7GitWx98JIeiYJPli7f6bO4kryh2ouJhCT mZnhngD3//Kq65WN0ye4Js8Qd3FDPp9FqCKQOQ2e3eVNm9DydXPi4+aq1za6lZSGMhDC Z6KFL9rR5SEDOhZr5s0kjfmU7sLXkv2h5MK38YLF1sMy6wlgb5ulY5drn1eiTD7+5Jmq Q74bm6A+Ks/wdt+JOFZMC3uQ4R+tt/tkAIYVd8Kf++lPnS/JuxHL+wJh/DpKzJbAScKC E/Rw== X-Forwarded-Encrypted: i=1; AJvYcCVPDLsPjr5iWaQySIXOnraiTSJyuzO2yNm1sN6ithRRbHng0H+DA0KzKJoVqs2bfHfdYJLrhfJLTijt7sE=@vger.kernel.org X-Gm-Message-State: AOJu0YxbeSQyR59+7V/fG2zDAD0lqgSaoA3pdbpRHmmg92yAVAvcpHjR 8IAft8G4wqA6XI81+Hgmoe6zOkiZhE8Auqik4v8eHb1MP+C0zMTCu48A X-Gm-Gg: ATEYQzwFlaUtw6Lyc6jTmH8UAoYQdemtxEUGXJ0PV2I0OB+oOCzQMLB9zgl7e7OaLEJ Kl/nwhaqcJJOMQKElyjMNWH5V3+jw4ypKqVvD2wL5sEqDiLd9plLOQu7YO9rOyXVJf4wx375i/E NGtQ/W0g4gXodPb1S4GZizm4QKQBdamc/167pmiS+PAspzYkF+QprNZsrnG5+vpsZLBrNssNb6y tXZbiD7gZAnZdTeKOUkM4yGG2ZCOUbx5ugCSn74Z+V5KxsOJM8BSnazvfERF9ju2JBd2Np1yMDa 4+bGZ1M4eiUJEzCxOEv1IZ2g/S+VTEqMOTjeJ6VN0cM52PHj+76QqztTa8VdISHkXpGMLX3hq0n PCKNSB6iLWopqGIvtQKnQELxXR+xCcAtYjJr28z2cPQijjXR1br2rJQeV9PY3uEtH+zpL+Rvnrq +fTGI5qQm6J0WfWuv/z/xM/DZKFtT05+HC5yyf2W+h7DPyOK8j28CrDQ== X-Received: by 2002:a05:600c:4fcd:b0:485:3bc7:a224 with SMTP id 5b1f17b1804b1-48556715146mr14780545e9.6.1773382363256; Thu, 12 Mar 2026 23:12:43 -0700 (PDT) Received: from DESKTOP-LCRLR8G.localdomain ([196.151.68.28]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe1affe9sm14371110f8f.15.2026.03.12.23.12.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 23:12:42 -0700 (PDT) From: Marwan Seliem To: paul@paul-moore.com, stephen.smalley.work@gmail.com Cc: omosnace@redhat.com, selinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC] selinux: add selinux=2 boot parameter for permissive mode through kernel cmdline Date: Fri, 13 Mar 2026 08:12:35 +0200 Message-Id: <20260313061235.9552-1-marwanmhks@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Paul, Stephen, Ondrej,=0D =0D I wanted to reach out to ask whether a change like the following would be c= onsidered useful or acceptable upstream, before investing more time polishi= ng it.=0D =0D Background=0D ----------=0D On a platform with the following Kconfig:=0D =0D CONFIG_SECURITY_SELINUX_DEVELOP is not set=0D CONFIG_SECURITY_SELINUX_BOOTPARAM=3Dy=0D =0D The only runtime options for the selinux=3D boot parameter are:=0D =0D selinux=3D0 -> SELinux disabled entirely=0D selinux=3D1 -> SELinux enforcing, non-switchable=0D =0D There is no way to boot into permissive mode without either enabling=0D CONFIG_SECURITY_SELINUX_DEVELOP (which also enables setenforce and is=0D not desirable in production) or disabling SELinux entirely.=0D =0D Proposal=0D --------=0D Introduce selinux=3D2 as a new boot parameter value that boots SELinux=0D in a permanently permissive mode:=0D =0D - SELinux is fully initialized and policy is loaded normally=0D - All AVC denials are logged but never enforced=0D - The permissive state is non-switchable at runtime=0D =0D Implementation=0D --------------=0D The change is minimal, touching only two files:=0D =0D security/selinux/hooks.c:=0D - Introduce selinux_permissive_boot __ro_after_init=0D - Parse selinux=3D2 in selinux_enabled_setup(), set the flag=0D =0D security/selinux/include/security.h:=0D - In the non-DEVELOP enforcing_enabled() path, return=0D !(selinux_permissive_boot && state->initialized)=0D instead of hardcoded true=0D =0D The initialized gate is intentional since, enforcing_enabled()=0D returns false before policy is loaded, which causes systemd to observe=0D a permissive+no-policy state and stall boot.=0D =0D Use case=0D ---------=0D The primary use case is embedded platforms shipping with=0D enforcing locked at build time, where the ABL needs a mechanism to=0D boot into permissive for debugging SELinux policy issues in the field,=0D and without enabling DEVELOP in production builds.=0D =0D Note that the ABL will be protected by secure boot in production.=0D =0D Would a change like this be of interest upstream, or is there an=0D existing mechanism I have missed that already covers this use case?=0D =0D Happy to send a proper patch if there is interest.=0D =0D Thanks,=0D Marwan Seliem=