Re: pam 1.6.1-2 breaks sudo password
Are you sure you're not just hitting the new(old at this point) idiotic default of always failing after X failed attempts in Y time? That would mean you mistyped the password a few times, but afterwards it would not matter even if you typed it correctly. Hello. This is a response not only to the above message, but also to many down in this thread. If one has a strong passphrase configured, understands basic security, and happens to be on their local home computer, faillock may be configured to use different options. For example I have it ~turned off altogether⁽¹⁾ and so do many people in a similar situation. The defaults are meant to provide sane security in the baseline case. Not only in faillock, but with everything. One installs a package, it doesn’t do something risky by default. Sounds reasonable, doesn’t it? And in the baseline case a 15 minutes lock after 3 failed logins in 10 minutes provides between a few hours to a day delay for the adversary, giving the sys/net admin enough time to detect and react. A 15 minute lock is also reasonably tamper-evident for the baseline case user. You may dislike UX decision, but you should get used to it: because now this becomes common best practice, in particular for network-facing services. The primary reason is avoiding side channel attacks, leading to the basic secure implementation not being able to distinguish between these two cases. Even where it could be possible, per WSTG-IDNT-04 it shouldn’t be possible to make such distinction. That’s not only a security feature, but also a user privacy improvement. Please be aware, that in the model the message goes not to an authorized user. Obviously it can’t, given the authorization has failed. Which means the recipient is an actor not permitted to receive this information. The always-authorized actor is the administrator and they have access to the detailed cause: it’s in the logs. Of course one may invent an edge case, where this isn’t needed. But mere existence of such cases is not really relevant, when they are not representative of the entire landscape. So please consider changing tone a bit; cheers. ⁽¹⁾ 999 attempts, 1 s lock.
Re: pam 1.6.1-2 breaks sudo password
I noticed that pam 1.6.1-2 breaks sudo. Every time I tried to enter my password with a sudo command, it tells me my password is incorrect. Of course, it is not. Similar to what was requested in the forum thread,⁽¹⁾ please provide the output of `pacman -Qii sudo pambase`. 1.6.1-2 works here. Cheers ⁽¹⁾ https://bbs.archlinux.org/viewtopic.php?id=294814
Re: [arch-announce] Increasing the default vm.max_map_count value
On Sun, 2024-04-07 at 18:12 +, Arch Linux: Recent news updates: Robin Candau wrote: > The [vm.max_map_count][1] paramater will be increased from the > default `65530` value to `1048576`. > > This change should help address performance, crash or start-up issues > for a number of memory intensive applications, Performance improvement is unlikely but could allow something to run that otherwise would not. The lkml comment [1] is worth a read and includes : "To be clear, what you are doing here is akin to adding more memory to your system when there is a memory leak. This is not the solution you should be pushing. Ironically, this is using more memory and performing worse than it should. At best, the limit increase is a workaround for buggy programs." As Robin said, setting the max higher is probably benign - and only impacts a system running the problematic software (games). Nonetheless, it is very simple to change it to whatever value you want with your own prefs dropped into /etc/sysctl.d/xxx.conf gene [1] https://lore.kernel.org/lkml/566168554.272637693.1710968734203.Jav aMail.root@zimbra54- e10.priv.proxad.net/T/#m1905a48f415bc6e8069a8fe53dec44bc311571f2 -- Gene signature.asc Description: This is a digitally signed message part
Re: PAM 1.6 breaks limits.conf parsing
This is now released with pam 1.6.1 and shipped in Arch Linux. Pretty sure it caused my issue here - https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3532 Will see how a rebooted system behaves now. Martin On Fri, Mar 15, 2024 at 12:09 AM Martin Rys wrote: > > That explains a lot, thanks for digging into this. > > I've had pw constantly run into ulimits and failed to find out why. > > Martin > > On Thu, Mar 14, 2024, 21:19 Simone Baratta wrote: >> >> Howdy, Arch community! >> >> Today Ardour warned me that I had a ulimit enforced for locked memory, >> and indeed I was surprised to find that `ulimit -l` reported 8192 for >> my user (which I configured to `unlimited` a long time ago). After a >> bit of investigation, it turned out that this is a bug introduced by >> PAM 1.6, which fails to read my limits.conf file due to the extra >> whitespace separating entries: >> >> ``` >> @audio - memlock unlimited >> ``` >> >> This makes pam_limits.so fail with the following: >> ``` >> pam_limits(login:session): wrong limit value 'unlimited' for >> limit type '-' >> ``` >> >> Looks like this issue was introduced with [1], and indeed I can >> confirm that it's fixed by [2] which references the first commit. >> >> Is there any chance we can get a 1.6.0-5 update with this patch in? >> This version is already in core, and it's a very subtle issue which is >> likely to be unnoticed by many but come with a lot of (possibly >> security-relevant) side effects. >> >> [1] >> https://github.com/linux-pam/linux-pam/commit/eec4358a49dc0d6d699532965f453f0da240227e >> [2] >> https://github.com/linux-pam/linux-pam/commit/9228077d762fc94ebc8d9fb4edfe9b481d96318d >> >> Thanks! >> >> -- >> Simone
Re: pam 1.6.1-2 breaks sudo password
On 2024-04-12 at 13:59:08 +0100, Andy Pieters wrote: > On Fri, 12 Apr 2024 at 13:53, Martin Rys wrote: > > > > It's common practice to not give an attacker more info than needed > > > > Which does not necessitate LYING to the user. In the old days, login(1) used to try to be helpful by separating bad usernames from bad passwords. Because that's bad for security, bad implementations changed to "login failed," but good implementation changed to "bad username or password" and also referenced the caps lock and/or num lock keys. The difference is subtle, but a huge win for usability, and not a loss for security. > I think we're a bit over-reacting here. I've fallen foul of this myself > also, trying to log into my X not realising that my keyboard layout wasn't > applied correctly. That's a different class of problem, although very much on a likely path to getting locked out. At least my screen locker is nice enough to tell me the state of my caps lock key, and it could tell me the keyboard layout, too, if I hadn't disabled it. Some display managers have similar capabilities. Fans of Windows used to say that Unix was like a car whose dashboard contained nothing, until something (anything) went wrong, and then displayed a flashing red question mark. > But I'm actually in favour restricting the amount of login attempts that > can be done, as it is in line with PCI/DSS practices and although many > people won't know what that means, just consider them best-practices. Many of those practices make a lot of assumptions that don't apply to my laptop, of which I am the only user, and which nearly never leaves my physical possession. Yes, it's connected to the internet, and yes, it could be stolen (from my couch, from a hotel room, inside my backpack, etc.), but best practices for a semi-public or corporate shared server are much different from best practices for my non-shared, effectively single-user laptop. > The implementation of these timeouts don't provide a method for sending an > extra message to the user as to why their login attempt failed, but Linux > is open source, so feel free to submit proposals and pull requests to make > it more to your liking :-P Someone already posted a link to a config file that makes a personal computer behave more like a personal computer. So all we're talking about here (I think) is tweaking the settings for your particular needs.
Re: pam 1.6.1-2 breaks sudo password
On Friday, 12 April 2024 at 13:59 (+0100), Andy Pieters wrote: The implementation of these timeouts don't provide a method for sending an extra message to the user as to why their login attempt failed, but Linux is open source, so feel free to submit proposals and pull requests to make it more to your liking :-P In fact, when you attempt to log in from the console while a fail lock has been activated, there is a message printed informing the user that they have used too many password attempts. It even reports the amount of time left on the lock. I guess that it is up to individual applications that use PAM authentication to find out why their authentication request has been denied, and then decide to tell the user. Having the fail lock refuse authentication using the same API as a wrong password at least provides backwards compatibility for an application like sudo that hasn't added this feature (or has decided not to add it). Best, Jaron
Re: pam 1.6.1-2 breaks sudo password
On Fri, 12 Apr 2024 at 13:53, Martin Rys wrote: > > It's common practice to not give an attacker more info than needed > > Which does not necessitate LYING to the user. > > I think we're a bit over-reacting here. I've fallen foul of this myself also, trying to log into my X not realising that my keyboard layout wasn't applied correctly. But I'm actually in favour restricting the amount of login attempts that can be done, as it is in line with PCI/DSS practices and although many people won't know what that means, just consider them best-practices. The implementation of these timeouts don't provide a method for sending an extra message to the user as to why their login attempt failed, but Linux is open source, so feel free to submit proposals and pull requests to make it more to your liking :-P
Re: pam 1.6.1-2 breaks sudo password
> It's common practice to not give an attacker more info than needed Which does not necessitate LYING to the user. A static "Password wrong or login timeout in effect " would also be infinitely better. Martin On Fri, Apr 12, 2024 at 2:25 PM Georg Pfahler wrote: > > Hi there, > > On Fri, Apr 12, 2024 at 11:36:43AM +0200, Martin Rys wrote: > > > FYI, the "idiotic default" may feel less annoying when you use the > > > documented solution > > > > Would be great if one got this as an error message when the logins > > start timing out. > > > > Unfortunately that's not the case, the UX is beyond terrible, you get > > the same identical error for a WRONG password as for the TIMED OUT > > password, making people waste time and be frustrated to the point of > > going on mailing lists. > > It's common practice to not give an attacker more info than needed, so > "wrong password" and "locked user" is most likely intended to give the > same error message. > > -- > Georg
Re: Building qt-5 packages from PKGBUILD
El jueves, 11 de abril de 2024 3:19:50 (CEST), Pocket escribió:
> In the qt5-* PKGBUILD most fail due to the wrong directory
>
> For example in qt5-tools:
>
> Build function
>
> qmake ../${_pkgfqn} CONFIG+=fat-static-lto
>
> should be
>
> qmake ../kde-${_pkgfqn} CONFIG+=fat-static-lto
Should be fixed now.
Re: pam 1.6.1-2 breaks sudo password
Hi there, On Fri, Apr 12, 2024 at 11:36:43AM +0200, Martin Rys wrote: > > FYI, the "idiotic default" may feel less annoying when you use the > > documented solution > > Would be great if one got this as an error message when the logins > start timing out. > > Unfortunately that's not the case, the UX is beyond terrible, you get > the same identical error for a WRONG password as for the TIMED OUT > password, making people waste time and be frustrated to the point of > going on mailing lists. It's common practice to not give an attacker more info than needed, so "wrong password" and "locked user" is most likely intended to give the same error message. -- Georg signature.asc Description: PGP signature
Re: pam 1.6.1-2 breaks sudo password
> FYI, the "idiotic default" may feel less annoying when you use the documented solution Would be great if one got this as an error message when the logins start timing out. Unfortunately that's not the case, the UX is beyond terrible, you get the same identical error for a WRONG password as for the TIMED OUT password, making people waste time and be frustrated to the point of going on mailing lists. It serves no purpose other than a terrible protection layer for people using insecure bruteforcable passwords, but it REALLY isn't much better that instead you can just DOS user logins instead, and users do it by accident, with no information that it happened. Someone with spare time should raise some complaints on the appropriate issue trackers, if they weren't already. It's much less annoying when you revert to the old behavior and just disable it: https://gitlab.com/C0rn3j/configs/-/blob/ebac36cd8508d71a5d759b326a3c23f9c03c79f3/roles/config_misc/tasks/main.yaml#L62-75 https://gitlab.com/C0rn3j/configs/-/blob/ebac36cd8508d71a5d759b326a3c23f9c03c79f3/roles/config_misc/files/faillock.conf Martin On Fri, Apr 12, 2024 at 10:31 AM Jaron Kent-Dobias wrote: > > On Friday, 12 April 2024 at 10:10 (+0200), Martin Rys wrote: > >Are you sure you're not just hitting the new(old at this point) idiotic > >default of always failing after X failed attempts in Y time? That would > >mean you mistyped the password a few times, but afterwards it would not > >matter even if you typed it correctly. > > > >Rebooting will get you out of the timelock > > FYI, the "idiotic default" may feel less annoying when you use the > documented solution: > > $ faillock --reset > > as your user will reset the counter. So, if you make some mistypes while > invoking sudo, you can unlock use of your password instantly from the > same shell where you messed up. > > On the other hand, if you're locked out while logging in, before you > have access to a shell, then running > > # faillock --reset --user [your username] > > as root will do the same. Note that by default root has no fail lock, so > this solution should always be possible. > > I hope this saves you a few reboots. > > Best, > Jaron >
Re: pam 1.6.1-2 breaks sudo password
On Friday, 12 April 2024 at 10:10 (+0200), Martin Rys wrote: Are you sure you're not just hitting the new(old at this point) idiotic default of always failing after X failed attempts in Y time? That would mean you mistyped the password a few times, but afterwards it would not matter even if you typed it correctly. Rebooting will get you out of the timelock FYI, the "idiotic default" may feel less annoying when you use the documented solution: $ faillock --reset as your user will reset the counter. So, if you make some mistypes while invoking sudo, you can unlock use of your password instantly from the same shell where you messed up. On the other hand, if you're locked out while logging in, before you have access to a shell, then running # faillock --reset --user [your username] as root will do the same. Note that by default root has no fail lock, so this solution should always be possible. I hope this saves you a few reboots. Best, Jaron
Re: pam 1.6.1-2 breaks sudo password
Are you sure you're not just hitting the new(old at this point) idiotic default of always failing after X failed attempts in Y time? That would mean you mistyped the password a few times, but afterwards it would not matter even if you typed it correctly. Rebooting will get you out of the timelock Can you upgrade back, try and enter it and see if it works now? Martin On Fri, Apr 12, 2024 at 9:40 AM Frederic Bezies wrote: > > Hello. > > I noticed that pam 1.6.1-2 breaks sudo. Every time I tried to enter my > password with a sudo command, it tells me my password is incorrect. Of > course, it is not. > > The "fix" was to downgrade to pam 1.6.1-1. > > Hope it helps! > > -- > Frederic Bezies > fredbez...@gmail.com > Blog: https://fredericbezies-ep.fr/blog/ >
Re: pam 1.6.1-2 breaks sudo password
Am 12.04.24 um 08:21 schrieb Frederic Bezies: > Hello. > > I noticed that pam 1.6.1-2 breaks sudo. Every time I tried to enter my > password with a sudo command, > it tells me my password is incorrect. Of course, it is not. > > The "fix" was to downgrade to pam 1.6.1-1. Both variants with and without `NOPASSWD` configured work fine on my setup with pam-1.6.1-2. Regards, Uwe > > Hope it helps! >
Re: pam 1.6.1-2 breaks sudo password
El vie, 12-04-2024 a las 08:21 +0200, Frederic Bezies escribió: > Hello. Hi! > I noticed that pam 1.6.1-2 breaks sudo. Every time I tried to enter > my > password with a sudo command, it tells me my password is incorrect. > Of > course, it is not. > > The "fix" was to downgrade to pam 1.6.1-1. > Are you absolutely sure there is nothing else? I mean, the only thing you change is that package? I comment this because what the version change from 1.6.1-1 to 1.6.1-2 does is simply add a missing dependency[1], but does not modify anything, so it seems very very very very strange to me that this could cause what you say. Greetings. [1]:https://gitlab.archlinux.org/archlinux/packaging/packages/pam/-/commit/89b5c13193d4173cd2a4c88db97e9df6ed197f90 -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me signature.asc Description: This is a digitally signed message part
pam 1.6.1-2 breaks sudo password
Hello. I noticed that pam 1.6.1-2 breaks sudo. Every time I tried to enter my password with a sudo command, it tells me my password is incorrect. Of course, it is not. The "fix" was to downgrade to pam 1.6.1-1. Hope it helps! -- Frederic Bezies fredbez...@gmail.com Blog: https://fredericbezies-ep.fr/blog/
