Security Principals from outside of //content

[Emily Andrews (LEDBETTER)]

Hi,

I'm trying to figure out how to make it an option to launch a service in such a way that the process can be associated with a ProcessLock. This pairs with my work on making processes reusable by multiple services because some services may be tied to a particular site and browser context and we need to be able to respect site isolation.

ServiceProcessHost::Options today includes an optional Site so you can associate the process with a site. This option is currently used from the //media directory. I have a series of Code Reviews out to make SiteInfo public because SiteInfo will also have the browser context necessary to create a ProcessLock. However, I wanted to ask around and see if anyone else had better ideas.

Thanks,
Emily

Sent from Outlook

[Emily Andrews (LEDBETTER)]

Hi,

I'm interested in being able to pass a SiteInfo into ServiceProcessHost::Options instead of a Site because SiteInfo has the browser context information and if we're tying utility processes to a particular site, we should have that security context. However, that requires making a lot of files public to roll SiteInfo to public.

If there's a better security principal for this, please let me know.

Thanks,

Emily

Sent from Outlook

---

From: Emily Andrews (LEDBETTER)
Sent: Monday, January 27, 2025 10:58 AM
To: Site Isolation Development <site-isol...@chromium.org>
Subject: Security Principals from outside of //content

 

[Charlie Reis]

Thanks for reaching out about it!  We chatted in the CSA meeting today and think it may make sense to finally expose a new public interface (e.g., SecurityPrincipal), but probably not SiteInfo in its entirety (which will later become a SecurityPrincipalImpl, especially as features like Origin Isolation and SiteInstanceGroup ship, making it possible for the principal to be an origin instead of a site in more cases).  We most likely won't want the public API to have ways of creating a new SecurityPrincipal just yet, and instead expose existing ones via SiteInstance, but we can discuss more details about what's needed.

Introducing this concept is something we've planned to do for a while (e.g., 40132133 and this doc), but it's a fairly large conceptual change and hasn't been necessary so far.  The right next step is probably to start a chromium.org doc discussing the new concept and what we want to be in the public interface vs the content-internal implementation, before proceeding with landing any changes.  We're happy to work with you on that, if you want to either start the doc or contribute to it.

Does that sound like it would help?

Charlie

[Emily Andrews]

Hi,

I started a conversation with our site isolation group at Microsoft. I'm pretty booked on finding performance gains for WebUIs this coming year, and my colleagues are excited to contribute to the project!

I think to move forward with my interests, I can either implement a very basic Principal interface SiteInfo inherits from that includes the relevant operators and the creation function with the GURL and Context object (current code makes it seem like IsolationContext is probably superfluous in favor of BrowserContext) or hold off on implementing a complete Utility Process Pooling solution with site isolation until there's a forcing use case or the API is made available in a few months.

From the document and the current uses, it's not super clear to me if the Principal is meant to be used as a key for comparison or the ProcessLock is supposed to be used as a key for comparison as it's being used in ChildProcessSecurityImpl. What I would like to do for my implementation of the sorting algorithm is to inherit off the correct key and make it a snap for someone to compare the Utility Process principal with the renderer process principal.

I implemented it today with a UtilityProcessLock that inherits off of ProcessLock and then if we hypothetically were to compare UtilityProcessLock A with ProcessLock B, it would use the ProcessLock operators, but if UtilityProcessLock A is compared with UtilityProcessLock C, it will use UtilityProcessLock operators. I'm planning to just pack in all the relevant ServiceProcessHost::Options into this key for the purposes of identifying suitable matches.

Let me know what your preferences are for me to move forward on this.

[Charlie Reis]

Thanks!  We're excited to move forward with this.  I think you might be getting a little too far ahead in planning the specific code changes, comparators, etc, though.  Can you start with a design doc (which is public / accessible to chromium.org accounts) proposing the new principal interface and how it will fit into the utility process work?  That's an important first step for us to agree on before moving to code changes.

A few points from my perspective:

• The doc I linked to is pretty old and has some stale references (e.g., FrameGroup refers to what is now SiteInstanceGroup, etc), so just take it as a general direction and not specific requirements.
• I think one of the interesting parts of this discussion will be deciding how SecurityPrincipal and ProcessLock should relate to each other, and how comparisons are done.  Today, a ProcessLock basically has a single SiteInfo or allows any site, but we would like to move to an API that says whether a given SecurityPrincipal is compatible with / allowed within a ProcessLock or not.  This would let an unlocked process (e.g., on Android) host multiple non-isolated SecurityPrincipals, while ensuring that any SecurityPrincipals that require isolation (e.g., sites where users enter passwords, WebUI, etc) require dedicated ProcessLocks.  We may be able to get by with minimal changes here for the utility process project, but this question is worth keeping in mind if changing the API sooner makes things easier for your project.
• It will also be interesting to discuss how the SecurityPrincipal creation functions should work, because not everything about SiteInfo will be exposed in the content/ public API.

At any rate, the right next step is to work together on the design doc.  I'll be out of town next week, but alexmos@ should be getting back and can continue the discussion in the meantime.

Thanks!

Charlie

[Emily Andrews]

Hi,

I have a public design document around what I'm doing in the utility process space here:
Service Process Pooling - Google Docs

If you go to page 7, you'll see my proposed design and on page 8 you'll see a number of objects and my proposal for how they'll interact going forward, though it was before opening this discussion. Are you wanting a design doc just for creating a new Principal interface in addition to my design doc on pooling services in the same process or are you alright with just modifying this particular one and using that for the purposes of discussion?

[Charlie Reis]

Ah, thanks.  I'm not opposed to discussing it in that doc, though I don't currently see anything in there on SiteInfo, SecurityPrincipal, or the proposed changes we're discussing here.  Creating a section in the existing doc for that would be ok by me.  (We can always split it out into a separate doc if it becomes a big enough topic on its own.)  I do think we'll want a separate bug to track the principal API work, vs the other service process pooling work.

Thanks,

Charlie

[Viktoriya Bryhider]

Created a bug to track the issue - https://issues.chromium.org/issues/397481045. Will update with the new doc later.

[Viktoriya Bryhider]

Shared the doc with the options how we can achieve site isolation for Utility processes - will appreciate feedback on which direction to move from there.