Ubuntu
sudo package

1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd

Bug #1688034 reported by Brian Candler
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
sudo (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7)

With sudo 1.8.16-0ubuntu1, everything is fine:

brian.candler@api-dev:~$ sudo -s
[sudo] password for brian.candler:
root@api-dev:~#

After update to 1.8.16-0ubuntu1.3, it no longer works:

brian.candler@api-dev:~$ sudo -k
brian.candler@api-dev:~$ sudo -s
[sudo] password for brian.candler:
brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported.

This is repeatable: downgrade sudo and it works again.

Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression.

--- Additional info ---

The sudo policy in IPA is extremely simple. It has a single rule, which says:

- applies to users in groups "system_administrators" and "security_administrators"
- applies to any host
- applies to any command

In LDAP under ou=sudoers tree, the groups are flattened out:

# system administrators on all hosts, sudoers, ipa.example.com
dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com
sudoRunAsGroup: ALL
objectClass: sudoRole
objectClass: top
sudoUser: brian.candler
sudoUser: ...
sudoUser: ... list more users
sudoUser: ...
sudoRunAsUser: ALL
sudoCommand: ALL
sudoHost: ALL
cn: system administrators on all hosts

Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals:

# 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com
dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com
ipaSudoRunAsUserCategory: all
ipaSudoRunAsGroupCategory: all
description: admins have full sudo access on any host they can ssh into
cmdCategory: all
hostCategory: all
memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com
memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com
objectClass: ipasudorule
objectClass: ipaassociation
ipaEnabledFlag: TRUE
cn: system administrators on all hosts
ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284

I have no workaround other than downgrade.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: sudo 1.8.16-0ubuntu1.3
ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59
Uname: Linux 4.4.0-1016-aws x86_64
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
Date: Wed May 3 16:01:23 2017
Ec2AMI: ami-a8d2d7ce
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: eu-west-1a
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: sudo
UpgradeStatus: No upgrade log present (probably fresh install)
VisudoCheck:
 /etc/sudoers: parsed OK
 /etc/sudoers.d/90-cloud-init-users: parsed OK
 /etc/sudoers.d/README: parsed OK

Revision history for this message
Brian Candler (b-candler) wrote :
Revision history for this message
Brian Candler (b-candler) wrote :

Some additional info.

I enabled sudo debugging by creating /etc/sudo.conf containing:

Debug sudo /var/log/sudo-debug all@info
Debug sudoers /var/log/sudoers-debug all@info

With the newer (non-functioning) sudo, /var/log/sudo-debug contains:

May 3 18:55:50 sudo[8003] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() /build/sudo-40pSZP/sudo-1.8.16/src/ttyname.c:336
May 3 18:55:50 sudo[8003] settings: run_shell=true
May 3 18:55:50 sudo[8003] settings: progname=sudo
May 3 18:55:50 sudo[8003] settings: network_addrs=10.0.0.230/255.255.255.0 xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
May 3 18:55:50 sudo[8003] settings: plugin_dir=/usr/lib/sudo/
May 3 18:55:51 sudo[8003] policy plugin returns 0

With the older (working) sudo, /var/log/sudo-debug contains:

May 3 19:00:19 sudo[8746] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() /build/sudo-g3ghsu/sudo-1.8.16/src/ttyname.c:336
May 3 19:00:19 sudo[8746] settings: run_shell=true
May 3 19:00:19 sudo[8746] settings: progname=sudo
May 3 19:00:19 sudo[8746] settings: network_addrs=10.0.0.230/255.255.255.0 xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
May 3 19:00:19 sudo[8746] settings: plugin_dir=/usr/lib/sudo/
May 3 19:00:22 sudo[8746] policy plugin returns 1
May 3 19:00:22 sudo[8746] settings: run_shell=true
May 3 19:00:22 sudo[8746] settings: progname=sudo
May 3 19:00:22 sudo[8746] settings: network_addrs=10.0.0.230/255.255.255.0 xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
May 3 19:00:22 sudo[8746] settings: plugin_dir=/usr/lib/sudo/
May 3 19:00:22 sudo[8746] command info from plugin:
May 3 19:00:22 sudo[8746] 0: command=/bin/bash
May 3 19:00:22 sudo[8746] 1: runas_uid=0
May 3 19:00:22 sudo[8746] 2: runas_gid=0
May 3 19:00:22 sudo[8746] 3: runas_groups=0
May 3 19:00:22 sudo[8746] 4: closefrom=3
May 3 19:00:22 sudo[8746] 5: set_utmp=true
May 3 19:00:22 sudo[8746] 6: umask=022
May 3 19:00:22 sudo[8746] executed /bin/bash, pid 8754
May 3 19:00:22 sudo[8746] sudo_ev_add_v1: adding event 0x55e83b06c630 to base 0x55e83b07ea40
May 3 19:00:22 sudo[8746] sudo_ev_add_v1: adding event 0x55e83b078180 to base 0x55e83b07ea40
May 3 19:00:22 sudo[8746] signal pipe fd 10
May 3 19:00:22 sudo[8746] backchannel fd 5
May 3 19:00:22 sudo[8754] exec /bin/bash [/bin/bash]
May 3 19:00:22 sudo[8746] sudo_ev_scan_impl: 1 fds ready
May 3 19:00:22 sudo[8746] failed to read child status: EOF
May 3 19:00:22 sudo[8746] sudo_ev_del_v1: removing event 0x55e83b078180 from base 0x55e83b07ea40

