On 6 Jun 2025, at 12:45 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:
I think we need to step back and first establish requirements and goals.
It makes sense to me to be able to use uid/gid as a selector in firewall
rules. I don't agree that making rules about socket creation/binding is
sufficient. I can think of a specific use for a program with its
associated uid that I would want to write per-program (per-uid) rules
for.
While not addressing colluding programs, one could run program A as user
A, and then write rules that user A can only send/receive to some
particular prefix, or to specific addresses and ports. This happens on
Android, e.g. in CalyxOS, where one can turn on/off network access per
app (which is per uid because that's how apps work on Android),
selecting wifi/cell/vpn separately.
The question of what happens to a listen-cloned socket that is handed to
a non-privileged process from a root-created listen socket is a good
one. I see the point of previous comments that the proper uid is not
obvious and not one-size-fits-all. But I can very much see the point of
wanting the unprivileged user to own the socket, or really to be the uid
that is used in firewall lookups.
Turning this around, why is a listen socket owned by root anyway, for a
non-root daemon? It might be just because of privileged port, and no
other reason, so perhaps that deserves a changed uid anyway.
Unix-domain sockets are perahps another matter, and perhaps not. We
don't have the ability to firewall them. Perhaps we should, but it
doesn't seem pressing.
Maybe that’s for another day.
A scoffer seeks wisdom in vain, but knowledge is easy for a man of understanding.
Emmanuel
|