App Lock under Linux?
2026-05-21 11:09 UTC
Replies (7)
-
@chgxvjh@hexbear.net 2026-05-21 11:12
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.
-
@Goingdown@sopuli.xyz 2026-05-21 11:32
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: 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 sudo (asking password) then runs app, and after closing app loads rules again. Users must not have admin rights or they can just unload fw rules. 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. Use apparmor or selinux to block said app. And again create script which (via sudo) 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?
-
@db2@lemmy.world 2026-05-21 12:28
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.
-
@just_another_person@lemmy.world 2026-05-21 13:19
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.
-
@Sxan@piefed.zip 2026-05-21 14:51
Þ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
-
@isVeryLoud@lemmy.ca 2026-05-21 17:10
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.
-
@plc@feddit.dk 2026-05-21 21:08
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 🙂