5 ms·

And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherw

by ldng 7y ago

And when would you want to do that ? Really curious as I fail to see a usecase where the same goal could not be achieve otherwise. But there must be some otherwise the API would not have been introduced i guess.

twoodfin 7y ago
Organizing and executing code via a storage scheme other than a file system? Security issues aside, I can imagine maintaining compiled code for stored procedures in database BLOBs. Similarly, in an appropriate trust environment, I might want to ship work units to remote machines in the form of raw ELF. Copying the bits to disk just to execute them is unneeded overhead.
- shawnz 7y ago
  But a tmpfs (the usual way to do this) isn't persisted to a disk
  - gnode 7y ago
    It can be; swap and suspend-to-disk / hibernation can cause tmpfs to be written. I wonder if there's a way to execute from mlock'd or madvised memory. I can imagine this be particularly useful, if you wanted to prevent your injected program (malware? valuable IP?) from being written to disk or appearing in a core dump.
    - shawnz 7y ago
      True, but those caveats apply to OP's technique too. What I am saying is that there is no specific behavior of a tmpfs which causes things in it to be necessarily persisted to disk like the parent was suggesting. It works just like any other anonymous memory does.
gnode 7y ago
In the example given "We've managed to get access to a victim at 10.131.66.89", it's implied that nefariously injecting arbitrary binaries into a locked-down host is one use case. > otherwise the API would not have been introduced I don't think memfd_create was added specifically for the purpose of running binaries from memory; it's more generally useful in cases where you want a memory-backed file but don't want to rely on the presence of a memory-backed filesystem (tmpfs). Many programs create a file in a well-known tmpfs like /dev/shm then delete it, but memfd_create is a more sensible solution if you don't want to share memory via the filesystem. memfd_create eliminates concerns over naming and collisions.
bennofs 7y ago
Runc used by Docker actually does this. The reason is that you don't want /proc/self/exe to refer to any host path when spawning the container process (see https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html?m=1 https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-fr...). The way to fix this is to reexecute the runc binary through a memfd so that /proc/self/exe is that memfd.
justincormack 7y ago
It lets you execute files even with no writeable filesystem , which could be useful exploiting a locked down system. It is also an argument that locking down programs with no writeable fs is not sufficient for security. The memfd api has lots of other uses, the fact you can exec is just a byproduct.
- the8472 7y ago
  > It is also an argument that locking down programs with no writeable fs is not sufficient for security. It is in fact silly since write and execute are orthogonal. You can mount a filesystem as noexec. Although memfd does put a bullet into W^X aspirations.

by ldng 7y ago

twoodfin 7y ago

Organizing and executing code via a storage scheme other than a file system? Security issues aside, I can imagine maintaining compiled code for stored procedures in database BLOBs. Similarly, in an appropriate trust environment, I might want to ship work units to remote machines in the form of raw ELF. Copying the bits to disk just to execute them is unneeded overhead.

shawnz 7y ago
But a tmpfs (the usual way to do this) isn't persisted to a disk
- gnode 7y ago
  It can be; swap and suspend-to-disk / hibernation can cause tmpfs to be written. I wonder if there's a way to execute from mlock'd or madvised memory. I can imagine this be particularly useful, if you wanted to prevent your injected program (malware? valuable IP?) from being written to disk or appearing in a core dump.
  - shawnz 7y ago
    True, but those caveats apply to OP's technique too. What I am saying is that there is no specific behavior of a tmpfs which causes things in it to be necessarily persisted to disk like the parent was suggesting. It works just like any other anonymous memory does.

gnode 7y ago

In the example given "We've managed to get access to a victim at 10.131.66.89", it's implied that nefariously injecting arbitrary binaries into a locked-down host is one use case. > otherwise the API would not have been introduced I don't think memfd_create was added specifically for the purpose of running binaries from memory; it's more generally useful in cases where you want a memory-backed file but don't want to rely on the presence of a memory-backed filesystem (tmpfs). Many programs create a file in a well-known tmpfs like /dev/shm then delete it, but memfd_create is a more sensible solution if you don't want to share memory via the filesystem. memfd_create eliminates concerns over naming and collisions.

bennofs 7y ago

Runc used by Docker actually does this. The reason is that you don't want /proc/self/exe to refer to any host path when spawning the container process (see https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html?m=1 https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-fr...). The way to fix this is to reexecute the runc binary through a memfd so that /proc/self/exe is that memfd.

justincormack 7y ago

It lets you execute files even with no writeable filesystem , which could be useful exploiting a locked down system. It is also an argument that locking down programs with no writeable fs is not sufficient for security. The memfd api has lots of other uses, the fact you can exec is just a byproduct.

the8472 7y ago
> It is also an argument that locking down programs with no writeable fs is not sufficient for security. It is in fact silly since write and execute are orthogonal. You can mount a filesystem as noexec. Although memfd does put a bullet into W^X aspirations.