Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



> 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.


Afaik 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.


You don't need any fancy packaging to restrict ptrace: https://www.kernel.org/doc/Documentation/security/Yama.txt


I'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.


What do you mean? If package developers don't specify permissions correctly, their code doesn't work when sandboxed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: