why have one package management system if the user can have 3x 4x 5x?

to keep it simple imho it would be better to use only one “one to rule em all” (maybe python pip as exception)

snap is written in Go and JavaScript (?) is installed per default on ubuntu, it can be optionally installed on Debian (if the user ABSOLUTELY is forced to, because a M$ program is only shipped via snap)

to be honest not a big fan of snap as it creates a lot of loop back devices (one for every app installed? X-D)

findmnt |grep snap; # what is all this crap?
\u2502 \u251c\u2500/run/snapd/ns                             tmpfs[/snapd/ns]                  tmpfs           rw,nosuid,nodev,noexec,relatime,size=400532k,mode=755,inode64
\u2502 \u2502 \u2514\u2500/run/snapd/ns/lxd.mnt                   nsfs[mnt:[4026532656]]            nsfs            rw
\u251c\u2500/snap/bare/5                                /dev/loop0                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/core20/2379                           /dev/loop1                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/core20/2434                           /dev/loop2                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/core22/1663                           /dev/loop3                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/core22/1722                           /dev/loop4                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/firefox/5239                          /dev/loop5                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/gnome-42-2204/176                     /dev/loop6                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/gtk-common-themes/1535                /dev/loop7                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/lxd/29351                             /dev/loop8                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/lxd/31333                             /dev/loop9                        squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/snapd/21759                           /dev/loop10                       squashfs        ro,nodev,relatime,errors=continue
\u251c\u2500/snap/snapd/23258                           /dev/loop11                       squashfs        ro,nodev,relatime,errors=continue

what does the AI think

technical differences between Snap and APT in more detail, focusing on how they handle packages, dependencies, installations, updates, and the overall architecture.

1. Package Format & Structure

  • APT:
    • APT uses .deb packages, which are the standard for Debian-based systems (like Ubuntu).
    • A .deb package typically contains the application’s binary files, configuration files, and a control file that lists dependencies (libraries or other software it needs to function).
    • When installing via APT, the package manager checks for and installs dependencies from the system’s repository (like apt-get or apt-cache), which may already be installed on the system.
  • Snap:
    • Snap uses .snap packages, which are a completely different format. A Snap package is essentially a self-contained application bundle.
    • Snap packages include everything the application needs to run: binaries, libraries, configuration files, and even runtime environments (if needed).
    • This makes Snap packages larger but means they are independent of the underlying system’s libraries, as they come bundled with their own versions of the dependencies.

2. Dependency Handling

  • APT:
    • APT resolves dependencies in a traditional way. When you install a .deb package, APT checks if the required dependencies are already installed on your system (from the repository) or if they need to be installed.
    • The dependencies are shared among packages. For example, if two packages require the same version of a library, APT only installs one version of that library system-wide, which reduces duplication and overall disk usage.
  • Snap:
    • Snap uses a sandboxing approach. Each Snap package bundles its own dependencies inside the package, even if other packages on the system already have the same dependencies installed.
    • This means that if you install multiple Snap packages that rely on the same library, each Snap package might include its own version of that library, leading to more disk space usage. However, this avoids potential compatibility issues with different versions of dependencies across various distributions.

3. Installation and Distribution

  • APT:
    • APT installs packages directly from the distribution’s official repositories (like Ubuntu’s or Debian’s package servers).
    • When you run sudo apt install <package>, APT connects to a repository, downloads the .deb package, and installs it along with its dependencies.
    • Repositories are managed by your distribution, and you need to manually add extra repositories for third-party software.
  • Snap:
    • Snap packages are distributed via the Snap Store, which is a central, cloud-based service managed by Canonical (the company behind Ubuntu).
    • When you run sudo snap install <package>, Snap downloads the package from the Snap Store, installs it in a specific directory (/var/lib/snapd/), and ensures the package is sandboxed from the rest of the system.
    • Snap packages are cross-platform, meaning they can run on any Linux distribution that has Snap support, making Snap more distribution-agnostic than APT.

