7 ms·

Capsudo: Rethinking sudo with object capabilities

93 points by fanf2 11mo ago

PunchyHamster 11mo ago
That's functionally equivalent to using sudo but only allowing a certain shell script that's a wrapper for what needs to be done by a given user (to avoid the whole syntax mess). But somehow with more boilerplate.
- ryukafalz 11mo ago
  If I'm a user who's been given access to run such a wrapper script via sudo, how do I further delegate that access?
  - deleted 11mo ago
    [deleted]
  - deleted 11mo ago
    [deleted]
- thwarted 11mo ago
  What's missing in this writeup is if/how capsudod can be configured to drop/acquire capabilities (in the capabilities(7) sense, in a namespace sense, or using openbsd's pledge(2)) before executing the command. From looking at the code it seems to rely on filesystem permissions to access the capsudod socket; when in order to make mounting USB drives actually safe via this kind of permission proxying method, you'd want to only give it very limited access to operations, like only the ability to make the mount(2) syscall. I generally agree, this is sudo in a different format and with a daemon; perhaps that's better. And it's written in C, which doesn't speak to avoiding the classic C-related privilege escalation risks (although this is a small amount of code compared to sudo).
esseph 11mo ago
Every time somebody wants to do something in Linux and they mention Objects, I turn around and go the other way. These people still do not understand why that userspace became so powerful and so useful. I also think that's the "solution", which is to craft a new optional userspace experience that leaves traditional unix strings and pipes alone. It's not for me, but I'm sure many would like it. I mean, look at PowerShell on Linux :/
charcircuit 11mo ago
You don't need to elevate privileges if you give things the right privileges from the start. Sudo is just a hack to avoid setting up proper capabilities / permissions in the first place.
- deleted 11mo ago
  [deleted]
- kccqzy 11mo ago
  I am the owner and only user of the computer. Does that mean I should run everything with root? Of course not. It’s simply better to start with little privileges and then elevate when needed. Using any additional privileges should be an intentional act. I also do it the other way: reduce my privileges via sudo -u nobody.
  - charcircuit 11mo ago
    The root account shouldn't exist either. Having god accounts is a bad idea security wise. Instead everything should follow the principle of least privilege.
    - cyberax 11mo ago
      This sounds good in theory, but in practice it doesn't work. You always end up with an object that has all the privileges.
      - rurban 11mo ago
        Which is a well known anti-pattern. https://en.wikipedia.org/wiki/God_object https://en.wikipedia.org/wiki/God_object
        lucketone 11mo ago
        That one seems unrelated with OS security model and root account. (One must squint really hard to see root and oop god object as same)
saghm 11mo ago
My most recent mini-adventure with sudo was on the Steam Deck; with OS updates, everything (or at least most?) of what's outside of your home directory is replaced. (In fact, you have to manually opt into being able to write to those directories at all, e.g. to use the system package manager instead of flatpak, by running `sudo steamos-readonly disable`). There are a couple sudo settings I change from the defaults, and because `/etc/sudoers and `/etc/sudoers.d/` (as in the entire directory) were restored to the base versions, my custom settings don't get preserved when updates occur. However, I was surprised to find out that using `visudo` to try to update the settings wasn't actually causing the settings I changed to take effect, which I eventually tracked down to some extra configs getting shipped by the base system in `/etc/sudoers.d`. I looked up what the precedence rules are for sudo rules, and apparently the rule is that anything in `/etc/sudoers.d/` will override `/etc/sudoers`, and the files in `/etc/sudoers.d/` are evaluated in lexigraphical order. That's how I got where I am today, with a file called `zzz` that I copy into `/etc/sudoers.d/` every time there's a system update.
- heavyset_go 11mo ago
  There's probably a way you can just set it and forget it with overlayfs. OpenWRT solved the problem of updates via immutable firmware image flashing while maintaining customizations 15 years ago using it.
  - saghm 11mo ago
    Probably! At the end of the day, this is the only change I need to make, and the updates are fairly infrequent, so this solution is good enough for me. I only brought it up as an example of how even the meta-rules around how sudo rules are interpreted might be more complex than people realize.
