Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Sandboxes and Fil-C

fil-c.org

Post reply on HN
Print view View original

61–70 of 162 posts

Re: Linux Sandboxes and Fil-C

#61

Post by zozbot234 »

pizlonator wrote: post #17
pornel wrote: post #13

There's a hybrid approach of C -> WASM -> C compilation, which ends up controlling every OS interaction and sandboxing memory access like WASM, while technically remaining C code: https://rlbox.dev/

That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.

Wasm now supports multiple modules and multiple linear memories per module, so it ought to be quite possible to compile C to Wasm in a way that enforces C's object access rules, much like CHERI if perhaps not Fil-C itself.

Re: Linux Sandboxes and Fil-C

#62

Post by IshKebab »

jart wrote: post #27
pornel wrote: post #13

There's a hybrid approach of C -> WASM -> C compilation, which ends up controlling every OS interaction and sandboxing memory access like WASM, while technically remaining C code: https://rlbox.dev/

WASM sandboxes don't do much to guarantee the soundness of your program. It can hose your memory all it wants, it can just only do so within the confines of the sandbox. Using a sandbox also limits what you can do with a system. With stuff like SECCOMP you have to methodically define policies for all its interactions. Like you're dealing with two systems. It's very bureaucratic and the reason we do it, is because we…

> It can hose your memory all it wants, it can just only do so within the confines of the sandbox.

True, although as I understand it the WASI component model at least allows multiple fine-grained sandboxes, so it's somewhere in-between per-object capabilities and one big sandbox for your entire program. I haven't actually used it yet so I might be wrong about that.

> so you'll probably have to wait ten years to get something comparable from WASI

I think for many WASI use cases the capability control would be done by the host program itself, so you don't need OS-level support for it. E.g. with Wasmtime I do

  WasiCtxBuilder::new()
        .allow_tcp(false)
        .allow_udp(false)
        .allow_ip_name_lookup(false)
But yeah a standard WASI program can't itself decide to give up capabilities.

Re: Linux Sandboxes and Fil-C

#63

Post by IshKebab »

zozbot234 wrote: post #61
pizlonator wrote: post #17

Earlier quoted context omitted.

That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.

Wasm now supports multiple modules and multiple linear memories per module, so it ought to be quite possible to compile C to Wasm in a way that enforces C's object access rules, much like CHERI if perhaps not Fil-C itself.

You wouldn't be able to get quite as fine-grained. One memory per object is probably horrifically slow. And I don't know about Fil-C, but CHERI at least allows capabilities (pointers with bounds) to overlap and subset each other. I.e. you could allocate an arena and get a capability for that, and then allocate an object inside that arena and get a smaller capability for that, and then get a pointer to a field in that object and get capability just for that field.

Re: Linux Sandboxes and Fil-C

#64

Post by [deleted] »

ComputerGuru wrote: post #20
pizlonator wrote: post #17

Earlier quoted context omitted.

That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.

Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun. But, yeah, it’s runtime safety, so going to wasm as a middle step doesn’t do much.

[deleted]

Re: Linux Sandboxes and Fil-C

#65

Post by deredede »

integralid wrote: post #57
pizlonator wrote: post #31

Earlier quoted context omitted.

It’s true that a full blown VM is an excellent sandbox. The usual situation is like what chrome or OpenSSH want: - They want to be able to do dangerous things by design. Chrome wants to save downloads. Chrome wants to call rendering APIs. OpenSSH wants to pop a shell. - They want to deal with untrusted inputs. Chrome downloads things off the internet and parses them. OpenSSH has a protocol that it parses. So you want…

Does it even work with openssh example? Pwning the parser progress will let attacker spoof arbitrary communication, which in case of SSH lets them execute arbitrary commands. Or is there a smart way to work around that?

You can send arbitrary commands, but they will be rejected unless you provide valid credentials first.

Re: Linux Sandboxes and Fil-C

#66

Post by pjmlp »

IshKebab wrote: post #62
jart wrote: post #27

Earlier quoted context omitted.

WASM sandboxes don't do much to guarantee the soundness of your program. It can hose your memory all it wants, it can just only do so within the confines of the sandbox. Using a sandbox also limits what you can do with a system. With stuff like SECCOMP you have to methodically define policies for all its interactions. Like you're dealing with two systems. It's very bureaucratic and the reason we do it, is because we…

