Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
On 03/05/2017 15:05, Brian Candler wrote: It turns out we had another 16.04 machine which was working fine. But as soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 1.8.16-0ubuntu1.3, it stopped working too. So it looks like I have a reproducing case for this and I can investigate further FYI, I finally got to the bottom of this issue. (1) The groups referred to in the sudo rule had been created as non-posix groups in FreeIPA (2) It seems that the old sudo in Ubuntu wasn't checking groups at all, and the new one did. But it could not see non-posix groups. (3) I solved the problem by adding "objectClass: posixgroup" and "gidNumber: NN" to the groups. More details at: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1688034/comments/4 Aside: I discovered that the way to debug the sudoers plugin is like this: Debug sudo /var/log/sudo-debug all@info Debug sudoers.so /var/log/sudoers-debug all@info (I had originally missed off the ".so" suffix) It's a bit frightening that sudo+sssd was not enforcing policies correctly, for who knows how long. Regards, Brian. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
It turns out we had another 16.04 machine which was working fine. But as soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 1.8.16-0ubuntu1.3, it stopped working too. So it looks like I have a reproducing case for this and I can investigate further - I suspect it's a behaviour change from this fix: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
> do you have 'sudo: files sss" or "sudoers: files sss"? The former
doesn't do anything, the latter is correct.
My mistake, I meant
sudoers: files sss
But oddly, out of the three 16.04 boxes I set up and enrolled, it was
missing on one of them - and this happened to be the one I was checking
logs on :-( (However, sudo fails in the same way on all three machines)
So after adding this I've rechecked logs.
/var/log/sudo-debug is the same, in particular it still shows "policy
plugin returns 0" and nothing after.
With sss_debuglevel 5, /var/log/sssd/sssd_IPA.EXAMPLE.COM.log has
...
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): ruser: brian.candler
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): rhost:
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): authtok type: 0
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): newauthtok type: 0
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): priv: 0
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): cli_pid: 22709
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data]
(0x0100): logon name: not set
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[ipa_hostgroup_info_done] (0x0200): Dereferenced host group: normal_hosts
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[ipa_hostgroup_info_done] (0x0200): Dereferenced host group:
development_hosts
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[hbac_get_category] (0x0200): Category is set to 'all'.
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule
[allow_normal_hosts]
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, )
[Success]
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success)
[Success]
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[be_pam_handler_callback] (0x0100): Sending result [0][IPA.EXAMPLE.COM]
(Wed May 3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]]
[be_pam_handler_callback] (0x0100): Sent result [0][IPA.EXAMPLE.COM]
("allow_normal_hosts" is indeed the name of the rule in FreeIPA database)
sssd.log has:
(Wed May 3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed May 3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed May 3 08:50:35 2017) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'root' matched without domain, user is root
(Wed May 3 08:50:35 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
Requesting info for [root] from []
(Wed May 3 08:50:35 2017) [sssd[nss]] [nss_cmd_initgroups_search]
(0x0080): No matching domain found for [root], fail!
(Wed May 3 08:50:37 2017) [sssd[nss]] [client_recv] (0x0200): Client
disconnected!
(Hmm, suspicious that error about "root" ??)
sssd_sudo.log has:
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [brian.candler] from []
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [brian.cand...@ipa.example.com]
(Wed May 3 08:50:35 2017) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=brian.candler)(sudoUser=#121103)(sudoUser=%security_administrators)(sudoUser=%admins)(sudoUser=%network_readonly)(sudoUser=%vpn)(sudoUser=%system_administrators)(sudoUser=%ipausers)(sudoUser=%staff)(sudoUser=%brian.candler)(sudoUser=+*))(&(dataExpireTimestamp<=1493801435)))]
(Wed May 3 08:50:35 2017) [sssd[sudo]]
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [brian.candler] from []
(Wed May 3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about
Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
On Wed, May 03, 2017 at 09:04:05AM +0100, Brian Candler wrote: > Hi, > > I have FreeIPA set up under CentOS 7. When I use freeipa-client to add an > ubuntu 14.04 client it works fine (*). However when do the same with ubuntu > 16.04, sudo always refuses to run: > > $ 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. > > I have a simple one-entry sudo policy which says that for all users in > groups X and Y, on all hosts, run all commands. (**) > > If I crank up sudo logging by setting this in /etc/sudo.conf: > > Debug sudo /var/log/sudo-debug all@info > > then on the working 14.04 machine I see > > ... various settings ... > May 2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/ > May 2 22:05:27 sudo[19175] user_info: user=brian.candler > May 2 22:05:27 sudo[19175] user_info: pid=19175 > ... lots more user_info, perms, netgroups etc ... > May 2 22:05:29 sudo[19175] policy plugin returns 1 > ... > > but on the failing 16.04 machine I see only this: > > May 3 07:44:56 sudo[21118] will restore signal 13 on exec > May 3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @ > sudo_ttyname_dev() ./ttyname.c:336 > May 3 07:44:56 sudo[21118] settings: run_shell=true > May 3 07:44:56 sudo[21118] settings: progname=sudo > May 3 07:44:56 sudo[21118] settings: network_addrs=x.x.x.x/255.255.255.0 > :::::230/::::::: > fe80::1:::/::::: > May 3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/ > May 3 07:44:58 sudo[21118] policy plugin returns 0 > > That's all that gets logged - nothing more. It seems that a return of 0 > means failure: > > https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html > > "open() > ... > Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if > there was a usage error." > > But I have no idea what sort of failure or why. > > /var/log/auth.log shows: > > May 3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication failure; > logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 > ruser=brian.candler rhost= user=brian.candler > May 3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication success; > logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 > ruser=brian.candler rhost= user=brian.candler > May 3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ; > TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash > > (which shows I gave the correct FreeIPA password, but not why the sudoers > lookup failed) > > I really can't see where else to look. Both machines have "sudo: files sss" > in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf. Setting > "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but no obvious > errors. do you have 'sudo: files sss" or "sudoers: files sss"? The former doesn't do anything, the latter is correct. if you crank up debugging in the sudo section in sssd.conf do you see any activity at all? do you have '/usr/lib64/libsss_sudo.so' installed? On fedora/rhel, this is provided by libsss_sudo, I don't know what provides it on Debian. > > I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from > https://www.sudo.ws/download.html, but this makes no difference. > > Has anyone seen this problem before, or have some ideas where else to look? > > Thanks, > > Brian Candler. > > > (*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services: > > |[sssd]| > |services = nss, pam, ssh, sudo| > > but this was done automatically by freeipa-client in Ubuntu 16.04. > > (**) Therefore I'm pretty sure this is not the netgroups problem, for which > the fix has been released anyway: > https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666 > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"
Hi, I have FreeIPA set up under CentOS 7. When I use freeipa-client to add an ubuntu 14.04 client it works fine (*). However when do the same with ubuntu 16.04, sudo always refuses to run: $ 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. I have a simple one-entry sudo policy which says that for all users in groups X and Y, on all hosts, run all commands. (**) If I crank up sudo logging by setting this in /etc/sudo.conf: Debug sudo /var/log/sudo-debug all@info then on the working 14.04 machine I see ... various settings ... May 2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/ May 2 22:05:27 sudo[19175] user_info: user=brian.candler May 2 22:05:27 sudo[19175] user_info: pid=19175 ... lots more user_info, perms, netgroups etc ... May 2 22:05:29 sudo[19175] policy plugin returns 1 ... but on the failing 16.04 machine I see only this: May 3 07:44:56 sudo[21118] will restore signal 13 on exec May 3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() ./ttyname.c:336 May 3 07:44:56 sudo[21118] settings: run_shell=true May 3 07:44:56 sudo[21118] settings: progname=sudo May 3 07:44:56 sudo[21118] settings: network_addrs=x.x.x.x/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/ May 3 07:44:58 sudo[21118] policy plugin returns 0 That's all that gets logged - nothing more. It seems that a return of 0 means failure: https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html "open() ... Returns 1 on success, 0 on failure, -1 if a general error occurred, or -2 if there was a usage error." But I have no idea what sort of failure or why. /var/log/auth.log shows: May 3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication failure; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 ruser=brian.candler rhost= user=brian.candler May 3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication success; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 ruser=brian.candler rhost= user=brian.candler May 3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash (which shows I gave the correct FreeIPA password, but not why the sudoers lookup failed) I really can't see where else to look. Both machines have "sudo: files sss" in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf. Setting "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but no obvious errors. I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from https://www.sudo.ws/download.html, but this makes no difference. Has anyone seen this problem before, or have some ideas where else to look? Thanks, Brian Candler. (*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services: |[sssd]| |services = nss, pam, ssh, sudo| but this was done automatically by freeipa-client in Ubuntu 16.04. (**) Therefore I'm pretty sure this is not the netgroups problem, for which the fix has been released anyway: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
