netdev - Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Jul 2016 16:13:25 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	David Ahern <dsa@...ulusnetworks.com>,
	David Miller <davem@...emloft.net>,
	Linux-Netdev <netdev@...r.kernel.org>
Subject: Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with
 CIPSO & Smack

On Tue, Jul 19, 2016 at 7:37 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> Digging into this further I have determined that the
> circumstances leading to this issue are somewhat complex.
> The good news is that there seems to be a very limited
> circumstances under which the problem manifests.
>
> I have a socket, and change the Smack attributes on the
> socket (security_inode_setsecurity) before connecting to
> a server.

This is a minty fresh, disconnected socket, yes?

> The connect succeeds. The client sends a packet,
> also successfully. The response is received. Now here's
> where it gets interesting. I instrumented the code to print
> the Smack attributes on the socket both before and after
> the Smack access check.

I'm assuming that when you say "access check" you are talking about
the smk_access() call in smack_socket_sock_rcv_skb(), yes?

(as a totally unrelated side note, you really went nuts on the cpp
conditionals in there, was there a sale on #ifdefs that I missed? <g>)

> Before the check is made the Smack
> data reflects the initial values from when the socket was
> created. After the check, they reflect the explicit change
> made earlier.

It has been too long since I looked at how Smack handled network
packets, I assume this is not the intended behavior?

> The check reports failure based on the initial
> values. As a result, an attempt to notify the caller that
> the action failed is made (netlbl_skbuff_err) which results
> in a call to icmp_send that frees already freed memory.

What memory is being double freed?  The original skb?  I don't believe
netlbl_skbuff_err(), cipso_v4_error(), or icmp_send() frees the
original skb ... or rather it shouldn't, perhaps I'm missing
something.

I'm not arguing, you saw what you saw, I'm just trying to understand
and make sense of it.  Can you elaborate on what you saw, using very
small words, and concrete descriptions (I'm much more stupider than
everyone here so you have to make it easy for me to understand)?

> If the Smack attributes in the sk_security blob are not
> explicitly set the problem does not occur. I have the same
> result if I change the Smack attributes within the socket
> security blob as I do if I replace the security blob.

-- 
paul moore
www.paul-moore.com