PAM about to be merged in -current

LuckyCyborg · 05-21-2020, 11:25 PM

Quote:

Originally Posted by mlangdn

@gegechris99

There is no Autologin section in /etc/sddm.conf
In /etc/sddm.conf.d there is a file called kde_settings.conf with an Autologin section. I changed that to reflect the above changes. I tried adding that section to sddm.conf but no go.

There is an /etc/pam.d/sddm-autologin with nearly the same entries as what you have. I have made these changes while making sure that I keep the originals. In every case, I end up at a blank screen with mouse and cursor visible for over 10 minutes before I do a hard reboot. I'm gonna keep trying - something is missing..... I hate not being able to figure this out. I ain't giving up yet.

Unfortunately, there is no way to setup the SDDM's autologin while the /etc/pam.d/sddm rely on /etc/pam.d/login because of "pam_securetty.so" which in this context has the absolutely sole role to lock the root login, because from what I understand, the SDDM will never get a "secure tty" from a pure reason: it is a X11 graphical application which does NOT run in a TTY.

And, like I said already in this thread, for autologin the SDDM does a root login then "su" to the target user logged-in, then the root lock with block also the autologin to an unprivileged user.

Also, please be kind to search the Internet this "pam_securetty.so" and you will discover that the PAM driven distributions considers it obsolete since 2015, in precedence being used as root locker for SSHD, like do today the SSHD's config option: "PermitRootLogin no"

It has no other security features other than locking the root login on ttys - excluding certain ones, and it was abandoned mainly because it is known to interact badly with the containers and SSHD become smart enough to lock the root users itself.

Also, please note that from my searches from the last days, no other distribution guards this SDDM with "pam_securetty.so" even the Ubuntus, where the root account is disabled by default, and they uses PAM configs for SDDM in a similar manner with the one proposed by me in this thread.

And, BTW... "allowing root autologin" is not a security issue per se for you as end user, because nobody other than you root and owner of your computer, only you can activate this root autologin, then possibly ending with a root desktop, which many considers being risky.

What Mr. Hameleers did is another story, is his personal "War on Root Desktop" and I respect his position as packages builder, but in the end, we'll see if those strong-hand configs against root desktop will end in Slackware...

After all, they are just nuisances, because you can start well a root desktop from runlevel 3 or using another DM like lightDM or GDM or simply modifying the PAM configs for SDDM.

drgibbon · 05-21-2020, 11:34 PM

Quote:

Originally Posted by Richard Cranium

Nervous head twitch.

I used to be a signal officer in the US Army. If I remember correctly, NATO countries also used the same standard.

Over means that you are done speaking and expect a reply from the distant station.
Out means that you are done speaking and do not expect a reply from the distant station.

There's no reason to use both.

Hell, I still twitch a bit when I listen to https://www.youtube.com/watch?v=9VcT...rBGeCvrLdJh94f (A link to the Sneaker Pimps song Tesko Suicide, in case you don't want to give traffic to YouTube.)

Interesting, although the LQ forum is not a US army ship (I hope), and it would have sounded rather odd if he'd ended his post with just "Over." or "Out."

So clearly, the reason to use "over and out" together is because it sounds much more stylish!

Richard Cranium · 05-21-2020, 11:43 PM

Quote:

Originally Posted by drgibbon

Interesting, although the LQ forum is not a US army ship (I hope), and it would have sounded rather odd if he'd ended his post with just "Over." or "Out."

So clearly, the reason to use "over and out" together is because it sounds much more stylish!

Blinks Well, as far as I know, the US Army doesn't own any ships.

And I do know that idiosyncrasies in radio traffic really helps an enemy figure out who you are after the daily frequency/hopset change; it's best to act like everyone else according to doctrine so that you look like everyone else. That's why that doctrine is in place, after all. (Yes, if you don't move around very much and don't use directional antennas, they could suss that out from your cross-triangulated location after a bit of cross-referencing.)