ninjin 11mo ago
I am somewhat cautious to comment as I know the author is way more experienced than I am and I fear that I may be missing something. However, let me try to accomplish the same with my elementary doas(1) knowledge. Allowing mounting for a specific group is simple with doas.conf(5): permit :mountd cmd /sbin/mount permit :mountd cmd /sbin/umount We can of course tighten it further as the author did: permit :mount-usb cmd /sbin/mount /dev/sdb1 permit :umount-usb cmd /sbin/umount /media/usb If you want to go more complex than specifying arguments, we could of course create a shell script and specify it instead of a binary. Likewise, we can do something similar for a service account: permit :www-deployment as www-deployment cmd /var/www/bin/build /var/www/application The key difference here would be that www-deployment can not delegate as easily to arbitrary users, as they would need to ask someone with root access to add additional users to the www-deployment group. But I am left wondering if this use case (if it is important enough) is not equally well served by specifying a location for non-root users to add permissions akin to what we see in doas.conf(5), but with the constraint that they of course can only allow other users to run commands with their privileges. Yes, it would "bloat" doas(1), but these code paths are not that long as long as you keep your scope constrained (doas(1) has a core of just over 500 lines and with environment handling and configuration format parsing we arrive a a final line count at just over 1,300). At this point, the main advantage I see with capsudod is that you can more easily drop privileges and put in restrictions like pledge(2) before the binary is ever called upon by whatever user we have granted permissions. While with the doas(1) thinking above you have to run over plenty of code that could be exploited. Still, this feels like a rather minor relative improvement to what we already have. Am I missing something in my ignorance? Lastly, let me also say that I am sure that sudo(8) has the ability to do the same things I proposed to do with doas(1) above, but I know the latter far better.
- srazkvt 11mo ago
  sure, but that doesn't change the fact that doas(1) is a suid binary. everything done would be done as root, from parsing the config file, checking the rights, and finally executing the command. capsudo here would rely on singular unix sockets with file access rights, so in essence, it would indeed be similar to what you could do with doas, but the idea here is to seperate things. with doas, doas would check if you have the correct group or user to do the command, while with capsudo, the kernel would check it, and reject it if you don't have the right.
haradion 11mo ago
If you squint hard enough, this is really a pretty similar idea to Polkit [0] but with a much simpler communication layer. [0]: https://polkit.pages.freedesktop.org/polkit/ https://polkit.pages.freedesktop.org/polkit/
qhwudbebd 11mo ago
Whenever I think about writing a central privileged daemon to grant capabilities to other processes, I'm puzzled by the choice to remove the old version of CAP_SETPCAP in 2.6.24: "grant or remove new capabilities to/from an existing running process" - sadly it still exists but means something else in newer kernels with filesystem capabilities. (In a sense, not having this capability in processes running as root is theatre anyway: you have /dev/kmem access so could just edit the kernel data structures. It's just doing so cleanly that is no longer possible.) Being able to briefly escalate my editor to have the capabilities to write /etc/wibble.conf when I started editing it as a non-privileged user, then take away the capability again would be more convenient that always needing to run the editor as root. (So convenient, in fact, that people fake this with little editor helpers that do the equivalent of 'really tee FILE-TO-WRITE >/dev/null', but that's an ugly hack.)
- Denvercoder9 11mo ago
  > you have /dev/kmem access so could just edit the kernel data structures. Not anymore: since kernel 2.6.26 /dev/kmem only exists if CONFIG_DEVKMEM is enabled, and it was removed completely in 5.13. [1] https://lwn.net/Articles/851531/ https://lwn.net/Articles/851531/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/mem.c?id=bbcd53c960713507ae764bf81970651b5577b95a https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
davexunit 11mo ago
It's nice to see other people writing about the capability transfer feature of Unix domain sockets. File paths are not object capabilities, but file descriptors are. Using a privileged daemon on top of an ambient authority system like Linux seems to be a good way to retrofit object capabilities onto the operating systems we already use. This is the same approach we took in Goblins[0] for our Unix domain socket netlayer for the OCapN[1] protocol. [0] https://spritely.institute/news/spritely-goblins-v0-16-0-released.html https://spritely.institute/news/spritely-goblins-v0-16-0-rel... [1] https://ocapn.org https://ocapn.org
nuudlman 11mo ago
This feels like pfexec on Illumos/Solaris, although I’m too unqualified to say for certain.

93 points by fanf2 11mo ago

That's functionally equivalent to using sudo but only allowing a certain shell script that's a wrapper for what needs to be done by a given user (to avoid the whole syntax mess). But somehow with more boilerplate.

ryukafalz 11mo ago
If I'm a user who's been given access to run such a wrapper script via sudo, how do I further delegate that access?
- deleted 11mo ago
  [deleted]
- deleted 11mo ago
  [deleted]
thwarted 11mo ago
What's missing in this writeup is if/how capsudod can be configured to drop/acquire capabilities (in the capabilities(7) sense, in a namespace sense, or using openbsd's pledge(2)) before executing the command. From looking at the code it seems to rely on filesystem permissions to access the capsudod socket; when in order to make mounting USB drives actually safe via this kind of permission proxying method, you'd want to only give it very limited access to operations, like only the ability to make the mount(2) syscall. I generally agree, this is sudo in a different format and with a daemon; perhaps that's better. And it's written in C, which doesn't speak to avoiding the classic C-related privilege escalation risks (although this is a small amount of code compared to sudo).

