netdev - Re: [PATCH] net: reflect the fwmark for replies with no socket

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]

Message-ID: <CAKD1Yr2rSwpzSdvjsO-=QUkivAkw2gnj+_mvydtR8OfAnsTicg@mail.gmail.com>
Date:	Mon, 17 Mar 2014 14:24:57 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: reflect the fwmark for replies with no socket

On Thu, Mar 13, 2014 at 5:17 AM, David Miller <davem@...emloft.net> wrote:
>> Kernel-originated IP packets that have no user socket associated
>> with them (e.g., ICMP errors and echo replies, TCP RSTs, etc.)
>> are emitted with a mark of zero. Instead, make them have the
>> same mark as the packet they are replying to.
>>
>> This is consistent with TOS, which is also reflected from the
>> incoming packet, and it allows the administrator to use
>> mark-based routing, firewalling, etc. for these replies by
>> marking the original packets inbound.
>>
>> Also fix the IPv6 code to reflect the tclass in replies like the
>> IPv4 code does.
>>
>> Change-Id: Ifd8dd75016e60dc982e7860f720d45c27dcaf04c
>> Signed-off-by: Lorenzo Colitti <lorenzo@...gle.com>
>
> I don't think it's safe to change this behavior after all of this
> time.

Fair enough. My bad.

> And incoming marks absolutely do not have any automatic relation
> to what an administartor might want to use for output packets.

In general, that's true. Still - currently the mark on these packets
is 0, period, and the administrator can't do anything about that at
all. The idea was that some control is better than zero control, and
since these packets are always in reply to other packets, then marking
responses based on the packets that provoked them made sense, since
the input marking can be as flexible as the administrator desires.

If this was optional behaviour (e.g., controlled by
/proc/sys/net/ipv{4,6}/reflect_fwmark), would that be acceptable?
That way, even if it doesn't work for everyone, at least some
environments will be able to use it. I'm happy to send in a new patch
that does that.

If not, do you see another way to do this? If you use mark-based
routing, there doesn't currently seem to be a good way of sending
these packets where they need to go. iptables doesn't really work,
because it can only touch the packet after a lot of it has been
decided. You can override some of those decisions via NAT / MSS
rewrite / ..., but it gets messy, and it seems better to send the
right packet off the bat rather than send the wrong one and then
rewrite it without updating any of the socket structures.

Regards,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html