7 ms·
Linux Sandboxes and Fil-C
- hurturue 11mo agoMicroVMs seem to be getting more popular. I wonder how they fit into the picture.
- pizlonator 11mo agoGood point! It would require a bit of porting (since Fil-C currently assumes you have all of the Linux syscalls). But you could probably even lift some of the microVM’s functionality into Fil-C’s memory safe userland.
- loeg 11mo agoSort of similarly, I'd like to see more use of sandboxing in memory-safe language programs. But I don't see a ton of people using these OS primitives in, e.g., Rust or Go.
- pizlonator 11mo agoI think Rust is great for sandboxing because of how Rust has basically no runtime. This is one of the nice things about rust! Go has the same problems I’m describing in my post. Maybe those folks haven’t done the work to make the Go runtime safe for sandboxing, like what I did for Fil-C.
- loeg 11mo agoSure, but even just setuiding to a restrictive uid or chrooting would go a long way, even in a managed runtime language where syscall restrictions are more challenging.
- pornel 11mo agoThere's a need for some portable and composable way to do sandboxing. Library authors you can't configure seccomp themselves, because the allowlist must be coordinated with everything else in the whole process, and there's no established convention for negotiating that. Seccomp has its own pain points, like being sensitive to libc implementation details and kernel versions/architectures (it's hard to know what syscalls you really need). It can't filter by inputs behind pointers, most notably can't look at any file paths, which is very limiting and needs even more out-of-process setup. This makes seccomp sandboxing something you add yourself to your application, for your specific deployment environment, not something that's a language built-in or an ecosystem-wide feature.
- silon42 11mo agoTo be properly useful as a sandbox, it would be nice to have a tool that would run another process/executable in a sandboxed environment. Basically a tool that would allow to run flatpaks/AppImages/ etc... Maybe firejail already does all that can be done without using a VM.
- razighter777 11mo agoI hope this project gets more traction. I would love to see a memory safe battle tested sudo or polkit in my package manager without having to install a potentially workflow breaking replacement.
- mbrock 11mo agoIf you're into Nix, check out https://github.com/mbrock/filnix https://github.com/mbrock/filnix — not yet integrated & maintained in upstream Nixpkgs, but lets you replace Nix/NixOS packages with Fil-C versions quite easily.
- razighter777 11mo agoI am into nix! it's me and my gf's daily driver. thank you.
- mbrock 11mo agoGreat! Feel free to ask questions or report problems on GitHub or the Fil-C Discord. If some package doesn't compile I can probably look into it!
- jagrsw 11mo agoThe 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 out to the author on Twitter, as it could be problematic. Setuid applications need to be written super-defensively because they can be affected by envars, file descriptors (e.g. there could be funny logical bugs if fd=1/2 is closed for a set-uid app, and then it opens something, and starts using printf(), think about it:), rlimits, and signals. The custom modifications to ld.so likely don't account for this yet? In other words, these are still teething problems with Fil-C, which will be reviewed and fixed over time. I just want to point out that using it for real-world "infrastructures" might be somewhat risky at this point. We need unix nerds to experiment with. OTOH, it's probably a good idea to test your codebase with it (provided it compiles, of course) - this phase could uncover some interesting problems (assuming there aren't too many false positives).
- jacquesm 11mo agoIf you are really concerned you should do this and then report back. Otherwise it is just a mild form of concern trolling.
- jagrsw 11mo agoI checked the the code, reported a bug, and Filip fixed it. Therefore, as I said, I was a little concerned.
- jacquesm 11mo agoYes, but instead of remarking solely on the fact that the author has a pretty good turnaround time for fixing bugs (I wished all open source projects were that fast) and listens to input belies the tone of your comment, which makes me come away with a negative view of the project, when in fact the evidence points to the opposite. It's a 'damning with faint praise' thing and I'm not sure to what degree you are aware of it but I don't think it is a fair way to treat the author and the project. HN has enough of a habit of pissing on other people's accomplishments already. Critics have it easy, playwrights put in the hours.
- pornel 11mo agoThere'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/ https://rlbox.dev/
- pizlonator 11mo agoThat's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.
- ComputerGuru 11mo agoRunning 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.
- pizlonator 11mo ago> 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.
- ComputerGuru 11mo agoI’m not disagreeing with anything you said about wasm?
- deleted 11mo ago[deleted]
- pjmlp 11mo agoFinally reality is catching up with the WASM sales pitch against other bytecode formats introduced since 1958, regarding security and how great it is over anything else.
- fragmede 11mo agoWhich 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.
- pizlonator 11mo agoIt’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 to split your process into two with privilege separation: - one process has zero privileges and does the parsing of untrusted inputs. - another process has high privilege but never deals with untrusted inputs. And then the two processes have some carefully engineered IPC protocol for talking to one another. Could you run the deprivileged process in a VM for maximum security? Yeah that’s one way to do it. But it’s cleaner to run it as a normal process, ask the OS to sandbox it (deprivilege it), and then have a local domain socket (or whatever) that the two processes can use to communicate. If you used a VM for deprivileging then: - There’d be more overhead. Chrome wants to do this per origin per tab. OpenSSH wants to do it per connection. Maybe a VM is too much - You could put the whole browser into the VM but then you’d still need something outside it for saving files. And probably for talking to the GPU. You could run OpenSSH in the VM but then that defeats the purpose (you want to use it to pop a shell after all). - You can use vsocks and other things to communicate between host and guest but it’s much more gross than the options available when using traditional process sandboxing
- integralid 11mo agoDoes 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?
- deredede 11mo ago
- burakemir 11mo agoMy 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.
- vlovich123 11mo ago> including a way of compiling and executing C that panics when a memory access bug is encountered. WASM couldn’t do that because it doesn’t have a sense of the C memory model nor know what is and isn’t safe - that information has long been lost. That kind of protection is precisely what Fil-C is doing. WASM is memory safe in that you can’t escape the runtime. It’s not memory safe in that you can escape escape the program running within the sandbox, which you can’t do with a memory safe language like Rust or Fil-C.
- pizlonator 11mo agoWasm 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 bug inside the wasm memory gives read write access to all of that memory means the attacker can make the program do whatever they want, subject to the wasm sandbox limits (ie whatever the host allows the wasm guest to do). Basically wasm amounts to a lightweight and portable replacement for running native code in a sufficiently sandboxed process
- dekerklas 11mo ago[dead]
- fooker 11mo agoWhat's the rationale for naming it after yourself?
- airstrike 11mo agoPride is as good a reason as any other
- quotemstr 11mo agoThroughout history, the prospect of glory has motivated people to do great deeds. Nothing wrong with it now.
- nospice 11mo agoCough Linux cough You're getting cool tech for free. You can use it or not use it. Complaining about the name is weird.
- mxey 11mo agoLinus didn’t name Linux, someone else named it after him.
- fooker 11mo agoHe did name git after himself though :)
- cryptonector 10mo agoI guess you're kidding, but just in case: no he didn't. The "git" was Larry McVoy.
- yjftsjthsd-h 11mo agoAnother 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.
- Too 11mo agoCan 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.
- procaryote 11mo agoIf 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".
- seabrookmx 11mo agoExactly. 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.
- brabel 11mo agoEven without unwrap, Rust could still crash on array out of bounds access. And probably more similar cases.
- Too 11mo agoFrom a definition point of view that might be right and it’s no doubt a good step up, compared to continuing with tainted data. In practice though, that is still not enough, these days we should expect higher degree of confidence from our code before it’s run. Especially with the mountains of code that LLMs will pour over us.
- procaryote 11mo agoIt's a nice ambition, but it's a different thing than memory safety
- 11mo ago
- oofbey 11mo agoNit：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.
- puilp0502 11mo agoBut it's much easier to say "orthogonal" than "linearly independent", no? As you mentioned, I think the word "orthogonal" has already lost its meaning of "dot product equals zero", and bears the meaning of "linearly independent" (i.e. dim(N) > 1) in casual speech.
- iberator 11mo agoAny wizard here? Fill-C vs Rust? Realistic comments without hype.
- forgotpwd16 11mo agoFil-C introduces a garbage collector and can result in significant slowdowns in some cases. Its main existence reason is making non-perf sensitive C/C++ memory safe, not improving the language design. If really want your stack to be C/C++ & Fil-C then your competition includes D/Nim/Go/etc, not (just) Rust/Zig. Even if it magically made C/C++ memory safe, no downsides, your question basically boils down to C vs C++ vs Rust. Don't know about you but prefer somewhat larger binaries and some compiler brawling over programming 70s style.
- kokada 11mo agoOne thing that I am interested in is the performance of Fil-C compared to other compiled programming languages that are also GC'd, especially Go.
- the-lazy-guy 11mo agoFil-C aborts your program if it detects unsafe memory operations. You very much can write code that is not memory safe, it will just crash. Also it has significant runtime cost. Rust tries to prevent you from writing memory-unsafe code. But it has official ways of overcoming these barriers ("unsafe" keyword, which tells compiler - "trust me bro, I know what I'm doing) and some soundness holes. But beause safety is proven statically by compiler, it is mostly zero-cost. ("Mostly" because some things compiler can't prove and people resort to "unsafe" + runtime checks) Two orthogonal approaches to safety. You could have Fil-C style runtime checks in Rust, in principle.
- razighter777 11mo agoBoth are great tech but solve the problem of safety differently. I would say Fil-c is great for non-performance-critical (think like somewhere between c and go/java, still very fast) existing C programs where compatibility with the existing program / security is a big concern. think ffmpeg, nginx, sudo. Fil-c: - You have a great existing c program that may have memory bugs, and you wanna make it safer. - Or you wanna write a new program in c, and be extra sure it's safe and don't mind a little performance penalty. - Or you wanna find subtle memory bugs by building your c program with fil-c (asan style) and disable it for performance in your release build. Rust is great when you want to build a new codebase from scratch, and have the time and patience to deal with the borrow checker. It also gives you some thread safety, (which is different from memory safety) at the development time cost of dealing with the borrow checker. Rust: - A new codebase where you need multithreading and safety, and want excellent performance - You need a broad ecosystem of existing packages - Your problem space benefits from a robust type system.
- hubabuba44 11mo agoWhy doesn't it mention landlock?
- anacrolix 11mo agobecause it's shit
- hubabuba44 11mo agoOk, if you say so
- nhanb 11mo agoBy "it" do you mean landlock or fil-c? Also elaboration would be nice.
- pizlonator 11mo agoBecause 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.
- hubabuba44 11mo agoThanks, I see. From the title I didn't infer that it's browser or openssh specific but that's ok.
- pizlonator 11mo agoFair point! I should add that landlock just works, and that lots of the other sandboxing techs also work
- littlecranky67 11mo agoJust dropping this: I can't load the link from Spain, as La Liga blocks access to it - football censoring.
- supernetworks 11mo agoSome of the properties of fil-c managed heaps are very similar to what CHERI can do with Cornucopia by the way: see https://dl.acm.org/doi/10.1145/3620665.3640416 https://dl.acm.org/doi/10.1145/3620665.3640416