5 ms·

I've found it interesting that systemd and Linux user permissions/groups never come into the sandboxing discussions. They're both quite robust, offer a good de

I've found it interesting that systemd and Linux user permissions/groups never come into the sandboxing discussions. They're both quite robust, offer a good deal of customization in concert,and by their nature, are fairly low cost.

moezd 9mo ago
This assumes people know more than just writing Dockerfiles and push straight to production. This is still a rarity.
- ijustlovemath 9mo ago
  Nowadays, it's fairly simple to ask for a unit file and accompanying bash script/tests for correctness. I think the barrier in that sense has practically vanished.
pjmlp 9mo ago
Because that is actually UNIX user permissions/groups, with a long history of what works, and what doesn't?
ape4 9mo ago
cgroups are part of whats used to implement docker and podman
- ijustlovemath 9mo ago
  True, and they do indeed offer an additional layer of protection (but with some nontrivial costs). All (non-business killing) avenues should be used in pursuit of defense in depth when it comes to sandboxing. You could even throw a flatpak or firejail in, but that starts to degrade performance in noticeable ways (though I've found it's nice to strive for this in your CI).
  - TingPing 9mo ago
    Namespaces are very lightweight though? Like single digit overhead.
nextaccountic 9mo ago
Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model Anyway I already linked this elsewhere in this thread but in this comment it's a better fit https://xkcd.com/1200/ https://xkcd.com/1200/
- fsflover 9mo ago
  This is why my daily driver is https://qubes-os.org https://qubes-os.org
- theteapot 9mo ago
  I feel like apparmor is getting there, very, very slowly. Just need every package to come with a declarative profile or fallback to a strict default profile.
- curt15 9mo ago
  >And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model Unix permissions remain a fundamental building block of Android's sandbox. Each app runs as its own unix user.
  - surajrmal 9mo ago
    Android sandboxing works in spite of the underlying security model, not because of it. It's also really selinux that does a lot of heavy lifting.
  - goodthenandnow 9mo ago
vbezhenar 9mo ago
Linux kernel is ridden with local privilege escalation vulnerabilities. This approach works for trusted software that you just want to contain, but it won't work for malicious software.
- viraptor 9mo ago
  Ridden? There are issues from time to time, but it's not like you can grab the latest, patched Ubuntu LTS and escalate from an unprivileged seccomp sandbox that doesn't include crazy device files.
  - vbezhenar 9mo ago
    Any sandbox technology works fine until it isn't. It's not like you could escape Java sandbox, but Java applets were removed from the browsers due to issues being found regularly. In the end, browser sandbox is one of the few that billions of people use and run arbitrary code there every day, without even understanding that. The only comparable technology is qemu. I don't think there are many hosters who will hand off user account to a shared server and let you go wild there.
    - viraptor 9mo ago
      > Any sandbox technology works fine until it isn't. Tautology is tautology. > but Java applets were removed from the browsers Java applets provided more scope compared to the browser itself, not less. They're not really comparable to seccomp or namespaces. > hosters who will hand off user account to a shared server There's lots of CI or function runners that expose docker-like environments.
      - vbezhenar 9mo ago
        > Java applets provided more scope compared to the browser itself, not less. They're not really comparable to seccomp or namespaces. They are comparable because they provided a restricted sandbox to execute untrusted code. > There's lots of CI or function runners that expose docker-like environments. These are running inside VMs.
hendry 9mo ago
Agreed! systemd nspawn is actually pretty awesome, though not many people use it.
srcreigh 9mo ago
It shouldn’t come up because it’s not sufficient. How would systemd prevent local JavaScript code from sending DNS, http, webrtc network requests when it’s opened in the users browser?
realityfactchex 9mo ago
> user permissions/groups never come into the sandboxing discussions Sometimes *nix user accounts for AI agent sandboxing does come up in discussions. At [0], HN user netcoyote linked to his sandvault tool [1], which "sandboxes AI agents in a MacOS limited user account". Actually seems like a great idea IMO, to be lightweight, generic, and robust-enough. [0] https://news.ycombinator.com/item?id=46760777 https://news.ycombinator.com/item?id=46760777 [1] https://github.com/webcoyote/sandvault https://github.com/webcoyote/sandvault

