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

101–110 of 162 posts

Re: Linux Sandboxes and Fil-C

#101

Post by pizlonator »

torginus wrote: post #70
pizlonator wrote: post #51

Earlier quoted context omitted.

> 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…

No, this program doesn’t demonstrate the issue.

You can’t access out of bounds of whatever capability you loaded.

Re: Linux Sandboxes and Fil-C

#102

Post by quotemstr »

pizlonator wrote: post #98
quotemstr wrote: post #52

Earlier quoted context omitted.

You may define "memory safety" as you like. I will define "trustworthy system" as one in which the author acknowledges and owns limitations instead of iteratively refining private definitions until the limitations disappear. You can define a mathematical notation in which 2+3=9, but I'm under no obligation to accept it, and I'll take the attempt into consideration when evaluating the credibility of proofs in this str…

> I will define "trustworthy system" as one in which the author acknowledges and owns limitations instead of iteratively refining private definitions until the limitations disappear. You know about this limitation that you keep going on about because it’s extremely well documented on fil-c.org

[Woman walking on beach at sunset, holding hands with husband]

Voiceover: "Miracurol cures cancer."

[Couple now laughing over dinner with friends]

"Ask your doctor if Miracurol is right for you."

[Same footage continues, voice accelerates]

"In clinical trials, five mice with lymphoma received Miracurol. All five were cured. One exploded. Not tested in humans. Side effects include headache, itchiness, impotence, explosion, and death. Miracurol's cancer-free guarantee applies only to cancers covered under Miracurol's definition of cancer, available at miracurol.org. Manufacturer not responsible for outcomes following improper use. Consult your doctor."

[Couple walking golden retriever, sun flare]

Voiceover: "Miracurol. Because you deserve to live cancer-free."

Patient: "I exploded."

Miracurol: "That's extremely well documented on miracurol.org."

Re: Linux Sandboxes and Fil-C

#103

Post by pizlonator »

Too wrote: post #50

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.

Address sanitizer won’t panic/crash your program on all memory safety violations. Attackers know how to achieve remote code execution in processes running Asan. Asan’s docs specifically call out that you should not use it in prod. In other words, Asan is not memory safe. It’s just a bug finding tool.

Fil-C will panic your program, or give some kind of memory safe outcome (that is of no use to the attacker) in all of the cases that attackers use to achieve remote code execution. In other words, Fil-C is memory safe.

The fact that Fil-C achieves memory safety using runtime checks doesn’t make it any less memory safe. Even rust uses runtime checks (most importantly for array bounds). And, type systems that try to prove safety statically often amount to forcing the programmer to write the checks themselves.

Re: Linux Sandboxes and Fil-C

#104

Post by IshKebab »

Findecanor wrote: post #91
IshKebab wrote: post #63

Earlier quoted context omitted.

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…

Fil-C has like one "linear memory" per object and each capability gives read/write access to the whole object. But Fil-C has its compiler which does analysis passes for eliding bounds-checks where they are not needed, and I think it could theoretically do a better job at that than a WASM compiler with multi-memories, because C source code could contain more information. Unlike WASM, but like CHERI, every pointer in m…

It has a separate address space for each object? That seems unlikely. Is it not pretty much a software implementation of CHERI?

Re: Linux Sandboxes and Fil-C

#105

Post by quotemstr »

pizlonator wrote: post #101
torginus wrote: post #70

Earlier quoted context omitted.

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…

No, this program doesn’t demonstrate the issue. You can’t access out of bounds of whatever capability you loaded.

Fil-C lets programs access objects through the wrong pointer under data race. All over the Internet, you've responded to the tearing critique (and I'm not the only one making it) by alternatively 1) asserting that racing code will panic safely on tear, which is factually incorrect, and 2) asserting that a program can access memory only through its loaded capabilities, which is factually correct but a non sequitur for the subject at hand.

You're shredding your credibility for nothing. You can instead just acknowledge Fil-C provides memory safety only for code correctly synchronized under the C memory model. That's still plenty useful and nobody will think less of you for it. They'll think more, honestly.

Re: Linux Sandboxes and Fil-C

#106

Post by tialaramex »

foldr wrote: post #92
tialaramex wrote: post #81

