<username> ALL=NOPASSWD: ALL

Is this ever an option? Say you live alone, and no one else ever uses your computer…

I’m single and live alone. I still use a password. But, If I chose not to use a password, I’d have ticked that option on initial install of the OS. You can still do that in KDE’s Settings > Login Screen (SDDM) > Behavior.

2 Likes

Yes. I remember that during install. Its been a while since I had an install of Linux that way. Automatically logging in actually caused another issue, but I cant remember what it was :thinking: Anyway, I was thinking it would be handy if one could type a kb combination, and that would enable root access. I suppose one could make it as complicated as they wanted, but type the hot keys, and boom, you have root access. You could even disable it with the same, or a different kb combination.

I use it, my laptop has never left the house, it makes scripting so much easier. I do have a log-in password.

If somebody nicks it, it would need to be encrypted to be secure, which it isn’t, so anyone with a live usb can access the files on it. So what’s the point.

People say it makes it harder (with a sudo password) to trash your machine - I can confirm it doesn’t :rofl:

Woke up with a headache - so I hope that makes sense!!

I use “username” ALL=(ALL) NOPASSWD: ALL. Editing /etc/sudoers is one of the very first things that I do on a new install. I also do the auto login on boot. Not secure, but like mentioned above, I too live alone and the laptops never leave home.

That is completely irrelevant to that particular change IMO.

If you allow sudo without a password, it means that any unprivileged compromise instantly becomes a root compromise. In other words, the security implications have nothing to do with who else has physical access to your device.

It is your machine. If you don’t care about the security of your data, there is no reason to worry about things like passwords at all.

2 Likes

In this case I think I can rely on all the good folks who are the Linux community to be my watchdogs when it comes to nefarious software. Im doing nothing out of the ordinary using the same software as most others. What I am doing is something blasphemous though. Disabling security in Linux. I should be blindfolded, and shot at dawn. I know.

1 Like

Nefarious software isn’t really the biggest risk. The larger risk is tied to an outside party exploiting a bug or a vulnerability. This is a pretty real risk. Have you ever looked at how many critical security flaws are found in basically every web browser?

What it comes down to, is how much you care about your data.

Is losing access all your data a problem for you? Likewise, if the data you have on your machine became stolen, would that be a problem for you?

If the answer to those questions is “no” then you can probably afford to run with lower security. If the answer is “yes” then you are just closing your eyes to what is a real risk and pretending it doesn’t exist.

Security is often one of those things that people don’t pay attention to until it becomes a problem for them. The challenge is that once it does, it is often too late and the consequences can be pretty severe.

1 Like

I guess that would apply also if one runs a couple of specific commands which requires sudo without password. I have a couple of them in /etc/sudoers.d/pebcak :worried:

It would, yes. Although, the risk level would depend on what those specific commands were.

I have actually a few of them: pacman, systemctl, modprobe, rmmod and some more :man_facepalming:t5:

Well it was really nice knowing you.

3 Likes

Why wait until dawn? :gun:

I am pretty sure both pacman and systemctl could be used to run an arbitrary command as root.

I am not sure if I understand this correctly:

Let’s say pacman has an unprivileged compromise. So running pacman -Si X should not compromise the system as pacman is not running in root mode.

However, if I run sudo pacman -S X, then the unprivileged compromise could be problematic.

What does it matter if I have to give the password or if it is configured to run without?

In both cases, pacman will run in elevated root mode.

Please correct me if my understanding is erroneous!

I considered it once, but no it’s too risky. Picture this scenario, you run a script you downloaded from somewhere, or a script u made yourself 5 years ago and don’t quite remember in exact detail how it worked, it doesn’t even have to be a script, it could just be some small program, it throws you a sudo prompt.

If you have a password, you have time to cancel it. if you don’t have a password, it’s just gonna run with you likely not even realizing that the script did something as root, it could be anything, and it could fck up your system potentially,.

Meanwhile if you do have that password, you do get that sudo prompt, you’re thinking “huh, better read this more closely” so you cancel and you analyze just what it’s going to do as sudo before running it again.

Also programs that require root access depending on how they’re written might no longer actually request it and just take it since no password is required, which create other issues as well.

Basically it just makes you too vulnerable to never be prompted if you really wanna run something as root or not. if you solve that problem, then implementing something similar to UAC in windoze (yes/no button) would be ok i suppose.

2 Likes

Because remote code execution vulnerabilities will give someone the ability to run commands as your user but that doesn’t mean they know your password.

1 Like

How would you judge, if you were to speculate, the probability of such an attack would be if the user have firewall configured on the router and on all the systems on the network?

If I understand what you said correctly, for this sort of the attack to be successful, first there should be a vulnerability in some process running on the system and second, the system should be “wide” open for a remote attacker to take advantage of this vulnerability.

Remote code execution vulnerabilities generally wouldn’t be blocked by local or network firewalls. The compromise is effectively local and then reaches out to a remote server. Very few people would have their firewalls blocking outbound http/https traffic.

Firewalls are more effective at blocking attacks which originate outside your machine.

1 Like

Alright. So this means that one has already a malicious process executing code which then connects to a remote server? I get it!

By the way, thanks for your patience and taking your time replying!

1 Like