1025606 - [Flame] Ensure IPv6 defaults to privacy extensions enabled

Status: RESOLVED FIXED

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[:gerard-majax]

Attachment: IPv6 without privacy extensions

The current IPv6 configuration on Flame does not make use of the IPv6 privacy extensions, leading to potential leaking of personnal infos.

Comment 1

[:gerard-majax]

The fix involve just pushing the proper option to use_tempaddr:
> echo 2 > /proc/sys/net/ipv6/conf/default/use_tempaddr

After this, the IPv6 addr preferred is a generated one.

Comment 2

[:gerard-majax]

Attachment: IPv6 Privacy preferred

Screenshot after enabling IPv6 privacy extension.

Comment 3

[:gerard-majax]

This should be set in init.qcom.sh from device/qcom/common

Viral, Vance, can you reach to CAF for this? This should help enforcing user privacy.

Comment 4

[:gerard-majax]

Attachment: Ensure IPv6 privacy extensions are used

Comment 5

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Alexandre -

This happens on JB or KK build?

Thanks

Vance

Comment 6

[:gerard-majax]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #5)
> Hi Alexandre -
> 
> This happens on JB or KK build?
> 
> Thanks
> 
> Vance

Both.

Comment 7

[viral [:viralwang]]

I think Vance already help on this, thanks :)

Comment 8

[viral [:viralwang]]

Comment on attachment 8488595 [details] [diff] [review]
Ensure IPv6 privacy extensions are used

I think we should move it to device-flame/init.target.rc to reduce the maintain effort.

Comment 9

[:gerard-majax]

Attachment: JB Device PR

Comment 10

[:gerard-majax]

Attachment: KK Device PR

Comment 11

[Michael Wu [:mwu]]

Hmm. Well, at minimum we should use RFC 7217 to hide the mac address. dhcpcd 6.4 supports that. Unfortunately the shipping dhcpcd doesn't seem to be that new, and this is easier to turn on. There seems to be some complaints about the privacy extensions that aren't an issue with RFC7217. However, it sounds like iOS 7 has privacy extensions turned on, so maybe it's not a big deal.

Comment 12

[:gerard-majax]

(In reply to Michael Wu [:mwu] from comment #11)
> Hmm. Well, at minimum we should use RFC 7217 to hide the mac address. dhcpcd
> 6.4 supports that. Unfortunately the shipping dhcpcd doesn't seem to be that
> new, and this is easier to turn on. There seems to be some complaints about
> the privacy extensions that aren't an issue with RFC7217. However, it sounds
> like iOS 7 has privacy extensions turned on, so maybe it's not a big deal.

So, r+ or r- ?

Comment 13

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Alexandre LISSY :gerard-majax from comment #12)
> (In reply to Michael Wu [:mwu] from comment #11)
> > Hmm. Well, at minimum we should use RFC 7217 to hide the mac address. dhcpcd
> > 6.4 supports that. Unfortunately the shipping dhcpcd doesn't seem to be that
> > new, and this is easier to turn on. There seems to be some complaints about
> > the privacy extensions that aren't an issue with RFC7217. However, it sounds
> > like iOS 7 has privacy extensions turned on, so maybe it's not a big deal.
> 
> So, r+ or r- ?

Comment 14

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Freddy, can you have a look at this from a secreview perspective. Sounds like an important feature but I'm interested to know what implications there are for enabling this.

Comment 15

[Michael Wu [:mwu]]

BTW, regarding the implementation, if we want to do this, we should enable it *everywhere*, through init.b2g.rc and then pushing upstream to CAF since they don't use init.b2g.rc.

Comment 16

[Frederik Braun [:freddy]]

I am going to call this "sec moderate": Leaking "private" through your IPv6 isn't uncommon but not something we'd like to keep.
I can't r+ this as asked in the quote from Alexandre, but I support the idea of enabling them across all supported platforms.

Comment 17

[Michael Wu [:mwu]]

Comment on attachment 8493800 [details] [review]
KK Device PR

Clearing review since we'd like this to apply everywhere. I suggest patching init.b2g.rc, and then having a separate patch for the init.rc in CAF's system/core. The init.rc patch would go upstream.

Comment 18

[:gerard-majax]

Attachment: PR for gonk-misc

Michael, this is the PR for init.b2g.rc. How are we supposed to make partner's include this?

Comment 19

[Michael Wu [:mwu]]

Comment on attachment 8506096 [details] [review]
PR for gonk-misc

This will fix it for everything but CAF based devices. For CAF, make a patch against the copy of init.rc in system/core and request review from :m1 .

Comment 20

[:gerard-majax]

Attachment: Use IPv6 privacy extensions by default r=m1

Comment 21

[:gerard-majax]

Thanks, how do we get this landed on CAF side now?

Comment 22

[:gerard-majax]

https://github.com/mozilla-b2g/gonk-misc/commit/73d68c9c91bc568ce7c888ac057b3f44bd1b2e79

Comment 23

[Michael Vines [:m1] [:evilmachines]]

(In reply to Alexandre LISSY :gerard-majax from comment #21)
> Thanks, how do we get this landed on CAF side now?

We'll track it internally for the next product release.  There is no branch on CAF at this time though, so if you want this to apply to Flame now then a Mozilla fork will be needed for your usage.

Comment 24

[:gerard-majax]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #23)
> (In reply to Alexandre LISSY :gerard-majax from comment #21)
> > Thanks, how do we get this landed on CAF side now?
> 
> We'll track it internally for the next product release.  There is no branch
> on CAF at this time though, so if you want this to apply to Flame now then a
> Mozilla fork will be needed for your usage.

I'm not a big fan of forking if CAF will include. When is the next product release planned?

Comment 25

[Michael Vines [:m1] [:evilmachines]]

Please contact your product management team.

Comment 26

[:gerard-majax]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #25)
> Please contact your product management team.

Candice, do you have any input on this?

Comment 27

[Candice Serran (:cserran)]

(In reply to Alexandre LISSY :gerard-majax from comment #26)
> (In reply to Michael Vines [:m1] [:evilmachines] from comment #25)
> > Please contact your product management team.
> 
> Candice, do you have any input on this?

Gregor to respond via email as this is partner-sensitive...

Comment 28

[:gerard-majax]

To be verified once CAF has this.

Comment 29

[John Thomas [:Johnt]]

This issue appears to be an issue Qanalyst is unable to verify. Marking QAExclude in QA Whiteboard.