<html><body>Rob, Yes.. in our setup allow_all has to be explicitly applied to a persons/group HBAC for it to be available to them. This user has one direct HBAC rule and its called Bob which only allows access to 2 servers and the services I provided below and one indirect HBAC rule which allows him access to our NFS server automouting home profiles and his own sudo rule called bob. I have removed /bin/bash from his sudo rule and it is working as expected now however I am thinking this will affect app owners from being able to sudo to app IDs so they will just have to su to them instead I am thinking. Is probably a better approach anyways as the app owner should know the app password and keep anyone else from sudoing to it with there own pw. output of working as required: [bob@server ~]$ sudo -i Sorry, user bob is not allowed to execute '/bin/bash' as root on server.example.local. [bob@server ~]$ sudo cat /etc/sysconfig/iptables # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter [bob@server ~]$ sudo -i Sorry, user bob is not allowed to execute '/bin/bash' as root on server.example.local. [bob@server ~]$ Any comments or suggestions welcome Sean Hogan Security Engineer Watson Security & Risk Assurance Watson Cloud Technology and Support email: schogan@us.ibm.com | Tel 919 486 1397 <img src="cid:1__=88BBF583DFFACA398f9e8a93df938690918c88B@" width="67" height="53" align="top"> <img src="cid:2__=88BBF583DFFACA398f9e8a93df938690918c88B@" width="60" height="51" align="top"> <img width="16" height="16" src="cid:3__=88BBF583DFFACA398f9e8a93df938690918c88B@" border="0" alt="Inactive hide details for Rob Crittenden ---12/03/2015 11:21:23 AM---Sean Hogan wrote: > I had the log bumped to 8 and yes the ">Rob Crittenden ---12/03/2015 11:21:23 AM---Sean Hogan wrote: > I had the log bumped to 8 and yes the allow_all HBAC rule is enabled From: Rob Crittenden <rcritten@redhat.com> To: Sean Hogan/Durham/IBM@IBMUS, "Freeipa-users@redhat.com" <Freeipa-users@redhat.com> Date: 12/03/2015 11:21 AM Subject: Re: [Freeipa-users] Sudo question <hr width="100%" size="2" align="left" noshade style="color:#8091A5; "> <tt>Sean Hogan wrote: > I had the log bumped to 8 and yes the allow_all HBAC rule is enabled > however not associated with this user at all. This test only allows this > user to hit 2 servers with individual HBAC rule to the 2 servers via the > services I provided earlier. > allow_all applies to everyone unless you've changed it. HBAC is deny by default so once allowed, always allowed. I'm not well-versed in the sssd logs so maybe one of those guys will chime in. rob > [bob@server ~]$ sudo -l > [sudo] password for bob: > Matching Defaults entries for bob on this host: > requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS > DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE > LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL > LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, logfile=/var/log/sudo.log > > User bob may run the following commands on this host: > (root) !/usr/local/bin/sudo, !/usr/bin/sudo, !/bin/sudo > (root) /usr/bin/xclock > (root) /sbin/iptables, /sbin/service, /bin/vi, /bin/view, /usr/bin/vim, > /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat, > !/usr/bin/sudo -i, !/usr/bin/sudo-i, !/usr/bin/sudo -u root -i > > > > sssd.conf > server.example.local:/var/log# cat /etc/sssd/sssd.conf > [domain/example.local] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = example.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = server.example.local > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, mastersrv.example.local > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > debug_level = 8 > > domains = example.local > [nss] > homedir_substring = /home > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > Ran thru the commands again: > [me@mine ~]$ ssh bob@server > bob@server password: > Last login: Thu Dec 3 11:24:53 2015 from IP_ADDRESS > [bob@server ~]$ sudo -i > [sudo] password for bob: > Sorry, try again. > [sudo] password for bob: > sudo: 1 incorrect password attempt > [bob@server ~]$ sudo cat /etc/sysconfig/iptables > [sudo] password for bob: > # Firewall configuration written by system-config-firewall > # Manual customization of this file is not recommended. > *filter > [bob@server ~]$ sudo -i > server.example.local:/root# exit > > This is what the logs show for above conversations > Dec 3 11:49:52 server sshd[61682]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob > Dec 3 11:49:53 server sshd[61682]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob > Dec 3 11:49:53 server sshd[61682]: Accepted password for bob from > IP_ADDRESS port 50273 ssh2 > Dec 3 11:49:53 server sshd[61682]: pam_unix(sshd:session): session > opened for user bob by (uid=0) > Dec 3 11:49:53 server sshd[61682]: User child is on pid 61687 > > Attempt sudo -i which fails with bad pw but at least fails, PW is correct. > Dec 3 11:50:05 server sudo: pam_unix(sudo-i:auth): authentication > failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:06 server sudo: pam_sss(sudo-i:auth): authentication > success; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:06 server sudo: pam_sss(sudo-i:account): Access denied for > user bob: 6 (Permission denied) > Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): conversation failed > Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): auth could not > identify password for [bob] > Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): authentication > failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): received for user bob: > 7 (Authentication failure) > Dec 3 11:50:11 server sudo: bob : 1 incorrect password attempt ; > TTY=pts/2 ; PWD=/home/rusers/bob ; USER=root ; COMMAND=/bin/bash > > Cat /etc/syconfig/iptables which works after prompting for pw so good > Dec 3 11:50:42 server sudo: pam_unix(sudo:auth): authentication failure; > logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob > Dec 3 11:50:43 server sudo: pam_sss(sudo:auth): authentication success; > logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob > Dec 3 11:50:43 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ; > USER=root ; COMMAND=/bin/cat /etc/sysconfig/iptables > > sudo -i now works even though it did not before > Dec 3 11:50:52 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ; > USER=root ; COMMAND=/bin/bash > > > I expect the pam_unix fails as the accounts are not local.. I expect the > first set of fails for sudo -i even though its comes up a pw issue which > is not the case. I expect success when catting iptables which is good > but then sudo -i just works after that which is not expected. > > Client: > rpm -qa | grep ipa > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-python-1.11.6-30.el6_6.4.ppc64 > ipa-python-3.0.0-42.el6.ppc64 > libipa_hbac-1.11.6-30.el6_6.4.ppc64 > device-mapper-multipath-libs-0.4.9-80.el6_6.3.ppc64 > sssd-ipa-1.11.6-30.el6_6.4.ppc64 > ipa-client-3.0.0-42.el6.ppc64 > device-mapper-multipath-0.4.9-80.el6_6.3.ppc64 > > > Server: > rpm -qa | grep ipa > sssd-ipa-1.12.4-47.el6.x86_64 > ipa-admintools-3.0.0-47.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.12.4-47.el6.x86_64 > ipa-client-3.0.0-47.el6.x86_64 > ipa-python-3.0.0-47.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-server-selinux-3.0.0-47.el6.x86_64 > ipa-server-3.0.0-47.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-1.12.4-47.el6.x86_64 > > > > Inactive hide details for Rob Crittenden ---12/03/2015 08:29:53 > AM---Sean Hogan wrote: > Hi Rob,Rob Crittenden ---12/03/2015 08:29:53 > AM---Sean Hogan wrote: > Hi Rob, > > From: Rob Crittenden <rcritten@redhat.com> > To: Sean Hogan/Durham/IBM@IBMUS, "Freeipa-users@redhat.com" > <Freeipa-users@redhat.com> > Date: 12/03/2015 08:29 AM > Subject: Re: [Freeipa-users] Sudo question > > ------------------------------------------------------------------------ > > > > Sean Hogan wrote: >> Hi Rob, >> >> Thanks for the suggestion. I think that is what I have though. The >> sudorule applied for this user does not have sudo as an avail command >> unless it picks up /usr/bin/sudo -u user -i which I was thinking would >> only allow sudoing to user. >> HBAC services I have for the user has sudo and no sudo -i. >> Services >> sshd >> login >> gdm >> gdm-password >> kdm >> su >> su-l >> vsftpd >> sudo >> >> Sudo Rule >> *Sudo Allow Commands*: /sbin/iptables, /sbin/service, >> /bin/view,/bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >> *Sudo Deny Commands*: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo >> -u root -i >> >> Unfortunately I am really stumped on this one. > > You probably have the allow_all HBAC rule enabled. If sudo-i isn't > allowed in HBAC then the pam service shouldn't be allowed at all. I'd > suggest you bump up the sssd debug level to better see what is happening. > > rob > >> >> >> >> >> >> Inactive hide details for Rob Crittenden ---12/02/2015 04:26:24 >> PM---Sean Hogan wrote: > Hi All,Rob Crittenden ---12/02/2015 04:26:24 >> PM---Sean Hogan wrote: > Hi All, >> >> From: Rob Crittenden <rcritten@redhat.com> >> To: Sean Hogan/Durham/IBM@IBMUS, freeipa-users@redhat.com >> Date: 12/02/2015 04:26 PM >> Subject: Re: [Freeipa-users] Sudo question >> >> ------------------------------------------------------------------------ >> >> >> >> Sean Hogan wrote: >>> Hi All, >>> >>> I have a significant amount of time on this and hoping some of you might >>> have an idea. I want to limit user bob from getting to a root prompt on >>> this test box. >>> It seems to work until bob is able to run a command he is allowed via >>> sudo such as cat. Sudo -i is on the deny command list in IPA and root is >>> local(not in IPA) with >>> nsswitch pointing to files first then sss. >>> >>> So logged on as user bob, first thing attempted was sudo -i which >>> produces wrong pw message even though it is the correct pw but it is >>> denying so fine. Then I issue sudo cat /etc/sysconfig/iptables >>> and it allows it after I enter bob's pw which is fine. However right >>> after that I try sudo -i again and get root prompt which is not good. I >>> am thinking since root is local and files first then once I sudo up root >>> is avail. >>> Any suggestions are welcome >> >> I think you are better off using an HBAC rule to only grant sudo and not >> sudo -i. >> >> rob >> >>> >>> >>> >>> *[me@mine ~]$ ssh bob@server* >>> bob@servers password: >>> Last login: Time: from IP >>> Internal systems must only be used for conducting company business or >>> for purposes authorized by company management >>> Use is subject to audit at any time by company management >>> *[bob@server ~]$ sudo -i* >>> [sudo] password for bob: >>> Sorry, try again. >>> *[bob@server ~]$ sudo -i* >>> [sudo] password for bob: >>> Sorry, try again. >>> [sudo] password for bob: >>> Sorry, try again. >>> [sudo] password for bob: >>> sudo: 2 incorrect password attempts >>> *[bob@server ~]$ sudo cat /etc/sysconfig/iptables* >>> [sudo] password for bob: >>> # Firewall configuration written by system-config-firewall >>> # Manual customization of this file is not recommended. >>> *filter >>> *[bob@server ~]$ sudo -i* >>> *server.example.local:/root# cat /etc/sysconfig/iptables* >>> # Firewall configuration written by system-config-firewall >>> # Manual customization of this file is not recommended. >>> *filter >>> >>> >>> >>> ipa sudorule-show bob >>> Rule name: bob >>> Description: test sudo rule for user bob >>> Enabled: TRUE >>> Host category: all >>> Users: bob >>> Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view, >>> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >>> Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u >>> root -i >>> >>> Is it just me or is white space ignored as well with sudo commands much >>> like the sudo options? >>> >>> >>> >>> >>> >>> >>> Sean Hogan >>> Security Engineer >>> Watson Security & Risk Assurance >>> Watson Cloud Technology and Support >>> email: schogan@us.ibm.com | Tel 919 486 1397 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > </tt> </body></html>