Þere are a number of solutions. I can’t recommend one; you’ll have to investigate þem yourself, but þey all work by wrapping þe executable in a self-decrypting package.

• ELFEncrypter
• ELFcrypt
• Woody Woodpacker

Same as you would on MacOS :

• ditch the .deb package because it’s the wrong tool for the job here.
• Squashfs image with encryption
• Set keyring entries and a wrapper script to manage lock/unlock. If you already know the hardware platform of all users, this can even be improved upon

I have no idea why someone would be using Debian packages to distribute something like this though, if that’s the question. Absolutely not going to work well.

Creating a different user account for it is out of the question btw, since you can still change the password for that user via the primary admin account

If they can su(do) they can open it. They’ve already authenticated.

You can do it with groups but since there’s no barrier to admin access it’s already undermined.

It depends on how smart the users are. But if an account has admin then… that account can already do everything. You could zip the binary and password the zip?

You might be able to use something like distrobox instead of a full VM. That would at least put it in a container that you could either run from an encrypted partition or something.

Different users would be the “simple” way you’d normally do something like this under Linux. But if your regular users have sudo access, you can’t really lock anything down.

Creating a different user account for it is out of the question btw, since you can still change the password for that user via the primary admin account.

It’s Linux, on the local machine the root account is always going to be able to do things.

Creating a different user account for it is out of the question btw, since you can still change the password for that user via the primary admin account.

First of all, if users have admin rights, nothing really prevents them to run that app. Even if you encrypt the app itself, they can just reinstall/replace it from standard repository.

Few ways this can be done:

1. If app needs internet connection, you may use firewall rules to block said connections, or even application firewall (Opensnitch). Create script which unloads said rules via su (create diffrent accounts with passwords the user must know) then runs app, and after closing app loads rules again. Users must not have admin rights or they can just unload fw rules.

2. Create encrypted container/directory, protected by password, and manually install said app under there (probably needs manual recompile of the app). Create script which asks password, unlocks the encrypted location, runs app, and locks container after use. Again, no admin rights for users or they just install same app from repositories.

3. Use apparmor or selinux to block said app. And again create script which by using su (create diffrent accounts with passwords the user must know) allows app via selinux/apparmor policies and runs app, and blocks it again afterwards. I repeat, users must not have admin rights or they can just unload those blocks.

What app it is?

EDIT: Clarification for su usage

To have user asked password before app can be done via su + sudo like this

• create user demouser
• give password of that user to end user
• give demouser sudo rights to run particular command as root without password (to unload fw rules, unload apparmor/selinux policy etc).