1

We've got some RHEL 5 servers joined to AD using Winbind/Kerberos which is working well overall.

I've specified an AD security group in PAM to restrict which domain users can login.

auth        requisite     pam_succeed_if.so user ingroup ad_group debug

I've also specified the same group in sudoers so they can attain root access.

%ad_group ALL=(ALL)     ALL

These work as expected.

However, I've noticed that "su -" will allow me to become a domain user that is not in the security group.

Let's say jdoe is not in the "ad_group":

[kernelpanic@server01 ~]$ sudo su - jdoe
[sudo] password for user:
Creating directory '/home/jdoe'.
Creating directory '/home/jdoe/.mozilla'.
Creating directory '/home/jdoe/.mozilla/plugins'.
Creating directory '/home/jdoe/.mozilla/extensions'.
[jdoe@server01 ~]$

Here's the /var/log/secure output:

Oct 25 09:42:42 server01 su: pam_unix(su-l:session): session opened for user jdoe by kernelpanic(uid=0)
Oct 25 09:43:53 server01 su: pam_unix(su-l:session): session closed for user jdoe

Is there a way to restrict users from an "su -" to a domain user who is not allowed to login to the box in the first place?

kernelpanic
  • 1,246
  • 1
  • 10
  • 30

1 Answers1

1

I believe the first line in /etc/pam.d/su looks like this:

auth            sufficient      pam_rootok.so

In other words, when you su tries to authorize your to become jdoe, everything looks okay.

What you can do is either add your pam_succeed_if line to /etc/pam.d/su, or much better, add an entry to /etc/pam.d/system-auth, but modify it so the auth becomes session like so:

session requisite pam_succeed_if.so user ingroup ad_group debug

This will get triggered even in the situation that you described and will not let a user from the non ad_group to ever open a shell. This would also have the unfortunate side effect of restricting root from opening a shell (as pointed out in the comments), so you may need to only apply it for user ids in the correct range:

session [default=1 success=ignore] pam_succeed_if.so quiet uid >= 1000
session requisite pam_succeed_if.so user ingroup ad_group debug

By the way, ssh may also bypass PAM if you are authenticating with a public key, so it is still better to use session instead of auth.

chutz
  • 7,569
  • 1
  • 28
  • 57