8 ms·

Pledge() and unveil() in SerenityOS (2020)

195 points by easton 4y ago

easton 4y ago
(Although the post says “Written on January 22, 2020”, it clearly wasn’t. I’m guessing there’s just an old template somewhere.)
- compressedgas 4y ago
  Well, the videos linked to were uploaded on the 11th and 20th of January 2020. I think the article's date of the 22nd is correct.
  - easton 4y ago
    I’m dumb and thought that the video being posted yesterday meant this was more recent.
    - olliej 4y ago
      Meh, it happens :D
- aeyes 4y ago
  What leads you to believe this? pledge() has existed for years in SerenityOS. https://github.com/SerenityOS/serenity/commits/master/Kernel/Syscalls/pledge.cpp https://github.com/SerenityOS/serenity/commits/master/Kernel... and it used to be in a different file previously.
- jeroenhd 4y ago
  SerenityOS has had pledge and unveil for a while now, to the point where many system tools implement pledge by default. The video covering a reimplementation of justine.lol's pledge.com was uploaded yesterday (https://youtu.be/T6YkQF6ohoA https://youtu.be/T6YkQF6ohoA) leveraging these APIs to replicate the original tool's behaviour (though it needs some pledges just to spawn the child process which I think are a bit clunky, but surely can be worked around).
IshKebab 4y ago
Why is the interface string-based? Seems very hacky and unusual. Also, special bonus evil points for whoever decided that "rpath" should have nothing to do with RPATH. Seriously please can all of you other programmers stop pointlessly abbreviating things that are already quite short?! "read_path" is perfectly fine.
- kotborealis 4y ago
  `pledge` is from OpenBSD, as suggested by the article, and it also implements it using string-based interface (https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2) I think, the main point is to make it as easy as possible to use.
  - IshKebab 4y ago
    Yeah I know, I was really asking why OpenBSD did it that way. I don't think string-based arguments are easier to use. If it was a struct with a load of `bool` fields you'd get code completion, compile time type checking, built in documentation, discoverability, etc. Much easier!
    - cyphar 4y ago
      You can't trivially extend structs in a kernel ABI (to be fair this is worse in Linux as there is more than one libc and many programs do raw syscalls bypassing the libc anyway -- though it can still be done[1]) but string APIs are simpler to use and upgrade. They can also be far more ergonomic in some cases. The core issue is that userspace programs and libraries can be compiled using structs with the old size (in theory the libc can abstract this using symbol versioning but then the same issue lies within the libc) causing out-of-bounds memory accesses when the kernel tries to access the struct fields. There's also forwards-compatibility issues but bad memory accesses are marginally worse. [1]: https://lwn.net/Articles/830666/ https://lwn.net/Articles/830666/
      - loeg 4y ago
        The kernel can easily version APIs using struct size, as long as new members are only appended. The libc function would pass the size of the struct to the syscall, or you could have pledge() itself be a macro that computes sizeof in the caller.
sdwvit 4y ago
Please ELI5, is it like application permissions? I am not a cpp/c coder.
- freemint 4y ago
  In unix like user spaces applications have access to a lot of stuff by default (such as the complete filesystem accessible to the executing users and a lot of system calls). For security purposes tighter restrictions would be better. Pledge() and Unveil() allow application authors to opt in at run time to restrict what they can do in the future.
- simongr3dal 4y ago
  AFAIK, with pledge() a process can tell the kernel “I’m only going to use X, Y, Z features” (e.g. read, write from file system) After the process has told this to the kernel the process can then only do these things for its life time. You can pledge() again later, but you can only restrict your pledge never expand it. This is a nice feature because it limits the number of processes that can potentially be security liabilities even if they have bugs. unveil() is a similar feature but for file system paths. It’s a feature of SerenityOS (inspired/borrowed from OpenBSD), and not a feature of C/C++. Try reading the article, it’s pretty easy to follow :)
  - calvinmorrison 4y ago
    If you fork, can you change your pledge?
    - elbigbad 4y ago
      No a forked process only inherits the broadest permissions of the parent and can only downscope.
      - notaplumber1 4y ago
        It's not the broadest permissions from the parent, but the promises at the time of the fork, for example you can setup the parent in such a way that you fork off early a unprivileged (or privileged) child that has a different set of promises from the parent.
