On Tue, 24 Nov 2015, Winfried de Heiden wrote:


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





Op 24-11-15 om 14:04 schreef Jakub Hrozek:
On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote:
Hi all,

[winfried@ipa ~]$ ipa hbacrule-show allow_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

[winfried@ipa ~]$ ipa hbacrule-show testuser
  Rule name: testuser
  Enabled: TRUE
  Users: testuser
  Hosts: fedora23-server.blabla.bla
  Services: sshd

[winfried@ipa ~]$ ipa user-show winfried
  User login: winfried
  First name: Winfried
  Last name: de Heiden
  Home directory: /home/winfried
  Login shell: /bin/bash
etc. .etc.

[winfried@ipa ~]$ ipa user-show testuser
  User login: testuser
  First name: test
  Last name: user
  Home directory: /home/testuser
  Login shell: /bin/bash
  Email address: testu...@blabla.bla
  UID: 10005
  GID: 10005
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Member of HBAC rule: testuser
  Kerberos keys available: True



[[testuser@fedora23-server ~]$ su winfried
Wachtwoord:
[winfried@fedora23-server testuser]$ id
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

Op 24-11-15 om 11:43 schreef Jakub Hrozek:
On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:
   Hi all,

   Running as an ordinary user, straight from the beginning.

   Is the (default) suid of/usr/bin/su causing this?
   Anyway: the info requested:

   /var/log/secure will tell:
   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.

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

--
/ Alexander Bokovoy

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

Reply via email to