But, all of this is even more OT than my original comment. Back to the normal flamewar!

drgibbon · 05-21-2020, 11:52 PM

Quote:

Originally Posted by Richard Cranium

Blinks Well, as far as I know, the US Army doesn't own any ships.

Of course I meant spaceship

Right, back to flaming.

gegechris99 · 05-22-2020, 02:22 AM

Quote:

Originally Posted by LuckyCyborg

Unfortunately, there is no way to setup the SDDM's autologin while the /etc/pam.d/sddm rely on /etc/pam.d/login because of "pam_securetty.so" which in this context has the absolutely sole role to lock the root login, because from what I understand, the SDDM will never get a "secure tty" from a pure reason: it is a X11 graphical application which does NOT run in a TTY.

Do you mean that a user who is willing to tinker with his own system just has to comment the pam_securetty.so line in /etc/pam.d/login to make sddm autologin work?
If so, then I believe that mlangdn is such a user.
I haven't read the whole thread, so it's possible that this solution has already been tested without success.

GazL · 05-22-2020, 04:34 AM

Having sddm 'include' the pam config of another service is a bad idea to start with. Including something intended to be included into other things -- such as 'system-auth' -- is obviously fine, but you don't want unrelated services including each other. That's just going to lead to you being eaten by a Grue!

What I did here, was I created a system-entrypoint that things like login, xdm, sshd, etc. can include, which itself includes system-auth (which I've modified as I don't like what Pat ships).

I'm afraid I can't help you with sddm as I don't use it.

LuckyCyborg · 05-22-2020, 05:05 AM

Quote:

Originally Posted by gegechris99

Do you mean that a user who is willing to tinker with his own system just has to comment the pam_securetty.so line in /etc/pam.d/login to make sddm autologin work?
If so, then I believe that mlangdn is such a user.
I haven't read the whole thread, so it's possible that this solution has already been tested without success.

I guess he tries to respect Mr. Hameleers' login stack and the root lock.

However, from my own experience, there should be modified both /etc/pam.d/sddm and /etc/pam.d/sddm-autologin, like I described there: https://www.linuxquestions.org/quest...ml#post6125265

I managed to get also even a variant which does the root lock, both in autologin and manual login, but keeping working the autologin for unpriveldeged users, like this:

/etc/pam.d/sddm

Code:

#%PAM-1.0

auth       requisite    pam_nologin.so
auth       required     pam_env.so
auth       required     pam_succeed_if.so uid >= 1000 quiet  # Disable the login as root

auth       include      system-auth
auth       include      postlogin

-auth      optional     pam_gnome_keyring.so
-auth      optional     pam_kwallet5.so

account    include      system-auth

password   include      system-auth
-password  optional     pam_gnome_keyring.so use_authtok
-password  optional     pam_kwallet5.so use_authtok

session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_keyinit.so force revoke
session    optional     pam_ck_connector.so nox11
session    include      postlogin

-session   optional     pam_gnome_keyring.so auto_start
-session   optional     pam_kwallet5.so auto_start

/etc/pam.d/sddm-autologin

Code:

#%PAM-1.0

auth       requisite    pam_nologin.so
auth       required     pam_env.so
auth       required     pam_succeed_if.so uid >= 1000 quiet  # Disable the autologin as root
auth       required     pam_permit.so

-auth      optional     pam_gnome_keyring.so
-auth      optional     pam_kwallet5.so

account    include      system-auth

password   include      system-auth

session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_ck_connector.so nox11
session    include      postlogin

-session   optional     pam_gnome_keyring.so auto_start
-session   optional     pam_kwallet5.so auto_start

/etc/pam.d/sddm-greeter

Code:

#%PAM-1.0

# Load environment from /etc/environment and ~/.pam_environment
auth            required pam_env.so

# Always let the greeter start without authentication
auth            required pam_permit.so

# No action required for account management
account         required pam_permit.so

# Can't change password
password        required pam_deny.so

