netdev - Re: [PATCH net-next v4 0/2] net: Introducing socket mark receive socket option

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 2 Mar 2015 20:34:32 +0200
From:	Eyal Birger <eyal.birger@...il.com>
To:	Florian Westphal <fw@...len.de>
Cc:	David Miller <davem@...emloft.net>,
	Willem de Bruijn <willemb@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Shmulik Ladkani <shmulik.ladkani@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v4 0/2] net: Introducing socket mark receive
 socket option

Hi,

On Mon, Mar 2, 2015 at 4:36 PM, Florian Westphal <fw@...len.de> wrote:
> Eyal Birger <eyal.birger@...il.com> wrote:
>> On Mon, Mar 2, 2015 at 3:29 PM, Florian Westphal <fw@...len.de> wrote:
>> > Eyal Birger <eyal.birger@...il.com> wrote:
>> >> This patch set introduces a new socket option for fetching the mark
>> >> of skbs passed to sockets as ancillary data.
>> >>
>> >> A userspace program may wish to receive the mark of packets it
>> >> receives, for example for distinguishing between different TPROXY
>> >> diversion rules to the same userspace proxy socket.
>> >
>> > Hmm... Whats the use case?
>> > Even if you cannot use multiple sockets for every divert rule,
>> > TPROXY doesn't mangle payload; applications could use sockaddrs
>> > returned by accept, getpeername, getsockname etc.  to figure out
>> > which original port/address the packet was sent to?
>>
>> Right. But that would mean the criteria for traffic diversion would need to
>> be known to the application receiving the traffic.
>
> For your solution to work the application needs to know about the TPROXY
> rule set and how that is structured, no?
>

The application does not need to know about the match criteria. Only about the
eventual mark. This decouples the semantics of a flow and it's actual
match criteria.

> I don't see how that is 'better' than e.g. looking at dst port number.

As mentioned, in cases where the match criteria is more complex than
just the dst
port number, the match logic has to be duplicated in the application.

>
>> Also, the feature has use-cases outside of TPROXY as the skb->mark may be set
>> by other mechanisms (including SO_MARK from user space).
>
> Right, but to me it seems very hacky to use SO_MARK as some kind of OOB signal.
>
> It won't work depending on loaded ruleset, it won't work with non-localhost
> traffic and it won't work when other application runs in another network
> namespace.
>
> Seems such facility would be limited to some pre-configured distribution where
> users don't run own software and make no changes to the default system
> setup.
>

It does not necessarily imply a static configuration, only a carefully
crafted one.
There are more than a few systems with this premise.

>> For example, a user space daemon can receive traffic from multiple
>> applications using a single socket and distinguish between different traffic groups
>> according to the packet mark.
>
> Right, but it might as well use SO_PEERCRED to identify the other pid, right?

I don't think so.

This would only work on connection/pair based sockets (and currently
only supported
in AF_UNIX) - the skb->mark can be different on a per packet basis -
especially when
several applications interact with a single daemon.

Regards,
Eyal.
--
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