Can I disable command execution in find

Question

I have been asked to provide access to a stack of RedHat EL servers to an external discovery tool (and no is not an option). This tool requires access to a list of commands via sudo. Most of those are simple listings or can be locked down to one option. However, they also require sudo /usr/bin/find.

Obviously I am not happy about this, as find allows executing any command via -exec and friends, as well as deleting random files. It's as good as giving unrestricted root access.

I don't think a simple sudo command alias is going to help either, as it must necessarily include a wildcard for the path (1st argument), which will allow any subsequent argument as well. Is it at all possible/feasible to disable the insecure commands in /usr/bin/find when executed with sudo?

So to summarise:

• Let normal finds happen: e.g.

  /usr/bin/sudo /usr/bin/find /some/path/or/other -mtime +3 -print
  /usr/bin/sudo /usr/bin/find /home -executable -ls
  

• Block use of exec/execdir/delete: e.g.

  /usr/bin/sudo /usr/bin/find /some/path/or/other -name '*' -type f -exec /bin/rm -f {} \;
  /usr/bin/sudo /usr/bin/find / -ctime -1 -delete
  

Answer 1

You mention that you have to provide access to commands via sudo, so you can definitely do things to make sudo require more harmful intent to work around rules. It's not a perfect tool for the job, since it's trying to lock down access after it's given, rather than allowing specific access from a default deny position in other RBAC implementations.

I would never trust an auditor with unfettered access. Their job is to try and break your security profile and illuminate any vulnerabilities. The more secure you make your system, the harder it will be for them, and for any nefarious parties as well, to pick your locks.

Since sudo works by applying rules in order, start with the commands they are allowed to run, and then add rules that restrict various options to those commands. You could modify the sudoers file to use something like:

%auditor ALL = /usr/bin/lsattr,
               /usr/bin/find, 
               ! /usr/bin/find *-exec*,
               ! /usr/bin/find *-ok*,
               ! /usr/bin/find *-delete*

This would allow the auditor to run find, without allowing them to run it with -exec, -execdir, -ok, -okdir or -delete. You may also want to consider blocking the -fprint, -fprintf and -fls predicates which would allow overwriting any file with any content.

Note that it would also block commands like find no-execution.txt or find . -name '*-ok*'.

tom@evil:~$ sudo id
uid=0(root) gid=0(root) groups=0(root),999(lightsd)

tom@evil:~$ sudo find . -mtime -50
.
./.bashrc
./.kshrc
./.bash_history
./.bash_logout
./.profile

tom@evil:~$ sudo find . -mtime 5 -exec ls -la {} \;
Sorry, user tom is not allowed to execute '/usr/bin/find . -mtime 5 -exec ls -la {} ;' as root on localhost.

tom@evil:~$ sudo find . -mtime -5 -name .kshrc -delete
Sorry, user tom is not allowed to execute '/usr/bin/find . -mtime -5 -name .kshrc -delete' as root on localhost.

It's kind of a PITA to set up and maintain good sudoers profiles, but I consider it worth the effort, especially in a compliant environment.

Answer 2

Focus on LOGGING instead if you have to give a partially trusted user access that can be escalated to root - and make it clear that escaping the logging by using some variant of "sudo su" is deprecated and considered a malevolent action.

Log to a remote log server that is off limits to the partially trusted user, and also have the log server monitor continous network connectivity to the machine under supervision (so a log entry cannot be trivially suppressed by interrupting the network).