> On 6 Jun 2025, at 12:45 PM, Greg Troxel <g...@lexort.com> 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
