Skip to main content
add obvious -ok alternatives to -exec.
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k

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.

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 *-delete*

This would allow the auditor to run find, without allowing them to run it with -exec, -execdir, or -delete.

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.

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.

removed `/usr/bin/*` from the example, because it's unsafe.
Source Link
Tim Kennedy
  • 20.2k
  • 5
  • 42
  • 58

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 *-delete*

This would allow the auditor to run find, without allowing them to run it with -exec, -execdir, or -delete.

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.

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/*, 
               ! /usr/bin/find *-exec*,
               ! /usr/bin/find *-delete*

This would allow the auditor to run find, without allowing them to run it with -exec, -execdir, or -delete.

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.

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 *-delete*

This would allow the auditor to run find, without allowing them to run it with -exec, -execdir, or -delete.

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.

Source Link
Tim Kennedy
  • 20.2k
  • 5
  • 42
  • 58

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/*, 
               ! /usr/bin/find *-exec*,
               ! /usr/bin/find *-delete*

This would allow the auditor to run find, without allowing them to run it with -exec, -execdir, or -delete.

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.