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/mkdirUsing only this rule, is there any way ricardo could intentionally or accidentally compromise the system?
Is there any way attacker could use mkdir to compromise a system?
security;directory
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.koNote 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 updateso 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.