deleted 4y ago
[deleted]
unicornporn 4y ago
He's live on YouTube now if you want to ask a question :) https://www.youtube.com/watch?v=h3IasVVL_k0 https://www.youtube.com/watch?v=h3IasVVL_k0
- jamal-kumar 4y ago
  This guy's story is really impressive. Sounds like he managed to quit his job to work on livestream developing this full time as part of a drug addiction recovery strategy. [1] That's pretty impressive, I hope the best for him going forward with that. It looks like a pretty interesting introduction to operating system development, a huge topic with tons of stuff to cover. [1] https://awesomekling.github.io/I-quit-my-job-to-focus-on-SerenityOS-full-time/ https://awesomekling.github.io/I-quit-my-job-to-focus-on-Ser...
ape4 4y ago
Are all files veiled (inaccessible) until an unveil() call?
- notaplumber1 4y ago
  No, simply because using unveil is not mandatory. It's opt-in. The filesystem becomes "veiled" to the application only after the first call to unveil(), subsequent calls "unveil" files/directories until the final call which locks it, preventing any future unveils.
- deleted 4y ago
  [deleted]
j_m_b 4y ago
This is awesome, now if someone asks me what a promise is, I can say "it's an argument to pledge about which system resources I am declaring access to" and watch their faces glaze over. "No I'm talking about the async promise..."
perryizgr8 4y ago
The way Andreas Kling builds up code in his livestream makes it seem so easy to do OS development. After watching one of his videos I feel I could easily build up any system level program or feature, but I know from prior experience that it is not so easy for me.
dang 4y ago
Discussed at the time: Pledge() and Unveil() in SerenityOS - https://news.ycombinator.com/item?id=22116914 https://news.ycombinator.com/item?id=22116914 - Jan 2020 (28 comments) Related from yesterday: Show HN: Porting OpenBSD Pledge() to Linux - https://news.ycombinator.com/item?id=32096801 https://news.ycombinator.com/item?id=32096801 - July 2022 (114 comments)

195 points by easton 4y ago

(Although the post says “Written on January 22, 2020”, it clearly wasn’t. I’m guessing there’s just an old template somewhere.)

compressedgas 4y ago
Well, the videos linked to were uploaded on the 11th and 20th of January 2020. I think the article's date of the 22nd is correct.
- easton 4y ago
  I’m dumb and thought that the video being posted yesterday meant this was more recent.
  - olliej 4y ago
    Meh, it happens :D
aeyes 4y ago
What leads you to believe this? pledge() has existed for years in SerenityOS. https://github.com/SerenityOS/serenity/commits/master/Kernel/Syscalls/pledge.cpp https://github.com/SerenityOS/serenity/commits/master/Kernel... and it used to be in a different file previously.
jeroenhd 4y ago
SerenityOS has had pledge and unveil for a while now, to the point where many system tools implement pledge by default. The video covering a reimplementation of justine.lol's pledge.com was uploaded yesterday (https://youtu.be/T6YkQF6ohoA https://youtu.be/T6YkQF6ohoA) leveraging these APIs to replicate the original tool's behaviour (though it needs some pledges just to spawn the child process which I think are a bit clunky, but surely can be worked around).

IshKebab 4y ago

Why is the interface string-based? Seems very hacky and unusual. Also, special bonus evil points for whoever decided that "rpath" should have nothing to do with RPATH. Seriously please can all of you other programmers stop pointlessly abbreviating things that are already quite short?! "read_path" is perfectly fine.

