Is probably a way you can get privesc on >90% of desktop users. Not that it matters since you can access saved cookies and passwords without root anyway.
that is true, but it’s more of a general problem with everyones security-sensitive settings being stored in a writeable place. sudo could do better though, by showing you what command you are running when asking for credentials.
aside: I’m really annoyed that run0, which is mostly reasonable, prints the action it asks authentication for as
Authentication is required to start transient unit 'run-p695148-i710731.service'.
which is completely useless. it almost fixed most of the problems with sudo, and then decided to leak implementation details in this particular spot.
author here, did not expect this to surface after so much time lol. I guess it doesn’t matter much anymore, since deno will probably be dead soon, but it was weird while it lasted.
Last I heard it still has an active fork which is pulling out all the node compat and going back to the basics.
Honestly I think being set free from its company will prove good for it, because node compat was a "let's cash in" move, not one that made sense given the project's own vision. I'm not the first person to point this out either, but I very much agree with others who have.
It is unfortunate that Deno specifically declined to pursue a capability based security model, which would have moved the needle.
But who are we kidding? It's JavaScript/TypesScript, security and correctness are not core value in this ecosystem. I'm hoping AI can make high assurance languages feasible and ergonomic. Until then, I'm staying out of the security world.
bwrap doesn't give you a one-liner, but a vertical scan through that manpage should allow you to construct something reasonable. For example, the following works fine:
EDIT: yes, it's a mouthful, but anything more specific becomes opinionated, and bwrap tries to be unopinionated. Writing an opinionated sandboxing tool on top of bwrap would essentially be about the above in terms of lines of code, plus whatever configuration you want to expose.
xonix | 15 hours ago
Java since its inception had similar concept of Security Manager, which was eventually deprecated and removed: https://openjdk.org/jeps/411
I think it was "broken by design" similarly to the Deno's case.
ambiso | 7 hours ago
Good article; though regarding the sudo example - most people's sudo is not really secure in any way:
Is probably a way you can get privesc on >90% of desktop users. Not that it matters since you can access saved cookies and passwords without root anyway.
goldstein | 4 hours ago
that is true, but it’s more of a general problem with everyones security-sensitive settings being stored in a writeable place. sudo could do better though, by showing you what command you are running when asking for credentials.
aside: I’m really annoyed that
run0, which is mostly reasonable, prints the action it asks authentication for aswhich is completely useless. it almost fixed most of the problems with sudo, and then decided to leak implementation details in this particular spot.
ambiso | 6 hours ago
Interesting: https://github.com/systemd/systemd/issues/42992
goldstein | 4 hours ago
author here, did not expect this to surface after so much time lol. I guess it doesn’t matter much anymore, since deno will probably be dead soon, but it was weird while it lasted.
conartist6 | 2 hours ago
Last I heard it still has an active fork which is pulling out all the node compat and going back to the basics.
Honestly I think being set free from its company will prove good for it, because node compat was a "let's cash in" move, not one that made sense given the project's own vision. I'm not the first person to point this out either, but I very much agree with others who have.
indolering | 54 minutes ago
It is unfortunate that Deno specifically declined to pursue a capability based security model, which would have moved the needle.
But who are we kidding? It's JavaScript/TypesScript, security and correctness are not core value in this ecosystem. I'm hoping AI can make high assurance languages feasible and ergonomic. Until then, I'm staying out of the security world.
cmcaine | 25 minutes ago
Recommending bwrap at the bottom just reminds me that bwrap has no easy or obvious way to sandbox processes either.
https://man.archlinux.org/man/bwrap.1
I know a fair bit about linux, and idk how to use that interface to sandbox stuff properly.
The interface for Jart's pledge tool is much easier to understand (tho idk how safe it is either)
https://github.com/jart/pledge
tomsmeding | 8 minutes ago
bwrap doesn't give you a one-liner, but a vertical scan through that manpage should allow you to construct something reasonable. For example, the following works fine:
EDIT: yes, it's a mouthful, but anything more specific becomes opinionated, and bwrap tries to be unopinionated. Writing an opinionated sandboxing tool on top of bwrap would essentially be about the above in terms of lines of code, plus whatever configuration you want to expose.