dz...@disroot.org(dz...@disroot.org) on 2021.06.15 14:12:22 +:
> > Seems to be working as intended. You are letting someone run all binaries.
> And I am not letting someone write to the filesystem. Yet, they can
> bypass that easily. `unveil("/", "rx")` gives a false illusion of
> security, whi
On 6/15/21 4:33 PM, dz...@disroot.org wrote:
> If it only needs access to its lock file,
> why should I give it access to my ssh keys?
I think that it is worth understanding that you can use file and process
permissions, for that.
Unveil is an extra layer, because no matter what ssh key you prov
> On Jun 15, 2021, at 11:08 AM, dz...@disroot.org wrote:
>
> A presentation is going to have a bigger effect on people than docs.
> That's the point of it.
You must lead an interesting life full of surprises.
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?
>
> https://peerj.com/articles/cs-43
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 of
Hi,
I didn't want to reply, but I saw all this thread and had to because it seems
you're on some fumes dude.
I surely knew before and after my commit that the unveil wound't descend into
the child process, what happened in this case was that I actually didn't see
that the main process actually wa
>> 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 n
dz...@disroot.org writes:
> 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
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 fil
On Tue, Jun 15, 2021 at 04:33:19PM +, dz...@disroot.org wrote:
> >> 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 st
> "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 O
dz...@disroot.org wrote:
> 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?
No, the purpose is to declare the bounds of what a program does.
So to answer your ques
dz...@disroot.org wrote:
> > If you use "exec", you have intentionally and visibly opened an escape
> > hatch to run other programs, which are EXPECTED to self-protect against
> > their own misbehaviour.
> Yet, the documentation doesn't warn about it. It's an easy mistake to make.
> Let's say that
The expected uses of unveil and pledge aren't some weird fiction
of "oh look I can use them wrong".
The interesting cases are when pledge and unveil are used correctly,
which means they reduce control or access to objects.
This is expecially true around pledge "proc exec".
Say you have program1
On Tue, Jun 15, 2021 at 11:21:03AM +, dz...@disroot.org wrote:
> > "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 gu
dz...@disroot.org wrote:
> > "Theo de Raadt" wrote:
> > If it is a shared executable, you would need to encode access to ld.so
> > and all the library environment, and additional strange things used
> > during libc initialization for various subsystems.
> >
> > That would require hard-coding a l
Currently, if an unveiled process execs another program, it doesn't
inherit the unveil paths. This means that if the unveiled process
hasn't pledged itself out of the exec syscall and it has a suitable
binary inside of its paths, it can trivially bypass unveil. Here's a
short PoC: https://gist.gith
Theo de Raadt writes:
> dz...@disroot.org wrote:
>
>> If there isn't - what about changing the kernel so unveiled paths persist
>> between execs? That would allow very easy container-like sandboxing.
>
> This last sentence bothers me a lot, I am extremely jaded having heard the
> same ideas over
dz...@disroot.org wrote:
> If there isn't - what about changing the kernel so unveiled paths persist
> between execs? That would allow very easy container-like sandboxing.
This last sentence bothers me a lot, I am extremely jaded having heard the
same ideas over and over and over.
"very easy" is
dz...@disroot.org wrote:
> Currently, if an unveiled process execs another program, it doesn't
> inherit the unveil paths. This means that if the unveiled process
> hasn't pledged itself out of the exec syscall and it has a suitable
> binary inside of its paths, it can trivially bypass unveil. Her
20 matches
Mail list logo
