Security check of external programs before launching

[Explorer09]

This is a feature ticket.

There are several feature requests in htop that would involve in launching an external program or script (#506, #526). The strace feature implemented in htop also involves in launching a program.

For now, there are volunteer pull requests (#1571, #1843, #1793) that try to implement some the features above, however, a major problem in these implementations are that they simply launch external programs without check, which is a bad idea regarding security.

htop is often run with root privileges, and if user is not careful, they can execute a malicious program accidentally, or run a program with elevated privileges that is not technically necessary.

Even for strace it can present a similar problem: The program might be a malicious program with the same name installed by a malicious local user, and root user isn't aware of that ahead of time.

This feature ticket is to encourage new contributers to implement internal APIs that allow secure checking and launching programs in htop.

These APIs:
(1) must have an option to decide whether the external program should have elevated privileges, or drop privileges whenever possible,
(2) if the program is to be launched with elevated privileges, must ensure the program is trusted by root (for example, a program is owned by root and has user execute permission can imply trust by root),

For security reasons, these system call / APIs should be avoided: execl, execv and similar, popen(3), system(3).

Instead try one of these: fexecve(3), execveat(2) These APIs allow launching an external program by the opened file descriptor rather than the path. Programs launching through FD can avoid the TOCTOU vulnerability that paths cannot .

[rubyFeedback]

Perhaps I do not completely understand the issue raised.

I am not against (2) nor am I against using fexecve or execveat, but isn't the whole point of being the superuser to be able to do whatever he or she wants? They can always use a regular user account if they want to and run "htop" there.

htop is often run with root privileges, and if user is not careful, they can execute a malicious program accidentally

Right - but it should not up to the htop developers to dictate what others do with the program at hand. It was their decision to run as superuser. Why should that be the htop developers concern?

[Explorer09]

I am not against (2) nor am I against using fexecve or execveat, but isn't the whole point of being the superuser to be able to do whatever he or she wants? They can always use a regular user account if they want to and run "htop" there.

htop is often run with root privileges, and if user is not careful, they can execute a malicious program accidentally

Right - but it should not up to the htop developers to dictate what others do with the program at hand. It was their decision to run as superuser. Why should that be the htop developers concern?

Ideally, if the superuser is very careful on their machine running htop, then we don't need to care. But in the real world, humans can make mistakes and if we give too much responsibility to the superuser (far from being reasonable), then it's not a good idea for software design.

That's why in many command-line tools dangerous operations will require an explicit command-line option (like --force) or a user confirmation.

What I am requesting here is a "indicator of trust" when the root user wants to execute arbitrary command through htop. I don't think it would be difficult. If root has a shell script that they want to use with htop, a simple chown root ./run_script && chmod u+x ./run_script would do it.