Non-core user applications?

[nobody43]

Therefore, this project tries to confine all the core applications you will usually find in a Linux system: all systemd services, xwayland, network, bluetooth, your desktop environment... Non-core user applications are out of scope as they should be sandboxed using a dedicated tool (minijail, bubblewrap, toolbox...).

What does it mean? That profiles for userland applications is not a priority? Or not accepted? How non-core is determined?

[roddhjav]

This refer to the ultimate goal of this project (and we are far to be there yet).

The idea is to fit into the new architecture of modern (future) Linux distribution: all major Linux distributions will move to an immutable system (Eg: Fedora Silverblue, Core OS, Ubuntu Core...). The idea is that the core system is mounted in read only and all programs in it are fully confined. Non core application are then sandboxed thanks to container or VM. These non core apps would still be confined but with a more generic profile.

The notion of core application varies depending of the distribution (and flavor). For a desktop this include at least:

• All privileged services
• The desktop environment and all user services linked to it.
• All "sandbox manager": flatpak, snap, firejail, docker, podman, toolbox, libvirt, steam...
• All browsers (they are kind of sandbox manager nowadays)
• All file browsers

Now, let's be honest, this structure will not be the default before years in most of the distribution, so we will always support non-core apps. However, as this project is still in its early stage the priority is on these core programs. This explain why app like Thunderbird or vlc is not a priority as they should simply be put in sandbox.

For more, please have a look at my talk to LSS, it presents some of the security arch behind the project: https://www.youtube.com/watch?v=OzyalrOzxE8 (slides)

[nobody43]

I understand about priorities, but don't agree on sandboxing: moving security to user's decision and outside of outer kernel governance won't do the job. Either way, thanks for the answer.

[beroal]

I don't understand how sandboxing is different from AppArmor. You still need to write what OS resources a program can access. You do this even in Android. How a generic profile is possible?

[nobody43]

Because sandboxing is a user's choice, but MAC is an admin's choice. And when malware from userspace have a choice - of course it will run unrestricted.

[beroal]

Because sandboxing is a user's choice, but MAC is an admin's choice. And when malware from userspace have a choice - of course it will run unrestricted.

AFAIK, AppArmor developers plan to allow a user to create and use profiles that will be valid only for that user.

[nobody43]

I hope it won't be controlled by the unprivileged user.

[beroal]

Why is this a problem?

[nobody43]

If you have restrictions - they should reside on outer layer of controlled space.
As I said, if there is malware in userspace - it could just unload such profile, choose not to use a sandbox, etc.

[beroal]

You forgot that AppArmor is enabled, so user isolation is not the only form of isolation. In order to unload profiles, a process needs the specific set of permissions which are absent in typical profiles (including profiles in this repository). Actually, even confined programs working under the root user can't unload profiles!

[roddhjav]

To sum up, sandboxing and confinement are two different things, both are needed and not applied to the same kind of software.

You may want to have a look at my talk to LSS, it presents some of the security arch behind the project: https://www.youtube.com/watch?v=OzyalrOzxE8 (slides)

I will try to expand a bit the security architecture section of the doc in the coming months.