4 ms·

From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Is it possible to in

From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Is it possible to instead execute the compressed application code directly and present to the resulting process a virtualized file system that decompresses the dependencies on the fly too? Then you could run the single binary without giving it any filesystem access. One way to do it would be to have have the parent process provide some routine that the kernel can call for reading a particular "file". Or perhaps just have standard embedding and compression methods that the kernel supports, so you would just provide the offsets to the kernel. I guess what I mean is: do any platforms provide the necessary syscalls to pull that off?

rkeene2 8y ago
This is in fact what Tcl Starkits/Starpacks do -- all access to the filesystem goes through the Tcl VFS, which can be redirected to the script level.
the8472 8y ago
Yes, on linux you could do this with FUSE, in principle you would still need one empty temporary directory as mountpoint, but that can be placed in a tmpfs, e.g. under /run/user/ by convention.
TheDong 8y ago
What you describe can be accomplished on linux using mount namespaces. It gives a namespaced view of the filesystem which the parent process can control via picking its root location and what is bindmounted where. You've basically described a container where the filesystem is virtualized to a safe location on disk. Disallowing reading/writing data entirely is pretty easy with seccomp or ptrace, though that's not required with namespacing.
jordwalke 8y ago
I asked this question just yesterday. The challenge (the one I was interested in) was if this can be done in a general purpose way for arbitrary programming languages so long as they used libc to go through the file system. I actually think it might be theoretically possible using LD_PRELOAD and some equivalent on OSX. I don't know why I'm compelled to want the executable to leave no trace on disk, but it seems much cleaner. However, if you _write_ to the virtual file system, that will need to change the packed binary itself which might result in problems (the binary would grow/shrink as you pack more / less files into it at runtime by writing to the "disk"). https://twitter.com/jordwalke/status/1050277143085608960 https://twitter.com/jordwalke/status/1050277143085608960 Maybe it's just not worth it and a temp directory is not so bad. I just worry about little changes to the way `mktmp` works across OS updates etc. A totally self contained executable that leaves no trace, with virtual file system support is about as isolated and reliable as you could ever hope. I just don't think anyone has been determined enough to achieve it.
- marcoperaza 8y ago
  That’s a good idea, doing it by shimming libc, but it feels kind of fragile. Go, for example, does not use libc and makes syscalls directly instead, so this would not work for any fs-accessing Go code either in the application or its dependencies. Even for things that do go through libc, wouldn’t you end up in a cat and mouse game to add shims for any new file operations added to the kernel? I suspect even shimming the existing interfaces is less straightforward than at first thought. I don’t think you can have a truly robust solution without kernel support. Maybe the FUSE kernel-side code already supports, or could be modified to support, per-process ad-hoc virtual file systems? If done right, you might even get existing fs caching and other optimizations for (closed to) “free”. I also can’t quite explain why I find this so desirable. It just feels intuitively cleaner and more robust to not have to spray files elsewhere into some cache.
GordonS 8y ago
It's far from easy, but you can create virtual filesystems on Windows using a minifilter driver. There are some wrappers, like Dokan[1], that make this a lot easier though. [1] https://github.com/dokan-dev/dokan-dotnet/blob/master/README.md https://github.com/dokan-dev/dokan-dotnet/blob/master/README...
pdonis 8y ago
> From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Isn't this a huge security hole? The user should not have write access to the application binaries.

rkeene2 8y ago

This is in fact what Tcl Starkits/Starpacks do -- all access to the filesystem goes through the Tcl VFS, which can be redirected to the script level.

the8472 8y ago

Yes, on linux you could do this with FUSE, in principle you would still need one empty temporary directory as mountpoint, but that can be placed in a tmpfs, e.g. under /run/user/ by convention.

TheDong 8y ago

What you describe can be accomplished on linux using mount namespaces. It gives a namespaced view of the filesystem which the parent process can control via picking its root location and what is bindmounted where. You've basically described a container where the filesystem is virtualized to a safe location on disk. Disallowing reading/writing data entirely is pretty easy with seccomp or ptrace, though that's not required with namespacing.

jordwalke 8y ago

I asked this question just yesterday. The challenge (the one I was interested in) was if this can be done in a general purpose way for arbitrary programming languages so long as they used libc to go through the file system. I actually think it might be theoretically possible using LD_PRELOAD and some equivalent on OSX. I don't know why I'm compelled to want the executable to leave no trace on disk, but it seems much cleaner. However, if you _write_ to the virtual file system, that will need to change the packed binary itself which might result in problems (the binary would grow/shrink as you pack more / less files into it at runtime by writing to the "disk"). https://twitter.com/jordwalke/status/1050277143085608960 https://twitter.com/jordwalke/status/1050277143085608960 Maybe it's just not worth it and a temp directory is not so bad. I just worry about little changes to the way `mktmp` works across OS updates etc. A totally self contained executable that leaves no trace, with virtual file system support is about as isolated and reliable as you could ever hope. I just don't think anyone has been determined enough to achieve it.

marcoperaza 8y ago
That’s a good idea, doing it by shimming libc, but it feels kind of fragile. Go, for example, does not use libc and makes syscalls directly instead, so this would not work for any fs-accessing Go code either in the application or its dependencies. Even for things that do go through libc, wouldn’t you end up in a cat and mouse game to add shims for any new file operations added to the kernel? I suspect even shimming the existing interfaces is less straightforward than at first thought. I don’t think you can have a truly robust solution without kernel support. Maybe the FUSE kernel-side code already supports, or could be modified to support, per-process ad-hoc virtual file systems? If done right, you might even get existing fs caching and other optimizations for (closed to) “free”. I also can’t quite explain why I find this so desirable. It just feels intuitively cleaner and more robust to not have to spray files elsewhere into some cache.

GordonS 8y ago

It's far from easy, but you can create virtual filesystems on Windows using a minifilter driver. There are some wrappers, like Dokan[1], that make this a lot easier though. [1] https://github.com/dokan-dev/dokan-dotnet/blob/master/README.md https://github.com/dokan-dev/dokan-dotnet/blob/master/README...

pdonis 8y ago

> From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Isn't this a huge security hole? The user should not have write access to the application binaries.