4. System Integration and Sandboxing

  • APT:
    • APT packages are installed directly into the system’s file structure (like /usr/bin, /etc/, /lib/).
    • The installed application interacts directly with the system’s environment. APT doesn’t isolate applications from each other, which means that all applications share the same system resources (e.g., libraries).
    • There’s no inherent sandboxing or strict isolation for applications installed via APT.
  • Snap:
    • Snap packages are installed into a sandboxed environment. This means that each Snap package runs in its own isolated container with limited access to the rest of the system.
    • Snap uses AppArmor (Linux security module) to enforce this isolation and restrict what files and resources the Snap application can access.
    • The sandbox ensures that the app can’t affect other parts of the system directly. It also prevents conflicts with other applications or system libraries, as each Snap has its own environment.

5. Updates

  • APT:
    • Updates for APT packages are handled by the package manager, which checks for newer versions in the repositories when you run sudo apt update && sudo apt upgrade.
    • Updates are generally manual unless set up otherwise. APT updates only the packages installed via APT and doesn’t affect any other types of software on the system.
    • When an update is applied, the system libraries or software are replaced with the new versions, and you may need to restart the application or service.
  • Snap:
    • Snap packages have automatic updates. By default, Snap packages will automatically update in the background without user intervention. You can configure Snap to update at specific times or intervals, but it generally doesn’t require manual action.
    • When a Snap is updated, the Snapd service (which handles Snap packages) will download and install the new version. Since each Snap package is self-contained, updates do not affect other applications.
    • The older version of the Snap package is kept on the system until the new version is fully installed, ensuring that you can roll back to the previous version if needed (Snap supports rollbacks).

6. Performance

  • APT:
    • Since APT packages are often smaller (just the application binaries and their dependencies, but not the dependencies themselves unless required), they can be faster to install and use less disk space.
    • The performance of applications installed via APT is more dependent on the system libraries available and the specific version of the package you install.
  • Snap:
    • Snap packages can be slower to launch initially because they are sandboxed and need to go through additional layers of security and environment setup.
    • Because Snaps bundle their dependencies, they can be larger, and this can impact disk usage. Also, Snaps are mounted in read-only mode and use a loopback filesystem, which can sometimes impact performance in terms of file access speed.

7. Security

  • APT:
    • APT relies on the package repositories and security updates provided by your distribution. The system administrator must ensure that the system is kept up to date with security patches.
    • There’s no sandboxing by default, so if a malicious application is installed via APT, it has full access to the system.
  • Snap:
    • Snap applications are sandboxed, which means that they are restricted from accessing other parts of the system unless explicitly allowed.
    • Snapd (the daemon responsible for Snap management) uses security features like AppArmor to limit Snap’s access to system resources, enhancing security by isolation.

Conclusion

  • APT is more traditional and relies on the system’s package management infrastructure. It is efficient for installing and updating packages in a system-wide manner but is less flexible when it comes to handling dependencies across distributions.
  • Snap, on the other hand, is a newer and more flexible packaging system that aims for cross-distribution compatibility, ease of use, and stronger isolation through sandboxing, but at the cost of performance and increased disk space usage due to bundled dependencies.

Which one to choose depends on your needs:

  • If you’re looking for efficiency, smaller packages, and tight integration with your system, APT is likely the better choice.
  • If you’re looking for an app that works across multiple Linux distros, with automatic updates and stronger security through sandboxing, Snap might be the way to go.

 

Snap’s sandboxing is a key feature designed to enhance security by isolating applications from the rest of the system. While it adds a layer of protection, like all security mechanisms, it has its strengths and limitations. Let’s break down how Snap sandboxing is technically realized and evaluate how “safe” it actually is.

1. Sandboxing Mechanism:

Snap uses AppArmor and other kernel security mechanisms to enforce sandboxing for its applications. Here’s a breakdown:

  • AppArmor:
    • AppArmor (Application Armor) is a Linux security module that helps enforce security policies for applications by restricting what resources they can access.
    • For each Snap package, Snapd (the Snap package manager) creates an AppArmor profile that defines what the application can or cannot access. For example, a Snap application may be prevented from accessing files outside of its designated directories or from making certain system-level calls.
    • AppArmor profiles for Snaps are specific to each Snap, so the application can only access files, network resources, and devices that are explicitly allowed by the profile.
  • Filesystem Isolation:
    • Snap packages are installed in a separate directory from the rest of the system, typically under /var/lib/snapd/. This ensures that Snap applications don’t overwrite or interfere with system files.
    • Each Snap package runs in its own isolated environment, and applications cannot directly access files outside of their designated directories, unless explicit permissions are given (such as access to /home, /dev, etc.).
  • Namespaces:
    • Snap uses Linux namespaces to further isolate applications. Namespaces are a fundamental part of containerization, which allow processes to have their own isolated view of the system’s resources, such as network interfaces, process IDs, and mount points.
    • Snap packages are run in a “mount namespace,” meaning they have their own isolated file system, separate from the rest of the system.
  • Cgroups (Control Groups):
    • Snap also utilizes cgroups to limit the resources (CPU, memory, disk I/O, etc.) that a Snap application can consume. This prevents one Snap from consuming too many resources and impacting the system’s performance.
  • Seccomp:
    • Snap uses seccomp (secure computing mode) to restrict the system calls an application can make. This limits the potential attack surface by blocking access to dangerous or unnecessary system calls that the application doesn’t need to function.
  • Network Isolation:
    • In some cases, Snap applications are isolated from the system’s networking stack. By default, they may have restricted access to networking resources, limiting the risk of remote exploits.

