Bug 717

Summary:	Referencing a netgroup with multiple triplets from sudoHost and sudoUser
Product:	Sudo	Reporter:	Daniel Kopeček <dkopecek>
Component:	Sudoers	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED FIXED
Severity:	normal	CC:	daniele
Priority:	normal
Version:	1.8.14
Hardware:	PC
OS:	Linux
Attachments:	experimental patch

Description Daniel Kopeček 2015-09-04 02:48:29 MDT

I'm not sure whether this is an RFE or a bug, so let me try to explain the issue. When there are multiple triplets in a netgroup LDAP entry:

------
dn: cn=role_linux_admin,ou=netgroup,dc=example,dc=com
objectClass: nisNetgroup
objectClass: top
cn: role_linux_admin
nisNetgroupTriple: (server1.example.com,user101,)
nisNetgroupTriple: (server2.example.com,user201,)
nisNetgroupTriple: (,user301,)
------

and we reference this netgroup from the sudoHost and sudoUser:

------
dn: cn=sudo_rule_admin,ou=sudoers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: sudo_rule_admin
description: Test commands
sudoCommand: /sbin/service httpd start
sudoCommand: /sbin/service httpd stop
sudoCommand: /sbin/service httpd restart
sudoHost: +role_linux_admin
sudoOption: !authenticate
sudoRunAs: ALL
sudoUser: +role_linux_admin
------

then sudo will allow access for user101 or user201 to other hosts than server1 or server2. I think that the problem is in the way sudo processes the sudoHost and sudoUser netgroups:

sudoHost:
 netgr_matches(val, user_host, user_shost, NULL)

sudoUser:
 netgr_matches(val, NULL, NULL, handle->pw->pw_name)

i.e. not using all the fields for each netgr_matches call. Is this the expected behavior?

Thanks,
Dan K.

Comment 1 Daniel Kopeček 2015-09-18 07:22:52 MDT

Just found a similar question in the mailing list archive but without an answer:

 http://www.sudo.ws/pipermail/sudo-users/2010-March/004343.html

The documentation references to the netgroups in sudoHost and sudoUser as "host netgroup" and "user netgroup". So, that should be read as a hint how sudo processes the netgroups, right?

Comment 2 Todd C. Miller 2015-09-18 07:27:21 MDT

Yes, sudo has always only used either the host or user part of the netgroup but not both together.  This is because historically sudo keyed everything on the user name.

Comment 3 Daniele Palumbo 2015-09-18 14:45:45 MDT

Hi,

According to http://linux.die.net/man/5/netgroup, ( ,user, ) means all hosts and all domains.
This is in contradiction to how sudo parse for netgroup.

I personally think that this can be configured as a security bug, since netgroup with hosts and/or domain can be parsed anyway in sudoUser, and netgroups with users can be parsed anyway as sudoHost.

Am i correct? Do you also think that this is a security bug?
What do you think about it?

Thanks,
Daniele

Comment 4 Todd C. Miller 2015-09-18 15:54:18 MDT

Sorry, I don't agree.  The netgroup API allows the caller to specify which parts of the tuple are to be matched.  This is something that could be documented better for sure.

Comment 5 Daniel Kopeček 2015-09-21 07:33:57 MDT

Hi Todd, do you see this issue as worth resolving as an RFE? i.e. introducing a new option to change the netgroup matching behavior?

Comment 6 Todd C. Miller 2015-09-21 07:55:41 MDT

Yes, I think that makes the most sense.  Perhaps something like a netgroup_tuple option.

Comment 7 Daniel Kopeček 2015-11-10 04:23:43 MST

Just to give an update on this:

I'm working on a patch for this issue, i.e. implementing the netgroup_tuple option. We are testing it currently and once I have a confirmation that it's working properly, I'll attach it here.

Regards,
Dan K.

Comment 8 Daniel Kopeček 2015-12-07 06:28:27 MST

Created attachment 465 [details]
experimental patch

Comment 9 Todd C. Miller 2016-01-12 15:04:45 MST

I've adapted this diff to sudo trunk:
https://www.sudo.ws/repos/sudo/rev/9f694ba7c86d

Comment 10 Daniel Kopeček 2016-01-13 06:11:49 MST

(In reply to Todd C Miller from comment #9)
> I've adapted this diff to sudo trunk:
> https://www.sudo.ws/repos/sudo/rev/9f694ba7c86d

Great, thanks!

Comment 11 Todd C. Miller 2016-03-17 10:22:04 MDT

Fixed in 1.8.16, available now.