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

51–60 of 162 posts

Re: Linux Sandboxes and Fil-C

#51

Post by pizlonator »

quotemstr wrote: post #49
pizlonator wrote: post #48

Earlier quoted context omitted.

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

> 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 safe. You get to access P1 if p pointed at P1.

You don’t get to define what memory safety means in Fil-C. I have defined it here: https://fil-c.org/gimso

Not every memory safe language defines it the same way. Python and JavaScript have a weaker definition since they both have powerful reflection including eval and similar superpowers. Rust has a weaker definition if you consider that you can use `unsafe`. Go has a weaker definition if you consider that tearing in Go leads to actual weird execution (attacker gets to pop the entire Go type system). Java’s definition is most similar to Fil-C’s, but even there you could argue both ways (Java has more unsafe code in its implementation while Fil-C doesn’t have the strict aliasing of Java’s type system).

You can always argue that someone else’s language isn’t memory safe if you allow yourself to define memory safety in a different way. That’s not a super useful line of argumentation, though it is amusing and fun

Re: Linux Sandboxes and Fil-C

#52

Post by quotemstr »

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…

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

Nobody is trying to hide the existence of "eval" or "unsafe". You're making a categorical claim of safety that's true only under a tendentious reading of common English words. Users reading your claims will come away with a mistaken faith in your system's guarantees.

Let us each invest according to our definitions.

Re: Linux Sandboxes and Fil-C

#53

Post by oofbey »

Nit：The word “orthogonal” should not mean merely “different”. It should mean “completely unrelated” if we are drawing a proper analogy from linear algebra. Orthogonal vectors have a dot product of zero. No correlation whatsoever. As ML and linear algebra terms spread to more common language of course the terms will change their meaning. Just as “literally” now often means “figuratively” I’m not going to die on this hill. But I will try to resist degradation of terms that have specific technical meaning.

So I would very much disagree with the statement that memory safety and sandboxing are orthogonal. They are certainly different. Linearly independent even. But with a fair amount of overlap.

Re: Linux Sandboxes and Fil-C

#54

Post by procaryote »

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.

If you can rely on memory errors panicing before the memory error can have an effect, you're memory safe. Memory safety doesn't require "can't crash".

Re: Linux Sandboxes and Fil-C

#55

Post by integralid »

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.

ASan does not make your code memory safe! It is quite good at catching unintentional bugs/oob memory writes in your code, and it is quite reliable (authors claim no false positives), but it has false negatives i.e. won't detect everything. Especially if you're against someone who tries to corrupt your memory intentionally.

ASan works by (simplifying a lot) padding allocations and surrounding them with untouchable "red zone". So with some luck even this can work:

  char *a = new char[100];
  char *b = new char[1000];
  a[500] = 0; // may end up in b

Re: Linux Sandboxes and Fil-C

#57

Post by integralid »

pizlonator wrote: post #31
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.

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?

Re: Linux Sandboxes and Fil-C

#58

Post by fooker »

mxey wrote: post #56
nospice wrote: post #44

Earlier quoted context omitted.

Cough Linux cough You're getting cool tech for free. You can use it or not use it. Complaining about the name is weird.

Linus didn’t name Linux, someone else named it after him.

He did name git after himself though :)

Re: Linux Sandboxes and Fil-C

#59

Post by fsflover »

creatonez wrote: post #34
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.

When it comes to VMs, most things are solved and have near native performance, but desktop graphics are not. Due to limitations in GPU architecture, you usually have to dedicate an entire GPU to the VM to have reasonable graphical acceleration. Qubes doesn't solve this either, IIRC the apps running in VMs are glued to the host with X11 forwarding without any acceleration support.

It's planned to allow GPU for chosen, trusted VMs on Qubes: https://github.com/QubesOS/qubes-issues/issues/8552

Re: Linux Sandboxes and Fil-C

#60

Post by seabrookmx »

procaryote wrote: post #54
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.

If you can rely on memory errors panicing before the memory error can have an effect, you're memory safe. Memory safety doesn't require "can't crash".

Exactly. Or Rust wouldn't be memory safe due to the existence of unwrap().

Not that crashing can't be bad, as we saw recently with Cloudflare's recent unwrap-based incident.

Post reply on HN