3

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
    
8
  • 4
    Remove those features from source then compile it. Nov 13, 2017 at 6:10
  • That does not address the problem - I only want to stop the discovery user from using them, not all legit users and processes that run on the system.
    – Tony
    Nov 13, 2017 at 6:32
  • 1
    Do you have selinux turned on? Nov 13, 2017 at 6:47
  • Also, would you be up for aliasing a different find for just the discovery user that was built without the execution parts? Nov 13, 2017 at 6:50
  • 2
    A continuation of @IporSircer's first suggestion - if you compile from source into a non-standard location (not in $PATH) normal users can use the full featured distro provided find while your special case can use /my/path/to/find. Nov 13, 2017 at 7:42

2 Answers 2

2

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.

2
  • 3
    Note, /usr/bin/* is a bit too wide, as it allows the user to sudo ln find myfind in /usr/bin and then sudo myfind.
    – meuh
    Nov 13, 2017 at 20:20
  • Good point. If you set up a profile like this, please don't use /usr/bin/*, instead determine what commands the profile needs, and specify them explicitly. Nov 14, 2017 at 15:45
0

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).

You must log in to answer this question.

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