Connecting to a unix abstract socket from chromium

[Primiano Tucci]

Hello security-dev,

TL;DR:

Context: chrome://tracing. I'm writing a CL which connects to a UNIX socket (the expected endpoint won't be there most of the times / in production). Is there any security risk associated with that (trying to connect) I should be aware of?

Longer story:

on Android we need to get some graphics memory stats (for the browser and gpu processes) into tracing because we need to track them continuously into telemetry/chromeperf dashboards. Due to the way the API is designed in Android, those stats are accessible only to root, which is a bummer for chrome.

The solution I designed (link to design doc) is organized into two major parts:

 1. [not shipped] a unix daemon which runs as root on the device and listens on a UNIX abstract socket. The daemon will be there only when: running telemetry; developers follow the extra steps ( ninja and adb push).

 2. When tracing is enabled, the tracing code inside of chrome tries to connect to the UNIX socket, sends its PID and receives back the memory stats; noop if the daemon is not present (connect fails).

The daemon itself (1.) is OUT of the scope of this request, as it is not shipped / does not affect production chrome.

My question here is about 2. Can you see a problem having chrome code trying to connect to a unix abstract socket? The code (Link to file in the cl) is checking that the other socket endpoint is root and bails out otherwise.

I think it's fine security-wise but I am also not a security guy, so I guess what I think might not be necessarily relevant.

In essence the expected output of this mail is:

- Go ahead, this is just fine and I'm just over-worrying -> apologies for the noise

- I need to loop a reviewer from security-dev in the CL -> name plz?

- Some other process to follow?

Thanks,

Primiano

[Joel Weinberger]

This sounds like non-trivial work to me, so I'm surprised to see you don't have a launch bug to track the feature. At the very least, you should probably follow the Chrome Security Reviews guide, which will make it a lot easier for us to help you.

--Joel 

[Primiano Tucci]

> This sounds like non-trivial work to me

Did you had a chance to look at the linked cl? gyp/gn plumbing aside ut's a <100 lines connect()+send()+recv()? Can you please explain what part specifically does sound non-trivial?

> I'm surprised to see you don't have a launch bug to track the feature

I'm confused, the doc you linked seems to be about "All launches and major changes to Chrome". This is part of an already existing feature (tracing), not even user facing (unless following manual debugging steps). Does this require a new launch?

[Joel Weinberger]

Per an offline discussion, we're going to move this to chrome-...@google.com, since it's really more of an issue about reviewing.