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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHC9VhS-uSaVmy65oA8p6tCzMZxMsuzdmxO-vf7L0p44ZKO=_A@mail.gmail.com>
Date: Mon, 3 Feb 2025 19:29:53 -0500
From: Paul Moore <paul@...l-moore.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: stsp <stsp2@...dex.ru>, Ondrej Mosnacek <omosnace@...hat.com>, 
	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 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?

--
paul-moore.com