Ubuntu Version:
Kubuntu 25.04Desktop Environment (if applicable):
KDEProblem Description:
Hello everyone. I've always read that it's advisable to avoid installing via .deb. But if you absolutely have to, how can you control or ensure security? Thank you.It’s your choice, either install .deb packages or don’t. That being said if the packages are from the official repos then don’t worry about it.
I’d choose not to install them, hahaha, but I have no other choice since there are programs like VirtualBox, Steam, Obsidian, and similar that can only be installed with the .deb files from their websites.
That’s why I’d like to know if there’s any way to control them or something similar.
You can’t control what comes from a 3rd party site.
Again it’s your choice to download or not. Look for the programs in the Ubuntu repos and if available then you’re good but if you download from a 3rd party it’s “buyer beware”.
The author of the Debian package essentially has root permission on your system if you choose to install it, unless you can verify the package content(including the binary parts), there’s little space to “control or ensure security” besides not installing the whole thing.
This kind of claim could be very misleading.
The Ubuntu repositories are .deb, and are quite safe. Debs and snaps are the fully-supported methods that come with every release of Ubuntu (except Ubuntu Core).
If you are downloading random debs from elsewhere on the dirty internet, then the problem is that you are downloading from an untrustworthy source.
We strongly advise new users to stick to App Center, which uses the Ubuntu repositories.
For users who really want to use non-Ubuntu deb packages, determining the trustworthiness of the source is for the sysadmin (you, the human) to judge. Don’t download from untrustworthy sources. Because, yeah, the install scripts run as root. It was the '90s.
Snap packages, developed 20 years later to overcome some of those deb shortcomings, are automatically confined, of course. One of the reasons they were developed.
So, according to your recommendation, the ideal thing would be to install Steam (or another application not in the official repositories) using Snap rather than its .deb package. Is that correct? Thank you very much.
Installing software not in the archives always comes with a risk and you have to assess that risk yourself when doing it … There are some points that apply though:
Installing a deb (regardless from where outside the archive, i.e. this also applies to PPAs) means that you give the owner of that package full root access to your system via package maintainer scripts included in said deb. Consider twice if you trust that person or organisation that much.
Snaps are by design fully locked down and not capable of doing something like this, they can not access your system by default or take over the machine or parts of it. They also get an automated and very deep security scan when getting uploaded to the central snap store and packagers have to use pre-defined mediated interfaces to allow their snap any access to system resources. Snaps can be packaged and uploaded by anyone though, including you. The latter bit means that there are many snaps in the store that have ever only seen one upload or are maintained by people not really qualified to do so, so if you want to install a snap, inspect it first to judge the quality. The store page for example shows you when the package was last updated and shows if there are regular updates in other channels (edge, beta) too which usually allows to judge its maintainers’ quality. It also helps to check if the packager took some effort in the presentation of the package (proper description, perhaps a screenshot or two etc). The snap store has a bunch of ways to tell you a packager is trusted and verified by putting a green check mark or a golden star next to their name on the website or in the App Store app.
flatpaks are similar to snaps except they usually only provide GUI apps and that anyone can open their own “store” (which means they can define the security requirements/levels used on that “store” themselves). While flatpaks are similarly sandboxed as snaps, opposed to the snap design their default policy is usually “open” and you have to apply the locking down as a user yourself, which exposes some additional small security weakness you can overcome by “sealing them” after install and before you run them for the first time. I’d suggest learning about that sealing process before you use your first flatpak if you care about security of your system.
Some website that tells you to download some shell script and run it with sudo (or pipe it directly via a wget command into sudo) … don’t do that ! Unless you have read said shell script and understood what it does to your computer.
Our recommendation is to try App Center first…which will, in the Steam example, install the Snap package.
If you encounter a problem with that App Center package, Deb or Snap, first ask for help here.
If, after troubleshooting, your hardware or configuration make the Ubuntu-provided packages unsuitable, then look to non-Ubuntu sources. But there is a learning curve there that prior Windows experience won’t prepare for. It can be treacherous water.
I feel this might be a complex topic but if you want to control the resources that a application has access to, you can use apparmor (default in ubuntu) or SELinux (default for most rpm based distros. These will tell the system what files and folders the application can access (There is more too it but at a basic level)
Thank you very much for your response; I found it very interesting.
I’d be interested in reading more about what you’re saying about Flatpak. If you have any information you think would be interesting, please feel free to send it. Thank you very much.
Thank you very much for your advice and help, I will read more on the subject and try to do some tests.
I’ll look into the tools; they might be helpful. Thank you very much.
How are you, Ogra? Can you explain a little more about what you’re talking about with Flatpak? Thank you very much.