Earlier quoted context omitted.

> Rust has a weaker definition if you consider that you can use `unsafe` I don't see it. Rust makes the same guarantees regardless of the unsafe keyword. The difference is only that with the unsafe keyword you the programmer are responsible for upholding those guarantees whereas the compiler can check safe Rust.

C is safe by the same logic, then? You can write safe code in anything if you don’t make mistakes.

But the definition is what we're talking about, not whether you make mistakes. Of course it's important that safe Rust is checked by the compiler, but that's crucially not part of how safety is defined.

I would guess that somebody more on the pulse of C's safety efforts could tell you whether they have a definition of memory safety for C or whether they're comfortable with an existing definition from somebody else.

Re: Linux Sandboxes and Fil-C

#107

Post by judofyr »

quotemstr wrote: post #105
pizlonator wrote: post #101

Earlier quoted context omitted.

No, this program doesn’t demonstrate the issue. You can’t access out of bounds of whatever capability you loaded.

Fil-C lets programs access objects through the wrong pointer under data race. All over the Internet, you've responded to the tearing critique (and I'm not the only one making it) by alternatively 1) asserting that racing code will panic safely on tear, which is factually incorrect, and 2) asserting that a program can access memory only through its loaded capabilities, which is factually correct but a non sequitur for…

Can you show an actual minimal C program which has this problem? I’m trying to follow along here, but it’s very hard for me to understand the exact scenario you’re talking about.

Re: Linux Sandboxes and Fil-C

#108

Post by kragen »

azakai wrote: post #41
pizlonator wrote: post #37

Earlier quoted context omitted.

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...

Correct me if I'm wrong, but with LLVM on Wasm, I think casting a function pointer to the wrong type will result in you calling some totally unrelated function of the correct type? That sounds like the opposite of safety to me.

I agree about the call stack, and don't know about GC.

Re: Linux Sandboxes and Fil-C

#109

Post by 7373737373 »

fragmede wrote: post #25

Which requirements does a full blown virtual machine not meet? By leaning on that as the sandbox, we get Qubes, but maybe I don't know what I'm talking about.

OS-level sandboxes are way too coarse grained to achieve a good "hollowing out" of the attack surface. The principle of least privilege should extend down to/start at the individual language library level (because this is where the actual trust boundaries are), or even finer grained, at the individual function or code segment level (thereby providing maximum control), and therefore not be limited to larger domains.

Most software today relies on many (imported, third party) libraries, so the security architecture should provide primitives/abstractions to manage rights at that level, which requires programming languages to implement the ability to sandbox (managing the effects of) code. If they did this with lightweight, portable virtual machines like WebAssembly, that could work.

The vast majority of code out there should be limited to pure computation and have no ability to access anything external at all (and otherwise, only what it actually requires) - yet most languages are simply incapable of providing any such guarantees. If the programmer of software cannot get ironclad assurances, they cannot in turn provide them to their users.

I'm not saying that OS-level sandboxing isn't good, just that it doesn't go far enough. And depending on the setup, it may not sufficiently limit the effects of compromised elements, and it provides no "monitoring in the small". It's also not convenient or efficient to have an entire OS instance for every single system component. Compartmented microkernel operating systems like Genode do it better imo.

Re: Linux Sandboxes and Fil-C

#110

Post by jancsika »

tialaramex wrote: post #106
foldr wrote: post #92

Earlier quoted context omitted.

C is safe by the same logic, then? You can write safe code in anything if you don’t make mistakes.

But the definition is what we're talking about, not whether you make mistakes. Of course it's important that safe Rust is checked by the compiler, but that's crucially not part of how safety is defined. I would guess that somebody more on the pulse of C's safety efforts could tell you whether they have a definition of memory safety for C or whether they're comfortable with an existing definition from somebody else.

Since you know C and you know Rust:

I'm curious what you make of quotemastr's point about a race causing a mismatch between the pointer's capability and its index. First off, in your estimation can this realistically be exploited to wreak havoc on extant C programs compiled using Fil-C? Second, is such a mismatch able to happen in safe Rust? Third, is such a mismatch able to happen in unsafe Rust?

Edit: clarification to narrow the question even further

Post reply on HN