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

[Andrew Cagney]

On Thu, 11 Mar 2021 at 17:56, Andrew Cagney <andrew.cagney at gmail.com> wrote:

>
> It's the error paths where we have problems - even if that is down to one
> line.
> We also have problems with code working src/dst (which could be
> incoming or outgoing).
>
>
So I hacked a local branch to:

- add .is_sensitive to the ip_structures, and propagate it
- mark anything from the wire as sensitive
- mark any remote address (i.e., from recv) as sensitive
- force log_ip=false

and, yes, it is errors that lack sanitizing:

"test1" #1: Peer ID is ID_IPV4_ADDR: '<sensitive-address>'
"westnet-eastnet" #1: the peer proposed: <sensitive-selector> -<all>->
<sensitive-selector>

It also turned up a counter problem: the code building up and then invoking
up-down scripts should not be sanitized - we'd need jam_unsanitized*()?

> > 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() ...
> >
> > enabling verbose logging or debug is game over for privacy. We can't
> > start obfuscating things there.
>

Enabling debugging could disable sanitizing, or I think better, warn of the
conflict.
It can also be viewed as a feature - someone posting sensitive logs is less
likely to leak an address

food for thought
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210409/527b3c3f/attachment.html>