5 ms·
> But I've seen no justification why that should be co-mingled with package management. Building sandboxing on top of package management makes a lot of sense b
by Kinrany 4y ago
> But I've seen no justification why that should be co-mingled with package management.
Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.
- simon_o 4y ago> want sandboxing to work by default Yeah, wake me up when Flatpak is remotely close to doing this. Most "apps" simply disable the sandbox. Not to mention I'm not going to trust "app" developers setting their own permissions. That's the job of package maintainers.
- bionade24 4y agoAfaik they disable filesystem sandboxing, not process namespaces. Still better if programs can't ptrace around, although this is indeed a big issue. If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.
- simon_o 4y agoI'm not comparing sandboxing against SELinux/AppArmor. It's a social problem, not a technical one. I'm comparing "app developers holding themselves accountable" to "package maintainers dish out consequences for misbehavior". I have absolutely zero trust in the former, and lots of trust in the latter.
- account42 4y agoYou don't need any fancy packaging to restrict ptrace: https://www.kernel.org/doc/Documentation/security/Yama.txt https://www.kernel.org/doc/Documentation/security/Yama.txt
- Kinrany 4y agoWhat do you mean? If package developers don't specify permissions correctly, their code doesn't work when sandboxed.