4 ms·

Can you elaborate on this please? I'd consider unveil to be far more capable of creating "an arbitrarily structured virtualized filesystem" view than chroot. I'

Can you elaborate on this please? I'd consider unveil to be far more capable of creating "an arbitrarily structured virtualized filesystem" view than chroot. I'd also invert the thinking of "just hide parts of the existing filesystem" as it whitelists paths and access rather than blacklisting.

ori_b 6y ago
How do you bind a /tmp/empty to /home/$USER with unveil, so that you can see and capture the files some program creates?
- gbrown_ 6y ago
  Sorry I don't quite grok your comment. It sounds like a bind mount so I'm unsure how it relates to unveil or chroot?
  - ori_b 6y ago
    Chroot is more or less a bind mount over /. Bind mounts generalize chroot. Unveil does not, and therefore does not allow you to provide arbitrary views of the file system. It's useful for other reasons. On OpenBSD, a full web browser compromise does not lead to full file system access.
shawnz 6y ago
Unveil has no way to change the existing structure of the filesystem. With chroot it's easy: create the structure you want in a subdirectory and then chroot into it
- gbrown_ 6y ago
  If changing a process root directory is really what you want to do then yes chroot is the right tool for the job. But from a perspective of "jailing" daemons as mentioned in the article I think unveil is a better API. I'm not sure what pieces of software populate directories and then chroot into them aside from maybe some build systems? But those likely create or bind in some /dev and /proc pieces which would be privileged operations anyway. And in such a case would containers not have surplanted chroot?
  - shawnz 6y ago
    "Jailing" isn't necessarily just about security, but isolation in general. Unveil would be a stronger tool if the concern is strictly security, but also there's no reason they couldn't both be used. Chroot is itself sometimes used to provide container-style functionality, so I think it's wrong to say containers "surplanted" it.
  - zokier 6y ago
    > And in such a case would containers not have surplanted chroot? Containers use chroot
    - knorker 6y ago
      They don't use fs namespaces?

ori_b 6y ago

How do you bind a /tmp/empty to /home/$USER with unveil, so that you can see and capture the files some program creates?

gbrown_ 6y ago
Sorry I don't quite grok your comment. It sounds like a bind mount so I'm unsure how it relates to unveil or chroot?
- ori_b 6y ago
  Chroot is more or less a bind mount over /. Bind mounts generalize chroot. Unveil does not, and therefore does not allow you to provide arbitrary views of the file system. It's useful for other reasons. On OpenBSD, a full web browser compromise does not lead to full file system access.

shawnz 6y ago

Unveil has no way to change the existing structure of the filesystem. With chroot it's easy: create the structure you want in a subdirectory and then chroot into it

gbrown_ 6y ago
If changing a process root directory is really what you want to do then yes chroot is the right tool for the job. But from a perspective of "jailing" daemons as mentioned in the article I think unveil is a better API. I'm not sure what pieces of software populate directories and then chroot into them aside from maybe some build systems? But those likely create or bind in some /dev and /proc pieces which would be privileged operations anyway. And in such a case would containers not have surplanted chroot?
- shawnz 6y ago
  "Jailing" isn't necessarily just about security, but isolation in general. Unveil would be a stronger tool if the concern is strictly security, but also there's no reason they couldn't both be used. Chroot is itself sometimes used to provide container-style functionality, so I think it's wrong to say containers "surplanted" it.
- zokier 6y ago
  > And in such a case would containers not have surplanted chroot? Containers use chroot
  - knorker 6y ago
    They don't use fs namespaces?