4 ms·

What would be an use case for `os.Root`? Based on my understanding ( https://github.com/golang/go/issues/67002 https://github.com/golang/go/issues/67002 ), it i

What would be an use case for `os.Root`? Based on my understanding ( https://github.com/golang/go/issues/67002 https://github.com/golang/go/issues/67002 ), it is related to security. However, under the hood, it doesn't use `Chroot`, so I could imagine, that eventually someone finds a way to escape from the Root.

nesarkvechnep 2y ago
Why would it use `chroot`? Combined with a sandboxing facility, like Capsicum, you can open a directory before entering capability mode and later, you use `os.Root` to open files in the file system tree under the opened directory.
- Hixon10 2y ago
  > Why would it use `chroot`? I am not sure, is this custom Os.Root implementation good enough to relay on it? I see that it is based on openat, and validation of paths/symlinks. But should we expect CVEs, which will break this protection layer?
  - nesarkvechnep 2y ago
    Let me get my crystal ball.
duskwuff 2y ago
chroot only makes sense for applications which can commit to exclusively operating out of a single directory, ever. (It also requires the process to have superuser privileges, so it can't be used by applications which are run as users.) os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.
- Hixon10 2y ago
  Yeah, I like your examples. In such scenarios, it makes sense when we're just trying to protect against our own bugs rather than a user deliberately sending a path that leads to the password.txt file.
- demi56 2y ago
  Yeah, some dev usually don’t put safe guards especially when the user input is directly linked to file operations
- fweimer 2y ago
  Linux has had unprivileged chroot for a while, via user namespaces. Their setup is a bit complicated if you want to support nesting in other container runtimes: https://sourceware.org/git/?p=glibc.git;a=blob;f=support/support_become_root.c https://sourceware.org/git/?p=glibc.git;a=blob;f=support/sup... After this dance, you can call chroot from within the new namespace. It's often also possible to use unprivileged bind-mount /dev, /sys, /proc, for a more regular execution environment (although some container runtimes block this unfortunately).

nesarkvechnep 2y ago

Why would it use `chroot`? Combined with a sandboxing facility, like Capsicum, you can open a directory before entering capability mode and later, you use `os.Root` to open files in the file system tree under the opened directory.

Hixon10 2y ago
> Why would it use `chroot`? I am not sure, is this custom Os.Root implementation good enough to relay on it? I see that it is based on openat, and validation of paths/symlinks. But should we expect CVEs, which will break this protection layer?
- nesarkvechnep 2y ago
  Let me get my crystal ball.

duskwuff 2y ago

chroot only makes sense for applications which can commit to exclusively operating out of a single directory, ever. (It also requires the process to have superuser privileges, so it can't be used by applications which are run as users.) os.Root() is more about putting a "seatbelt" on filesystem operations - like restricting operations related to an application's cache to its cache directory, or restricting a file server to serving files from the appropriate shared directory. It's not the same kind of ironclad guarantee as chroot, but it'll still protect an application from simple directory traversals.

Hixon10 2y ago
Yeah, I like your examples. In such scenarios, it makes sense when we're just trying to protect against our own bugs rather than a user deliberately sending a path that leads to the password.txt file.
demi56 2y ago
Yeah, some dev usually don’t put safe guards especially when the user input is directly linked to file operations
fweimer 2y ago
Linux has had unprivileged chroot for a while, via user namespaces. Their setup is a bit complicated if you want to support nesting in other container runtimes: https://sourceware.org/git/?p=glibc.git;a=blob;f=support/support_become_root.c https://sourceware.org/git/?p=glibc.git;a=blob;f=support/sup... After this dance, you can call chroot from within the new namespace. It's often also possible to use unprivileged bind-mount /dev, /sys, /proc, for a more regular execution environment (although some container runtimes block this unfortunately).