Ouch, missed a sentence in my post “So yes, giving this info only to those reading the testing release announcements is sub-optimal.” Re-added it! Thanks.
But again, I think that manually installing a kernel from the testing branch is better. When stable is updated, that kernel is going to automatically realign to stable and you will run no risk of remaining with the “temporary fix” in place forever.
I’ve been using a test branch on my laptop for some time and a stable one on my main PC, yes, indeed, the test branch behaves stably according to my observations, but it’s not for nothing that it’s called a test branch) Although it is in the stable branch that I encounter problems more often.
1 Like
You need root privileges, because nothing under /etc is writable to unprivileged user accounts.
2 Likes
awesome thanks and how do you reverse this once the new patched kernel arrives? My linux Fu is still weak… 
sudo rm /etc/modprobe.d/disable-algif.conf
And reboot into the new kernel.
2 Likes
Remote access is not local access. Local is physical access.
Also, regarding branch, I’ve my main computer and family laptops on Testing. I usually update mine (so they don’t have down time) then theirs. It’s been a fairly solid experience for the past couple of years since my switch to Linux.
Ok so maybe a stupid question. I run dual boot testing and stable. I have testing on 7.1.0rc1-1 which so far runs fine and according to philm’s earlier post that said all after 7.0-rc7 was patched. In stable I dont see anything past 7.0-rc4 available. While I was more concerned about the “stable isnt going to be updated for a while” post earlier in this thread, I dont see how to get 7.0-rc7 or anything later over to stable, So far the 7.1 kernel is running fine in testing but I am loath to upgrade stable to testing. Thanks.
Question, I’ve recently switched from stable to testing branch and have snagged all the latest updates. My Kernel is still on version 6, the latest LTS version. I have no problems with that; but should switching to Testing have also updated my Kernel to the latest release vs staying on the LTS version? Or are my updates working as intended?
Switching to testing does not affect your kernel series selection (6.18-LTS, I guess) but you will receive the latest release considering your branch, i.e. 6.18.26 at the moment for testing branch.
1 Like
How many users do you have on your computer? If only you, then the only user capable of performing the copy-fail exploit, is you. Are you thinking about doing it?
1 Like
No. Once you are authenticated and have a shell/session on the machine via SSH, you are effectively a local user for purposes of a local privilege escalation vulnerability.
In vulnerability terminology, local usually means the attacker already has the ability to run code or commands on the target system as some user.
Copy fail is exploitable by a malicious user that has an account and who can connect to this unprivileged account over ssh.
2 Likes
So anyone can ssh into your computer, as that unprivilaged user.
Why anyone? You have a host on which you have configured 10 users, because 10 people need to work on that host. Now assume that all those 10 users have ssh access because most of the time they work on the host remotely. Only them (not anyone!) can log in via ssh. But that does not make an LPE vulnerability less serious. With copy-fail each of these users can potentially “convert” their regular account into a privileged one.
Because the ““Copy Fail” Linux kernel flaw lets local users gain root in seconds” it basically removes the distinction between regular users and root, regardless of the fact that these users have physical access or only ssh access. So, whoever is administering a host with multiple users where the distinction between the administrator and the users must be enforced can worry.
2 Likes
So, you have 10 people who can log in to your computer. Yes, that could be a problem, if any of them are untrustworthy.
Well, that is the very idea of a multiuser operating system: you can have multiple users, all with their separated working areas (homes), etc. and the operating system manages their “privilege” (i.e., their possibility of doing things) in such a way that — at least in principle — the system integrity is preserved even if some user is not fully trustworthy and no one can mess with some other data. In fact, the assumption in multiuser systems like Unix (and thus Linux) is that no user should be considered trustworthy by default (in other words, the OS should not rely on the idea that it can trust its users).
LPE specifically hints at the fact that there is a problem that lets users escape the limits set in place by the OS about the privilege they get (what they can and what they cannot do).
LPE vulnerabilities are a problem even if the users are not malicious. For instance a user (even yourself, when you are the sole user) may get convinced to run some random software he/she found on the net and do that in 100% good faith. Now, that software runs with user privilege. But if it is malicious and designed to exploit the vulnerability it can get root privilege and then use that privilege to create damage.
A chat with an LLM can tell you more if you are interested.
2 Likes
Yes you are absolutely correct about Linux/Unix and indeed other Multi user Operating Systems.
My original question to you was
“How many users do you have on your computer?”
I did not ask how many users CAN be configured to log in on a Linux or Unix operating system.
It depends on what you mean by “my computer.” On the computers I own and use daily, the number is very small, for example to let members of my family use the same machine without using my account. On systems I do not own, such as lab machines, the number may be much larger.
In fact, even if you are just a regular user on a multiuser system administered by someone else, an LPE vulnerability can still create problems for you. If another user exploits it and gains elevated privileges, they may be able to access or modify your data, interfere with your work, steal credentials or tokens, or impersonate you on that system or others (with stolen credentials).
2 Likes
Thank you. Finally, I understand what your problem is.
So, I take it you are responsible for a number of computers that are running Manjaro Linux stable, that can be used by multiple people. It’s not just your personal computer, with, just you using it.
Yes, now, I can understand your concerns.
Well, I got worried even for my personal computer, given that I cannot be 100% sure that some member of my family will not run (in perfect good faith) some random software and for systems for which I am responsible. And somehow I am also worried about systems on which I am a mere user. On the systems where I have admin power, I can apply fixes (e.g. on my Manjaro PC now I am running kernel 6.18.26, while remaining on stable). On systems I work on and do not administer, I must wait for the fixes to come through stable channels or hope in the administrators being proactive.
2 Likes
You can install a particular Kernel branch via pamac (GUI, search “linux70” for 7.0.x), pacman (CLI) or Manjaro Settings Manager. Rebooting should boot into the latest installed, if not you can usually bring up grub at boot by pressing 'Esc' after the BIOS splash screen.
If I’m incorrect or one is preferred over another, please let me know