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 <rcrit...@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: scho...@us.ibm.com | Tel 919 486 1397 >> >> >> >> >> >> >> > > > > -- 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] Sudo question
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: scho...@us.ibm.com | Tel 919 486 1397 From: Rob Crittenden <rcrit...@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 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
Re: [Freeipa-users] Sudo question
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 <rcrit...@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 <rcrit...@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 >> s
[Freeipa-users] Sudo question
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 [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: scho...@us.ibm.com | Tel 919 486 1397 -- 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
