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

41–50 of 162 posts

Re: Linux Sandboxes and Fil-C

#41

Post by azakai »

pizlonator wrote: post #37
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…

Wasm is just sandboxing. Say your C program has sensitive information in module A and a memory safety bug in module B. Running that program in wasm won’t prevent the attacker from using the bug in B to get read/write access to the data in A. In practice what the attacker will really do is use the memory safety bug to achieve weird execution: even without control over the program counter, the fact that a memory safety…

Your general point stands - wasm's original goal was mainly sandboxing - but

1. Wasm does provide some amount of memory safety even to compiled C code. For example, the call stack is entirely protected. Also, indirect calls are type-checked, etc.

2. Wasm can provide memory safety if you compile to WasmGC. But, you can't really compile C to that, of course...

Re: Linux Sandboxes and Fil-C

#42

Post by pizlonator »

quotemstr wrote: post #39
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…

It's difficult for me to have a positive opinion of the author when he responds with dismissal and derision to concerns others have raised about Fil-C and memory safety under data races. The fact is that Fil-C allows capability and pointer writes to tear. That is, when thread 1 writes pointer P2 to a memory location previously holding P1, thread 2 can observe, briefly, the pointer P2 combined with the capability for…

> Because thread 2 can observe a mismatch between a pointer and its capability, an attacker controlled index into P2 from thread 2 can access memory of an object other than the one to which P2 points.

Under Fil-C’s memory safety rules, „the object at which P points” is determined entirely by the capability and nothing else.

You got the capability for P1? You can access P1. That’s all there is to it. And the stores and loads of the capability itself never tear. They are atomic and monotonic (LLVM’s way of saying they follow something like the JMM).

This isn’t a violation of memory safety as most folks working in this space understand it. Memory safety is about preventing the weird execution that happens when an attacker can access all memory, not just the memory they happen to get a capability to.

> He claims Java has the same problem. It does not.

It does: in Java, what object you can access is entirely determined by what objects you got to load from memory, just like in Fil-C.

You’re trying to define „object” in terms of the untrusted intval, which for Fil-C’s execution model is just a glorified index.

Just because the nature of the guarantees doesn’t match your specific expectations does not mean that those guarantees are flawed. All type systems allow incorrect programs to do wrong things. Memory safety isn’t about 100% correctness - it’s about bounding the fallout of incorrect execution to a bounded set of memory.

> That's correct but irrelevant: thread 2 has P2 and it's paired with the wrong capability. Kaboom.

Yes, kaboom. The kaboom you get is a safety panic because a nonadversarial program would have had in bounds pointers and the tear that arises from the race causes an OOB pointer that panics on access. No memory safe language prevents adversarial programs from doing bad things (that’s what sandboxes are for, as TFA elucidates).

But that doesn’t matter. What matters is that someone attacking Fil-C cannot use a UAF or OOBA to access all memory. They can only use it to access whatever objects they happen to have visibility into based on local variables and whatever can be transitively loaded from them by the code being attacked.

That’s memory safety.

> He doesn't acknowledge corner cases like the one I've described.

You know about this case because it’s clearly documented in the Fil-C documentation. You’re just disagreeing with the notion that the pointer’s intval is untrusted and irrelevant to the threat model.

Re: Linux Sandboxes and Fil-C

#43

Post by pizlonator »

fc417fc802 wrote: post #38
pizlonator wrote: post #9

Earlier quoted context omitted.

Posts like the one I made about how to do sandboxing are specifically to make the runtime transparent to folks so that meaningful auditing can happen. > For example, Filip mentioned that some setuid programs can be compiled with it, but it also makes changes to ld.so. I pointed this out to the author on Twitter, as it could be problematic. The changes to ld.so are tiny and don’t affect anything interesting to setuid.…

Is it FUD? Approximately speaking, all software has bugs. Being an early adopter for security critical things is bound to carry significant risk. It seems like a relevant topic to bring up in this sort of venue for a project of this sort.

It’s like half FUD.

The FUDish part is that the only actual bug bro is referring to got fixed a while ago (and didn’t have to do with ld.so), and the rest is hypothetical

Re: Linux Sandboxes and Fil-C

#45

Post by quotemstr »

pizlonator wrote: post #42
quotemstr wrote: post #39

Earlier quoted context omitted.

It's difficult for me to have a positive opinion of the author when he responds with dismissal and derision to concerns others have raised about Fil-C and memory safety under data races. The fact is that Fil-C allows capability and pointer writes to tear. That is, when thread 1 writes pointer P2 to a memory location previously holding P1, thread 2 can observe, briefly, the pointer P2 combined with the capability for…

> Because thread 2 can observe a mismatch between a pointer and its capability, an attacker controlled index into P2 from thread 2 can access memory of an object other than the one to which P2 points. Under Fil-C’s memory safety rules, „the object at which P points” is determined entirely by the capability and nothing else. You got the capability for P1? You can access P1. That’s all there is to it. And the stores an…

> The kaboom you get is a safety panic

