1
  • Given that I'm the only human who should have access to a Linux server, what are the major security risks associated with updating sudo to not require a password for my local user?
  • Are there other ways of making sudo less cumbersome without running everything as root?
    • I've already increased the timeout so I don't have to enter my password very often per session, but for other reasons I end up disconnecting several times per day.

I have a Linux server (hosted on DigitalOcean) running a fairly popular website.

My normal process is:

  • SSH into the server as michael (uses my SSH key with I've already added to my ssh-agent)
  • When I need to run something as root (to restart a service, edit cron jobs for www-data, etc):
    • I use sudo [cmd], which requires michael's password
    • I copy that password (a long random string) from my password manager and paste it into the terminal

One of my colleagues says they don't bother with a regular user account -- they always SSH as root. I'd rather NOT do that -- I like knowing that I won't accidentally cause serious problems unless I use sudo.

It would be nice, since I'm the only human who logs into this server, to SSH as a regular user but still not have to enter a password to run something as the superuser -- without substantially increasing risk.

3
  • 1
    Requiring a password prevents accidents, including running a script that you hadn't realized invokes sudo. Requiring sudo over just logging in as root gives you an audit log and keeps root's environment clean for emergencies (when you have to e.g. sudo su - without inheriting personal customizations that may have broken).
    – Adam Katz
    Feb 27 at 21:25
  • @AdamKatz I certainly don't want scripts to be able to invoke sudo without requiring my password. What about in the default state, where the sudo password lasts 15 minutes? Would scripts I run be able to invoke sudo silently in that circumstance, meaning I need to set the password timeout to 0?
    – mgiuffrida
    Mar 1 at 0:08
  • Yes, a script that runs sudo will ride your previous authentication, but only from the same shell instance. You shouldn't be running unknown scripts regardless; at least give them a quick read (or even grep sudo script.sh).
    – Adam Katz
    Mar 1 at 5:34

2 Answers 2

2

You need to analyze your security risk, starting with what does your server host?

You should look at the Confidentiality, Integrity, and Availability of your server and the data it holds compared to your security posture. How important is the Confidentiality, Integrity, and Availability of the information that your authentication provides access to?

Given that I'm the only human who should have access to a Linux server, what are the major security risks associated with updating sudo to not require a password for my local user?

Some examples of the risks;

  • Making a mistake that you screw something up and you've taken down your server, reduces the server's availability. So protecting sudo to prevent this puts you in the mindset "should I do this action?" before you do it.

  • Running malicious (even accidentally malicious) software or script that uses root access (and not realizing it) can put your servers confidentiality and integrity at risk. Then availability risks, for the downtime to fix.

  • An attacker getting in, say through social engineering or other means and being able to run root commands without sudo asking for password, easily takes over the system.

Where putting sudo behind a password wall will reduce these risks and attack vectors.

You should ask yourself;

  • "What (or How much) risk am I willing to accept?"
  • "If data is leaked, lost, or destroyed what liability do I have?" (Particularly financial responsibility?)
  • "Am I losing money if my server is down?" (customers not having access? advertisements not being seen?)
  • "Am I losing money if my server is taken over?" (someone now installs a bot on your server, and uses its resources, costing you network bandwidth and high CPU costs?)

Is this all "likely", probably not, but are you willing or able to accept that risk?

Are there other ways of making sudo less cumbersome without running everything as root?

This question is a little confusing, running sudo is running as root. Running sudo whoami will return "root". I presume you mean "instead of logging in as root" or "using sudo su -" to persitently switch to the root user (su; switch user).

The answer is you shouldn't be using sudo all the time, you shouldn't need to be root all the time. You should install and run software in a way that doesn't require root privilages. Add groups to objects that need special access, like devices and other files, and let the software run in the account with limited access. Run services and cron jobs with limited user accounts. Similarly your user should be a part of the softwares group if you're going to modify it or files it has access to regularly.

Yes, there are times you need to have root access, but that should not be normal or regular.

Lets take an example, a minecraft server. It should run or be executed as a service with its own user account (ie. have a service script that runs minecraft in a screen session using the user minecraft), and the files should be owned and accessed by that user and group account. You as the application administrator should have access via the group permissions, and should be able to access the data, and settings of the minecraft application. Rarely, but occasionally you may need to switch to that application user, using su minecraft or switching to that screen session for that applications console interface.

You should only need root access to modify system settings (network configs for example), security settings (user passwords or firewall), and patches/updates (apt). Not running end-user facing software or modifying application settings (minecraft settings or user files, or a web server config or web data, or database server settings) As the system administrator you should use your root permissions only to modify the system itself.

Keeping a separation of duties is good security.

Something I'll touch on, but I'm not a great source about is your legal obligation of the information your server stores. (This is not legal advice!) You may think it's acceptable to risk the users data, but if you have certain types of data and your server is breached you may be put at legal or financial liabilities that you aren't ready for. If a forensic analysis is done, and you've specifically shown a lack of care of security measures, like just letting a user use passwordless sudo (or worse just using sudo through ssh) and it was the attack vector, that can put you personally at fault for a leak or loss, where if (and can prove) you followed proper security measures your personal liability may be reduced if something happened. (This is not legal advice!)

I hope you're not running a site with financial or other protected data types, but it's something you should be aware of if you store any user data. (Even home address and phone number.)

Best Practices

The US Government provides Unclassified Standard Technical Implementation Guides that you can use to look at best practices to secure a system, literal step by step guides to protecting your system. (The RedHat guide can be used mostly in whole for any linux system.)

https://public.cyber.mil/stigs/compilations/

The National Institute of Science and Technology (NIST) provides a comprehensive manual about the security controls and why you apply them. You can directly map the STIG guidance to the NIST Control.

https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

Going back to the Confidentility, Availability, and Integrity, the 800-53 provides some guidance with what controls are more important depending on what is important to the data/system you control.

4
  • Thanks for the detailed response! "The answer is you shouldn't be using sudo all the time, you shouldn't need to be root all the time." Of course. I've added my local user to the www-data group so I can update my webserver's content as needed. But root access is still needed once or twice per session. "You should install and run software in a way that doesn't require root privilages." Can you point me to resources for using apt without sudo? Or for changing certain services (apache, mysql) to not require sudo to restart, in Ubuntu?
    – mgiuffrida
    Feb 28 at 23:55
  • One related note -- my website connects to my MySQL server (on another machine), so one PHP file includes my MySQL password in plaintext (in a file only readable by www-data), and my local user has credentials stored in .mylogin.cnf. If someone could SSH into the server as my local user, they could use either of these to access the database, which of course would be catastrophic. To me, that seems like the bigger risk (compared with sudo itself), yet I don't know of other ways typically used to store MySQL credentials especially for webserver use.
    – mgiuffrida
    Mar 1 at 0:00
  • You cant run apt without sudo. I meant you should install and configure software or give permission to software after installation to where it doesn't need root to function. Apt is an administrator function, and so is handling services, however I think you can give permission to a user to specific services so they don’t need to sudo to restart apache, for example. I don’t have source for that, but I don’t see why apache needs to be a root only service. Mar 1 at 4:03
  • 1
    Apache needs root for opening sockets I believe. And i cant find a resource for allowing a user to have service access without using sudo, but i think with careful permission planning it could be done, I’m just not at a point where i could try to implement it. So my next question is why do you need to restart services so often?! Mar 1 at 4:23
0

You can change the behaviour by modifying /etc/sudoers, changing :

%sudo   ALL=(ALL:ALL) ALL

by

%sudo   ALL=(ALL:ALL) NOPASSWD: ALL

%sudo refers to the group associated with the parameter.

You may have a NOPASSWD associated only with a user :

your_user   ALL=(ALL:ALL) NOPASSWD: ALL

But it is not because it is possible that it is recommanded.

1
  • 2
    This does neither answer the question regarding the risks of passwordless sudo nor show how to make it less cumbersome (nopasswd is equivalent to run everything as root)
    – fleitner
    Feb 28 at 12:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .