[rsbac] nsswitch and pam configuration for UM

Palon Setin palons at danwin1210.me
Thu Dec 13 14:20:00 CET 2018

Amon Ott:
> Am 13.12.18 um 12:51 schrieb Palon Setin:
>> These changes to the /etc/pam.d/common-* files:
>>> < account       sufficient                              pam_rsbac.so
>>> 17d16
>>> < auth  sufficient                                      pam_rsbac.so
>>> 25d24
>>> < password      sufficient                      pam_rsbac.so
>>> 16d15
>>> < session       sufficient                      pam_rsbac.so
>> didn't get me the rsbac_login. They do allow me to log in the common
>> Linux way. So, no harm, but no success either.
>> I only got the usual prompt on the six consoles, no rsbac login prompt.
> Login looks the same - but the PAM libs will ask RSBAC instead of
> passwd/shadow.
> To see what happens, try
> echo debug_aef_um 1 >/proc/rsbac-info/debug
Yeah, I noticed that line in the docs or on mad-hacking.net.
> Amon.
I will do the debugging. But let me first report my try to get pure
rsbac, no mix with common linux, login. Text prepared previous to
downloading of your email, of course, boundary made of "=~=~=~".

I used the same kind of loops after I made the changes from
sufficient to required.

Doing it against the same backup of the Debian stock install:

# ls -l Backup/
total 20
-rw-r--r-- 1 root root 1208 2018-08-21 09:22 common-account
-rw-r--r-- 1 root root 1249 2018-08-21 09:22 common-auth
-rw-r--r-- 1 root root 1440 2018-08-21 09:22 common-password
-rw-r--r-- 1 root root 1156 2018-08-21 09:22 common-session
-rw-r--r-- 1 root root  494 2018-07-07 16:34 nsswitch.conf

The loop:

# for conf in `ls -1 Backup/`; do \
        if [ -e "/etc/$conf" ]; then \
                ls -l /etc/$conf Backup/$conf ; \
                diff /etc/$conf Backup/$conf >> this_text_for_this_email; \
        else ls -l /etc/pam.d/$conf Backup/$conf ; \
                diff /etc/pam.d/$conf Backup/$conf >>
this_text_for_this_email ; \
        fi ; \

got me:

< account       required
< #account      [success=1 new_authtok_reqd=done default=ignore]
> account       [success=1 new_authtok_reqd=done default=ignore]
< auth  required                                        pam_rsbac.so
< #auth [success=1 default=ignore]      pam_unix.so nullok_secure
> auth  [success=1 default=ignore]      pam_unix.so nullok_secure
< password      required                        pam_rsbac.so
< #password     [success=1 default=ignore]      pam_unix.so obscure sha512
> password      [success=1 default=ignore]      pam_unix.so obscure sha512
< session       required                        pam_rsbac.so
< #session      [default=1]                     pam_permit.so
> session       [default=1]                     pam_permit.so
< passwd:         rsbac
< group:          rsbac
< shadow:         rsbac
> passwd:         files
> group:          files
> shadow:         files

I will now reboot.

I rebooted, and got only common linux login prompt on the 6
consoles, but I wasn't able to log in.

I then thought to just try and see if removing the
"rsbac_softmode" kernel parameter would help, but then, since I
haven't applied any learning (also high level of understanding
needed), it only got me back Call Traces, because udevd wasn't
allowed to open the / device or somesuch.

Back to the old (but relatively new) conf restored from the
Backup folder as per my previous mail, and I easily booted.

These (new) conf reflect the (relatively) recent changes that
are still getting applied accross the Linux spectrum:

# ls -l /etc/nsswitch.conf /etc/pam.d/common-*
-rw-r--r-- 1 root root  494 2018-07-07 16:34 /etc/nsswitch.conf
-rw-r--r-- 1 root root 1208 2018-08-21 09:22 /etc/pam.d/common-account
-rw-r--r-- 1 root root 1249 2018-08-21 09:22 /etc/pam.d/common-auth
-rw-r--r-- 1 root root 1440 2018-08-21 09:22 /etc/pam.d/common-password
-rw-r--r-- 1 root root 1156 2018-08-21 09:22 /etc/pam.d/common-session
-rw-r--r-- 1 root root 1154 2018-08-21 09:22

(it's the same as listing of the
# ls -l Backup/
of course)

These are less then 4 months old on my Debian Testing.

It very well could be that my issues have nothing really to do
with the changes, but that I made something wrong, or set
something wrong in the kernel config.

I might look into the config and try and send the relevant
config (if I figure out correctly :( )...

And, if no clues suggested, I might go the lengthy way of
restoring the system from backup to the stage previous to any
changes, only freshly installed rsbac kernel, rsbac-admin and
rsbac-tools with no conf whatsoever, and try and do it all over
again :(

Of course, I'm unsure now of the above findings of mine... Will do the
debugging and will be able to tell more, next.

Palon Setin

More information about the rsbac mailing list