# Setup session
session         required pam_unix.so
-session         optional pam_systemd.so
-session         optional pam_elogind.so

Please note the red lines - they locks the root logins, commenting them enables the manual login and auto-login as root.

However, to make autologin works for unprivileged users, I needed to modify all those 3 files, like I presented here. It is not enough to modify only /etc/pam.d/sddm-autologin

gegechris99 · 05-22-2020, 05:59 AM

Thanks LuckyCyborg for detailed instructions.

I tested successfully sddm autologin with unprivileged user using your files /etc/pam.d/sddm and /etc/pam.d/sddm-autologin and changing the autologin section in /etc/sddm.conf.

Code:

$ cat /etc/sddm.conf 
[Autologin]
# Whether sddm should automatically log back into sessions when they exit
Relogin=false

# Name of session file for autologin session (if empty try last logged in)
Session=plasma.desktop

# Username for autologin session
User=<your username>

There was no need to change file /etc/pam.d/sddm-greeter.

All in all, it shows that to make autologin works with sddm on Slackware current, only configuration changes are required. There is no need to recompile anything.

From my perspective, this is good enough even if Slackware developers decide for other configuration options.You can always copy your own configuration files in a safe place and make them overwrite the standard Slackware configuration files at each boot (by making cp commands in /etc/rc.d/rc.local for example).

Alien Bob · 05-22-2020, 03:07 PM

I am working on a set of PAM configuration files for SDDM which address the feedback given in this thread. Even though KDE Plasma5 and SDDM are not part of Slackware (yet), it is still meant to get included at some point, and then it is up to the user to feel carefree and login as root into a graphical desktop. I would not want ever to do that, but as long as you do not hold me responsible if someone hacks your network because you had an urge to login as root instead of a regular user... it's your party.

So, the PAM files for SDDM shown in earlier posts have a couple of things I would like to avoid/improve.
For instance, they include functionality which is already covered in the system-auth stack, and do not need to be duplicated.
Also, I guess nobody who tried these files is actually using the KDE Wallet's PAM extension because with the above configuration, the pam_kwallet5.so line is never used and the KDE Wallet is not automatically opened at login.

This is my proposed setup. It is modeled after Pat's recent modifications of the 'kde' and 'kde-np' PAM configurations. I can login as root, my KDE Wallet behaves as it should, and indeed LuckyCyborg is right to add those two '-' in sddm-greeter. I also got rid of the tabbed spacing and used actual spaces instead.

/etc/pam.d/sddm

Code:

#%PAM-1.0

auth       substack     system-auth

# Uncomment this line to restrict login to users with a UID greater
# than 999 (in other words, don't allow login for root):
#auth       required     pam_succeed_if.so        uid >= 1000 quiet

-auth      optional     pam_gnome_keyring.so
-auth      optional     pam_kwallet5.so
auth       include      postlogin

account    include      system-auth

password   substack     system-auth
-password  optional     pam_gnome_keyring.so     use_authtok
-password  optional     pam_kwallet5.so          use_authtok

session    optional     pam_keyinit.so           force revoke
session    substack     system-auth
session    required     pam_loginuid.so
-session   optional     pam_gnome_keyring.so     auto_start
-session   optional     pam_kwallet5.so          auto_start
session    include      postlogin

/etc/pam.d/sddm-autologin

Code:

#%PAM-1.0
auth       requisite    pam_nologin.so
auth       required     pam_env.so
auth       required     pam_shells.so

# Uncomment this line to restrict autologin to users with a UID greater
# than 999 (in other words, don't allow autologin for root):
#auth       required     pam_succeed_if.so        uid >= 1000 quiet

auth       required     pam_permit.so
-auth      optional     pam_gnome_keyring.so
-auth      optional     pam_kwallet5.so

account    include      system-auth

password   include      system-auth

session    substack     system-auth
session    required     pam_loginuid.so
session    optional     pam_ck_connector.so      nox11
-session   optional     pam_gnome_keyring.so     auto_start
-session   optional     pam_kwallet5.so          auto_start
session    include      postlogin

