Sandboxing eval #3
Comments
|
I'm going to open a PR on Julia for extra-bare baremodules that won't
import even Core, so that will deal with the first part.
For the second, I think documentation on how to use the sandbox will be
sufficient.
Do you have an interest in using Sandboxes? Knowing your use case could
help inform the design.
…On Thu, 11 Mar 2021, 21:57 jtrakk, ***@***.***> wrote:
I see there are some caveats here:
- "eval'ing extra properties onto Core after a sandbox has started"
- "if the user imports any code with anything other than using X:
something_safe. Users will need to be cautious of eval available on most
module objects, for example."
Is it possible to prevent these threats too?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNZA6IAIFIVJXYAWOFS2R3TDEVERANCNFSM4ZBC7R3Q>
.
|
|
And I have a plan for making it easier to import the safe parts of modules
into the sandbox, too, but it's a bit complicated.
I might be applying for funding soon for expanding it.
…On Thu, 11 Mar 2021, 22:32 Colin Caine, ***@***.***> wrote:
I'm going to open a PR on Julia for extra-bare baremodules that won't
import even Core, so that will deal with the first part.
For the second, I think documentation on how to use the sandbox will be
sufficient.
Do you have an interest in using Sandboxes? Knowing your use case could
help inform the design.
On Thu, 11 Mar 2021, 21:57 jtrakk, ***@***.***> wrote:
> I see there are some caveats here:
>
> - "eval'ing extra properties onto Core after a sandbox has started"
> - "if the user imports any code with anything other than using X:
> something_safe. Users will need to be cautious of eval available on most
> module objects, for example."
>
> Is it possible to prevent these threats too?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#3>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABNZA6IAIFIVJXYAWOFS2R3TDEVERANCNFSM4ZBC7R3Q>
> .
>
|
|
This is entirely speculative, I don't have any investment in this kind of project, but: I think it would be very cool to have an object-capability system in julia. So I can restrict the capabilities of functions I call, and they can restrict the functions they call, etc. |
|
Yes, capabilities are precisely a motivation for this :)
…On Thu, 11 Mar 2021, 23:00 jtrakk, ***@***.***> wrote:
This is entirely speculative, I don't have any investment in this kind of
project, but: I think it would be very cool to have an object-capability
<https://github.com/dckc/awesome-ocap> system in julia. So I can restrict
the capabilities of functions I call, and they can restrict the functions
they call, etc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABNZA6J6KQ3BGAMWLUFROUDTDE4O3ANCNFSM4ZBC7R3Q>
.
|
|
I wonder what other restrictions can be applied from within julia. Like all the cgroupsv2 and nsjail things: network access, filesystem access, memory limits, etc. |
|
Yep, that's on the cards. Tho, as far as I know, all of those restrictions apply at the process level, but Julia can start new processes with OS-level restrictions like those, so long as it has the permission to do so. |
|
I don't exactly understand this but maybe it's possible to have different permissions for different threads? |
I see there are some caveats here:
"if the user imports any code with anything other than using X: something_safe. Users will need to be cautious of eval available on most module objects, for example."
Is it possible to prevent these threats too?
The text was updated successfully, but these errors were encountered: