Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I'm setting up a restricted user account for user ricardo, a troublesome user on my system. I want to grant him the right to make directories using sudo, which he sometimes needs to do. I'm considering this rule in my /etc/sudoers file:
ricardo ALL=(root) NOPASSWD: /bin/mkdir
Using only this rule, is there any way ricardo could intentionally or accidentally compromise the system?
I suspect an attack like this would work, where «something» is a kernel module that will try to load after rootfs is mounted:
$ sudo mkdir -m 777 /lib/modules/`uname -r`/a
$ cp evil.ko /lib/modules/`uname -r`/a/«something».ko
Note also that you could use other names, depending on the aliases declared in the module. I'm guessing it won't get loaded until depmod is run, which will happen the next time there is a kernel update—so the mkdir won't even show recently in the sudo log.
There are lots of things in /etc that read all files in a directory, sometimes recursively. Even worse, some of those directories don't exist by default, and the only way to know about them is to read the manpage, init scripts, etc. for the program that uses them. Some, even worse, are deprecated backwards-compatibility things, and may not even be documented anymore.
edit: Thought of a few more directories, these in /usr/local:
/usr/local/lib/perl/5.14.2 (differs depending on Perl version, try perl -V to find out). Create a File subdirectory in there, and put a Find.pm in it. Now whenever anyone uses File::Find, they'll be using the attacker's version. Similarly, do the same with Getopt::Long. System utilities are often written in Perl, so this probably gives root. (Try ack-grep --color -a 'use.+::' /usr/sbin | less -R)/usr/local/include.
By running mkdir as root, the user can block other processes/users from creating new files and directories by creating directories with identical names (and/or wrong rights) before.
This could be security relevant especially with log- and lock-files.
As jordanm noted, the maximal number of inodes can be also used up which can block the whole system.
By adding the user to specific groups (or using ACLs), you should be able to solve the issues without granting any rights via sudo.
mkdir off the list of commands ricardo is allowed to use.
Feb 21, 2013 at 17:25
for((i = 0;; i++)); do touch $i; done will do fine (bashism, sorry; but you get the idea).
sudo commands OP is considering may allow exhausting inodes as well; OP needs to be aware of that DoS vector.
You should redirect him to a chroot jail. Or even better, to a little VM, that he can crash once an hour. All you need to do is provide a new copy.
There's possibilities due to being able to create directories with write access. With mkdir -m 777 blah the ricardo user can write whatever they like into the new directory. You would need a process on the system already running as a different user that will recurse down a directory tree to load config, scripts or modules. Then the user could possibly add their own things to be loaded or run. The first thing I can think of is if you run a web server that can execute php or cgi. You could then run scripts as that user. I'm struggling to come up with more real world example's, especially root ones but I'm sure they are about.
ssh is an example of a daemon that traps this kind of scenario. If you created a .ssh directory for a user that didn't have one and put your own authorized_hosts file in place. sshd notices that the directories permissions are too open and ignores the public key.
You could definitely make a nuisance of yourself creating directories where files are expected to turn up (like transient tmp or swap files) which lots of programs would not handle nicely.
You could create lots of cgroups but it doesn't look you do anything with them. You might be able to bring a system to it's knees at least. It took about 10000 cgroups on a box with 256M for the OOM killer to take out sshd.
If you control the -m option to mkdir and the UMASK of the sudo environment I think it's back to just being a nuisance.
