Dmitrii Kuvaiskii

One common source of confusion is our `chroot` semantics of Graphene: people have a hard time wrapping their heads around the concept of chroot jails and just want everything from...

@pwmarcz It would be good to go through the "master list of issues" again and verify which ones were already fixed/became irrelevant. After this we can close this issue. I...

This is still valid for the current master: https://github.com/oscarlab/graphene/blob/af2f7809b36945382a535f95c2af7a2b32a2059a/LibOS/shim/src/sys/shim_wait.c#L231 Though we haven't encountered any real-world applications that rely on this, so assigning very low priority.

> Then we tested what would happen if an attacker changed the return value of open so that the same file descriptor value was used for both files. Interestingly that...

Thanks @shmeni! This is indeed a bug in our code (not sure if this could be exploited). The root cause is that we don't check whether `pal_handle->file.fd` returned by `ocall_open()`...

I agree that this is hardly the root cause for this issue (looks like some missing checks on Protected Files code?). But shouldn't this be considered a part of sanitization...

@shmeni I cannot reproduce your crash. Here is my diff on the latest Graphene master branch: ``` --- a/LibOS/shim/test/regression/helloworld.c +++ b/LibOS/shim/test/regression/helloworld.c @@ -1,6 +1,15 @@ +#include #include +#include +#include +#include...

@shmeni Would be interesting if you could cause a crash on Protected Files now, with #2372.

My hacky fix in #2372 is sub-par. We should actually refactor Protected Files in a much more comprehensive way, because it also shows it deficiencies for @pwmarcz's work on the...

This is true: https://github.com/oscarlab/graphene/blob/af2f7809b36945382a535f95c2af7a2b32a2059a/LibOS/shim/src/sys/shim_stat.c#L158-L163 However, the priority of this is very low. Does any application truly care?