June 15, 2021 8:45 PM, "Dave Voutila" wrote:
> The first link was to the paper:
>
> "A systematic analysis of the science of sandboxing"
> Maass, et.al. (2016). PeerJ Computer Science 2:e43
>
> It is most certainly not paywalled. Maybe you can try this one?
>
>
June 15, 2021 7:32 PM, "Claudio Jeker" wrote:
>> [...] It's on the official domain, so I've assumed that it was a
>> trustworthy source - I guess not? Did a hacker put it there?
> You are just trolling around.
Sorry, I was just a bit salty because of that "paper" about sandboxes.
The main point
>> And I am not letting someone write to the filesystem. Yet, they can
>> bypass that easily. `unveil("/", "rx")` gives a false illusion of
>> security, which can even trip up OpenBSD maintainers (more below).
>
> That statement has a precise meaning, so I disagree. The unveil manual
> page does
June 15, 2021 2:51 PM, "Theo de Raadt" wrote:
> "attacker"?
Isn't the purpose of pledge() and unveil() to prevent a person with
a code execution bug from damaging the system?
> Seems to be working as intended. You are letting someone run all binaries.
And I am not letting someone write to the
> "Theo de Raadt" wrote:
> Have you found anything which implies that unveil persists?
I haven't found anything which implies that unveil doesn't persist either.
Do you think that the documentation should keep developers guessing?
> unveil and pledge exist for a process to *PROTECT AGAINST IT'S
://gist.github.com/dzwdz/d65917e52cbf68262fc7216b9f963a91
It isn't mentioned in the man pages, the only mention of that behavior
is in an obscure comment deep in kern_exec.c. I wasn't able to find any
rationale behind the decision to make it this way either. Is there one?
If there isn't - what about changing