kotborealis 4y ago
`pledge` is from OpenBSD, as suggested by the article, and it also implements it using string-based interface (https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2) I think, the main point is to make it as easy as possible to use.
- IshKebab 4y ago
  Yeah I know, I was really asking why OpenBSD did it that way. I don't think string-based arguments are easier to use. If it was a struct with a load of `bool` fields you'd get code completion, compile time type checking, built in documentation, discoverability, etc. Much easier!
  - cyphar 4y ago
    You can't trivially extend structs in a kernel ABI (to be fair this is worse in Linux as there is more than one libc and many programs do raw syscalls bypassing the libc anyway -- though it can still be done[1]) but string APIs are simpler to use and upgrade. They can also be far more ergonomic in some cases. The core issue is that userspace programs and libraries can be compiled using structs with the old size (in theory the libc can abstract this using symbol versioning but then the same issue lies within the libc) causing out-of-bounds memory accesses when the kernel tries to access the struct fields. There's also forwards-compatibility issues but bad memory accesses are marginally worse. [1]: https://lwn.net/Articles/830666/ https://lwn.net/Articles/830666/
    - loeg 4y ago
      The kernel can easily version APIs using struct size, as long as new members are only appended. The libc function would pass the size of the struct to the syscall, or you could have pledge() itself be a macro that computes sizeof in the caller.

sdwvit 4y ago

Please ELI5, is it like application permissions? I am not a cpp/c coder.

freemint 4y ago
In unix like user spaces applications have access to a lot of stuff by default (such as the complete filesystem accessible to the executing users and a lot of system calls). For security purposes tighter restrictions would be better. Pledge() and Unveil() allow application authors to opt in at run time to restrict what they can do in the future.
simongr3dal 4y ago
AFAIK, with pledge() a process can tell the kernel “I’m only going to use X, Y, Z features” (e.g. read, write from file system) After the process has told this to the kernel the process can then only do these things for its life time. You can pledge() again later, but you can only restrict your pledge never expand it. This is a nice feature because it limits the number of processes that can potentially be security liabilities even if they have bugs. unveil() is a similar feature but for file system paths. It’s a feature of SerenityOS (inspired/borrowed from OpenBSD), and not a feature of C/C++. Try reading the article, it’s pretty easy to follow :)
- calvinmorrison 4y ago
  If you fork, can you change your pledge?
  - elbigbad 4y ago
    No a forked process only inherits the broadest permissions of the parent and can only downscope.
    - notaplumber1 4y ago
      It's not the broadest permissions from the parent, but the promises at the time of the fork, for example you can setup the parent in such a way that you fork off early a unprivileged (or privileged) child that has a different set of promises from the parent.

deleted 4y ago

[deleted]

unicornporn 4y ago

He's live on YouTube now if you want to ask a question :) https://www.youtube.com/watch?v=h3IasVVL_k0 https://www.youtube.com/watch?v=h3IasVVL_k0

jamal-kumar 4y ago
This guy's story is really impressive. Sounds like he managed to quit his job to work on livestream developing this full time as part of a drug addiction recovery strategy. [1] That's pretty impressive, I hope the best for him going forward with that. It looks like a pretty interesting introduction to operating system development, a huge topic with tons of stuff to cover. [1] https://awesomekling.github.io/I-quit-my-job-to-focus-on-SerenityOS-full-time/ https://awesomekling.github.io/I-quit-my-job-to-focus-on-Ser...

ape4 4y ago

Are all files veiled (inaccessible) until an unveil() call?

notaplumber1 4y ago
No, simply because using unveil is not mandatory. It's opt-in. The filesystem becomes "veiled" to the application only after the first call to unveil(), subsequent calls "unveil" files/directories until the final call which locks it, preventing any future unveils.
deleted 4y ago
[deleted]

j_m_b 4y ago

This is awesome, now if someone asks me what a promise is, I can say "it's an argument to pledge about which system resources I am declaring access to" and watch their faces glaze over. "No I'm talking about the async promise..."

perryizgr8 4y ago

The way Andreas Kling builds up code in his livestream makes it seem so easy to do OS development. After watching one of his videos I feel I could easily build up any system level program or feature, but I know from prior experience that it is not so easy for me.

dang 4y ago

Discussed at the time: Pledge() and Unveil() in SerenityOS - https://news.ycombinator.com/item?id=22116914 https://news.ycombinator.com/item?id=22116914 - Jan 2020 (28 comments) Related from yesterday: Show HN: Porting OpenBSD Pledge() to Linux - https://news.ycombinator.com/item?id=32096801 https://news.ycombinator.com/item?id=32096801 - July 2022 (114 comments)