esseph 11mo ago

Every time somebody wants to do something in Linux and they mention Objects, I turn around and go the other way. These people still do not understand why that userspace became so powerful and so useful. I also think that's the "solution", which is to craft a new optional userspace experience that leaves traditional unix strings and pipes alone. It's not for me, but I'm sure many would like it. I mean, look at PowerShell on Linux :/

charcircuit 11mo ago

You don't need to elevate privileges if you give things the right privileges from the start. Sudo is just a hack to avoid setting up proper capabilities / permissions in the first place.

deleted 11mo ago
[deleted]
kccqzy 11mo ago
I am the owner and only user of the computer. Does that mean I should run everything with root? Of course not. It’s simply better to start with little privileges and then elevate when needed. Using any additional privileges should be an intentional act. I also do it the other way: reduce my privileges via sudo -u nobody.
- charcircuit 11mo ago
  The root account shouldn't exist either. Having god accounts is a bad idea security wise. Instead everything should follow the principle of least privilege.
  - cyberax 11mo ago
    This sounds good in theory, but in practice it doesn't work. You always end up with an object that has all the privileges.
    - rurban 11mo ago
      Which is a well known anti-pattern. https://en.wikipedia.org/wiki/God_object https://en.wikipedia.org/wiki/God_object
      - lucketone 11mo ago
        That one seems unrelated with OS security model and root account. (One must squint really hard to see root and oop god object as same)

saghm 11mo ago

My most recent mini-adventure with sudo was on the Steam Deck; with OS updates, everything (or at least most?) of what's outside of your home directory is replaced. (In fact, you have to manually opt into being able to write to those directories at all, e.g. to use the system package manager instead of flatpak, by running `sudo steamos-readonly disable`). There are a couple sudo settings I change from the defaults, and because `/etc/sudoers and `/etc/sudoers.d/` (as in the entire directory) were restored to the base versions, my custom settings don't get preserved when updates occur. However, I was surprised to find out that using `visudo` to try to update the settings wasn't actually causing the settings I changed to take effect, which I eventually tracked down to some extra configs getting shipped by the base system in `/etc/sudoers.d`. I looked up what the precedence rules are for sudo rules, and apparently the rule is that anything in `/etc/sudoers.d/` will override `/etc/sudoers`, and the files in `/etc/sudoers.d/` are evaluated in lexigraphical order. That's how I got where I am today, with a file called `zzz` that I copy into `/etc/sudoers.d/` every time there's a system update.

heavyset_go 11mo ago
There's probably a way you can just set it and forget it with overlayfs. OpenWRT solved the problem of updates via immutable firmware image flashing while maintaining customizations 15 years ago using it.
- saghm 11mo ago
  Probably! At the end of the day, this is the only change I need to make, and the updates are fairly infrequent, so this solution is good enough for me. I only brought it up as an example of how even the meta-rules around how sudo rules are interpreted might be more complex than people realize.

ninjin 11mo ago

