netdev - Re: Possible mistake in commit 3ca459eaba1b ("tun: fix group permission check")

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFqZXNtq7SZSu_JyY5yaiOQy89c=5jG+vqdg3_RSUWm4JNN00w@mail.gmail.com>
Date: Tue, 4 Feb 2025 17:18:58 +0100
From: Ondrej Mosnacek <omosnace@...hat.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, stsp <stsp2@...dex.ru>, 
	Willem de Bruijn <willemb@...gle.com>, Jason Wang <jasowang@...hat.com>, 
	Jakub Kicinski <kuba@...nel.org>, network dev <netdev@...r.kernel.org>, 
	Linux Security Module list <linux-security-module@...r.kernel.org>, 
	SElinux list <selinux@...r.kernel.org>
Subject: Re: Possible mistake in commit 3ca459eaba1b ("tun: fix group
 permission check")

On Tue, Feb 4, 2025 at 1:30 AM Paul Moore <paul@...l-moore.com> wrote:
>
> On Thu, Jan 30, 2025 at 11:48 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> > stsp wrote:
> > > 29.01.2025 17:12, Willem de Bruijn пишет:
> > > > stsp wrote:
> > > >> 29.01.2025 01:59, Willem de Bruijn пишет:
> > > >>> stsp wrote:
> > > >>>> By doing that you indeed avoid
> > > >>>> the problem of "completely
> > > >>>> inaccessible tap". However, that
> > > >>>> breaks my setup, as I really
> > > >>>> intended to provide tap to the
> > > >>>> owner and the unrelated group.
> > > >>>> This is because, eg when setting
> > > >>>> a CI job, you can add the needed
> > > >>>> user to the needed group, but
> > > >>>> you also need to re-login, which
> > > >>>> is not always possible. :(
> > > >>> Could you leave tun->owner unset?
> > > >> That's exactly the problem: when
> > > >> the user is not in the needed group,
> > > >> then you need to unset _both_.
> > > >> Unsetting only owner is not enough.
> > > >> Adding the user to the group is not
> > > >> enough because then you need to
> > > >> re-login (bad for CI jobs).
> > > > At some point we can question whether the issue is with the setup,
> > > > rather than the kernel mechanism.
> > > >
> > > > Why does your setup have an initial user that lacks the group
> > > > permissions of the later processes, and a tun instance that has both
> > > > owner and group constraints set?
> > > >
> > > > Can this be fixed in userspace, rather than allow this odd case in the
> > > > kernel. Is it baked deeply into common containerization tools, say?
> > >
> > > No-no, its not a real or unfixible
> > > problem. At the end, I can just
> > > drop both group and user ownership
> > > of the TAP, and simply not to care.
> >
> > In that case the safest course of action is to revert the patch.
> >
> > It relaxes some access control restrictions that other users may have
> > come to depend on.
> >
> > Say, someone expects that no process can use the device until it
> > adds the user to one of the groups.
> >
> > It's farfetched, but in cases of access control, err on the side of
> > caution. Especially retroactively.
>
> If a revert is the best path forward for v6.14, do you think it would
> be possible to get this fixed this week, or do you expect it to take
> longer?

Willem has already posted patches on netdev [1][2] (thanks!), so I
expect it will be fixed soon.

[1] https://lore.kernel.org/netdev/20250204161015.739430-1-willemdebruijn.kernel@gmail.com/
[2] https://lore.kernel.org/netdev/20250203150615.96810-1-willemdebruijn.kernel@gmail.com/

-- 
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.