No, you can grant yourself this inside an unprivileged user namespace. `unshare -Ur capsh --print` lists the capabilities inside a user namespace and demonstrates that it has both CAP_SYS_ADMIN and CAP_NET_ADMIN.
Almost all distros allow unprivileged user namespaces, and in my opinion this is the right decision, because they're important for browser sandboxing which I think is more important than LPEs.
You're probably right, but that seems like the less important part of this. At that point you've already got an out-of-bounds write. Another comment speculated that you could use PageJack as an alternative exploit path once you have that primitive: https://news.ycombinator.com/item?id=48069623
Some codepaths do ns_capable() (must have capability in owning namespace, reachable via unprivileged user namespaces), some do capable() (must have capability in host user namespace, not reachable via user namespaces at all).
ZCRX can only be enabled by passing capable(CAP_NET_ADMIN), so you need to be privileged on the host.
Namespaces _may_ result in limits on what you can do with a capability, but a capability is global in scope.
If a kernel feature is gated on cap_sys_admin only, it doesn't matter at all what namespace it is in. Namespace support or additional constraints are not implicit and have to be added to each need.
People misunderstanding this is partially why we have this latest crop of vulnerabilities.
Am I reading this wrong or is this just a way of executing an arbitrary binary with uid=0 if you have both CAP_NET_ADMIN and CAP_SYS_ADMIN?
If you can write modprobe_path, is it really news that you can find a way to execute code?