Problems with capabilities
Problems with capabilities
Posted Jun 21, 2024 16:36 UTC (Fri) by NYKevin (subscriber, #129325)In reply to: Problems with capabilities by Cyberax
Parent article: A capability set for user namespaces
It is not 1985 any more. Just use systemd like everybody else, or at least use *something* that binds ports for you.
Posted Jun 21, 2024 22:08 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
At this point, does it matter? If you have untrusted unconfined code running as nobody, you're toast. You likely need to confine code to prevent ANY listening ports. There is also UPNP that can allow fully untrusted code to request your router to redirect your actual port 80 to any port.
On the other hand, the notion of privileged ports lead to many real issues with software that had to run as root (and maybe drop privileges after listening on a system port).
> It is not 1985 any more. Just use systemd like everybody else, or at least use *something* that binds ports for you.
Sure. And it's also not 1985, so randomly listening on a port won't expose it to the world because of NAT and other rules.
Posted Jun 22, 2024 3:35 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
All security is defense in depth. "If the attacker can do X, you've already lost" is a fallacy unless X is "on the other side of the airtight hatch," as Raymond Chen usually puts it. Local nobody is very deliberately *not* on the other side of the airtight hatch.
> There is also UPNP that can allow fully untrusted code to request your router to redirect your actual port 80 to any port.
The set of people who are using UPNP and the set of people who own domain names and use them for serious purposes do not exactly have an empty intersection, but it's not a very large intersection.
> And it's also not 1985, so randomly listening on a port won't expose it to the world because of NAT and other rules.
If we're talking about a system that owns a domain, it is reasonably likely that its port 80 is actually exposed to the real internet. If that is not the case, then it is difficult to argue that the system really "owns" the domain at all (unless it's some internal/split-horizon thing).
Posted Jun 22, 2024 4:37 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
The thing is, CAP_NET_SYS_BIND is not a free convenience. It imposes a lot of complications. For example, ejabberd creates listening sockets itself, based on the configuration. Before you scream "systemd!", ejabberd supports live reconfiguration, as interfaces can come and go. To be able to listen on privileged ports, it had to run as root.
> The set of people who are using UPNP and the set of people who own domain names and use them for serious purposes do not exactly have an empty intersection, but it's not a very large intersection.
So let's look at the requirements:
1. Untrusted code must be running on port 80.
In short, that's a highly unlikely scenario.
And these days, a lot of important services run on >1024 ports.
So for a real security, you'd want to deny untrusted users the ability to listen on ANY non-localhost-bound port. This kind of functionality is actually useful, and can work well with systemd.
Posted Jun 23, 2024 7:47 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
So does systemd.
But there is no point in continuing to discuss ejabberd's use case in particular, because Jabber is all but dead anyway. If ejabberd mattered, it would have gotten some kind of bespoke systemd integration, if you are correct in asserting that it would have needed such a thing in the first place.
> 1. Untrusted code must be running on port 80.
There is no such thing as "code running on port 80," trusted or otherwise. You mean that untrusted code must be running, and also must be allowed to bind port 80.
> On a machine that is a target of a domain name. That somebody actually cares about.
Web servers are a primary use case of Linux (much more common than ejabberd, certainly). I find it rather baffling that you are trying to characterize this as an unlikely deployment scenario. It is by far the most common deployment (that is a server of some kind - i.e. excluding Android, Steam Decks, scientific/engineering workstations, etc.).
> 3. The existing server must be down.
An attacker intentionally causing the server to crash is not implausible. It is accepting requests from the outside world, which it has to do in order to function as a web server.
> In short, that's a highly unlikely scenario.
No, it is a highly *specific*, but relatively common scenario.
Problems with capabilities
Problems with capabilities
Problems with capabilities
2. On a machine that is a target of a domain name. That somebody actually cares about.
3. The existing server must be down.
3. With SO_REUSEPORT it might be possible to listen alongside the server it if it also runs as 'nobody', but that option was added only recently. And if the code is the same user, it can trivially ptrace() the webserver process and inject whatever code it wants.
Problems with capabilities