> It can hose your memory all it wants, it can just only do so within the confines of the sandbox. True, although as I understand it the WASI component model at least allows multiple fine-grained sandboxes, so it's somewhere in-between per-object capabilities and one big sandbox for your entire program. I haven't actually used it yet so I might be wrong about that. > so you'll probably have to wait ten years to get s…

WASI is basically CORBA, and DCOM, PDO for newer generations.

Or if you prefer the bytecode based evolution of them, RMI and .NET Remoting.

I don't see it going that far.

The WebAssembly development experience on the browser mostly still sucks, especially the debugging part, and on the server it is another yet another bytecode.

Finally, there is hardly any benefit over OS processes, talking over JSON-RPC (aka how REST gets mostly used), GraphQL, gRPC, or plain traditional OS IPC.

Re: Linux Sandboxes and Fil-C

#67

Post by pjmlp »

ComputerGuru wrote: post #20
pizlonator wrote: post #17

Earlier quoted context omitted.

That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.

Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun. But, yeah, it’s runtime safety, so going to wasm as a middle step doesn’t do much.

Finally reality is catching up with the WASM sales pitch against other bytecode formats introduced since 1958, regarding security and how great it is over anything else.

Re: Linux Sandboxes and Fil-C

#68

Post by pjmlp »

burakemir wrote: post #30

My trouble with separate categories "memory safety technology" and "sandboxing technology" is that something like WASM execution is both: * Depending on how WASM is used, one gets safety guarantees. For example, memory is not executable. * Privileges are reduced as a WASM module interacts with the environment through the WASM runtime and the embedder Now, when one compiles C to WASM one may well compile things with b…

Depends on how it is used is already a sign that WebAssembly isn't really as safe as being sold, by many of its advocates, versus other bytecode formats.

Like, C is actually really safe, it only depends on how it is being used.

People only have to enumerate the various ways and tools to write safe code in C.

Problem solved, or so we get to believe.

Re: Linux Sandboxes and Fil-C

#69

Post by silon42 »

pornel wrote: post #10
loeg wrote: post #4

Sort of similarly, I'd like to see more use of sandboxing in memory-safe language programs. But I don't see a ton of people using these OS primitives in, e.g., Rust or Go.

There's a need for some portable and composable way to do sandboxing. Library authors you can't configure seccomp themselves, because the allowlist must be coordinated with everything else in the whole process, and there's no established convention for negotiating that. Seccomp has its own pain points, like being sensitive to libc implementation details and kernel versions/architectures (it's hard to know what syscal…

To be properly useful as a sandbox, it would be nice to have a tool that would run another process/executable in a sandboxed environment.

Basically a tool that would allow to run flatpaks/AppImages/ etc...

Maybe firejail already does all that can be done without using a VM.

Re: Linux Sandboxes and Fil-C

#70

Post by torginus »

pizlonator wrote: post #51
quotemstr wrote: post #49

Earlier quoted context omitted.

> Only if the program was written in a way that allowed for legitimate access to P1. You’re articulating this as if P1 was out of thin air; it’s not. My program: if (p == P2) return p[attacker_controlled_index]; If the return statement can access P1, disjoint from P2, that's a weird execution for any useful definition of "weird". You can't just define the problem away. Your central claim is that you can take any old…

> that's a weird execution for any useful definition of "weird". Weird execution is a term of art in the security biz. This is not that. Weird execution happens when the attacker can control all of memory, not just objects the victim program rightly loaded from the heap. > Your central claim is that you can take any old C program, compile it with Fil-C, and get a memory-safe C program. Yes. Your program is memory saf…

Sorry to intrude on the discussion, but I have a hard time grasping how to produce the behavior mentioned by quotemstr. From what I understand the following program would do it:

    int arr1[] = {1, 2, 3, 4, 5};
    int arr2[] = {10, 20, 30, 40, 50};
    int *p1 = &arr1[1];  
    int *p2 = &arr2[2];  
    int *p = choose_between(p1,p2);

    //then sometime later, a function gets passed p
    // and this snippet runs
    if (p == p2) {
     //p gets torn by another thread
     return p; // this allows an illegal index/pointer combo, possibly returning p1[1]
    }
Is this program demonstrating the issue? Does this execute under Fil-C's rules without a memory fault? If not, could you provide some pseudocode that causes the described behavior?
Post reply on HN