PAM about to be merged in -current

rkelsen · 05-19-2020, 07:49 PM

Quote:

Originally Posted by LuckyCyborg

Yes, I agree - it's common sense, but a Microsoftian common sense.

So, you lock the software from my own computer, offering me limited rights to use my own computer, considering that you know better than me what is better for me?

No, no... You're looking at this the wrong way. It's not about controlling you nor is it about protecting you from yourself.

It's about security. You're leaving the door open.

Quote:

Originally Posted by LuckyCyborg

A friend of mine, who use Fedora, was kind to take a look to our PAM files for SDDM, and he given me the configs bellow.

I'd be extremely cautious using any scripts or configs designed to bypass basic security. But YMMV as they say!

USUARIONUEVO · 05-19-2020, 08:03 PM

Quote:

Originally Posted by mlangdn

The config file /etc/pam.d/kde-np does not exist. Creating this file and populating with

Code:

#%PAM-1.0
# Begin /etc/pam.d/kde-np

auth     requisite      pam_nologin.so
auth     required       pam_env.so

auth     required       pam_succeed_if.so uid >= 1000 quiet
auth     required       pam_permit.so

account  include        system-account
password include        system-password
session  include        system-session

# End /etc/pam.d/kde-np

did nothing to help. I suppose that plasma-workspace needs to be rebuilt with this added.

Quote:

Originally Posted by volkerdi

Presumably as a safety feature, /etc/pam.d/kde-np contains uid >= 1000. Remove that part of the line and try it again.

thats for the stock kde4 ...

from changelog

Quote:

+--------------------------+
Mon May 18 23:30:26 UTC 2020
d/Cython-0.29.18-i586-1.txz: Upgraded.
kde/kde-workspace-4.11.22-i586-8.txz: Rebuilt.
Added /etc/pam.d/kde-np to fix KDM autologin.
Thanks to USUARIONUEVO for the bug report.
l/gnu-efi-3.0.12-i586-1.txz: Upgraded.
+--------------------------+

the plasma-workspace package , need provide some similar file ... and play with it.

Richard Cranium · 05-19-2020, 10:02 PM

Quote:

Originally Posted by mlangdn

The config file /etc/pam.d/kde-np does not exist. Creating this file and populating with

Code:

#%PAM-1.0
# Begin /etc/pam.d/kde-np

auth     requisite      pam_nologin.so
auth     required       pam_env.so

auth     required       pam_succeed_if.so uid >= 1000 quiet
auth     required       pam_permit.so

account  include        system-account
password include        system-password
session  include        system-session

# End /etc/pam.d/kde-np

did nothing to help. I suppose that plasma-workspace needs to be rebuilt with this added.

Your mirror hadn't been updated when you posted this.
From the kde-np that I installed from my -current mirror....

Code:

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

auth       required     pam_succeed_if.so uid >= 1000 quiet
auth       required     pam_permit.so

account    include      system-auth
password   include      system-auth
session    include      system-auth

Thom1b · 05-19-2020, 10:10 PM

Hi,

Quote:

a/shadow-4.8.1-x86_64-8.txz: Rebuilt.
It seems that /etc/suauth is not supported when PAM is in use, even if
configure.ac is hacked to enable it. I've removed the man pages for it,
and would suggest using sudo as a replacement.

Now if you don't want all users to be able to "su" as root (except users from wheel group), you can uncomment this line in "/etc/pam.d/su" :

Code:

auth           required        pam_wheel.so use_uid

Richard Cranium · 05-19-2020, 10:49 PM

Quote:

Originally Posted by rkelsen

^ That answers that.

While I generally prefer Eric's approach (i.e. It's not smart, but I won't stop you), I think in this case they're correct. If you learn how to use it properly, then you shouldn't ever need to log in to the GUI as root anyway.

That's not arrogance, it's common sense.

That aside, there are several work arounds for this "limitation."

There is need and there is want.

The "there is need" crowd are control freaks; good for corporate environments (I guess).

I almost always log in as a lesser user and then su - as root in a terminal to do something. Other times I'm in a fucking hurry and want to log in as root in a graphical environment. I view it as arrogance to tell me that I cannot do that on systems that I totally own.

Alien Bob · 05-20-2020, 12:50 AM

Quote:

Originally Posted by USUARIONUEVO

The plasma-workspace package , need provide some similar file ... and play with it.

So? Plasma5 is not part of Slackware, and I am not going to waste time fixing your private distro. If you have a fix and share that, I will use it.

rkelsen · 05-20-2020, 02:22 AM

Quote:

Originally Posted by Richard Cranium

There is need and there is want.

You want less security? If you're hacked, you want the attacker to have 100% control of your computer?

Quote:

Originally Posted by Richard Cranium

I almost always log in as a lesser user and then su - as root in a terminal to do something.

Perfect. That's exactly as you should do it.

Quote:

Originally Posted by Richard Cranium

Other times I'm in a fucking hurry and want to log in as root in a graphical environment.

How much time has this saved you so far? Am I missing something here?

Quote:

Originally Posted by Richard Cranium

I view it as arrogance to tell me that I cannot do that on systems that I totally own.

I view it as arrogance to tell unpaid developers how they should write their software... especially when they're doing it that way for your own benefit.

USUARIONUEVO · 05-20-2020, 02:45 AM

Quote:

Originally Posted by Alien Bob

So? Plasma5 is not part of Slackware, and I am not going to waste time fixing your private distro. If you have a fix and share that, I will use it.

your confused , i never install your plasma ... some one ask for SDDM , from plasma packages..not me.

then , i write , can try , play with some similar file for sddm ... if have or not , is not my problem.

