LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)
-   -   PAM support is now integrated into ARM -current (https://www.linuxquestions.org/questions/slackware-arm-108/pam-support-is-now-integrated-into-arm-current-4175675933/)

abga 05-28-2020 02:04 PM

Quote:

Originally Posted by gegechris99 (Post 6128162)
A more appropriate approach is to append character - at the beginning of the lines that bother you in /etc/pam.d/system-auth.
The reason is explained in this thread issue with PAM.

Thanks! Missed the post you linked, wasn't really into this PAM thing, I'm not really interested in using it but accepting the "evolution".
Haven't considered to uninstall the Gnome Keyring packages yet, fearing I might break something - need to check all the dependencies first, but only wanted to disable it. Good to know that I could use "-" for when I uninstall & blacklist those packages. Hope these will get optional, as I suggested in the Requests for -current thread .

abga 05-28-2020 04:26 PM

Actually, commenting the lines with -, in case the libs are still available, won't disable Gnome Keyring

- commented with "-"
Code:

# grep gnome /etc/pam.d/system-auth
-auth        optional      pam_gnome_keyring.so
-session    optional      pam_gnome_keyring.so auto_start
### - /var/log/secure entries:
sshd[25629]: pam_unix(sshd:session): session opened for user test by (uid=0)
sshd[25629]: gkr-pam: unable to locate daemon control file
sshd[25629]: gkr-pam: gnome-keyring-daemon started properly
su[25666]: Successful su for root by test
su[25666]: + /dev/pts/2 test:root
su[25666]: pam_unix(su:session): session opened for user root by test(uid=1000)
su[25666]: The gnome keyring socket is not owned with the same credentials as the user login: /home/test/.cache/keyring-4FDUL0/control
su[25666]: gkr-pam: couldn't unlock the login keyring.

- commented with "#"
Code:

# grep gnome /etc/pam.d/system-auth
#auth        optional      pam_gnome_keyring.so
#session    optional      pam_gnome_keyring.so auto_start
### - /var/log/secure entries:
sshd[25819]: pam_unix(sshd:session): session opened for user test by (uid=0)
su[25840]: Successful su for root by test
su[25840]: + /dev/pts/1 test:root
su[25840]: pam_unix(su:session): session opened for user root by test(uid=1000)


gegechris99 05-29-2020 04:40 AM

Quote:

Originally Posted by abga (Post 6128470)
Actually, commenting the lines with -, in case the libs are still available, won't disable Gnome Keyring

You're correct.

Quote:

If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system.
If Gnome Keyring is installed in the system, you showed that the logs continue to be present in /var/log/secure.

gegechris99 05-29-2020 05:16 AM

There is an option to control when gnome_keyring_daemon is started in PAM.

I added a "only_if" option in /etc/pam.d/system-auth:

Code:

$ cat system-auth | grep pam_gnome_keyring
auth        optional      pam_gnome_keyring.so
session    optional      pam_gnome_keyring.so auto_start only_if=xdm

based on gnome keyring PAM documentation: https://wiki.gnome.org/Projects/GnomeKeyring/Pam

Quote:

If the only_if argument is present with parameters in the PAM config, then the auto_start argument is considered only if the process is in the list of parameters. For example, auto_start only_if=gdm,xdm will only start the daemon if the process is gdm or xdm.
With this option, PAM will not try to auto start gnome keyring daemon for any process not mentioned in the only_if option. I put only xdm so that the daemon is not started for sshd and su (which are the processes that attempted to start gnome keyring daemon in your example).

Also, kill any existing gnome keyring daemon currently running before starting sshd or su to confirm that the daemon is not started with the new PAM option.

Code:

$ps aux | grep gnome-keyring
chris    7295  0.0  0.0  3928  2152 pts/1    S+  12:14  0:00 grep gnome-keyring

I can only test su here and with the only_if option, I now have:

Code:

$ tail /var/log/secure
[...]
May 29 12:17:51 mydarkstar su[7311]: Successful su for root by chris
May 29 12:17:51 mydarkstar su[7311]: + /dev/pts/1 chris:root
May 29 12:17:51 mydarkstar su[7311]: pam_unix(su:session): session opened for user root by chris(uid=1000)


abga 05-29-2020 01:45 PM

@gegechris99

I looked over all those options and implementation methods in my extended analysis, starting with post #13 and learned that some other distros enable it only under X, in xinitrc, like:
https://wiki.archlinux.org/index.php...xinitrc_method

I still failed to understand how/why is d-bus launching it instead of only "hooking" to it as an already running process (no doc found, mentioned that in my previous posts). I'm referring to: /usr/share/dbus-1/services/org.gnome.keyring.service

Also observed (ps ax output) that it's launched with the "--login" option and didn't understand how it's supposed to open the "login vault". Available doc states:
https://wiki.gnome.org/Projects/Gnom.../RunningDaemon
Quote:

- When run with the --login option, gnome-keyring-daemon does not fully initialize. It expects to be initialized later by calling another gnome-keyring-daemon with the --start option.
Then I'm not sure if this Keyring thingy is just a vault/wallet for extra user credentials, implementing the PKCS#11 standard, or it's also handling system credentials (user logins) - in which case, thank you, but no thank you. It looks too buggy/beta and insufficiently documented (like those freedesktop apps) for me to trust it.
https://wiki.gnome.org/Projects/Gnom...g/Architecture

I'm happy with it as optional package.

gegechris99 05-29-2020 04:25 PM

First, I'm using Slackware64 and not Slackware ARM. Maybe some of my observations are not applicable to Slackware ARM.

I'm no specialist of Gnome keyring but I use KDE Wallet on KDE 5 and looked into how KDE Wallet can be automatically opened using PAM configuration when the user logs in.

My understanding is that Gnome keyring is a vault/wallet managing user credentials just like KDE wallet (it may do more but you can get the idea). The default wallet of Gnome Keyring is called 'login':

https://wiki.gnome.org/Projects/Gnom...g/KeyringIntro
Quote:

A keyring stores a collection of encrypted passwords and encrypted information about those passwords. A user can have multiple keyrings, each for a different use, but there is a default one, called 'login'. There is also a special 'session' keyring which is not stored on disk and goes away when you log out.
That's where one can get confused as to whether Gnome keyring is used to authorize login of the user. It's not. In PAM configuration file, you have the control value (second argument) "optional" when calling the Gnome keyring PAM module (pam_gnome_keyring.so). It means that it's not a mandatory step and failure of the module will not prevent the user to log in.

My testing seems to show that Gnome keyring is started only by PAM in Slackware current. I tried only_if=xdm in my PAM configuration (see my previous post) and when I log in in my system using sddm as my graphical login program, Gnome Keyring is not started. If you use xdm to login, you can use option only_if=gdm to test whether or not Gnome Keyring starts after you log in.

Regarding the current PAM configuration in /etc/pam.d/system-auth:

Code:

$ cat system-auth | grep pam_gnome_keyring
auth        optional      pam_gnome_keyring.so
session    optional      pam_gnome_keyring.so auto_start

Case 1: Gnome Keyring package(s) are installed
This PAM configuration will work if you use Gnome Keyring (I haven't tested it as I don't use it)
If you don't use Gnome Keyring, you can comment out those lines.
Using the only_if option could be useful if you want to start Gnome Keyring only for certain processes (login or xdm come to mind) and not do it for the others (su, sshd come to mind).

Case 2: Gnome Keyring package(s) are not installed
This PAM configuration will log error messages in /var/log/secure. In this case, prepend the - character at the
beginning of the lines to avoid pesky error messages.
Or you can comment out those lines as you don't even have Gnome Keyring.

abga 05-29-2020 05:58 PM

I understood the login keyring (vault/wallet) concept, failed to understand how it gets unlocked on login through pam, because that's the current issue, I get in /var/log/secure -> gkr-pam: couldn't unlock the login keyring.

So far I also understood that it doesn't handle the system login credentials, but it keeps its master password (for unlocking the login) in sync with the user system login password. What that means, is only to be found in the source code (or in the heads of the devs).

Additionally, in that login keyring it also stores (if enabled) ssh private keys, and those are a little "touchy" IMHO. I don't mind storing NetworkManager Wifi passwords or other such "system non-critical" credentials. Actually, it's better to store them encrypted instead of clear text in some files that could be read by other users if improperly protected. Still, have no clue what encryption is employed, must be again available in the source code / devs heads.

Some extra info (cannot call it documentation):
https://wiki.gnome.org/Projects/Gnom...StoringSecrets
- You can keep the secret somewhere safe, or safe enough, like: Your brain. Very secure. - I knew it! :)
- Then, there is the section: How Storing Secrets in gnome-keyring Works

https://wiki.gnome.org/Projects/Gnom...mless_Security
- Unlocking on Login
- SSH Agent

https://wiki.gnome.org/Projects/Gnom...rityPhilosophy
- at least they're thinking about potential issues and it's the Passive Attacks I'm more concerned about.


All times are GMT -5. The time now is 01:02 PM.