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?

  • 2
    If you have a filesystem with a static inode count, he could use up all your inodes.
    – jordanm
    Feb 21, 2013 at 16:25
  • 2
    @schaiba He likes to tinker and see if he can exploit the system and doesn't always read the man pages as much as he should. Feb 21, 2013 at 16:38
  • 8
    A proper user education, combined with no sudo at the time being, would be the recommended thing to do from me.
    – schaiba
    Feb 21, 2013 at 16:41
  • 2
    As @schaiba says, you can use such users by teaching them, and giving them responsibilities (under close supervision). I've seen wars between sysdamins and users, as the first ones tried to lock down the system too much. The users outnumbered the sysadmins 10 to 1, and even then (without today's Internet access!) the defeat of the sysdamins was humiliating. Never get into such a position!
    – vonbrand
    Feb 21, 2013 at 23:43
  • 2
    That's the case of one ricardo too many. Or at least, thus spake BOFH... Feb 22, 2013 at 19:42

4 Answers 4


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)
  • I think Python, Ruby, etc. have similar directories. System utilities are written in Python as well.
  • Subvert many things someone compiles with subdirectories of /usr/local/include.
  • Oh, but if <evil user> can copy modules to where the kernel will load them, the game is over before the start.
    – vonbrand
    Feb 21, 2013 at 23:47
  • 1
    @vonbrand <evil user> normally can't, but used his sudo mkdir to create a new directory where he can.
    – derobert
    Feb 22, 2013 at 0:25

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.

  • Great points. I'll probably leave mkdir off the list of commands ricardo is allowed to use. Feb 21, 2013 at 17:25
  • If it is for exhausting inodes, a simple for((i = 0;; i++)); do touch $i; done will do fine (bashism, sorry; but you get the idea).
    – vonbrand
    Feb 21, 2013 at 23:45
  • @vonbrand Except that's not as root, so it'll be stopped by a quota. Of course, other sudo commands OP is considering may allow exhausting inodes as well; OP needs to be aware of that DoS vector.
    – derobert
    Feb 27, 2013 at 21:18

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.

  • I highly recommend this. Give him root access on his own VM.
    – emory
    Feb 22, 2013 at 0:55
  • to a chroot^H^H^H^H^Hounty jail... Feb 22, 2013 at 19:43

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.

You must log in to answer this question.

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