I am somewhat cautious to comment as I know the author is way more experienced than I am and I fear that I may be missing something. However, let me try to accomplish the same with my elementary doas(1) knowledge. Allowing mounting for a specific group is simple with doas.conf(5): permit :mountd cmd /sbin/mount permit :mountd cmd /sbin/umount We can of course tighten it further as the author did: permit :mount-usb cmd /sbin/mount /dev/sdb1 permit :umount-usb cmd /sbin/umount /media/usb If you want to go more complex than specifying arguments, we could of course create a shell script and specify it instead of a binary. Likewise, we can do something similar for a service account: permit :www-deployment as www-deployment cmd /var/www/bin/build /var/www/application The key difference here would be that www-deployment can not delegate as easily to arbitrary users, as they would need to ask someone with root access to add additional users to the www-deployment group. But I am left wondering if this use case (if it is important enough) is not equally well served by specifying a location for non-root users to add permissions akin to what we see in doas.conf(5), but with the constraint that they of course can only allow other users to run commands with their privileges. Yes, it would "bloat" doas(1), but these code paths are not that long as long as you keep your scope constrained (doas(1) has a core of just over 500 lines and with environment handling and configuration format parsing we arrive a a final line count at just over 1,300). At this point, the main advantage I see with capsudod is that you can more easily drop privileges and put in restrictions like pledge(2) before the binary is ever called upon by whatever user we have granted permissions. While with the doas(1) thinking above you have to run over plenty of code that could be exploited. Still, this feels like a rather minor relative improvement to what we already have. Am I missing something in my ignorance? Lastly, let me also say that I am sure that sudo(8) has the ability to do the same things I proposed to do with doas(1) above, but I know the latter far better.

srazkvt 11mo ago
sure, but that doesn't change the fact that doas(1) is a suid binary. everything done would be done as root, from parsing the config file, checking the rights, and finally executing the command. capsudo here would rely on singular unix sockets with file access rights, so in essence, it would indeed be similar to what you could do with doas, but the idea here is to seperate things. with doas, doas would check if you have the correct group or user to do the command, while with capsudo, the kernel would check it, and reject it if you don't have the right.

haradion 11mo ago

If you squint hard enough, this is really a pretty similar idea to Polkit [0] but with a much simpler communication layer. [0]: https://polkit.pages.freedesktop.org/polkit/ https://polkit.pages.freedesktop.org/polkit/

qhwudbebd 11mo ago

Whenever I think about writing a central privileged daemon to grant capabilities to other processes, I'm puzzled by the choice to remove the old version of CAP_SETPCAP in 2.6.24: "grant or remove new capabilities to/from an existing running process" - sadly it still exists but means something else in newer kernels with filesystem capabilities. (In a sense, not having this capability in processes running as root is theatre anyway: you have /dev/kmem access so could just edit the kernel data structures. It's just doing so cleanly that is no longer possible.) Being able to briefly escalate my editor to have the capabilities to write /etc/wibble.conf when I started editing it as a non-privileged user, then take away the capability again would be more convenient that always needing to run the editor as root. (So convenient, in fact, that people fake this with little editor helpers that do the equivalent of 'really tee FILE-TO-WRITE >/dev/null', but that's an ugly hack.)

Denvercoder9 11mo ago
> you have /dev/kmem access so could just edit the kernel data structures. Not anymore: since kernel 2.6.26 /dev/kmem only exists if CONFIG_DEVKMEM is enabled, and it was removed completely in 5.13. [1] https://lwn.net/Articles/851531/ https://lwn.net/Articles/851531/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/mem.c?id=bbcd53c960713507ae764bf81970651b5577b95a https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

davexunit 11mo ago

It's nice to see other people writing about the capability transfer feature of Unix domain sockets. File paths are not object capabilities, but file descriptors are. Using a privileged daemon on top of an ambient authority system like Linux seems to be a good way to retrofit object capabilities onto the operating systems we already use. This is the same approach we took in Goblins[0] for our Unix domain socket netlayer for the OCapN[1] protocol. [0] https://spritely.institute/news/spritely-goblins-v0-16-0-released.html https://spritely.institute/news/spritely-goblins-v0-16-0-rel... [1] https://ocapn.org https://ocapn.org

nuudlman 11mo ago

This feels like pfexec on Illumos/Solaris, although I’m too unqualified to say for certain.