(/var/log/sudoers-debug is not created in either case)

Note "policy plugin returns 0" in the first case.

Revision history for this message
Brian Candler (b-candler) wrote :
Download full text (21.5 KiB)

Now trying with @debug instead of @info

Slight munging of output to make it diffable, then diff -u:

--- v1.debug.trim 2017-05-03 20:28:07.784000000 +0000
+++ v2.debug.trim 2017-05-03 20:28:14.032000000 +0000
@@ -38,87 +38,6 @@
 -> parse_args @ /build/sudo-XXXXXX/sudo-1.8.16/src/parse_args.c:172
 -> get_net_ifs @ /build/sudo-XXXXXX/sudo-1.8.16/src/net_ifs.c:120
 <- get_net_ifs @ /build/sudo-XXXXXX/sudo-1.8.16/src/net_ifs.c:205 := 3
-<- parse_args @ /build/sudo-XXXXXX/sudo-1.8.16/src/parse_args.c:512 := 8
-sudo_mode 8
--> sudo_load_plugins @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:283
--> sudo_load_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:160
--> sudo_check_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:112
--> sudo_stat_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:46
-<- sudo_stat_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:104 := 0
-<- sudo_check_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:137 := true
--> sudo_conf_debug_files_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/sudo_conf.c:509
-<- sudo_conf_debug_files_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/sudo_conf.c:535 := (nil)
-<- sudo_load_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:255 := true
--> sudo_load_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:160
--> sudo_check_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:112
--> sudo_stat_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:46
-<- sudo_stat_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:104 := 0
-<- sudo_check_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:137 := true
--> sudo_conf_debug_files_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/sudo_conf.c:509
-<- sudo_conf_debug_files_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/sudo_conf.c:535 := (nil)
-<- sudo_load_plugin @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:255 := true
-<- sudo_load_plugins @ /build/sudo-XXXXXX/sudo-1.8.16/src/load_plugins.c:352 := true
--> policy_open @ /build/sudo-XXXXXX/sudo-1.8.16/src/sudo.c:1231
--> format_plugin_settings @ /build/sudo-XXXXXX/sudo-1.8.16/src/sudo.c:1175
--> sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:44
-<- sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:56 := plugin_path=/usr/lib/sudo/sudoers.so
-settings: progname=sudo
--> sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:44
-<- sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:56 := progname=sudo
-settings: network_addrs=10.0.0.230/255.255.255.0 xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
--> sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:44
-<- sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:56 := network_addrs=10.0.0.230/255.255.255.0 xxxx:xxxx:xxxx:xxxx::230/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff fe80::1:xxxx:xxxx:xxxx/ffff:ffff:ffff:ffff::
-settings: plugin_dir=/usr/lib/sudo/
--> sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8.16/lib/util/key_val.c:44
-<- sudo_new_key_val_v1 @ /build/sudo-XXXXXX/sudo-1.8...

Revision history for this message
Brian Candler (b-candler) wrote :

I found out how to enable debugging for sudoers:

Debug sudo /var/log/sudo-debug all@info
Debug sudoers.so /var/log/sudoers-debug all@info

With the *new* sudo I get the following logged matching 'sssd':

May 5 12:40:06 sudo[17912] sssd/ldap sudoHost 'ALL' ... MATCH!
May 5 12:40:06 sudo[17912] sssd/ldap sudoUser '%system_administrators' ... not (brian.candler)
May 5 12:40:06 sudo[17912] sssd/ldap sudoUser '%security_administrators' ... not (brian.candler)

But with the *old* sudo I get:

May 5 12:41:48 sudo[18384] sssd/ldap sudoHost 'ALL' ... MATCH!
May 5 12:41:48 sudo[18384] sssd/ldap sudoRunAsUser 'ALL' ... MATCH!
May 5 12:41:48 sudo[18384] sssd/ldap sudoCommand 'ALL' ... MATCH!

It seems to be a behaviour change with group checking.

The 'brian.candler' user *is* a member of one of those groups in IPA; but those groups are not posix groups so they are not visible using (e.g.) "id"

I was able to solve the problem by adding

objectClass: posixgroup
gidNumber: NNNNNNNN

to those group objects. After this, the sudoers log shows:

May 5 13:11:50 sudo[19545] sssd/ldap sudoHost 'ALL' ... MATCH!
May 5 13:11:50 sudo[19545] sssd/ldap sudoUser '%system_administrators' ... not (brian.candler)
May 5 13:11:50 sudo[19545] sssd/ldap sudoUser '%security_administrators' ... MATCH! (brian.candler)
May 5 13:11:50 sudo[19545] sssd/ldap sudoRunAsUser 'ALL' ... MATCH!
May 5 13:11:50 sudo[19545] sssd/ldap sudoCommand 'ALL' ... MATCH!

So: arguably this is not a bug, but a bug fix. Still, it would be nice if the release notes explained the potential for regression.

Revision history for this message
Brian Candler (b-candler) wrote :

I guess this also makes 1.8.16-0ubuntu1.3 a "security" update, since sudo+sssd now enforces policy which it should have done before, but didn't.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sudo (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.