sddm , is from your packages ... i no want fix , only help user ask for sddm
https://alien.slackbook.org/ktown/cu...64/kde/plasma/

https://www.linuxquestions.org/quest...ml#post6125093

calm down , and read slow ... understand ..and write later.

im not interested in plasma for now .. only when go under /current offical.

And as a little point ... my private distro , like you say , is more..much more old than yours ... i never say nothing, cause im here to help , not for lost time.

the first registered under distrowatch , is not the first obviously ..but 2012-12-22
https://distrowatch.com/table.php?distribution=wifislax

Didier Spaier · 05-20-2020, 02:47 AM

[useless, deleted]

Alien Bob · 05-20-2020, 02:54 AM

Quote:

Originally Posted by LuckyCyborg

Yes, I agree - it's common sense, but a Microsoftian common sense.

So, you lock the software from my own computer, offering me limited rights to use my own computer, considering that you know better than me what is better for me?

It's funny when you think it limits your rights to use your computer if you are not able to login the X session as root. You can simply become root afterwards in an X terminal and run any program you need to run as root. You can do everything you want to do that way. It's called security by design.
You are also confused about the Microsoftian approach to admin access - did you ever see a UAC prompt? This is largely the same as what I described for a Linux X session, but we use "sudo -i" instead.

ZhaoLin1457 · 05-20-2020, 03:40 AM

Quote:

Originally Posted by LuckyCyborg

A friend of mine, who use Fedora, was kind to take a look to our PAM files for SDDM, and he given me the configs bellow.

/etc/pam.d/sddm

Code:

#%PAM-1.0

auth       include      system-auth
auth       include      postlogin

account    include      system-auth

password   include      system-auth

session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_keyinit.so force revoke
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_permit.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

/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

Considering that he made them in no more than 10 minutes, there's no guaranty about consistency or inner security.

BUT with those configs, the SDDM looks like working fine both as autologin to whatever user including root, and as manual root login.

Feel free to test them, AFTER YOU DID A BACKUP OF YOUR ORIGINAL FILES.

Still, we talk about PAM here - a thing which have no remorse to lock you out.

Thanks!

With those configuration files I was able to autologin to my user account via SDDM, after doing a full upgrade of Slackware and KTown.

I managed also to login manually as root, but I do not tried also the autologin as root.

Looking at those config files, in my inexperienced sight looks like the changes present on them are largely borrowed from the KDE counterparts and removing support for keyrings, systemd and elogind.

Basically, we have /etc/pam.d/kde -> /etc/pam.d/sddm and /etc/pam.d/kde-np -> /etc/pam.d/sddm-autologin while /etc/pam.d/sddm-greeter presents just the deletion of systemd and elogind lines.

As I have little experience on PAM configuration under Slackware, I am unable to evaluate how secure is your configuration for SDDM, but looks like we have something functional for its purposes, and would be interesting to gradually add back the original features like the keyrings support, to see where the breaks appears.

LuckyCyborg · 05-20-2020, 05:31 AM

There's the second incarnation of the PAM config files for SDDM, made by my friend - at my request to help me to deal with the brand new and written from scratch configuration of PAM from Slackware.

I would like to note that he's also my neighbor then I know him personally, and at least for me, he's a benign guy with no hidden agenda...

This time he tried to be as much Slackwarian as he can, regarding the SDDM configuration.

Code:

#%PAM-1.0

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

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

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

Yep, the keyrings are back.

Also, my friend likes to note that he entrusted here the authentication, account and sessions management right to the unmodified system authentication: system-auth. Then, the whole thing is as much secure as the Slackware's system authentication is.

Code:

#%PAM-1.0

auth       requisite    pam_nologin.so
auth       required     pam_env.so
#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    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

Please note the red marked line - if you feel insulted (and your feelings wounded) by the SDDM's ability to autologin as root, you have just to uncomment this line, then only the ordinary users are accepted for autologin. Also, even the keyrings are back too!

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

Yep, even the support for systemd sessions is back!

Have fun and do not forget to backup your original config files!

LuckyCyborg · 05-20-2020, 06:23 AM

Quote:

Originally Posted by rkelsen

I view it as arrogance to tell unpaid developers how they should write their software... especially when they're doing it that way for your own benefit.

Locking me away from the highest privileged level is certainly not for my own benefit, but a limitation of my rights as computer owner.

Sorry, probably is just a cultural conflict, but as someone born, raised as Russian and living his entire life in the Russian Federation, I cannot appreciate that enforcing of my rights limitation on something which is my own property: my own computer.

Also, I cannot help to not remember that the Schutzstaffel (SS troops) was formed exclusively from (unpaid) volunteers...

Being a volunteer does not make you automatically right in everything you truly think is right and specially does not gives you the rights to enforce your own rules to others.

denydias · 05-20-2020, 06:36 AM

Quote:

Originally Posted by LuckyCyborg

Being a volunteer does not make you automatically right in everything you do and does not gives you the rights to enforce your own rules to others.

R u talking about Brazil? You just described the far-right "volunteers" here.

Anyway, thanks a bunch to your NSA/CIA spy neighbor for these lovely PAM bits!

kikinovak · 05-20-2020, 06:51 AM

Quote:

Originally Posted by LuckyCyborg

Yes, I agree - it's common sense, but a Microsoftian common sense.

So, you lock the software from my own computer, offering me limited rights to use my own computer, considering that you know better than me what is better for me?

There seems to be some sort of Second Amendment popular among a vocal minority of Linux users, defending the Right To Login As Root In A GUI as well as the Right To Shoot Oneself In The Foot Big-Time.