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

91–100 of 162 posts

Re: Linux Sandboxes and Fil-C

#91

Post by Findecanor »

IshKebab wrote: post #63
zozbot234 wrote: post #61

Earlier quoted context omitted.

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…

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 memory is also tagged, and would lose its pointer status if overwritten by an integer, so it is still more memory-safe in that way.

Re: Linux Sandboxes and Fil-C

#92

Post by foldr »

tialaramex wrote: post #81
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…

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

Re: Linux Sandboxes and Fil-C

#93

Post by [deleted] »

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

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

[deleted]

Re: Linux Sandboxes and Fil-C

#95

Post by nickpsecurity »

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 true. I used to promote high-assurance kernels. They had low odds of coding errors but the specs could be wrong. Many problems Linux et al. solved are essentially spec-level. So, we just apply all of that to the secure designs, right?

Well, those spec issues are usually not documented or new engineers won't know where to find a full list. That means the architecturally-insecure OS's might be more secure in specific areas due to all the investment put into them over time. So, recommending the "higher-security design" might actually lower security.

For techniques like Fil-C, the issues include abstraction gap attacks and implementation problems. For the former, the model of Fil-C might mismatch the legacy code in some ways. (Ex: Ada/C FFI with trampolines.) Also, the interactions between legacy and Fil-C might introduce new bugs because integrations are essentially a new program. This problem did occur in practice in a few, research works.

I haven't reviewed Fil-C. I've forgotten too much C and the author was really clever. It might be hard to prove the absence of bugs in it. However, it might still be very helpful in securing C programs.

Re: Linux Sandboxes and Fil-C

#96

Post by quotemstr »

lifis wrote: post #79
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…

I think his argument is that you can have code this: user = s->user; if(user == bob) user->acls[s->idx]->has_all_privileges = true; And this happens: 1. s->user is initialized to alice 2. Thread 1 sets s->idx to ((alice - bob) / sizeof(...)) and s->user to Bob, but only the intval portion is executed and the capability still points to Alice 3. Thread 2 executes the if, which succeeds, and then gives all privileges to…

Exactly. I agree that this specific problem is hard to exploit.

> Seems perhaps fixable by making pointer equality require that capabilities are also equal

You'd need 128-bit atomics or something. You'd ruin performance. I think Fil-C is actually making the right engineering tradeoff here.

My point is that the way Pizlo communicates about this issue and others makes me disinclined to trust his system.

- His incorrect claims about the JVM worry me.

- His schtick about how Fil-C is safer than Rust because the latter has the "unsafe" keyword and the former does not is more definitional shenanigans. Both Fil-C and Rust have unsafe code: it's just that in the Fil-C case, only Pizlo gets to write unsafe code and he calls it a runtime.

What other caveats are hiding behind Pizlo's broadly confident but narrowly true assertions?

I really want to like Fil-C. It's good technology and something like it can really improve the baseline level of information security in society. But Pizlo is either going to have to learn to be less grandiose and knock it off with the word games. If he doesn't, he'll be remembered not as the guy who finally fixed C security but merely as an inspiration for the guy who does.

Re: Linux Sandboxes and Fil-C

#98

Post by pizlonator »

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

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

Re: Linux Sandboxes and Fil-C

#99

Post by hubabuba44 »

pizlonator wrote: post #97
hubabuba44 wrote: post #78

Why doesn't it mention landlock?

Because that’s not the sandboxing tech that either OpenSSH or the browsers use as far as I can tell. But landlock works great in Fil-C.

Thanks, I see. From the title I didn't infer that it's browser or openssh specific but that's ok.

Re: Linux Sandboxes and Fil-C

#100

Post by pizlonator »

lifis wrote: post #79
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…

I think his argument is that you can have code this: user = s->user; if(user == bob) user->acls[s->idx]->has_all_privileges = true; And this happens: 1. s->user is initialized to alice 2. Thread 1 sets s->idx to ((alice - bob) / sizeof(...)) and s->user to Bob, but only the intval portion is executed and the capability still points to Alice 3. Thread 2 executes the if, which succeeds, and then gives all privileges to…

I understand his argument.

Here are the reasons why I don’t buy it:

1. I’m not claiming that Fil-C fixes all security bugs. I’m only claiming that it’s memory safe and I am defining what that means with high precision. As with all definitions of memory safety, it doesn’t catch all things that all people consider to be bad.

2. Your program would crash with a safety panic in the absence of a race. Security bugs are when the program runs fine normally, but is exploitable under adversarial use. Your program crashes normally, and is exploitable under adversarial use.

So not only is it not likely to be present or exploitable, but if you wrote that code then you’d be crashing in Fil-C in whatever tests you ran at your desk or whenever a normal user tried to use your code.

But perhaps point 1 is still the most important: of course you can write code with security bugs in Fil-C, Rust, or Java. Memory safety is just about making a local bug not result in control of arbitrary memory in the whole program. Fil-C achieves that key property here, hence its memory safe.

Post reply on HN