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 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 <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
>> 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
