29 ms·

>As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially Which is why what we r

>As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address. Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks.

BeefWellington 4y ago
> Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. SELinux can effectively do this via the 'semanage port' options[1] -- so you could configure it and then set privileged ports to 0 and achieve what you're looking for. Admittedly this seems like using a crane and wrecking ball to hang a painting. [1]: https://www.man7.org/linux/man-pages/man8/semanage-port.8.html https://www.man7.org/linux/man-pages/man8/semanage-port.8.ht...
- worthless-trash 4y ago
  I think you're overstating the additional complexity, just a little.
  - Spivak 4y ago
    SELinux on CentOS 7+ is basically turnkey. If you’re turning it off you’re doing yourself a disservice.
    - worthless-trash 4y ago
      Can't agree more.
- thayne 4y ago
  > Admittedly this seems like using a crane and wrecking ball to hang a painting Precisely. SELinux is incredibly complicated. It would be nice to have something simpler.
  - Spivak 4y ago
    Anything you invent that can confine software from the outside will become SELinux. SELinux is actually really simple, you tag stuff and write rules about what tags can and can’t do to other tags. And writing your own policies, while strange and esoteric because it uses m4, is straightforward. SELinix is hard because you really have to know what’s going on with your software to actually write these policies. The complexity is in creating a maintainable system of tags and rules with software that does all kinds of crazy weird things. The complexity is irreducible. The only thing you can really do is create tools to handle common cases and that’s semanage.
    - vlovich123 4y ago
      And yet I recall managing launchd security policies to be a fraction of the complexity to manage and easier to verify you were doing the thing you intended. As compared with Android where I observed SELinux required far more man power to maintain / complexity / foot guns. Now maybe SELinux is indeed more powerful. I’m not well versed enough in that problem domain to do a comparison. In terms of successfully getting broad adoption across teams of various skill sets, I’d say the launchd approach is better holistically.
      - tux1968 4y ago
        I thought launchd was more akin to systemd than to selinux or apparmor. Some brief googling didn't show anything about security policies. Do you have a link where I could learn some more?
        vlovich123 4y ago
        I don't know that there's anything external and it's possible I may have misremembered. Performance limits are managed in launchd (maximum memory etc). File access security is managed by setting a class on the file via ioctl which controls when the file is accessible (after first unlock, while screen is unlocked, etc). Maybe there isn't a secondary security layer? Can't recall now but I swear I thought the launchd plist described it all. I don't have a Mac anymore so I can't even look at the plist contents to double-check.
wavesquid 4y ago
> Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks. There should be no need for that if you use ambient capabilities. Which you can set in e.g. a systemd unit.
mappu 4y ago
The `authbind` package can automate this by path, user, port and many other things. It comes from the Debian world (developed by Ian Jackson) so perhaps less well known for RPM users? https://en.wikipedia.org/wiki/Authbind https://en.wikipedia.org/wiki/Authbind
akira2501 4y ago
> Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address. So, regular file permissions for ports. It would be nice if we had 9p's concept of a network filesystem here. No ioctl() needed.
- remram 4y ago
  Isn't this provided by inetd and systemd? They bind the socket and hand it to the server, who doesn't need permission to bind any port at all? (with the added optional benefit of "socket activation", i.e. starting the server on-demand when the first connection comes in)

BeefWellington 4y ago

> Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. SELinux can effectively do this via the 'semanage port' options[1] -- so you could configure it and then set privileged ports to 0 and achieve what you're looking for. Admittedly this seems like using a crane and wrecking ball to hang a painting. [1]: https://www.man7.org/linux/man-pages/man8/semanage-port.8.html https://www.man7.org/linux/man-pages/man8/semanage-port.8.ht...

worthless-trash 4y ago
I think you're overstating the additional complexity, just a little.
- Spivak 4y ago
  SELinux on CentOS 7+ is basically turnkey. If you’re turning it off you’re doing yourself a disservice.
  - worthless-trash 4y ago
    Can't agree more.
thayne 4y ago
> Admittedly this seems like using a crane and wrecking ball to hang a painting Precisely. SELinux is incredibly complicated. It would be nice to have something simpler.
- Spivak 4y ago
  Anything you invent that can confine software from the outside will become SELinux. SELinux is actually really simple, you tag stuff and write rules about what tags can and can’t do to other tags. And writing your own policies, while strange and esoteric because it uses m4, is straightforward. SELinix is hard because you really have to know what’s going on with your software to actually write these policies. The complexity is in creating a maintainable system of tags and rules with software that does all kinds of crazy weird things. The complexity is irreducible. The only thing you can really do is create tools to handle common cases and that’s semanage.
  - vlovich123 4y ago
    And yet I recall managing launchd security policies to be a fraction of the complexity to manage and easier to verify you were doing the thing you intended. As compared with Android where I observed SELinux required far more man power to maintain / complexity / foot guns. Now maybe SELinux is indeed more powerful. I’m not well versed enough in that problem domain to do a comparison. In terms of successfully getting broad adoption across teams of various skill sets, I’d say the launchd approach is better holistically.
    - tux1968 4y ago
      I thought launchd was more akin to systemd than to selinux or apparmor. Some brief googling didn't show anything about security policies. Do you have a link where I could learn some more?
      - vlovich123 4y ago
        I don't know that there's anything external and it's possible I may have misremembered. Performance limits are managed in launchd (maximum memory etc). File access security is managed by setting a class on the file via ioctl which controls when the file is accessible (after first unlock, while screen is unlocked, etc). Maybe there isn't a secondary security layer? Can't recall now but I swear I thought the launchd plist described it all. I don't have a Mac anymore so I can't even look at the plist contents to double-check.

wavesquid 4y ago

> Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks. There should be no need for that if you use ambient capabilities. Which you can set in e.g. a systemd unit.

mappu 4y ago

The `authbind` package can automate this by path, user, port and many other things. It comes from the Debian world (developed by Ian Jackson) so perhaps less well known for RPM users? https://en.wikipedia.org/wiki/Authbind https://en.wikipedia.org/wiki/Authbind

akira2501 4y ago

> Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address. So, regular file permissions for ports. It would be nice if we had 9p's concept of a network filesystem here. No ioctl() needed.

remram 4y ago
Isn't this provided by inetd and systemd? They bind the socket and hand it to the server, who doesn't need permission to bind any port at all? (with the added optional benefit of "socket activation", i.e. starting the server on-demand when the first connection comes in)