You don't always get a panic. An attacker who can get a program to access an offset he controls relative to P2 can access P1 if P2 is torn such that it's still coupled, at the moment of adversarial access, with P1's capability. That's dangerous if a program has made a control decision based on the pointer bits being P2. IOW, an attacker controlled offset can transform P2 back into P1 and access memory using P1's capability even if program control flow has proceeded as though only P2 were accessible at the moment of adversarial access.

That can definitely enable a "weird execution" in the sense that it can let an attacker make the program follow an execution path that a plain reading of the source code suggests it can't.

Is it a corner case that'll seldom come up in practice? No. Is it a weakening of memory safety relative to what the JVM and Rust provide? Yes.

You are trying to define the problem away with sleigh-of-hand about the pointer "really" being its capability while ignoring that programs make decisions based on pointer identity independent of capability -- because they're C programs and can't even observe these capabilities. The JVM doesn't have this problem, because in the JVM, the pointer is the capability.

It's exactly this refusal to acknowledge limitations that spooks me about your whole system.

Re: Linux Sandboxes and Fil-C

#46

Post by yjftsjthsd-h »

fooker wrote: post #33

What's the rationale for naming it after yourself?

Another option: It's genuinely easier, for what amounts to namespacing reasons. Like, if I came up with a cool new C compiler, I'd probably name it ${MYNAME}cc just because that's an easy identifier that is very unlikely to have a collision and doesn't require me to spend time thinking of some name that is clever, unique, and accurately conveys what the project is about.

Re: Linux Sandboxes and Fil-C

#47

Post by yjftsjthsd-h »

jart wrote: post #23
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.

Wishful thinking: Any possible chance that means you might make a Fil-C APE hybrid? It would neatly address the fact that Fil-C already needs all of its dependencies to also use Fil-C.

Re: Linux Sandboxes and Fil-C

#48

Post by pizlonator »

quotemstr wrote: post #45
pizlonator wrote: post #42

Earlier quoted context omitted.

> Because thread 2 can observe a mismatch between a pointer and its capability, an attacker controlled index into P2 from thread 2 can access memory of an object other than the one to which P2 points. Under Fil-C’s memory safety rules, „the object at which P points” is determined entirely by the capability and nothing else. You got the capability for P1? You can access P1. That’s all there is to it. And the stores an…

> The kaboom you get is a safety panic You don't always get a panic. An attacker who can get a program to access an offset he controls relative to P2 can access P1 if P2 is torn such that it's still coupled, at the moment of adversarial access, with P1's capability. That's dangerous if a program has made a control decision based on the pointer bits being P2. IOW, an attacker controlled offset can transform P2 back in…

> An attacker who can get a program to access an offset he controls relative to P2 can access P1 if P2 is torn such that it's still coupled, at the moment of adversarial access, with P1's capability

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. It’s the capability you loaded because the program was written in a way that let you have access to it. Like if you wrote a Java program in a way where a shared field F sometimes pointed to object P1. Of course that means loaders of F get to access P1.

> That can definitely enable a "weird execution"

Accessing a non-free object pointed by a pointer you loaded from the heap is not weird.

I get the feeling that you’re not following me on what „weird execution” is. It’s when the attacker can use a bug in one part of the software to control the entire program’s behavior. Your example ain’t that.

> Is it a corner case that'll seldom come up in practice? No. Is it a weakening of memory safety relative to what the JVM and Rust provide? Yes.

I don’t care about whether it’s a corner case.

My point is that there’s no capability model violation and no weird execution in your example.

It’s exactly like what the JVM provides if you think of the intval as just a field selector.

I’m not claiming it’s like what rust provides. Rust has stricter rules that are enforced less strictly (you can and do use the unsafe escape hatch in rust code to an extent that has no equal in Fil-C).

Re: Linux Sandboxes and Fil-C

#49

Post by quotemstr »

pizlonator wrote: post #48
quotemstr wrote: post #45

Earlier quoted context omitted.

> The kaboom you get is a safety panic You don't always get a panic. An attacker who can get a program to access an offset he controls relative to P2 can access P1 if P2 is torn such that it's still coupled, at the moment of adversarial access, with P1's capability. That's dangerous if a program has made a control decision based on the pointer bits being P2. IOW, an attacker controlled offset can transform P2 back in…

> An attacker who can get a program to access an offset he controls relative to P2 can access P1 if P2 is torn such that it's still coupled, at the moment of adversarial access, with P1's capability 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. It’s the capability you loaded because the program was written in a way t…

> 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 C program, compile it with Fil-C, and get a memory-safe C program. Turns out you get memory safety only if you write that C program with Fil-C's memory model and its limits in mind. If someone's going to do that, why not write instead with Rust's memory model in mind and not pay a 4x performance penalty?

Re: Linux Sandboxes and Fil-C

#50

Post by Too »

Can someone give a tldr of what makes fil-c different from just compiling with clang’s address sanitizer?

Calling it memory safe is a bit of a stretch when all it does is convert memory errors to runtime panics, or am I missing something? I mean, that’s still good, just less than I’d expect given the recent hype of fil-c being the savior for making C a competitive language again.

Post reply on HN