SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
While the focus is on user authentication and what have you, can I suggest commenting out CONSOLE_GROUPS in the shipped login.defs. It's a pretty archaic mechanism and I'm not convinced assigning groups like 'floppy' or 'lp' to a user just because they logged in on a virtual console was ever a good idea.
I've had it commented out for years.
Last edited by GazL; 02-12-2020 at 08:47 AM.
Reason: typo
While the focus is on user authentication and what have you, can I suggest commenting out CONSOLE_GROUPS in the shipped login.defs. It's a pretty archaic mechanism and I'm not convinced assigning groups like 'floppy' or 'lp' to a user just because they logged in on a virtual console was ever a good idea.
I've had it commented out for years.
Not going into security concerns, but those made my life much easier in interacting with stuff in console (run level 3)
They are just roff .so requests and don't really need compressed.
Maybe you don't want to change this, but no other packages do it and
it seems strange having hidden files in /usr/man/. The non-dot versions
of the man pages are installed as well, that is what these source. So,
it seems safe to just delete them?
__________________________________________________
usr/man/man3/Git.3pm
Not going into security concerns, but those made my life much easier in interacting with stuff in console (run level 3)
The feature made sense when people either logged in on a console, or telnetted in from a remote, and where you wanted to give the local logins additional privilege, but these days local pretty much means X11 where CONSOLE_GROUPS has no effect, and you'll need to grant the user access to those groups anyway. I'm sure there could be valid uses for the feature even today, I just don't think the groups listed in the stock file make sense.
Anyway, no biggy, I just thought it was something that could be cleaned up to make things simpler. In the old days we used to get "Why can I play audio on the console and not from X11?" questions, and it was always because of CONSOLE_GROUPS. It just confused people who weren't aware of the feature.
The feature made sense when people either logged in on a console, or telnetted in from a remote, and where you wanted to give the local logins additional privilege, but these days local pretty much means X11 where CONSOLE_GROUPS has no effect, and you'll need to grant the user access to those groups anyway. I'm sure there could be valid uses for the feature even today, I just don't think the groups listed in the stock file make sense.
There could be some cleanup, but I confirm that at least some Slint users never start an X server. I also had a request a few days ago for a "console only" Slint edition.
i have it build here, but unfortunately i can't provide mate-power-manager 1.24.0 as it requires newer upower as it's core dependency. I will provide binaries when newer upower comes out and that's probably the day when Plasma 5 is included in -current.
master branch in git has been updated to 1.24.x already
Hmm, I run subsets of Mate under XFCE and OpenBox/LXDE so the power manager should not be an inhibitor.
I "crash built" (ignoring errors) 1.24 from git:
-- the power manager turned out to still be the 1.22 version.
-- e.g. atril failed -- so I kept the 1.22 version.
/usr/bin/chsh seems to have lost its suidness in the new PAMified shadow package meaning non-root users can no longer change their login shell with it. Is this an intentional change or something that slipped through?
/usr/bin/chsh seems to have lost its suidness in the new PAMified shadow package meaning non-root users can no longer change their login shell with it. Is this an intentional change or something that slipped through?
Add this as line #2 of /etc/pam.d/chsh:
Code:
auth sufficient pam_shells.so
I won't promise that it's the best/only solution, but it works :-)
It is now possible[1] to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K. For this reason, we will be
disabling the "ssh-rsa" public key signature algorithm by default in a
near-future release.
This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs.
The better alternatives include:
* The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
algorithms have the advantage of using the same key type as
"ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
supported since OpenSSH 7.2 and are already used by default if the
client and server support them.
* The ssh-ed25519 signature algorithm. It has been supported in
OpenSSH since release 6.5.
* The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These
have been supported by OpenSSH since release 5.7.
To check whether a server is using the weak ssh-rsa public key
algorithm, for host authentication, try to connect to it after
removing the ssh-rsa algorithm from ssh(1)'s allowed list:
ssh -oHostKeyAlgorithms=-ssh-rsa user@host
If the host key verification fails and no other supported host key
types are available, the server software on that host should be
upgraded.
A future release of OpenSSH will enable UpdateHostKeys by default
to allow the client to automatically migrate to better algorithms.
Users may consider enabling this option manually.
[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf
Security
========
* ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa"
(RSA/SHA1) algorithm from those accepted for certificate signatures
(i.e. the client and server CASignatureAlgorithms option) and will
use the rsa-sha2-512 signature algorithm by default when the
ssh-keygen(1) CA signs new certificates.
Certificates are at special risk to the aforementioned SHA1
collision vulnerability as an attacker has effectively unlimited
time in which to craft a collision that yields them a valid
certificate, far more than the relatively brief LoginGraceTime
window that they have to forge a host key signature.
The OpenSSH certificate format includes a CA-specified (typically
random) nonce value near the start of the certificate that should
make exploitation of chosen-prefix collisions in this context
challenging, as the attacker does not have full control over the
prefix that actually gets signed. Nonetheless, SHA1 is now a
demonstrably broken algorithm and futher improvements in attacks
are highly likely.
OpenSSH releases prior to 7.2 do not support the newer RSA/SHA2
algorithms and will refuse to accept certificates signed by an
OpenSSH 8.2+ CA using RSA keys unless the unsafe algorithm is
explicitly selected during signing ("ssh-keygen -t ssh-rsa").
Older clients/servers may use another CA key type such as
ssh-ed25519 (supported since OpenSSH 6.5) or one of the
ecdsa-sha2-nistp256/384/521 types (supported since OpenSSH 5.7)
instead if they cannot be upgraded.
This release includes a number of changes that may affect existing
configurations:
* ssh(1), sshd(8): the above removal of "ssh-rsa" from the accepted
CASignatureAlgorithms list.
* ssh(1), sshd(8): this release removes diffie-hellman-group14-sha1
from the default key exchange proposal for both the client and
server.
* ssh-keygen(1): the command-line options related to the generation
and screening of safe prime numbers used by the
diffie-hellman-group-exchange-* key exchange algorithms have
changed. Most options have been folded under the -O flag.
* sshd(8): the sshd listener process title visible to ps(1) has
changed to include information about the number of connections that
are currently attempting authentication and the limits configured
by MaxStartups.
* ssh-sk-helper(8): this is a new binary. It is used by the FIDO/U2F
support to provide address-space isolation for token middleware
libraries (including the internal one). It needs to be installed
in the expected path, typically under /usr/libexec or similar.
Last edited by Thom1b; 02-14-2020 at 04:45 AM.
Reason: Still supporting RSA-SHA1
# Ensure that ENV_SUPATH from /etc/login.defs is used for the $PATH when
# 'su' is used. Otherwise /sbin paths will be missing unless 'su -' is used.
ALWAYS_SET_PATH yes
The traditional way su behaves allows a user to run a process with elevated privilege in either the same execution environment as they're currently using (potentially with a custom PATH) or within a new one (appropriate to the su'd to user). This change breaks that.
Please tell me you didn't change this traditional UNIX behaviour just because some users aren't educated enough to use 'su -' or 'su -l'. If the commented explanation in the defaults file is the only reason for this change and you still feel you have to pander to these users then I'd rather you just put /sbin in the default non-root users path.
I know it's just a default, and I can easily change it back to the traditional behaviour, and I'm being overly drama-queeny with this post, but I really have to question the wisdom of this one. Though it's only a small thing, it's an attack on the whole "Slackware is the most UNIX-like Linux distro" stance, and that really bothers me.
I won't promise that it's the best/only solution, but it works :-)
Thanks Robby, I'll look into that, but how would that help? the logged in user's chsh still won't have write access to /etc/passwd to change the field. Is there some sort of suid helper that chsh uses to rewrite the passwd file entry?
edit: ok didn't work. looks like chsh needs to be suid, and the chsh pam file needs
Code:
auth sufficient pam_permit.so
instead of pam_rootok.so in order to work properly. non root user can still only change their own shell with the above.
P.S. chfn is also missing SUID, but the stock pam config for it only allows root use so no one will notice unless they change it.
Thanks Robby, I'll look into that, but how would that help? the logged in user's chsh still won't have write access to /etc/passwd to change the field. Is there some sort of suid helper that chsh uses to rewrite the passwd file entry?
edit: ok didn't work. looks like chsh needs to be suid, and the chsh pam file needs
Code:
auth sufficient pam_permit.so
instead of pam_rootok.so in order to work properly. non root user can still only change their own shell with the above.
I have made the suggestion to Pat that (just like he already does for the login utility which gets added/not added to util-linux depending on whether we use PAM or not), that the PAM-ified util-linux also needs to provide su, chsh, chfn, nologin, vipw and vigr utilities instead of having them in the shadow package.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
