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.
Linux Sandboxes and Fil-C
11–20 of 162 posts
Re: Linux Sandboxes and Fil-C
#12The 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.
Re: Linux Sandboxes and Fil-C
#13Re: Linux Sandboxes and Fil-C
#14Earlier 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.
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
#15The 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.…
Congrats on Fil-C reaching heisentroll levels!
Re: Linux Sandboxes and Fil-C
#16Earlier 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…
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
#17There'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/
You can totally achieve weird execution inside the rlbox.
Re: Linux Sandboxes and Fil-C
#18Earlier 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…
- 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
#19Earlier 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 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
#20There'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.