On Mon, Jun 23, 2025 at 11:15:39AM -0400, Paul Moore wrote:
On Mon, Jun 23, 2025 at 8:39 AM Stephen Smalley stephen.smalley.work@gmail.com wrote:
On Sun, Jun 22, 2025 at 9:41 PM Abhinav Saxena via B4 Relay devnull+xandfury.gmail.com@kernel.org wrote:
--- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3847,6 +3847,12 @@ static int selinux_file_ioctl(struct file *file, unsigned int cmd, CAP_OPT_NONE, true); break;
case TIOCSTI:if (!file_ns_capable(file, &init_user_ns, CAP_SYS_ADMIN) ||!capable(CAP_SYS_ADMIN))error = -EPERM;break;So, aside from what I said previously, this also will break any existing policies currently controlling TIOCSTI via the selinux ioctl checking in the default case, so at the very least, this would need to be gated by a new SELinux policy capability for compatibility purposes. But I'm still unconvinced that this is the right approach.
I want to add my voice to the other comments that adding these capability checks to the SELinux code and not the main TIOCSTI kernel code is not an approach we want to support. Beyond that, as others have already pointed out, I think some additional inspection and testing is needed to ensure that the additional capability checks do not break existing, valid use cases.
+1 from me as well.
If the perceived problem is in core TTY logic, but the proposed fix is in SELinux, it only addresses a fraction of the install base, as not all machines use SELinux.
Also, it's not clear to me why the perceived problem of FD-passsing with SCM_RIGHTS is a problem at all. If a CAP_SYS_ADMIN process accepts FDs over SCM_RIGHTS, it is the responsibility of that process not to do unjustified privileged operations with these FDs, on behalf of other, less privileged, processes.
In the more classic attack scenarios (as described in a series of CVEs [1]) the process who had the FD first is normally the more privileged one, for for those ones, the existing CAP_SYS_ADMIN check seems fine.
—Günther
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=TIOCSTI