Hm… I struggle to picture what you’re trying to achieve…

If you are “making an app” as in coding one, you can just have it say ask for a pin in a window as part of starting up.

You suggest various encryption related solutions… what is your threat model? Do you want to make the identity of the app unknown to others? Normally, autkenticating users is the responsibility of the os/desktop environment, and it would be non-ideomatic for an application to bundle its own auth, except for apps such as a password manager.

If you want to make an existing system app privileged/secret in some way then that sounds awkward indeed. Normally you’d definitely be using user management facilities (e.g. dedicated users and sudo config) to achieve such a thing.

If you really do want to make the app “secret” in some sense you could achieve the same thing as with your mac using a combination of loopback block devices (see man losetup) with an encrypted luks volume inside… but depending on the app you might end up in dependency hell if it’s not statically linked.

ymmv 🙂

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.

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.

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

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.

Make your app (flatpak, snap or appimage) be owned by another user.

Use a .desktop, wrap the command in the graphical equivalent of “sudo -u” for your graphical shell, and it will ask you for that user’s password.

You can also write a util to decrypt an encrypted .tar.gpg flatpak directory (flatpak lets you specify different installation paths, you can use that to separate it from the main flatpak dir), or decrypt a .appimage.gpg, and execute it. You could even write a wrapper to install a flatpak with a specific password, and it would automatically pick that specific install dir and .tar.gpg it every time.

Keep in mind that nothing keeps your other users from downloading that software on their own and using another copy of it unless you use parental controls.

I highly recommend giving them their own account though.

Þ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