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

21–30 of 162 posts

Re: Linux Sandboxes and Fil-C

#21

Post by jagrsw »

jacquesm wrote: post #18
jagrsw wrote: post #16

Earlier quoted context omitted.

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to. At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements a…

I would suggest you re-read your comment in a week or so to see if by then you are far enough away from writing it to see how others perceive it. If it wasn't your intention to be negative then maybe it is my non-native English capability that is the cause of this but even upon re-reading it that's how I perceive it. - You start off with commenting that the author has a knack for self promotion and invention. My impr…

You're right, my tone was off.

Re: Linux Sandboxes and Fil-C

#22

Post by jagrsw »

pizlonator wrote: post #19
jagrsw wrote: post #16

Earlier quoted context omitted.

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to. At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements a…

> "If I don't make big claims, no one will notice." I am making big claims because there are big claims to be made. > he statements about the actual security benefits should be independently verified -this hasn't happened yet I don't know what this means. Folks other than me have independently verified my claims, just not exhaustively. No memory safe language runtime has been exhaustively verified, save maybe Spark.…

To clarify the position, my concern isn't that the project is bad - it's that security engineering is a two-front war. You have to add new protections (memory safety) without breaking existing contracts (like ld.so behavior).

When a project makes 'big claims' about safety, less technical users might interpret that as 'production ready'. My caution is caused by the fact that modifying the runtime is high-risk territory where regressions can introduce vulns that are distinct from the memory safety issues you are solving.

The goal is to prevent the regression in the first place. I'm looking forward to seeing how the verification matures and rooting for it.

Re: Linux Sandboxes and Fil-C

#23

Post by jart »

jagrsw wrote: post #6

The author has a knack for generating buzz (and making technically interesting inventions) :) I'm a little concerned that no one (besides the author?) has checked the implementation to see if reducing the attack surface in one area (memory security) might cause problems in other layers. For example, Filip mentioned that some setuid programs can be compiled with it, but it also makes changes to ld.so. I pointed this o…

I've been doing just that. If there's a way to break fil-c we're gonna find it.

Re: Linux Sandboxes and Fil-C

#24

Post by pizlonator »

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.

> Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun.

For all you know that’s a bug in the wasm port of the codec.

> it’s runtime safety

So is Fil-C

The problem with wasm is that an OOBA in one C allocation in the wasm guest can still give the attacker the power to clobber any memory in the guest. All that’s protected is the host. That’s enough to achieve weird execution.

Hence why I say that wasm is a sandbox. It’s not memory safety.

Re: Linux Sandboxes and Fil-C

#26

Post by pizlonator »

jagrsw wrote: post #22
pizlonator wrote: post #19

Earlier quoted context omitted.

> "If I don't make big claims, no one will notice." I am making big claims because there are big claims to be made. > he statements about the actual security benefits should be independently verified -this hasn't happened yet I don't know what this means. Folks other than me have independently verified my claims, just not exhaustively. No memory safe language runtime has been exhaustively verified, save maybe Spark.…

To clarify the position, my concern isn't that the project is bad - it's that security engineering is a two-front war. You have to add new protections (memory safety) without breaking existing contracts (like ld.so behavior). When a project makes 'big claims' about safety, less technical users might interpret that as 'production ready'. My caution is caused by the fact that modifying the runtime is high-risk territor…

> without breaking existing contracts (like ld.so behavior)

If you think that Fil-C regresses ld.so then get specific. Otherwise what you’re doing is spreading fear, uncertainty, and doubt for no good reason.

Fil-C has always honored the setuid behavior provided by ld.so. There was a bug - since fixed - that the Fil-C runtime called getenv instead of secure_getenv.

> When a project makes 'big claims' about safety, less technical users might interpret that as 'production ready'.

Fil-C is production ready and already has production users.

Re: Linux Sandboxes and Fil-C

#27

Post by jart »

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 don't trust our programs to behave.

With Fil-C you get a different approach. The language and runtime offer a stronger level of assurance your program can only behave, so you can trust it more to have unfettered access to the actual system. You also have the choice to use Fil-C with a sandbox like SECCOMP as described in the blog post, since your Fil-C binaries are just normal executables that can access powerful Linux APIs like prctl. It took Linux twenty years to invent that interface, so you'll probably have to wait ten years to get something comparable from WASI.

Re: Linux Sandboxes and Fil-C

#28

Post by ComputerGuru »

pizlonator wrote: post #24
ComputerGuru wrote: post #20

Earlier quoted context omitted.

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.

> Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun. For all you know that’s a bug in the wasm port of the codec. > it’s runtime safety So is Fil-C The problem with wasm is that an OOBA in one C allocation in the wasm guest can still give the attacker the power to clobber any memory in the guest. All that’s protected is the host. That’…

I’m not disagreeing with anything you said about wasm?

Re: Linux Sandboxes and Fil-C

#29

Post by [deleted] »

jagrsw wrote: post #6

The author has a knack for generating buzz (and making technically interesting inventions) :) I'm a little concerned that no one (besides the author?) has checked the implementation to see if reducing the attack surface in one area (memory security) might cause problems in other layers. For example, Filip mentioned that some setuid programs can be compiled with it, but it also makes changes to ld.so. I pointed this o…

[deleted]

Re: Linux Sandboxes and Fil-C

#30

Post by burakemir »

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 bugs. A memory access bug in C is still a memory access bug, but its consequences can be limited in WASM execution. Whether fail-stop behavior is guaranteed actually depends on the code the C compiler generates and the runtime (allocation/deallocation, concurrency) it sets up.

So when we enumerate immediately available security options and count WASM as sandboxing, this is not wrong. But WASM being an execution environment, one could do a lot of things, including a way of compiling and executing C that panics when a memory access bug is encountered.

Post reply on HN