| Message ID | 20250203150615.96810-1-willemdebruijn.kernel@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] tun: revert fix group permission check | expand |
03.02.2025 18:05, Willem de Bruijn пишет: > From: Willem de Bruijn <willemb@google.com> > > This reverts commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3. > > The blamed commit caused a regression when neither tun->owner nor > tun->group is set. This is intended to be allowed, but now requires > CAP_NET_ADMIN. > > Discussion in the referenced thread pointed out that the original > issue that prompted this patch can be resolved in userspace. The point of the patch was not to fix userspace, but this bug: when you have owner set, then adding group either changes nothing at all, or removes all access. I.e. there is no valid case for adding group when owner already set. During the discussion it became obvious that simpler fixes may exist (like eg either-or semantic), so why not to revert based on that? > The relaxed access control may now make a device accessible when it > previously wasn't, while existing users may depend on it to not be. > > Since the fix is not critical and introduces security risk, revert, Well, I don't agree with that justification. My patch introduced the usability problem, but not a security risk. I don't want to be attributed with the security risk when this wasn't the case (to the very least, you still need the perms to open /dev/net/tun), so could you please remove that part? I don't think you need to exaggerate anything: it introduces the usability regression, which should be enough for any instant revert.
stsp wrote: > 03.02.2025 18:05, Willem de Bruijn пишет: > > From: Willem de Bruijn <willemb@google.com> > > > > This reverts commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3. > > > > The blamed commit caused a regression when neither tun->owner nor > > tun->group is set. This is intended to be allowed, but now requires > > CAP_NET_ADMIN. > > > > Discussion in the referenced thread pointed out that the original > > issue that prompted this patch can be resolved in userspace. > > The point of the patch was > not to fix userspace, but this > bug: when you have owner set, > then adding group either changes > nothing at all, or removes all > access. I.e. there is no valid case > for adding group when owner > already set. As long as no existing users are affected, no need to relax this after all these years. It is up to users to not choose an overly restrictive setting, similar to how they should not set chmod a-rwx on a file. A user will immediately find out if they mess up this configuration, and it takes extra steps (ioctls) to reach it, so is unlikely to be reached by accident. > During the discussion it became > obvious that simpler fixes may > exist (like eg either-or semantic), > so why not to revert based on > that? We did not define either-or in detail. Do you mean failing the TUNSETOWNER or TUNSETGROUP ioctl if the other is already set? That could break existing users that set both. > > The relaxed access control may now make a device accessible when it > > previously wasn't, while existing users may depend on it to not be. > > > > Since the fix is not critical and introduces security risk, revert, > Well, I don't agree with that justification. > My patch introduced the usability > problem, but not a security risk. > I don't want to be attributed with > the security risk when this wasn't > the case (to the very least, you > still need the perms to open /dev/net/tun), > so could you please remove that part? > I don't think you need to exaggerate > anything: it introduces the usability > regression, which should be enough > for any instant revert. This is not intended to cast blame, of course. That said, I can adjust the wording. The access control that we relaxed is when a process is not allowed to access a device until the administrator adds it to the right group. Is this used? I doubt it. But we cannot be sure.
03.02.2025 22:09, Willem de Bruijn пишет: > stsp wrote: >> 03.02.2025 18:05, Willem de Bruijn пишет: >>> From: Willem de Bruijn <willemb@google.com> >>> >>> This reverts commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3. >>> >>> The blamed commit caused a regression when neither tun->owner nor >>> tun->group is set. This is intended to be allowed, but now requires >>> CAP_NET_ADMIN. >>> >>> Discussion in the referenced thread pointed out that the original >>> issue that prompted this patch can be resolved in userspace. >> The point of the patch was >> not to fix userspace, but this >> bug: when you have owner set, >> then adding group either changes >> nothing at all, or removes all >> access. I.e. there is no valid case >> for adding group when owner >> already set. > As long as no existing users are affected, no need to relax this after > all these years. I only mean the wording. My patch initially says what exactly does it fix, so the fact that the problem can be fixed in user-space, was likely obvious from the very beginning. >> During the discussion it became >> obvious that simpler fixes may >> exist (like eg either-or semantic), >> so why not to revert based on >> that? > We did not define either-or in detail. Do you mean failing the > TUNSETOWNER or TUNSETGROUP ioctl if the other is already set? I mean, auto-removing group when the owner is being set, for example. Its not a functionality change: the behaviour is essentially as before, except no such case when no one can access the device. >>> The relaxed access control may now make a device accessible when it >>> previously wasn't, while existing users may depend on it to not be. >>> >>> Since the fix is not critical and introduces security risk, revert, >> Well, I don't agree with that justification. >> My patch introduced the usability >> problem, but not a security risk. >> I don't want to be attributed with >> the security risk when this wasn't >> the case (to the very least, you >> still need the perms to open /dev/net/tun), >> so could you please remove that part? >> I don't think you need to exaggerate >> anything: it introduces the usability >> regression, which should be enough >> for any instant revert. > This is not intended to cast blame, of course. > > That said, I can adjust the wording. Would be good. > The access control that we relaxed is when a process is not allowed > to access a device until the administrator adds it to the right group. No-no, adding doesn't help. The process have to die and re-login. Besides, not only the "process" can't access the device, no. Everyone can't. And by the mere fact of adding a group...
stsp wrote: > 03.02.2025 22:09, Willem de Bruijn пишет: > > stsp wrote: > >> 03.02.2025 18:05, Willem de Bruijn пишет: > >>> From: Willem de Bruijn <willemb@google.com> > >>> > >>> This reverts commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3. > >>> > >>> The blamed commit caused a regression when neither tun->owner nor > >>> tun->group is set. This is intended to be allowed, but now requires > >>> CAP_NET_ADMIN. > >>> > >>> Discussion in the referenced thread pointed out that the original > >>> issue that prompted this patch can be resolved in userspace. > >> The point of the patch was > >> not to fix userspace, but this > >> bug: when you have owner set, > >> then adding group either changes > >> nothing at all, or removes all > >> access. I.e. there is no valid case > >> for adding group when owner > >> already set. > > As long as no existing users are affected, no need to relax this after > > all these years. > > I only mean the wording. > My patch initially says what > exactly does it fix, so the fact > that the problem can be fixed > in user-space, was likely obvious > from the very beginning. > > >> During the discussion it became > >> obvious that simpler fixes may > >> exist (like eg either-or semantic), > >> so why not to revert based on > >> that? > > We did not define either-or in detail. Do you mean failing the > > TUNSETOWNER or TUNSETGROUP ioctl if the other is already set? > > I mean, auto-removing group when > the owner is being set, for example. > Its not a functionality change: the > behaviour is essentially as before, > except no such case when no one > can access the device. > > >>> The relaxed access control may now make a device accessible when it > >>> previously wasn't, while existing users may depend on it to not be. > >>> > >>> Since the fix is not critical and introduces security risk, revert, > >> Well, I don't agree with that justification. > >> My patch introduced the usability > >> problem, but not a security risk. > >> I don't want to be attributed with > >> the security risk when this wasn't > >> the case (to the very least, you > >> still need the perms to open /dev/net/tun), > >> so could you please remove that part? > >> I don't think you need to exaggerate > >> anything: it introduces the usability > >> regression, which should be enough > >> for any instant revert. > > This is not intended to cast blame, of course. > > > > That said, I can adjust the wording. > > Would be good. Will do. > > The access control that we relaxed is when a process is not allowed > > to access a device until the administrator adds it to the right group. > > No-no, adding doesn't help. > The process have to die and > re-login. Besides, not only the > "process" can't access the device, > no. Everyone can't. And by the > mere fact of adding a group... A device can be created with owner/group constraints before the intended process (and session) exists.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 28624cca91f8..acf96f262488 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -574,18 +574,14 @@ static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb, return ret; } -static inline bool tun_capable(struct tun_struct *tun) +static inline bool tun_not_capable(struct tun_struct *tun) { const struct cred *cred = current_cred(); struct net *net = dev_net(tun->dev); - if (ns_capable(net->user_ns, CAP_NET_ADMIN)) - return 1; - if (uid_valid(tun->owner) && uid_eq(cred->euid, tun->owner)) - return 1; - if (gid_valid(tun->group) && in_egroup_p(tun->group)) - return 1; - return 0; + return ((uid_valid(tun->owner) && !uid_eq(cred->euid, tun->owner)) || + (gid_valid(tun->group) && !in_egroup_p(tun->group))) && + !ns_capable(net->user_ns, CAP_NET_ADMIN); } static void tun_set_real_num_queues(struct tun_struct *tun) @@ -2782,7 +2778,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) !!(tun->flags & IFF_MULTI_QUEUE)) return -EINVAL; - if (!tun_capable(tun)) + if (tun_not_capable(tun)) return -EPERM; err = security_tun_dev_open(tun->security); if (err < 0)