moezd 9mo ago

This assumes people know more than just writing Dockerfiles and push straight to production. This is still a rarity.

ijustlovemath 9mo ago
Nowadays, it's fairly simple to ask for a unit file and accompanying bash script/tests for correctness. I think the barrier in that sense has practically vanished.

pjmlp 9mo ago

Because that is actually UNIX user permissions/groups, with a long history of what works, and what doesn't?

ape4 9mo ago

cgroups are part of whats used to implement docker and podman

ijustlovemath 9mo ago
True, and they do indeed offer an additional layer of protection (but with some nontrivial costs). All (non-business killing) avenues should be used in pursuit of defense in depth when it comes to sandboxing. You could even throw a flatpak or firejail in, but that starts to degrade performance in noticeable ways (though I've found it's nice to strive for this in your CI).
- TingPing 9mo ago
  Namespaces are very lightweight though? Like single digit overhead.

nextaccountic 9mo ago

Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model Anyway I already linked this elsewhere in this thread but in this comment it's a better fit https://xkcd.com/1200/ https://xkcd.com/1200/

fsflover 9mo ago
This is why my daily driver is https://qubes-os.org https://qubes-os.org
theteapot 9mo ago
I feel like apparmor is getting there, very, very slowly. Just need every package to come with a declarative profile or fallback to a strict default profile.
curt15 9mo ago
>And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model Unix permissions remain a fundamental building block of Android's sandbox. Each app runs as its own unix user.
- surajrmal 9mo ago
  Android sandboxing works in spite of the underlying security model, not because of it. It's also really selinux that does a lot of heavy lifting.
- goodthenandnow 9mo ago

vbezhenar 9mo ago

Linux kernel is ridden with local privilege escalation vulnerabilities. This approach works for trusted software that you just want to contain, but it won't work for malicious software.

viraptor 9mo ago
Ridden? There are issues from time to time, but it's not like you can grab the latest, patched Ubuntu LTS and escalate from an unprivileged seccomp sandbox that doesn't include crazy device files.
- vbezhenar 9mo ago
  Any sandbox technology works fine until it isn't. It's not like you could escape Java sandbox, but Java applets were removed from the browsers due to issues being found regularly. In the end, browser sandbox is one of the few that billions of people use and run arbitrary code there every day, without even understanding that. The only comparable technology is qemu. I don't think there are many hosters who will hand off user account to a shared server and let you go wild there.
  - viraptor 9mo ago
    > Any sandbox technology works fine until it isn't. Tautology is tautology. > but Java applets were removed from the browsers Java applets provided more scope compared to the browser itself, not less. They're not really comparable to seccomp or namespaces. > hosters who will hand off user account to a shared server There's lots of CI or function runners that expose docker-like environments.
    - vbezhenar 9mo ago
      > Java applets provided more scope compared to the browser itself, not less. They're not really comparable to seccomp or namespaces. They are comparable because they provided a restricted sandbox to execute untrusted code. > There's lots of CI or function runners that expose docker-like environments. These are running inside VMs.

hendry 9mo ago

Agreed! systemd nspawn is actually pretty awesome, though not many people use it.

srcreigh 9mo ago

It shouldn’t come up because it’s not sufficient. How would systemd prevent local JavaScript code from sending DNS, http, webrtc network requests when it’s opened in the users browser?

realityfactchex 9mo ago

> user permissions/groups never come into the sandboxing discussions Sometimes *nix user accounts for AI agent sandboxing does come up in discussions. At [0], HN user netcoyote linked to his sandvault tool [1], which "sandboxes AI agents in a MacOS limited user account". Actually seems like a great idea IMO, to be lightweight, generic, and robust-enough. [0] https://news.ycombinator.com/item?id=46760777 https://news.ycombinator.com/item?id=46760777 [1] https://github.com/webcoyote/sandvault https://github.com/webcoyote/sandvault