/etc/pam.d/sddm-greeter

Code:

#%PAM-1.0

# Load environment from /etc/environment and ~/.pam_environment
auth       required     pam_env.so

# Always let the greeter start without authentication
auth       required     pam_permit.so

# No action required for account management
account    required     pam_permit.so

# Can't change password
password   required     pam_deny.so

# Setup session
session    required     pam_unix.so
-session   optional     pam_systemd.so
-session   optional     pam_elogind.so

mlangdn · 05-22-2020, 03:26 PM

@LuckyCyborg and @gegechris99 - thanks for the tips and configs. My unprivileged user has the autologin back. Root will never have an autologin on my box. Just sounds so wrong.

@Alien Bob - I don't use kdewallet (at least I don't think I do), so I'll have to research and see what it even is..... But thanks for the new configs. I gotta check out kdewallet.

Alien Bob · 05-22-2020, 03:42 PM

Quote:

Originally Posted by mlangdn

I don't use kdewallet (at least I don't think I do), so I'll have to research and see what it even is..... But thanks for the new configs. I gotta check out kdewallet.

One example: Chromium stores the passwords you want it to remember encrypted in the KDE Wallet if you launch the browser in a KDE session. But when it starts up, it needs to open the wallet before it can access those cached passwords. You'll have to type the wallet password before you can use the browser.
The pam-ified KDE Wallet can be automatically opened when you login, and when Chromium starts it has immediate access to the wallet and won't ask for a password.
One password less to enter, to me is a win.

gegechris99 · 05-22-2020, 04:01 PM

Quote:

Originally Posted by Alien Bob

The pam-ified KDE Wallet can be automatically opened when you login, and when Chromium starts it has immediate access to the wallet and won't ask for a password.
One password less to enter, to me is a win.

Yes but only if the kdewallet password is the same as the user login password.
My remark is not a critism of the PAM files for SDDM auto-starting kdewallet at login (I found a workaround for my use case here).
I fully understand that the proposed configuration can be a win for most users. It's just of clarification to avoid any disappointment down the road.

Or will this line in /etc/pam.d/sddm, force the kdewallet password to be the same as the user login password the next time the user password is changed?

Code:

-password  optional     pam_kwallet5.so          use_authtok

GazL · 05-22-2020, 05:15 PM

Quote:

Originally Posted by Alien Bob

So, the PAM files for SDDM shown in earlier posts have a couple of things I would like to avoid/improve.
For instance, they include functionality which is already covered in the system-auth stack, and do not need to be duplicated.

I've been looking at this for a couple of days now, learning as I go along, and IMO system-auth is doing too much. It's supposedly the common config that everything uses, but some stuff in it like gnome_keyring, nologin, pam_groups etc really only want to be done at the entry-point and not for anything that might need to run through authentication to for example check a password (like xscreensaver).

Also, I feel bits of it are actually broken.

example 1:

Code:

auth        required      pam_env.so                                                                                       
auth        optional      pam_group.so                                                                                     
auth        sufficient    pam_unix.so likeauth nullok                                                                      
auth        required      pam_deny.so                                                                                      
auth        optional      pam_gnome_keyring.so

Use of 'sufficient' on pam_unix.so will mean that on a successful password authentication the stack terminates early. pam_gnome_keyring.so never gets run, nor will anything after the include in the calling service's auth stack. The only time gnome_keyring gets run here is after a failed password is entered, which is the opposite of what you want to happen.

example2:

Code:

account     required      pam_time.so                                                                                      
account     required      pam_unix.so                                                                                      
account     sufficient    pam_succeed_if.so uid < 100 quiet
account     required      pam_permit.so

... again, note that a successful return on a 'sufficient' causes the stack to terminate early. So what this is saying is "if uid < 100 return success, else return success", which is just pointless.

example 3:
nologin is checked in system-auth and in many of the service's individual configs, so there's a double dip. I think it should be removed from system-auth.