2. Snap’s Permission Model:

One of the central aspects of Snap’s security is its permission model, which allows users to control the level of access each Snap has to their system:

  • When you install a Snap, it runs with a predefined set of permissions. These permissions specify what system resources the Snap can access. For instance:
    • Some Snaps might be given access to /home (e.g., for a text editor to save files) or to /dev (e.g., for a music player to access sound devices).
    • Snaps may request additional permissions, such as access to the camera, microphone, or other hardware, which must be explicitly granted by the user.
  • Interface system: Snaps can interact with the system through interfaces. These interfaces act as “bridges” that allow the Snap to request specific access to system resources. There are different types of interfaces:
    • Auto-connect interfaces: Permissions that automatically grant access (e.g., network access).
    • Manual interfaces: Permissions that the user must explicitly allow (e.g., access to system files, devices).

3. Is Snap Sandboxing Safe(r)?

While Snap’s sandboxing provides security benefits, it’s important to understand its strengths and weaknesses.

Strengths:

  • Isolation: By sandboxing Snaps, even if a malicious actor compromises a Snap, it can’t easily affect the rest of the system. The app is isolated in its own environment and has limited access to the system’s files, processes, and network.
  • Reduced Attack Surface: By limiting system calls and access to sensitive files, Snaps have a smaller attack surface compared to traditionally installed applications.
  • Automatic Updates: Snaps update automatically, reducing the time window for exploits based on older vulnerabilities. The Snap system enforces this consistency across all installations.
  • Granular Permissions: The explicit permission model means users can control what resources an application accesses, reducing the risk of unintended data leaks or malicious behavior.

Weaknesses:

  • Potential Over-permissioning: While Snap’s permissions model is fine-grained, some applications may still request more access than they need, which could be a security risk if users aren’t careful.
  • Snapd as a Single Point of Failure: The Snapd service that manages Snaps could be a target for attackers. If Snapd itself is compromised, it could potentially bypass some of the sandboxing protections, though this would require an exploit in Snapd itself.
  • AppArmor Profiles Can Be Complex: Writing and maintaining accurate AppArmor profiles for every Snap can be complex. If profiles are misconfigured, they could allow more access than intended, weakening the sandboxing protections.
  • Not Complete Isolation: While Snap offers good isolation, it’s not perfect. For example, Snap applications still share a kernel with the host system, and vulnerabilities in the kernel could potentially allow an attacker to escape the sandbox. Additionally, Snap applications have access to a subset of system resources like networking, so any vulnerability that allows access to those resources could lead to a system compromise.

4. Overall Security:

Snap provides stronger security than traditional Linux package management (like APT) by isolating applications from the rest of the system. This is particularly useful in mitigating the risks of privilege escalation, system-wide exploits, and software conflicts.

However, no security model is foolproof:

  • Snaps are still subject to vulnerabilities in the kernel, Snapd itself, or misconfigurations in the AppArmor profiles.
  • The user’s permissions are critical; if the user grants excessive permissions to a Snap, it can still access sensitive parts of the system.

Conclusion:

Snap’s sandboxing approach does make Linux systems safer, especially for desktop applications, by limiting the damage that a compromised application can do. However, it’s important to remember that no security model is infallible. Snap’s sandboxing is a stronger security layer compared to traditional package managers, but it is not a complete guarantee of safety.

dunno.

guess the safest thing would be that open source developers check each other’s code for malware.

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin