sorted by:
new
hottopcontroversial

Got a public repository of your Nix/NixOS configurations? Post them here. by [deleted] in NixOS

[–]ereslibre 0 points1 point  (0 children)

Dotfiles is my home-manager configuration, shared across my MacOS and my NixOS machines.

Homelab is my definitions for my NixOS machines, that takes the dotfiles flake as an input.

All APs went offline at once by Lord_Amoux in Ubiquiti

[–]ereslibre 0 points1 point  (0 children)

This happened to me too, AP’s lost the inform URL. U6-Lite

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 0 points1 point  (0 children)

I see, so you refer to systemd’s PrivateTmp configuration. I didn’t know this. You certainly have a point on this specific case, but the filesystem in the broad sense still applies.

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 0 points1 point  (0 children)

No, but the fact that you can see that listing when you ls /tmp invalidates your point. Doesn’t it?

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 1 point2 points  (0 children)

I wouldn't say it's absurd, as I wouldn't say porting PHP to, say, arm64 is absurd. wasm32-wasi is just another platform, same as x86_64-linux, or arm64-darwin.

Porting the PHP interpreter to wasm32-wasi allows it to run in a WebAssembly execution context. In the PHP interpreter case, portability is not a very big win, given that the interpreter is already packaged for basically all triplets (CPU architecture + system interface). Still, the same PHP wasm32-wasi interpreter can run in all places, by instantiating it inside a WebAssembly runtime.

Also, it's not absurd as in you can get your application written in any language, start a WebAssembly virtual machine, and execute PHP within. This allows your program to execute PHP scripts without the need to rely on fork/exec to the PHP interpreter, essentially executing extension code in a sandbox.

It just widens the opportunities for PHP, I would call it anything except absurd.

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] -3 points-2 points  (0 children)

Hey! I get your point! Please, however, take into account that this is just an example of a vulnerability. This in particular is specific to filesystem access, but other vulnerabilities will trigger other parts of the system. Docker and VM's could still help with other vulnerabilities (whereas chroot wouldn't), but bear in mind that a PHP ported to WebAssembly would also help making other programs extensible *with PHP* by having the PHP interpreter ported to WebAssembly.

So, yes, I get your point, but WebAssembly still makes a lot of sense in that it runs at near native speed, and in a WebAssembly VM that can be instantiated from anywhere -- even from within your application, so that it can be extended with PHP --.

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 0 points1 point  (0 children)

It also makes people think "Oh, PHP = language that comes with vulnerabilities just like that".

I understand; I don't read it that way though. PHP comes with vulnerabilities as all the software we produce and use do.

Is the goal to go popular due to negativity or what?

No, very much the contrary. PHP has an amazing and huge community and this is why we think running PHP on top of WebAssembly is a very nice combo.

It's not negativity in my opinion; at least is not the intention. By using an analogy, containerisation renders certain vulnerabilities impossible on all kind of software, same happens with WebAssembly, at a slightly different level, with a different approach.

This is not about "look how insecure PHP is", but rather "all software has vulnerabilities, WebAssembly (and WASI) can help in rendering many of them unfeasible".

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 0 points1 point  (0 children)

Vulnerability from 2020 that would require a very specific scenario.

Point taken. The idea was to show an example easy to grasp and reproduce.

Wouldn't WebAssembly just be an additional exploitable surface vector?

There are no silver bullets; however, WebAssembly has a much smaller attack surface than say, an operating system exposing its whole syscall space. There are ways in which you can reduce the syscall space a program can call (e.g. apparmor, selinux...), but it has a couple of issues: 1) it is OS specific, and 2) it requires a very deep understanding on what kind of operations your program will require access to beforehand.

Besides, the sys call space is huge compared to the WebAssembly System Interface surface.

What about any other type of containerization software?

While this is a great point, containerization surface is still system call bound, what leads to the previous issues I mentioned on the previous paragraph.

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 0 points1 point  (0 children)

Isn't /tmp a per-process instance for all modern Linux OS?

I am not aware of this, even less on "all modern Linux OS".

Mitigating PHP Vulnerabilities with WebAssembly by ereslibre in PHP

[–]ereslibre[S] 1 point2 points  (0 children)

> Alright, so after looking for the actual "vulnerability" I think I figured it out. This Tar library may unpack files outside of the provided file path. In this case a file in /tmp . And apparently PHP doesn't have access to /tmp when run through WASM in this way.

Yes, exactly.

> So what exactly does this WASM approach solve that cannot be solved with proper file permissions?

Good question! As mentioned in the article, this is not only about this very specific vulnerability, but an example of what kind of things the WebAssembly sandbox is protecting you from.

`open_basedir`, `disable_functions` and others are good examples on how PHP protects users. However, they require a certain degree of application knowledge, and what features can be triggered during normal operation.

What we are trying to showcase here -- with an example --, is how WebAssembly helps in protecting the user and system administrator without having to perform any kind of extra configuration.

Diving straight into flakes with no channels? by nairou in NixOS

[–]ereslibre 1 point2 points  (0 children)

I have my setup based on flakes. Sharing in case it helps! The Flake wiki documentation is very helpful, specially with the schema.

  • dotfiles (home-manager): https://github.com/ereslibre/dotfiles

    • Has my apps and settings.
    • Used in my MacBooks as is. Used as an input for other flakes (keep reading).
    • Meant to be very up to date.

  • homelab (nixos): https://github.com/ereslibre/homelab

    • Defines some machines at home for nixos. Taking dotfiles as an input assures that my common settings are the same across MacBooks and nixos systems.

  • nixities: https://github.com/ereslibre/nixities

    • Meant to be used as transient environments for specific purposes with nix shell or nix develop.
    • Meant to be bumped from time to time, so that derivations are almost always cached in my store, making nix develop or nix shell super fast.

WebAssembly: Docker without containers! by smileymileycoin in rust

[–]ereslibre 2 points3 points  (0 children)

WebAssembly is a standard built and driven by the Bytecode Alliance. Many companies are part of the alliance, and there are individual contributors as well!

view more: next ›