This is how I fixed it:

system-auth:

Code:

#%PAM-1.0
#
# Most of these PAM modules have man pages included, like 
# pam_unix(8) for example.
#

##################
# Authentication #
##################
#
auth        required    pam_env.so user_readenv=0
auth        required    pam_unix.so likeauth nullok

##################
# Account checks #
##################
#
# Enable restrictions by time, specified in /etc/security/time.conf
# This is equivalent to PORTTIME_CHECKS_ENAB on login.defs
#
account     required      pam_time.so           
account     required      pam_unix.so

#############################
# Password quality checking #
#############################
#
# Please note that unless cracklib and libpwquality are installed, setting
# passwords will not work unless the lines for the pam_pwquality module are
# commented out and the line for the traditional no-quality-check password
# changing is uncommented.
#
# The pam_pwquality module will check the quality of a user-supplied password
# against the dictionary installed for cracklib. Other tests are (or may be)
# done as well - see: man pam_pwquality
#
# Default password quality checking with pam_pwquality. If you don't want
# password quality checking, comment out these two lines and uncomment the
# traditional password handling line below.
password    requisite     pam_pwquality.so minlen=6 retry=3
password    sufficient    pam_unix.so nullok sha512 shadow minlen=6 try_first_pass use_authtok

# Traditional password handling without pam_pwquality password checking.
# Commented out by default to use the two pam_pwquality lines above.
#password    sufficient    pam_unix.so nullok sha512 shadow minlen=6

# ATTENTION: always keep this line for pam_deny.so:
password    required      pam_deny.so

#########################
# Session Configuration #
#########################
#
# This applies the limits specified in /etc/security/limits.conf
#
session     required      pam_limits.so
session     required      pam_unix.so

login:

Code:

#%PAM-1.0
auth            requisite       pam_nologin.so
auth            required        pam_securetty.so
# To set a limit on failed authentications, the pam_tally2 module
# can be enabled. See pam_tally2(8) for options.
#auth            required        pam_tally2.so deny=4 unlock_time=1200
auth            include         system-auth
auth            optional        pam_group.so
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         required        pam_loginuid.so
#session         optional        pam_ck_connector.so nox11

xdm:

Code:

#%PAM-1.0
auth		requisite	pam_nologin.so
auth		include		system-auth
auth            optional        pam_group.so
-auth           optional        pam_gnome_keyring.so
account		include		system-auth
password	include		system-auth
session		include		system-auth
session		required	pam_loginuid.so
-session	optional	pam_ck_connector.so

I moved nologin to auth from account so that the user doesn't need to pointlessly enter a password when his login is going to be refused anyway. I also changed it to requisite as there's no point continuing with the stack if the nlogin check fails.

It's still a work in progress, but it gives you an idea of how I'm approaching it.

I think pam_env probably needs to move out of system-auth to and into the individual service configs, but I'm still thinking on that one.

I'm also still considering gnome_keyring on the session stack. I've removed it above as I'm wondering whether its better to start if from Xsession rather than rely on the session stack in PAM.

I have a second set of config files which are more radically different to these, where I created a system-entrypoint, which is called by things like login, xdm, sshd and which in turn calls system-auth, but I thought it best to just share the less different ones that directly address problems in the existing configs.

Anyway, as I said, work in progress, but maybe some of this might be useful feedback, or at least present some areas that might need a little attention.

GazL · 05-22-2020, 05:21 PM

Oh, and while I think about it 'other' could do with some warns

other:

Code:

#%PAM-1.0

auth       required     pam_warn.so
auth       include      system-auth
account    required     pam_warn.so
account    include      system-auth
password   required     pam_warn.so
password   include      system-auth
session    required     pam_warn.so
session    include      system-auth

LuckyCyborg · 05-22-2020, 05:52 PM

Hello! I strongly believe that all those PAM configs must be treated as, well... configs!

Then, to NOT be overridden by a package upgrade or reinstall, like SDDM package did!