this post was submitted on 13 Apr 2025
25 points (90.3% liked)

Linux

9849 readers
28 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
 

I've been thinking. Android implements app permissions on top of Linux, Flatpak does it too. But why is it it's not part of the kernel?

Like all executable files would be sandboxed and would only be able to access syscalls and parts of the file system if they were allowed to. Making sandboxing the default instead of having to restrict programs.

I'm not a kernel developper so this question may be naive, but it bothers my mind. I guess part of it is because of historical reasons but are there any practical ones that make it not feasable?

EDIT : Thank you all for your answers, almost all of you were very nice and explained things clearly

top 18 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 6 days ago

This sounds like SELinux … just with less understanding.

[–] [email protected] 10 points 1 week ago* (last edited 1 week ago) (1 children)

The Linux kernel already has the infrastructure required for that. Heck, Android itself, including its permission system, is built atop the Linux kernel.

Making sandboxing the default instead of having to restrict programs.

What's missing for that is work on userspace software and app packaging. The kernel can't automatically know what a program should and shouldn't be allowed to do.

Some of that work has happened, like moving from X11, which really wasn't designed around sandboxing, to Wayland.

But a lot of it requires making a permission system the norm and creating a system such that software is normally distributed with restricted permissions and developers develop around that. Like, I can use firejail and disallow write access to parts of the filesystem or network access to a program, but there isn't a broad system of appropriate pre-created profiles that applications are distributed with and way to view this. We don't have a convention for an application-private space on disk and lack of access to most of the filesystem, which Android does and apps need to be written around.

IMHO, one of the largest jumps would be Valve doing this for Steam games


a lot of games are going to be amenable to being sandboxed, don't need broad access to the system, and are closed source. There are some issues there; for Windows binaries run under Proton, WINE wasn't originally written around being isolated, and the game developers writing the software are writing to a Windows API that aren't under the control of people on the Linux side of things.

I haven't poked at snaps much or their technical underpinnings, but my understanding is that the snap packages distribute apps in a sandboxed form, so that might be the closest Linux-native approach. I don't recall seeing an obvious set of permissions required a la Android package managers, though.

[–] [email protected] 1 points 1 week ago (1 children)

You looked into flatpaks?

They work using namespaces and cgroups like containers, but have a much more unified system than podman/docker

[–] [email protected] 1 points 1 week ago

I think I've used one once or twice, but haven't delved into the system. I haven't spent time comparing snaps and flatpaks, either.

[–] [email protected] 2 points 1 week ago

Look up "capabilities-based operating systems." They exist; Linux just isn't one.

Like microkernels, capabilities require certain core architecture designs that Linux doesn't have. Like all features, there are always tradeoffs: microkernels tend to be slower because of the message passing; capabilities based systems are harder to manage. Linux's design, for all it's popularity, is about a simple a kernel design as possible. And you see people making the same decisions now: X11 is inherently multi-user and network capable. Wayland eliminates both, because it makes things more simple.

[–] [email protected] 8 points 1 week ago

Let the kernel do kernel job, chief. It aint a kernel no more if it does apps job.

[–] [email protected] 24 points 1 week ago (1 children)

Mainly because it's not the kernel's job. It provides abstractions to access the hardware, manages memory and manages processes, it doesn't care what userspace does that's userspace's problem.

The kernel is responsible for enforcing security policies, but not for writing them or discovering them. It doesn't know what an "app" is, or what a permission would look like.

It's the userspace that assigns labels to files and SELinux policies so that the kernel is programmed to know what the boundaries are. As an example, when you log in on a Linux computer, logind ends up assigning your user access to the keyboard, mouse, display and audio to your user and then starts your session and that's how you get access to those /dev nodes. If you switch user they're yanked away from you so the other user can use them without you snooping on it.

Userspace uses the kernel's features to implement the permission systems. That's basically what Flatpak does: leverage those kernel features to sandbox the application. And it works great and is effective.

Android also uses the Linux kernel and its features for its own sandbox and permission system too.

Generally, the kernel provides the tools for userspace to be able to do things, that's its purpose. For example all the OpenGL and Vulkan stuff is in userspace, not the kernel, the kernel doesn't know what Vulkan is and doesn't care. It mediates access to the GPU and reserving memory on it anf uploading code to it. The code comes from your GPU driver in userspace.

[–] [email protected] 6 points 1 week ago

A system where everything is sandboxed by default exists too, you do that with a rule that denies everything that's not explicitly labeled for being allowed.

Only your package manager knows, at install time, how to label an application such that it only have access to the stuff it needs access to. That information have to come from somewhere.

Security is inherently a compromise. You've always been able to mount /home noexec so users can't execute non-approved stuff. But then Steam doesn't work, none of the games work because that makes them all foreign executables you're not allowed to execute. Steam has Flatpak-specific code to make it work with the nested sandbox.

It's up to the distros to make those choices for the desired user experience. Most regular distros are a bit old fashioned and leaves a lot of freedom to the user. And you can have a distro for workstations at offices where you really cannot run anything but company software, for security. Or a distro like Steam OS so regular users can't really break it.

[–] [email protected] 29 points 1 week ago (1 children)

It exists, there's already selinux and apparmor.

[–] [email protected] 20 points 1 week ago (1 children)

There's also cgroups and Linux namespaces -- probably most popularly interacted with via Docker currently.

[–] [email protected] 13 points 1 week ago

That's also effectively what Flatpak and Snap uses, and also Steam's Runtime also uses containers.