4 ms·

Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? This almo

Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? This almost looks like a hint to OpenBSD's pledge and unveil system calls. I'm just a hobbyist, but regarding we all run software we don't understand what I like (again) in OpenBSD is that I feel I can largely understand/control what's happening in my system, it quite fits in my head. Just my 2 cents.

user3939382 4y ago
Exactly. ‘ps ax’ on a fresh OpenBSD install gives you about 10-12 processes, each of whose purpose is either obvious or easy to discover. Try doing the same thing on macOS or Ubuntu. Last time I looked carefully at the former I discovered, for example, daemons for classrooms (??) It’s a free-for-all.
_wldu 4y ago
You can use strace to get this information. Linux also offers seccomp and landlock which are very similar to pledge and unveil.
- fefe23 4y ago
  I would like to emphatically point out that: no, you can't. You can't use strace to get this information. Let's say you want to use seccomp to whitelist allowed syscalls. Your code opens a file, uses stat to get the file size, then mallocs that many bytes and reads the file contents into the buffer. Trivial program, right? glibc will turn open into openat, stat into statx, malloc can become either nothing, or sbrk, or mmap, and maybe also munmap. If you hit an error, it will also call write to output an error message to stderr. dietlibc will do open, stat, mmap. This is also libc version dependent! But can you at least use strace to know which files will be opened? No, not even that! Because the code may open some files only under certain circumstances. For example, localtime will open /etc/localtime -- but then it will cache the result for a while. /etc/localtime may be a symlink. If you construct a container you would also need the thing it points to. What if you use a malloc that has explicit hugepage support? Also note that seccomp and landlock are very much different from pledge and unveil. I am particularly appalled by landlock as compared to unveil. Go look up the landlock API if you don't believe me, and compare it to the unveil man page. If you thought the hoops seccomp makes you jump through are ridiculous, you haven't seen anything yet. OpenBSD is not all gold either. pledge is not transitive. If your process pledges something but is allowed to execve something else, the process you exec is not bound by your pledge. There is MUCH room for improvement all around. However, the persisting idea that you can use a "training mode" or observe via strace to construct a whitelist IS WRONG and dangerously so. Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?) you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee.
  - goodpoint 4y ago
    > Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?) 100% test coverage does not guarantee absence of vulnerabilities in any way. > you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee. Having sandboxed many things, this is plain false. Normal applications and daemons have no reason to call reboot() or stime() and so on in any obscure code path. If they do, the sandbox should stop them and that's a feature and not a bug.
    - staticassertion 4y ago
      Their point about test coverage is that you don't know what syscalls will be made, or with what arguments, without running the program with enough coverage to find out. This is probably the most well known issue with sandboxing - maintaining the sandbox. It's especially hard with seccomp, because you could upgrade your distro, or a dependency, and suddenly you're making a different system call.
  - mmis1000 4y ago
    Docker actually comes with a seccomp and an apparmor config that bans many things by default. while it is absolutely not noticeable unless you are trying something like docker in docker. There are so many syscall that shouldn't even be relevant to normal programs.
    - fefe23 4y ago
      That's why I explicitly mention "whitelisting". If you just want to ban some obscure syscalls and call it a day, you can do that. It will probably even be helpful to some degree. I personally think our aspirations should be higher than "let's ban ptrace(2)".
      - mmis1000 4y ago
        It's actually a bit more than that. The syscall docker allowed isn't really fixed. It is affected by what linux capabilities the container had granted. Like: if you whitelist the container about CAP_SYS_PTRACE, you probably also want ptrace(2) to be whitelisted. Instead of a all or nothing/your program will still break even cap added model.

user3939382 4y ago

Exactly. ‘ps ax’ on a fresh OpenBSD install gives you about 10-12 processes, each of whose purpose is either obvious or easy to discover. Try doing the same thing on macOS or Ubuntu. Last time I looked carefully at the former I discovered, for example, daemons for classrooms (??) It’s a free-for-all.

_wldu 4y ago

You can use strace to get this information. Linux also offers seccomp and landlock which are very similar to pledge and unveil.

fefe23 4y ago
I would like to emphatically point out that: no, you can't. You can't use strace to get this information. Let's say you want to use seccomp to whitelist allowed syscalls. Your code opens a file, uses stat to get the file size, then mallocs that many bytes and reads the file contents into the buffer. Trivial program, right? glibc will turn open into openat, stat into statx, malloc can become either nothing, or sbrk, or mmap, and maybe also munmap. If you hit an error, it will also call write to output an error message to stderr. dietlibc will do open, stat, mmap. This is also libc version dependent! But can you at least use strace to know which files will be opened? No, not even that! Because the code may open some files only under certain circumstances. For example, localtime will open /etc/localtime -- but then it will cache the result for a while. /etc/localtime may be a symlink. If you construct a container you would also need the thing it points to. What if you use a malloc that has explicit hugepage support? Also note that seccomp and landlock are very much different from pledge and unveil. I am particularly appalled by landlock as compared to unveil. Go look up the landlock API if you don't believe me, and compare it to the unveil man page. If you thought the hoops seccomp makes you jump through are ridiculous, you haven't seen anything yet. OpenBSD is not all gold either. pledge is not transitive. If your process pledges something but is allowed to execve something else, the process you exec is not bound by your pledge. There is MUCH room for improvement all around. However, the persisting idea that you can use a "training mode" or observe via strace to construct a whitelist IS WRONG and dangerously so. Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?) you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee.
- goodpoint 4y ago
  > Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?) 100% test coverage does not guarantee absence of vulnerabilities in any way. > you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee. Having sandboxed many things, this is plain false. Normal applications and daemons have no reason to call reboot() or stime() and so on in any obscure code path. If they do, the sandbox should stop them and that's a feature and not a bug.
  - staticassertion 4y ago
    Their point about test coverage is that you don't know what syscalls will be made, or with what arguments, without running the program with enough coverage to find out. This is probably the most well known issue with sandboxing - maintaining the sandbox. It's especially hard with seccomp, because you could upgrade your distro, or a dependency, and suddenly you're making a different system call.
- mmis1000 4y ago
  Docker actually comes with a seccomp and an apparmor config that bans many things by default. while it is absolutely not noticeable unless you are trying something like docker in docker. There are so many syscall that shouldn't even be relevant to normal programs.
  - fefe23 4y ago
    That's why I explicitly mention "whitelisting". If you just want to ban some obscure syscalls and call it a day, you can do that. It will probably even be helpful to some degree. I personally think our aspirations should be higher than "let's ban ptrace(2)".
    - mmis1000 4y ago
      It's actually a bit more than that. The syscall docker allowed isn't really fixed. It is affected by what linux capabilities the container had granted. Like: if you whitelist the container about CAP_SYS_PTRACE, you probably also want ptrace(2) to be whitelisted. Instead of a all or nothing/your program will still break even cap added model.