Hacker News new | ask | show | jobs
by JCattheATM 19 days ago
It is true. The do surface level protections, but have nothing to really lock down a system. What do they provide that can restrict an attacker who managed to compromise a remote service that wasn't using pledge or unveil? On other OS's, you can set things like append only, limit files being readable by particular processes, whitelist paths or executables from where the system may execute, etc etc etc.
1 comments
yjftsjthsd-h 16 days ago
> compromise a remote service that wasn't using pledge or unveil?

You can't opt out of the protections and then complain that there are no protections

> On other OS's, you can set things like append only,

https://man.openbsd.org/chflags.1 lists such a flag

> limit files being readable by particular processes,

That's trivial by setting group/world permissions on any unix-like.

> whitelist paths or executables from where the system may execute,

So, https://why-openbsd.rocks/fact/noexec/ ?

> etc etc etc.

Etc etc etc.

link
JCattheATM 16 days ago
> You can't opt out of the protections and then complain that there are no protections

Sometimes you don't have a choice in running software that doesn't use the 'protections' an obscure OS offers. If someone wants to run Oracle, pledge and unveil is irrelivant, as where other security solutions can still protect Oracle without requiring opt-in, and to a far greater extent.

> https://man.openbsd.org/chflags.1 lists such a flag

It's too blunt, it's an all or nothing approach. You have no way to say process A can append only, but privileged process b should have no write access at all.

> That's trivial by setting group/world permissions on any unix-like.

Only in the bluntest of terms. There is no way to allow, say, a webserverto have read access to a file while not allowing a cat processes, spawned as a subprocess of that webserver process, to not have access.

> So, https://why-openbsd.rocks/fact/noexec/ ?

No, not even close. I mean allowing user a to run /bin/ls to execute while not having access to execute /bin/rm, and at the same time allowing user b to execute both, and user c to run /bin/rm but not /bin/ls

> Etc etc etc.

No, not really, since you didn't make any point that were not based on misunderstandings.

link