Python-in-NaCl, seeking feedback

[Dmitry Sagalovskiy]

Hello all!

We have a project to run Python in the NaCl sandbox (built around sel_ldr): Pynbox -- https://github.com/dsagal/pynbox. It recently got revamped and improved.

If you want to run untrusted Python code, it's actually pretty fantastic: easy to install (no root required), works cross-platform, supports native modules, allows configuring read/write access to specific directories.

The project actually involves a few fixes to webports and a significant feature added to NaCl's sel_ldr (improved restricted filesystem access, including Windows support).

We use it at Grist Labs, but haven't tried to push any changes upstream -- would like to gauge first if there is wider interest.

We'd love to get any feedback!

Dmitry

P.S. It's definitely too bad that NaCl is being dropped from Chrome. Last September Bradley said that they continue to care about keeping NaCl and sel_ldr working and secure. NaCl is still the best approach I know of for running native code securely in a cross-platform way. WebAssembly's potential for this use case seems very uncertain and distant. So if Google fully moves away from NaCl, it'll be up to the rest of the community to maintain it.

[Bennet Yee (余仕斌)]

hi dmitry,

that sounds like interesting work, purely from a personal perspective. has the sel_ldr changes to add restricted filesystem access undergone any security audits?

i doubt that google will review PRs for upstreaming changes, since AFAIK there is zero staff for doing this.

-bsy

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
To post to this group, send email to native-client-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--

bennet s yee
i usually don't capitalize due to mild tendonitis

[Dmitry Sagalovskiy]

Thank you Bennet!

The sel_ldr change have not undergone any security audit or actually any independent review, but we (as a company) would be interested in it too, since we'll be relying on it for the security of our own product. I am not sure who could be asked to do it.

Is it realistic to hope for the community to maintain NaCl going forward? Are there companies sponsoring such work? Would it help if our company did? (Incidentally, we *are* hiring.)

Having a userland cross-platform sandbox is kind of amazing. In the browser, I realize that WebAssembly won over NaCl in terms of standardization, but outside the browser are there any reasons to think that NaCl isn't a great approach?

Dmitry

On Tue, Jun 6, 2017 at 6:56 PM, Bennet Yee (余仕斌) <benne...@gmail.com> wrote:

hi dmitry,

that sounds like interesting work, purely from a personal perspective. has the sel_ldr changes to add restricted filesystem access undergone any security audits?

i doubt that google will review PRs for upstreaming changes, since AFAIK there is zero staff for doing this.

-bsy

On Tue, Jun 6, 2017 at 10:22 AM, Dmitry Sagalovskiy <dsa...@gmail.com> wrote:

Hello all!

We have a project to run Python in the NaCl sandbox (built around sel_ldr): Pynbox -- https://github.com/dsagal/pynbox. It recently got revamped and improved.

If you want to run untrusted Python code, it's actually pretty fantastic: easy to install (no root required), works cross-platform, supports native modules, allows configuring read/write access to specific directories.

The project actually involves a few fixes to webports and a significant feature added to NaCl's sel_ldr (improved restricted filesystem access, including Windows support).

We use it at Grist Labs, but haven't tried to push any changes upstream -- would like to gauge first if there is wider interest.

We'd love to get any feedback!

Dmitry

P.S. It's definitely too bad that NaCl is being dropped from Chrome. Last September Bradley said that they continue to care about keeping NaCl and sel_ldr working and secure. NaCl is still the best approach I know of for running native code securely in a cross-platform way. WebAssembly's potential for this use case seems very uncertain and distant. So if Google fully moves away from NaCl, it'll be up to the rest of the community to maintain it.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsubscri...@googlegroups.com.

To post to this group, send email to native-client-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--

bennet s yee
i usually don't capitalize due to mild tendonitis

[Dmitry Sagalovskiy]

I should clarify that sel_ldr changes were definitely written with security being the primary focus, and there is a discussion of security on the Pynbox README.

[Bennet Yee (余仕斌)]

hi dmitry,

i had assumed that the sel_ldr changes were written carefully. sorry if i may have misspoke and implied otherwise. it's just that independent auditing is really critical.

when I was with Google, we hired independent security penetration testing groups to conduct security audits as well as organized a security contest. security contests work well if finding vulnerabilities will help the reputations of the white-hat auditors, obviously, for future consulting gigs, and whether this is true depends on the reputation of the companies / people involved in the project. i was not that involved in the selection of security consulting companies for the pen testing, and even if i were i am not sure how much i could tell you.

whether the community could maintain NaCl going forward is an interesting question. i don't know if any other companies are sponsoring NaCl-related work now, though at various points earlier some were. keeping NaCl going in the longer term will involve not just maintaining the trusted computing base (essentially sel_ldr), but also ensuring that the compiler and toolchain support is maintained. the glibc / GNU toolchain support was just recently dropped. the LLVM-based compiler back-end changes may survive longer, and may be easier to maintain for newer front-end changes (new language standards / extensions). this moves at a different pace than innovations that might use NaCl, obviously. but having a cross-platform sandbox is useless unless people can generate efficient code to run inside it.

in any case, "the community" needs to be more than one or three companies / independent contributors. some of the politics over NaCl was over how much control Google had over PPAPI and API evolution, and i would imagine that having one company effectively control it is not going to go over any better. but then i suck at politics. :-)

outside the browser, NaCl (and PNaCl) has limitations that can reduce its usefulness. on x86-64 the address space for the untrusted code is only 4G, and on x86-32 (maybe nobody cares) and arm (some do?) the address space is only 1G. even if all we cared about was x86-64 for all OSes, 4G is not that much space for some more modern, VM-hungry applications.

-bsy

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.

To post to this group, send email to native-client-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

[Dmitry Sagalovskiy]

This is really informative, thank you!

At the moment, NaCl is the only cross-platform sandbox I know of. Are there alternatives?

As for community support, I guess the big question is whether there are interested companies out there. Our small startup is interested, but definitely insufficient.

I should say that the reason we are interested is that our product allows scripting, and we want such user-produced and shared logic to be executed in the sandbox. I think Microsoft should actually want that too for Excel, and the VBA in the office suite in general -- might they be interested?

I imagine also that supporting it requires willingness of people already familiar with it -- i.e. engineers who built it. Where are they now? Do any of them remain interested in it? In particular, and out of curiosity, where are you, Bennet, now?

Dmitry

[Bennet Yee (余仕斌)]

i think most of the other NaCl engineers are still w/ google, in other, non-NaCl roles, though i know that at least 2 other NaCl/PNaCl engrs are elsewhere. i am at snap, doing other security work, recapturing the small-company vibe. i might be able to contribute to NaCl on my weekends, but unless there is critical mass it wouldn't be useful. there doesn't seem to be many other companies interested (one would imagine such would be on this list).

-bsy