From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, xiyou.wangcong@gmail.com
Subject: Re: [net-next PATCH v2 1/1] net sched actions: skbedit add support for mod-ing skb pkt_type
Date: Mon, 13 Jun 2016 07:52:30 -0400 [thread overview]
Message-ID: <575E9E7E.6000507@mojatatu.com> (raw)
In-Reply-To: <575E681B.8080500@iogearbox.net>
On 16-06-13 04:00 AM, Daniel Borkmann wrote:
> Hi Jamal,
>
> On 06/12/2016 11:24 PM, Jamal Hadi Salim wrote:
>> From: Jamal Hadi Salim <hadi@mojatatu.com>
>>
>> Extremely useful for setting packet type to host so i dont
>> have to modify the dst mac address using pedit (which requires
>> that i know the mac address)
>>
>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
> I'm wondering if this is a good idea, I was thinking about something
> like this as well some time ago.
Good ;-> What was your uses case?
In my case it is mostly to allow packets coming into the system
with the wrong MAC address (but correct IP address).
I dont want to keep checking what the MAC address is and adding
a rule to change it before it goes up the stack.
> So far pkt_type is just exposed as
> read-only to user space right now and I'm a bit worried that when we
> allow to set it arbitrarily, then this could lead to hard to debug
> issues since skb->pkt_type is used in a lot of places with possibly
> different assumptions and applications now need to mistrust the kernel
> whether skb->pkt_type was actually what the kernel itself set in the
> first place or skbedit with possibly some nonsense value (like rewriting
> PACKET_OUTGOING into PACKET_LOOPBACK, etc).
Separation of church from state.
In Unix we allow people to shoot their big toe if they want to.
If someone wants to change the destination MAC address to something
stupid they can. If someone wants to set the skbmark they can.
They'll find out it is a bad idea pretty quickly if it was not
what they intended. This is no different.
>Did you audit that this is safe?
Do you see a security issue? then that would need an audit.
cheers,
jamal
next prev parent reply other threads:[~2016-06-13 11:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-12 21:24 [net-next PATCH v2 1/1] net sched actions: skbedit add support for mod-ing skb pkt_type Jamal Hadi Salim
2016-06-13 8:00 ` Daniel Borkmann
2016-06-13 11:52 ` Jamal Hadi Salim [this message]
2016-06-13 12:21 ` Daniel Borkmann
2016-06-13 21:52 ` Jamal Hadi Salim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=575E9E7E.6000507@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).