On Sun, Jun 22, 2025 at 07:41:08PM -0600, Abhinav Saxena via B4 Relay wrote: > From: Abhinav Saxena <xandf...@gmail.com> > > The TIOCSTI ioctl currently only checks the current process's > credentials, creating a TOCTOU vulnerability where an unprivileged > process can open a TTY fd and pass it to a privileged process via > SCM_RIGHTS.
If a priviliged process has a fd, what is the problem with it using this ioctl in the firstplace? > > Fix by requiring BOTH the file opener (file->f_cred) AND the current > process to have CAP_SYS_ADMIN. This prevents privilege escalation > while ensuring legitimate use cases continue to work. > > Link: https://github.com/KSPP/linux/issues/156 > > Signed-off-by: Abhinav Saxena <xandf...@gmail.com> > --- > security/selinux/hooks.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 595ceb314aeb..a628551873ab 100644 > --- 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; Are you sure this type of policy should be in the selinux core code? Wouldn't you need a "rule" for selinux to follow (or not follow) for this type of thing and not just a blanket change to the logic? Also, have you looked at what userspace tools actually use this ioctl to see if this change would break anything? thanks, greg k-h
