6 ms·

How does a program set up the device node in the chroot if it's jailed in the chroot? Is that possible? Would any non-root program be able to create device node

by buster 12y ago

How does a program set up the device node in the chroot if it's jailed in the chroot? Is that possible? Would any non-root program be able to create device nodes?

quotemstr 12y ago
You have to be root (well, have CAP_SYS_CHROOT) to call chroot in the first place. If you're root, you can call mknod to create your device nodes.
- vidarh 12y ago
  It is not a given that the process that runs LibreSSL at some point after the chroot happens will have CAP_SYS_CHROOT/root. Also, it doesn't solve the issue, as /dev/urandom will also be unaccessible temporarily if you run out of file handles.
  - deleted 12y ago
    [deleted]
    - vidarh 12y ago
      I agree, partly. The problem is that LibreSSL needs to decide what to do. The comments in the file outline why they believe they have few options: They are concerned about aborting, because of potentially unsafe core files (consider if someone lets you execute a suid process in a chroot that has access to read SSL keys you should not have access to, and you can cause it to dump a core file that you can read simply by DOS'ing access to /dev/urandom), and lack of other safe ways of reporting failure. Couple that with the fact that whether or not the /dev/ is set up correctly is a distraction: You have no guarantee that you will be able to open and read any file, as they can not guarantee that there's nothing available on the server that can't easily be used to hit file descriptor limits for a suitable process or open file limits for the entire system. So this problem is there regardless of whether or not you're willing to demand a correctly configured /dev.
      - quotemstr 12y ago
        There are two issues here. One is the ability to obtain, given sufficient local resources, a file descriptor to /dev/urandom. I think defining away this problem is fine: running a program in an environment without a valid /dev is simply user error. In such an environment, operations that might require entropy should simply fail. The second issue is resource limits: low level components of LibreSSL cannot cope with entropy-generating functions failing. On OpenBSD, these functions cannot fail, but on Linux, they can. That's not a problem with Linux, but with LibreSSL's architecture. It's LibreSSL's responsibility to ensure that it allocates. Every call to LibreSSL's internal RNG is preceded by some kind of resource-allocating call that can fail. It's in this call that LibreSSL should obtain the resources needed to do its work. That it doesn't is simply a bug in LibreSSL, not a deficiency in Linux.
        vidarh 12y ago
        If LibreSSL was the origin of the API, I might agree with you. But LibreSSL is trying to largely conform to an API they have inherited. If that isn't feasible to do safely on Linux, then while it may be arguable whether or not it is a deficiency in Linux, it is a problem for Linux users. For my part, I believe strongly that it is a deficiency if we have to go through all these kinds of hoops in order to safely obtain entropy, when the solution is so simple on the kernel end: Ensure we retain a syscall.
        quotemstr 12y ago
        Exactly what part of LibreSSL's API prohibits the maintenance of an internal file descriptor and early checks that this file descriptor can be filled with a handle to /dev/urandom? Resource management is not a "hoop". It is a fact of life.
        vidarh 12y ago
        Nothing. But nothing also prevents the client from intentionally or accidentally closing that file descriptor. As I've pointed out elsewhere, looping over all file descriptors and closing them on fork() is a common pattern for applications where you want to ensure you don't have resource leaks (whether for capacity or security). Which is fine if you have a safe way of returning errors in all code paths, but as the comments points out, they believe they don't. Maybe they're wrong, but they seem to have spent some time thinking about it. They've also provided an easy define to change the behaviour to failing hard for people building it on systems where their caveats against failing hard does not apply (e.g. systems with secure core files) If they can't fail early in a safe manner without potentially creating a security leak (as they potentially would if an unprivileged user could induce an unsafe core dump), and can't even be guaranteed that they're able to safely log the error (there's no guarantee they'd be able to write it anywhere), it's hard to see alternatives but to try to do something that is "good enough" as the alternative could be much worse. Neither is a good solution.
- buster 12y ago
  So most programs can't "just create a device node".

by buster 12y ago

How does a program set up the device node in the chroot if it's jailed in the chroot? Is that possible? Would any non-root program be able to create device nodes?

quotemstr 12y ago

You have to be root (well, have CAP_SYS_CHROOT) to call chroot in the first place. If you're root, you can call mknod to create your device nodes.

vidarh 12y ago
It is not a given that the process that runs LibreSSL at some point after the chroot happens will have CAP_SYS_CHROOT/root. Also, it doesn't solve the issue, as /dev/urandom will also be unaccessible temporarily if you run out of file handles.
- deleted 12y ago
  [deleted]
  - vidarh 12y ago
    I agree, partly. The problem is that LibreSSL needs to decide what to do. The comments in the file outline why they believe they have few options: They are concerned about aborting, because of potentially unsafe core files (consider if someone lets you execute a suid process in a chroot that has access to read SSL keys you should not have access to, and you can cause it to dump a core file that you can read simply by DOS'ing access to /dev/urandom), and lack of other safe ways of reporting failure. Couple that with the fact that whether or not the /dev/ is set up correctly is a distraction: You have no guarantee that you will be able to open and read any file, as they can not guarantee that there's nothing available on the server that can't easily be used to hit file descriptor limits for a suitable process or open file limits for the entire system. So this problem is there regardless of whether or not you're willing to demand a correctly configured /dev.
    - quotemstr 12y ago
      There are two issues here. One is the ability to obtain, given sufficient local resources, a file descriptor to /dev/urandom. I think defining away this problem is fine: running a program in an environment without a valid /dev is simply user error. In such an environment, operations that might require entropy should simply fail. The second issue is resource limits: low level components of LibreSSL cannot cope with entropy-generating functions failing. On OpenBSD, these functions cannot fail, but on Linux, they can. That's not a problem with Linux, but with LibreSSL's architecture. It's LibreSSL's responsibility to ensure that it allocates. Every call to LibreSSL's internal RNG is preceded by some kind of resource-allocating call that can fail. It's in this call that LibreSSL should obtain the resources needed to do its work. That it doesn't is simply a bug in LibreSSL, not a deficiency in Linux.
      - vidarh 12y ago
        If LibreSSL was the origin of the API, I might agree with you. But LibreSSL is trying to largely conform to an API they have inherited. If that isn't feasible to do safely on Linux, then while it may be arguable whether or not it is a deficiency in Linux, it is a problem for Linux users. For my part, I believe strongly that it is a deficiency if we have to go through all these kinds of hoops in order to safely obtain entropy, when the solution is so simple on the kernel end: Ensure we retain a syscall.
        quotemstr 12y ago
        Exactly what part of LibreSSL's API prohibits the maintenance of an internal file descriptor and early checks that this file descriptor can be filled with a handle to /dev/urandom? Resource management is not a "hoop". It is a fact of life.
        vidarh 12y ago
        Nothing. But nothing also prevents the client from intentionally or accidentally closing that file descriptor. As I've pointed out elsewhere, looping over all file descriptors and closing them on fork() is a common pattern for applications where you want to ensure you don't have resource leaks (whether for capacity or security). Which is fine if you have a safe way of returning errors in all code paths, but as the comments points out, they believe they don't. Maybe they're wrong, but they seem to have spent some time thinking about it. They've also provided an easy define to change the behaviour to failing hard for people building it on systems where their caveats against failing hard does not apply (e.g. systems with secure core files) If they can't fail early in a safe manner without potentially creating a security leak (as they potentially would if an unprivileged user could induce an unsafe core dump), and can't even be guaranteed that they're able to safely log the error (there's no guarantee they'd be able to write it anywhere), it's hard to see alternatives but to try to do something that is "good enough" as the alternative could be much worse. Neither is a good solution.
buster 12y ago
So most programs can't "just create a device node".