[Swan-dev] tainted^D^D^D^D sensitive addresses

Andrew Cagney andrew.cagney at gmail.com
Thu Feb 25 15:28:42 UTC 2021


Hi,

I'm sitting on a patch that adds still more str_*_sensitive()
functions but I'm getting the feeling that it is both excessive and
deficient.  For instance, consider:

   str_endpoints_sensitive(local, remote)   1.2.3.4:0 -ICMP-> 4.3.2.1:8
   str_endpoints_sensitive(remote, local)   4.3.2.1:8 -ICMP-> 1.2.3.4:0

with sanitizing turned on, we end up with:

  str_endpoints_sensitive(local, remote) <endpoint> -<sensitive>-> <endpoint>

which is really not very helpful.

Hence, I'm wondering if instead (if it isn't obvious from the subject)
we can pick up on both Antony's ip_range.is_subnet hint and perl's
tainted variable hack and add a .sensitive bit to ip_* types.  The
functions manipulating ip_* types would propagate the bit, and the
str_*() functions would check the bit when emitting strings.

That way, because only the remote endpoint has the sensitive bit set,
we'd be able to log the more meaningful:

   str_endpoints(remote, local)   <endpoint> -ICMP-> 1.2.3.4:0
   str_endpoints(local, remote)   1.2.3.4:0 -ICMP-> <endpoint>

one place I know this will fall flat is with dbg() lines.  The current
convention is to not sanitize addresses in dbg() lines, the above
would make that impossible (short of str_endpoints_insensitive() ...
:-).


More information about the Swan-dev mailing list