[Freeipa-users] hbac service allowed despite not listed

[Winfried de Heiden]

[Jakub Hrozek]

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

[Sumit Bose]

Post by Jakub Hrozek

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

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

Have you disabled the allow_all rule?

bye,
Sumit

Post by Jakub Hrozek
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Winfried de Heiden]

[Jakub Hrozek]

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.
You (testuser) are not allowed to access to (crontab) because of pam
configuration.
Client connected!
Received client version [3].
Offered version [3].
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
SSS_PAM_ACCT_MGMT
not set
testuser
crond
cron
not set
not set
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
type: 0
newauthtok type: 0
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
1910
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
name: testuser
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]
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
SSS_PAM_ACCT_MGMT
blabla.bla
testuser
crond
cron
not set
not set
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
type: 0
newauthtok type: 0
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
1910
(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
name: testuser
pam_dp_send_req returned 0
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
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
# 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?
$ 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
6. https://fedorahosted.org/sssd/wiki/Troubleshooting

[Winfried de Heiden]

[Jakub Hrozek]

Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
 
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)

Interesting, there is even no account message at all...not even auth
message?

De pam.d files are from a clean fresh Fedora23 install and
/etc/pam.d/su
#%PAM-1.0
auth        sufficient    pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel"
group.
#auth        sufficient    pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel"
group.
#auth        required    pam_wheel.so use_uid
auth        substack    system-auth
auth        include        postlogin
account        sufficient    pam_succeed_if.so uid = 0 use_uid quiet
account        include        system-auth

...yet clearly here su includes system_auth unless pam_succeed_if ran
(which should only happen if you ran su as root)

Just to be sure, can you comment out the pam_succeed_if.so line?

password    include        system-auth
session        include        system-auth
session        include        postlogin
session        optional    pam_xauth.so
/etc/pam.d/postlogin
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm*
service !~ su* quiet
session     [default=1]   pam_lastlog.so nowtmp silent
session     optional      pam_lastlog.so silent noupdate showfailed
/etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok
try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so
password    requisite     pam_pwquality.so try_first_pass local_users_only
retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass
use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
re 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)

[Jakub Hrozek]

Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
 
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
would do:
pam_start("su", "root", ...)
pam_authenticate();

So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.

[Jakub Hrozek]

Hi all,
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
Rule name: testuser
Enabled: TRUE
Users: testuser
Hosts: fedora23-server.blabla.bla
Services: sshd
User login: winfried
First name: Winfried
Last name: de Heiden
Home directory: /home/winfried
Login shell: /bin/bash
etc. .etc.
User login: testuser
First name: test
Last name: user
Home directory: /home/testuser
Login shell: /bin/bash
UID: 10005
GID: 10005
Account disabled: False
Password: True
Member of groups: ipausers
Member of HBAC rule: testuser
Kerberos keys available: True
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
So yes, I can su to another IPA-user :(
sssd_pam now shows information, but nothing seems to go wrong...

I think you forgot to CC freeipa-users.

In this case, can you look into /var/log/secure again and into the
domain logs?

What's happening?
Winny

Post by Jakub Hrozek

Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
pam_start("su", "root", ...)
pam_authenticate();
So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.

[Winfried de Heiden]

Hi all,

The problem is clear, there is a misunderstanding of the service "su"
and "su-l", this is about the target users. Hence; su - to user winfried
is allowed since su and su-l are added to the hbac service list of this
user.

This looks a bit strange from the ui perspective, all other HBAC
services are what this user is allow to do; "su" and "su-l" defines that
OTHER user may become this user by using su.

A bit strange, but this is how is works. Anyone disagree?

Winny

Post by Jakub Hrozek

Hi all,
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
Rule name: testuser
Enabled: TRUE
Users: testuser
Hosts: fedora23-server.blabla.bla
Services: sshd
User login: winfried
First name: Winfried
Last name: de Heiden
Home directory: /home/winfried
Login shell: /bin/bash
etc. .etc.
User login: testuser
First name: test
Last name: user
Home directory: /home/testuser
Login shell: /bin/bash
UID: 10005
GID: 10005
Account disabled: False
Password: True
Member of groups: ipausers
Member of HBAC rule: testuser
Kerberos keys available: True
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
So yes, I can su to another IPA-user :(
sssd_pam now shows information, but nothing seems to go wrong...

I think you forgot to CC freeipa-users.
In this case, can you look into /var/log/secure again and into the
domain logs?

What's happening?
Winny

Post by Jakub Hrozek

Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
pam_start("su", "root", ...)
pam_authenticate();
So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.

[Alexander Bokovoy]

Hi all,
The problem is clear, there is a misunderstanding of the service "su"
and "su-l", this is about the target users. Hence; su - to user
winfried is allowed since su and su-l are added to the hbac service
list of this user.
This looks a bit strange from the ui perspective, all other HBAC
services are what this user is allow to do; "su" and "su-l" defines
that OTHER user may become this user by using su.
A bit strange, but this is how is works. Anyone disagree?

Consider the fact that HBAC names are names of PAM services used by
applications. If an application uses PAM, it specifies name of own
configuration file relative to /etc/pam.d toPAM API.

For 'su' utility look into its manual page, section FILES:
FILES
/etc/pam.d/su default PAM configuration file
/etc/pam.d/su-l PAM configuration file if --login is specified
/etc/default/su command specific logindef config file
/etc/login.defs global logindef config file

'su' utility uses two different PAM names for different modes of
operation. Therefore, when defining HBAC rules for 'su' you need to take
into account both PAM services and decide what you want to do with them.

Winny

Post by Jakub Hrozek

Hi all,
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
Rule name: testuser
Enabled: TRUE
Users: testuser
Hosts: fedora23-server.blabla.bla
Services: sshd
User login: winfried
First name: Winfried
Last name: de Heiden
Home directory: /home/winfried
Login shell: /bin/bash
etc. .etc.
User login: testuser
First name: test
Last name: user
Home directory: /home/testuser
Login shell: /bin/bash
UID: 10005
GID: 10005
Account disabled: False
Password: True
Member of groups: ipausers
Member of HBAC rule: testuser
Kerberos keys available: True
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
So yes, I can su to another IPA-user :(
sssd_pam now shows information, but nothing seems to go wrong...

I think you forgot to CC freeipa-users.
In this case, can you look into /var/log/secure again and into the
domain logs?

What's happening?
Winny

Post by Jakub Hrozek

Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
pam_start("su", "root", ...)
pam_authenticate();
So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.

--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project