[Freeipa-users] hbac service allowed despite not listed

Jakub Hrozek jhrozek at redhat.com
Tue Nov 24 09:37:33 UTC 2015 

On Tue, Nov 24, 2015 at 10:25:11AM +0100, Winfried de Heiden wrote:
>    Hi all,
> 
>    sss_debuglevel 6; in /var/log/sss/sssd_pam.log
> 
>    Running as "testuser" crond is denied; perfecr since it is not listed in
>    the HBAC services.
> 
>    [testuser at fedora23-server ~]$ crontab -l
>    You (testuser) are not allowed to access to (crontab) because of pam
>    configuration.
> 
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [accept_fd_handler] (0x0400):
>    Client connected!
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
>    Received client version [3].
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
>    Offered version [3].
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100):
>    entering pam_cmd_acct_mgmt
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_parse_name_for_domains]
>    (0x0200): name 'testuser' matched without domain, user is testuser
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
>    SSS_PAM_ACCT_MGMT
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
>    not set
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
>    testuser
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
>    crond
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): tty:
>    cron
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>    not set
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>    not set
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
>    type: 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
>    newauthtok type: 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
>    1910
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>    name: testuser
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400):
>    Issuing request for [[1]0x561eb0a4b2e0:3:testuser at blabla.bla]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400):
>    Creating request for
>    [blabla.bla][0x3][BE_REQ_INITGROUPS][1][name=testuser]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_internal_get_send]
>    (0x0400): Entering request [[2]0x561eb0a4b2e0:3:testuser at blabla.bla]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search] (0x0100):
>    Requesting info for [[3]testuser at blabla.bla]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search] (0x0400):
>    Returning info for user [[4]testuser at blabla.bla]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
>    request with the following data:
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
>    SSS_PAM_ACCT_MGMT
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
>    blabla.bla
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
>    testuser
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
>    crond
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): tty:
>    cron
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>    not set
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>    not set
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
>    type: 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
>    newauthtok type: 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
>    1910
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>    name: testuser
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
>    pam_dp_send_req returned 0
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400):
>    Deleting request: [[5]0x561eb0a4b2e0:3:testuser at blabla.bla]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_process_reply] (0x0200):
>    received: [6 (Permission denied)][blabla.bla]
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
>    called with result [6]: Permission denied.
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27
>    (Tue Nov 24 09:54:58 2015) [sssd[pam]] [client_recv] (0x0200): Client
>    disconnected!
> 
>    Now, using su or su - does not show anything in de sssd logs, it looks
>    like the su service is not using sssd. What could be wrong?

Are you running su as an ordinary user or root? What does appear in
/var/log/secure when you run su ?

Can you show what is the /etc/pam.d/su config and the config of the
service that is included from /etc/pam.d/su ? (typically system-auth)

> 
>    forgot to mention; allow_all is disabled, checked that 100 times...
> 
>    Kind regards,
> 
>    Winny
> 
>    Op 23-11-15 om 17:16 schreef Jakub Hrozek:
> 
>  On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote:
> 
>     Hi all,
> 
>     I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
> 
>     # ipa hbacrule-show testuser
>       Rule name: testuser
>       Enabled: TRUE
>       Users: testuser
>       Hosts: fedora23-server.blabla.bla
>       Services: sshd
> 
>     Hence, " testuser"  is only allowed using sshd on "fedora23-server". No
>     surprise, this user is not allowed to use "su":
> 
>     # ipa hbactest --user testuser --host fedora23-server.blabla.bla --service
>     su
>     ---------------------
>     Access granted: False
> 
>     (and yeah sshd is allowed)
> 
>     However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
>     correct password, access is granted. This user is not a member of any
>     other groups.
>     HBAC Services like cron or console access are denied correctly since they
>     are not in the HBAC service list.
> 
>     I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several
>     other ipa-clients (RHEL/CentoOS 6.x, 7.x)
> 
>     Shouldn't su or su -l be denied when not listed?
> 
>  Yes, and in my testing with a similar rule:
> 
>  $ ipa hbacrule-show allow_sshd
>    Rule name: allow_sshd
>    Enabled: TRUE
>    Users: admin
>    Hosts: client.ipa.test
>    Services: sshd
> 
>  admin can ssh to client.ipa.test but it's not possible to su to admin.
> 
>  Please follow [6]https://fedorahosted.org/sssd/wiki/Troubleshooting and check
>  /var/log/secure and the sssd logs.
> 
>  Also, you're not calling su as root, are you?
> 
> References
> 
>    Visible links
>    1. mailto:0x561eb0a4b2e0:3:testuser at blabla.bla
>    2. mailto:0x561eb0a4b2e0:3:testuser at blabla.bla
>    3. mailto:testuser at blabla.bla
>    4. mailto:testuser at blabla.bla
>    5. mailto:0x561eb0a4b2e0:3:testuser at blabla.bla
>    6. https://fedorahosted.org/sssd/wiki/Troubleshooting

More information about the Freeipa-users mailing list