{"id":12188,"date":"2025-10-14T02:00:00","date_gmt":"2025-10-14T06:00:00","guid":{"rendered":"https:\/\/www.both.org\/?p=12188"},"modified":"2025-10-11T20:35:12","modified_gmt":"2025-10-12T00:35:12","slug":"a-caution-about-using-sudo","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=12188","title":{"rendered":"A caution about using sudo"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

The sudo<\/strong> program is an excellent way to extend “administrator”-like access to users who are not otherwise system administrators. In fact, modern Linux desktop distributions assume that at least one user should have an “administrator”-like role. When using a Linux system this way, a user can run certain “system” level commands as root, using their normal user account.<\/p>\n\n\n\n

For example, on my Fedora Linux desktop system, I am this “administrator”-like person. I can run any<\/em> command as root, simply by using the sudo<\/strong> command. I use this rarely, but it sometimes comes in handy. For example, while I can use a desktop package manager to install new programs and applications, I’m familiar enough with the Linux command line that I prefer to do it “by hand.” To install the pngcrush<\/strong> package, which can optimize a PNG graphic file for size, I just type this:<\/p>\n\n\n\n

$ sudo dnf install pngcrush<\/code><\/pre>\n\n\n\n
Using sudo on a server<\/h2>\n\n\n\n
On a server where you need to provide other non-“administrators” with the ability to run certain commands as root, you can edit the \/etc\/sudoers<\/code> file to specify who can run which commands<\/em>. You can even limit the options<\/em> that these users can give to these commands, such as only allowing certain users to mount the CD-ROM drive, as though they were root. The sudoers<\/code> file contains examples of how to limit these kinds of commands.<\/p>\n\n\n\n
But you need to be very careful<\/em> about how you grant this access, and what commands they have access to run. Here’s an example that demonstrates what I mean:<\/p>\n\n\n\n
A friend of mine used to work for a large company, as an applications administrator<\/em>. Like many organizations, this company split up roles on the server: the systems administrators supported the hardware and operating system, the database administrators maintained the databases, and the application administrators ran the applications. The applications needed to be launched as root, so the systems administration team set up sudo<\/strong> commands for them.<\/p>\n\n\n\n
For this example, let’s say the application was installed in \/opt\/___<\/code>, which was “owned” by the application administrator team. Like good Linux users, the applications administrators set up scripts to automate tasks for them. For example, they had a script that acted like a “system” script, so they could start the application by running a command like \/opt\/___\/bin\/app<\/code> with an option like start<\/strong> or stop<\/strong> or restart<\/strong>. You can imagine a script that looked like this: (I’ve replaced any actual commands with an echo<\/strong> command, because I’m only demonstrating it)<\/p>\n\n\n\n
#!\/bin\/bash\n# run this with 'sudo app start' or 'sudo app stop'\n\ncase \"$1\" in\nstart)\n  echo 'starting app server..'\n  ;;\nstop)\n  echo 'stopping app server..'\n  ;;\nrestart)\n  \"$0\" stop && \"$0\" start\n  ;;\n*)\n  echo \"usage: $(basename $0) start|stop|restart\"\n  ;;\nesac<\/code><\/pre>\n\n\n\n
The system administrators set up an \/etc\/sudoers<\/code> rule that allowed the application administrators to only run this script with start<\/strong> or stop<\/strong> or restart<\/strong>, with a rule that looked like this:<\/p>\n\n\n\n
%apps ALL=\/opt\/___\/bin\/app start, \/opt\/___\/bin\/app stop, \/opt\/___\/bin\/app restart<\/code><\/pre>\n\n\n\n
With this rule, any member of the apps<\/code> group (the application administrators) could start the application by typing this command:<\/p>\n\n\n\n
$ sudo \/opt\/___\/bin\/app start\nstarting app server..<\/code><\/pre>\n\n\n\n
..or stop the application with this command:<\/p>\n\n\n\n
$ sudo \/opt\/___\/bin\/app stop\nstopping app server..<\/code><\/pre>\n\n\n\n
..or restart the application (such as when the application needs to be “refreshed”) by typing:<\/p>\n\n\n\n
$ sudo \/opt\/___\/bin\/app restart\nstopping app server..\nstarting app server..<\/code><\/pre>\n\n\n\n
A security issue<\/h2>\n\n\n\n
Using sudo<\/strong> made it easy to “draw a line” between the systems administrator and the application administrator roles. The applications team could manage the application without involving the systems team, especially because the applications team “owned” the \/opt\/___<\/code> directory on the server.<\/p>\n\n\n\n
But do you see the security gap in this script? Here’s what happened:<\/p>\n\n\n\n
One night, the application crashed hard. My friend was the application administrator on-call person, so he was paged by the automatic monitoring system. I don’t recall exactly what the problem was that night (it was years ago) but let’s say the issue was that the \/opt<\/code> filesystem had filled up. Through some investigation, my friend found that the “temporary” area in an unrelated \/opt\/temp<\/code> directory was full. This directory was well known to only contain “interim” files, and deleting the files in this “temporary” area (especially file names starting with “tmp”) was safe to do.<\/p>\n\n\n\n
But the system administrator on-call person wasn’t responding to calls. No one with the access to clean up the \/opt\/temp<\/code> directory was available to do this quick task.<\/p>\n\n\n\n
My friend realized they could run the script as root<\/em> using sudo<\/strong>, and they could edit the script<\/em>. So they made a quick edit to the \/opt\/___\/bin\/app<\/code> script to clean up the \/opt\/temp<\/code> directory. The edit might have looked like this: (again, I’ll use the echo<\/strong> command instead, because I’m only demonstrating it)<\/p>\n\n\n\n
#!\/bin\/bash\n# run this with 'sudo app start' or 'sudo app stop'\n\necho 'cd \/opt\/temp ; rm tmp.*'\nexit\n\ncase \"$1\" in\nstart)\n  echo 'starting app server..'\n  ;;\nstop)\n  echo 'stopping app server..'\n  ;;\nrestart)\n  \"$0\" stop && \"$0\" start\n  ;;\n*)\n  echo \"usage: $(basename $0) start|stop|restart\"\n  ;;\nesac<\/code><\/pre>\n\n\n\n
This modification to the script adds a command to delete temporary files in the \/opt\/temp<\/code> directory, then immediately exit the script. With this edit, my friend ran the script with one of the options allowed in the \/etc\/sudoers<\/code> rule file, such as stop<\/strong>, and the system cheerfully deleted the other temporary files:<\/p>\n\n\n\n
$ sudo \/opt\/___\/bin\/app stop\ncd \/opt\/temp ; rm tmp.*<\/code><\/pre>\n\n\n\n
After running this command, my friend removed the two extra lines from the script, returning things to normal.<\/p>\n\n\n\n
Security and sudo<\/h2>\n\n\n\n
This demonstrates why it’s important to be careful about what commands you allow users to run with sudo<\/strong>. My friend was able to edit the script, so was effectively able to run any arbitrary command as root<\/em>. Fortunately, this was a benign “abuse” of sudo<\/strong>, but imagine if a bad actor had been able to login as an application administrator and made a different change to the script–such as an edit that transferred system access to an outside agent. That would be a disaster.<\/p>\n\n\n\n
This is not a sudo<\/strong> problem, but a user management issue. In fact, this issue is also noted in the sudo<\/strong> documentation, such as this note in the sudo<\/em>(8) “man” page:<\/p>\n\n\n\n
\n
There is no easy way to prevent a user from gaining a root shell if that user is allowed to run arbitrary commands via sudo<\/strong>.<\/p>\n\n\n\n
\u2026 Running shell scripts via sudo<\/strong> can expose the same kernel bugs that make set-user-ID shell scripts unsafe on some operating systems.<\/p>\n<\/blockquote>\n\n\n\n
One way to avoid the problem I described is do not allow general users to edit the script<\/em>. If the \/opt\/___\/bin\/app<\/code> script were “owned” by root and mode 500<\/code> (that is, read+execute only by root) then the script could still be executable using sudo<\/strong>.<\/p>\n\n\n\n
The sudo<\/strong> command is great for controlling access, but take this example as a general caveat about using sudo<\/strong>: you cannot<\/em> let people edit any script that sudo<\/strong> lets them run.<\/p>\n","protected":false},"excerpt":{"rendered":"
This example shows why it is important that users should not be able to edit scripts that they can run with sudo.<\/p>\n","protected":false},"author":33,"featured_media":2700,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[5,75,89],"tags":[91,261,97],"class_list":["post-12188","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security","category-system-administration","tag-linux","tag-security","tag-sysadmin"],"modified_by":"Jim Hall","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/12188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12188"}],"version-history":[{"count":5,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/12188\/revisions"}],"predecessor-version":[{"id":12194,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/12188\/revisions\/12194"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/2700"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}