Live data from Hacker News

Linux Sandboxes and Fil-C

fil-c.org

11–20 of 162 posts

Re: Linux Sandboxes and Fil-C

#11
post #4

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

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

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

Re: Linux Sandboxes and Fil-C

#12
post #8
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…

If you are really concerned you should do this and then report back. Otherwise it is just a mild form of concern trolling.

I checked the the code, reported a bug, and Filip fixed it. Therefore, as I said, I was a little concerned.

Re: Linux Sandboxes and Fil-C

#14
post #12
post #8

Earlier quoted context omitted.

If you are really concerned you should do this and then report back. Otherwise it is just a mild form of concern trolling.

I checked the the code, reported a bug, and Filip fixed it. Therefore, as I said, I was a little concerned.

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

Re: Linux Sandboxes and Fil-C

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

> a perfectly ambiguous mix of truth and FUD

Congrats on Fil-C reaching heisentroll levels!

Re: Linux Sandboxes and Fil-C

#16
post #12

Earlier quoted context omitted.

I checked the the code, reported a bug, and Filip fixed it. Therefore, as I said, I was a little concerned.

Yes, 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 o…

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to.

At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements about the actual security benefits should be independently verified -this hasn't happened yet, but it probably will, as the project is gaining increasing attention.

Re: Linux Sandboxes and Fil-C

#17
post #13

There'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/

That's a sandboxing technology but not a memory safety technology.

You can totally achieve weird execution inside the rlbox.

Re: Linux Sandboxes and Fil-C

#18
post #16

Earlier quoted context omitted.

Yes, 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 o…

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to. At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements a…

I would suggest you re-read your comment in a week or so to see if by then you are far enough away from writing it to see how others perceive it. If it wasn't your intention to be negative then maybe it is my non-native English capability that is the cause of this but even upon re-reading it that's how I perceive it.

- You start off with commenting that the author has a knack for self promotion and invention. My impression is that he's putting in a status report for a project that is underway.

- you follow this up with something that you can't possibly know and use that to put the project down, whilst at the same time positioning yourself as a higher grade authority because you are apparently able to see something that others do not, effectively doing that which you accuse the author of: self promotion.

- You then double down on this by showing that it was you who pointed out to the author that there was a bug in the software, which in the normal course of open source development is not usually enough to place yourself morally or technically above the authors.

- You then in your more or less official capacity of established critic warn others to hold off putting this project to the test until 'adults' have reviewed it.

- And then finally you suggest they do it anyway, with your permission this time (and of course now amply warned) with the implicit assumption that problems will turn up (most likely this will be the case) and that you hope 'there won't be too many false positives', strongly suggesting that there might be.

And in your comment prior to this reply you do that once again, making statements that put words in the mouth of the author.

Re: Linux Sandboxes and Fil-C

#19
post #16

Earlier quoted context omitted.

Yes, 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 o…

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to. At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements a…

> "If I don't make big claims, no one will notice."

I am making big claims because there are big claims to be made.

> he statements about the actual security benefits should be independently verified -this hasn't happened yet

I don't know what this means. Folks other than me have independently verified my claims, just not exhaustively. No memory safe language runtime has been exhaustively verified, save maybe Spark. So you're either saying something that isn't true at all, or that could be said for any memory safe language runtime.

Re: Linux Sandboxes and Fil-C

#20
post #13

There'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/

That's a sandboxing technology but not a memory safety technology. You can totally achieve weird execution inside the rlbox.

Running 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.
Post reply on HN