0

I'd like to have a table of executables that are allowed to be run on the machine with everything else not getting executed even when the executable flag is set. For instance via a config file like this:

| command        | location                  | allowed | hash  | access options 
|----------------|---------------------------|---------|-------|--------------------
| youtube-dl     | /usr/local/bin/youtube-dl | x       | ...   | firejail youtube-dl

(This table could also define the way that the software is allowed to be called - "access options" - with the default option allowing for direct calls and otherwise only allowing e.g. certain commands or a list of authorized software to launch it.)

I think from a security standpoint this would make sense for a mechanism for authorizing software to run on the machine and to ensure their integrity via hashes. And more specific: this could also hash all dependencies a software has (the hash in the table could e.g. be a hash of all the relevant hashes of the software) and thereby ensure the software's integrity.

Does something like this exist for Debian (probably as part of the Linux kernel; it would need to have default entries for all the software that is required by Linux/GNU/the DE so that it can start up properly)?

1 Answer 1

1
  1. Speaking of verifying files:

There are

The issue is I'm not aware of any manuals/how-tos to set up the former, and the latter is AFAIK only implemented in Android.

Then there are tools like AIDE, Tripwire (no longer developed), mugsy, SAMHAIN but they are all mostly monitors, not something which has the required power to stop/allow applications to run based on their hashsums.

Lastly, let's think about this very file where you're going to store files hashsums. I guess the reason you want to do that is to avoid running software which has been modified behind your back but if that has happened the attacker has compromised your system entirely and can change the contents of the file where you store all the data and all your protections have been rendered ineffective which means fs-verity/dm-verity are unfortunately the only way forward but both also require read-only storage and deep system locking because the attacker can remount your storage in read write mode and again render your protections useless.

  1. As to allowing to run only specific applications:

I'm not aware of any ready solutions but this can be achieved by

  • Changing the required directories permissions from 755 to 750 and then copying all the allowed applications to a special path accessible by the user, e.g. /usr/local/allowbin

  • Writing a sudo wrapper which will check the run application against the permissions file you've specified and then allow/deny its execution based on that.

  • Creating a chroot jail.

TLDR As far as I know they are no ready solutions for desktop Linux to either of your issues.

3
  • This is very helpful. However, the reason for it is not modifications of files on the system but at the place where it's downloaded from & during transfer as well as preventing undesired or unauthentic software from being run in general (& idfying such) or via calls from other software & having a central place to manage & track. One usecase is making sure that youtube-dl is only being run via the firejail sandbox. For 2: I'm interested in practical solutions that are not only implementable in practice but also somewhat convenient - it also misses some core functionality of what I was seeking
    – mYnDstrEAm
    Commented Nov 1, 2020 at 15:51
  • I guess you're on your own with that and if you come up with a solution you may as well share it with the rest of the community e.g. via github :-) Commented Nov 1, 2020 at 18:25
  • @mYnDstrEAm You can apply dm-verity at build-time, before transfering your build image. Create a digitial signature of the dm-verity root hash. And then exchange the digital signature. And the way to verify the public key used on the digitial signature would be via some form of a chain-of-trust that starts from the root-of-trust Commented Sep 4, 2023 at 8:47

You must log in to answer this question.

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