3 ms·

As anyone who has put together a chroot knows, it isn't as simple as just preventing a process from accessing the filesystem. Most programs need to access a fil

As anyone who has put together a chroot knows, it isn't as simple as just preventing a process from accessing the filesystem. Most programs need to access a filesystem, just so they can load libc and the various other libraries it might need.

AstralStorm 7y ago
Do they now? Usually, the linker does all the loading, also known in Linux as ld.so. (even when you use dlopen) Lazy loading can thunk through kernel so that ld.so service loads things into the process - and preferably strict loading should be used.
- mnw21cam 7y ago
  Indeed. But ld.so runs in the context of the process that is starting up, so if it doesn't have access to anything, it can't.
  - AstralStorm 7y ago
    It doesn't actually have to, but you'd need a fun bit of stub code in place of unloaded function pointers etc.
- pjc50 7y ago
  Not a useful distinction, since it needs to be visible inside the chroot either way. Not only that but libc via getpwnam() and friends needs to access PAM and thence all the libpam modules.
  - mnw21cam 7y ago
    That also depends. I have a chroot set up here to run sftp-server for incoming ssh connections, and it has 55 files in it, 40 of which appear to be libraries - none of them having anything to do with PAM.
nemaar 7y ago
I think the idea that the program can load files as code is insane in itself. There shouldn't be such a mechanism in an ideal world. The operating system would decide what you can actually load and load it for you.
- anoncake 7y ago
  How would you prevent that? If programs can load files into memory and execute data loaded into memory as code, they can load files as code. The former is necessary for obvious reasons, the latter for JIT. It's also pointless. If a program can cause damage by loading harmful code it can also cause damage directly. Restricting what programs can do is a great way to prevent experimentation and hinder progress.
  - la_barba 7y ago
    You can prevent that by using the NX or the XD bit. Its a CPU feature and I believe the support was added over 15 years ago in most popular OSs. Here's the commit for Linux https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=36bc33bac78f6bc08282c622138f4e432b62e7be https://git.kernel.org/pub/scm/linux/kernel/git/history/hist... >It's also pointless. If a program can cause damage by loading harmful code it can also cause damage directly. It is not pointless, but it is also not perfect. That's why we have defense in depth. Where instead of having one perfect moat to protect the castle, you also have alligators and witches that turn people into frogs. :P
    - anoncake 7y ago
      The OS can prevent it, but can it do so without making JIT impossible?
      - andrekandre 7y ago
        well, if you can’t make pages executable you can “just in time” it by interpreting and writing it to an optimized interpreter format i suppose (but it will be much slower)... as an example, see WKWebView vs UIWebView (from iOS)
hlandau 7y ago
Author here. This is the case with *nix but doesn't need to be. As far as I'm aware, it's quite common in microkernel-based OSes to implement even ELF loading, dynamic linking, etc. inside system libraries loaded inside the process creating the new process. So the parent process basically constructs the child process, which means you could easily design an OS such that the parent needs access to the library files, but the child doesn't.

AstralStorm 7y ago

Do they now? Usually, the linker does all the loading, also known in Linux as ld.so. (even when you use dlopen) Lazy loading can thunk through kernel so that ld.so service loads things into the process - and preferably strict loading should be used.

mnw21cam 7y ago
Indeed. But ld.so runs in the context of the process that is starting up, so if it doesn't have access to anything, it can't.
- AstralStorm 7y ago
  It doesn't actually have to, but you'd need a fun bit of stub code in place of unloaded function pointers etc.
pjc50 7y ago
Not a useful distinction, since it needs to be visible inside the chroot either way. Not only that but libc via getpwnam() and friends needs to access PAM and thence all the libpam modules.
- mnw21cam 7y ago
  That also depends. I have a chroot set up here to run sftp-server for incoming ssh connections, and it has 55 files in it, 40 of which appear to be libraries - none of them having anything to do with PAM.

nemaar 7y ago

I think the idea that the program can load files as code is insane in itself. There shouldn't be such a mechanism in an ideal world. The operating system would decide what you can actually load and load it for you.

anoncake 7y ago
How would you prevent that? If programs can load files into memory and execute data loaded into memory as code, they can load files as code. The former is necessary for obvious reasons, the latter for JIT. It's also pointless. If a program can cause damage by loading harmful code it can also cause damage directly. Restricting what programs can do is a great way to prevent experimentation and hinder progress.
- la_barba 7y ago
  You can prevent that by using the NX or the XD bit. Its a CPU feature and I believe the support was added over 15 years ago in most popular OSs. Here's the commit for Linux https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=36bc33bac78f6bc08282c622138f4e432b62e7be https://git.kernel.org/pub/scm/linux/kernel/git/history/hist... >It's also pointless. If a program can cause damage by loading harmful code it can also cause damage directly. It is not pointless, but it is also not perfect. That's why we have defense in depth. Where instead of having one perfect moat to protect the castle, you also have alligators and witches that turn people into frogs. :P
  - anoncake 7y ago
    The OS can prevent it, but can it do so without making JIT impossible?
    - andrekandre 7y ago
      well, if you can’t make pages executable you can “just in time” it by interpreting and writing it to an optimized interpreter format i suppose (but it will be much slower)... as an example, see WKWebView vs UIWebView (from iOS)

hlandau 7y ago

Author here. This is the case with *nix but doesn't need to be. As far as I'm aware, it's quite common in microkernel-based OSes to implement even ELF loading, dynamic linking, etc. inside system libraries loaded inside the process creating the new process. So the parent process basically constructs the child process, which means you could easily design an OS such that the parent needs access to the library files, but the child doesn't.