On Wed, Aug 14, 2013 at 7:25 PM, Henning Brauer <lists-openbsdb...@bsws.de> wrote: > > * Maxim Khitrov <m...@mxcrypt.com> [2013-08-14 22:51]: > > On Wed, Aug 14, 2013 at 3:14 PM, Mike Belopuhov <m...@belopuhov.com> wrote: > > > unless a local socket is found, user or group check will not be performed. > > That doesn't make sense to me. Are you saying that a user/group > > condition is ignored in some cases? That sounds like a bug in itself. > > think it through: how do you look uo the user owning the socket on a > remote machine?
That's not what I meant and it's not what the man page says: "For outgoing connections initiated from the firewall, this is the user that opened the connection. For incoming connections to the firewall itself, this is the user that listens on the destination port. For forwarded connections, where the firewall is not a connection endpoint, the user and group are unknown... Forwarded packets with unknown user and group ID match only rules that explicitly compare unknown with the operators = or !=. For instance user >= 0 does not match forwarded packets." That's exactly the behavior that I wanted. Here are some (untested) examples: # Only match firewall-initiated connections pass out proto tcp user >= 0 # Only match connections where the firewall is the destination (and a local daemon is listening) pass in proto tcp user root # Only match connections that will be forwarded (or nothing listening on the local host) pass in proto tcp user unknown # Only match connections that were forwarded (similar to "received-on all"?) pass out proto tcp user unknown In my original example, the connection is forwarded, but "user root" is either matched or ignored. I'm not sure which one, but either action is wrong if the user is supposed to be "unknown" in this situation, as the man page says. It explicitly states that such forwarded connections should not be matched unless tested with "user = unknown".
