ChildProcessSecurityPolicy and base::PlatformFileFlags

[Steve VanDeBogart]

Right now, ChildProcessSecurityPolicy uses base::PlatformFileFlags to set per renderer access to files and file systems.  We'd like to add finer grained permissions to ChildProcessSecurityPolicy for DOM file systems; such as delete.  Right now, this requires fileapi::kWriteFilePermissions permission, which is more than we want to grant.

Baring other suggestions, I propose duplicating the parts of PlatformFileFlags used in ChildProcessSecurityPolicy and letting the two sets diverge.

--

Steve

[Eric Uhrhane]

Can you expand on what you'll be doing? I'm not following you.

What flags will you be adding where, and after the addition, which
APIs will use which set of flags?

Thanks,

Eric

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
>
>

[Steve VanDeBogart]

Sorry I wasn't clear. Right now, ChildProcessSecurityPolicy uses exactly the flags in base::PlatformFileFlags to describe what level of access a given renderer has to specific files and to DOM file systems.  These flags map as directly as possible to permissions in the operating system file system permission scheme.  FileAPIMessageFilter than checks for a permission or combination of permissions before permitting sending DOM FileSystem operation on to the implementation.

We'd like to have finer grained permissions.  For example, I'd like a permission that grants delete permission, without granting write permission or a permission that grants

copyTo/moveTo permission without granting permission to create new directories.

My proposal is that ChildProcesSecurityPolicy should use a set of permissions distinct from those in base::PlatformFileFlags, at least for DOM file systems.

--

Steve

[Justin Schuh]

+security@ plus a few specific people who might be helpful

[Kinuko Yasuda]

I support this proposal, or at least I don't think we should have a flag like PLATFORM_FILE_ENUMERATE (which is added solely for permission check and used only for ChildProcessSecurityPolicy) as a PlatformFileFlag that is supposed to be used for opening or creating a file according to the comment.

Do we know if there're any places where PlatformFileFlag given as a Open/Create flag is directly passed for permission check? (I should probably do grep) If there's not such a place we could probably start with a new smaller set of flags purely for permission check (if security folks are ok with it)

[Charlie Reis]

I defer to Tom on this one.  It sounds like having finer grained permissions could be useful, and I imagine ChildProcessSecurityPolicy was just using PlatformFileFlag out of convenience.

Charlie

[Steve VanDeBogart]

I'm working on the media galleries API (http://developer.chrome.com/trunk/apps/mediaGalleries.html).  One use case is to upload pictures and then delete them.  This requires delete access without needing full write access. Another thing we're working on is a form of write support.  Through a series of events, it was decided that the best way to do this is by having the ability to copy/move into a dom file system, without the explicit capability of writing to files.  So while technically this is write access, granting that permission would permit more actions then we want to.

--

Steve

On Wed, Mar 20, 2013 at 10:07 AM, Thomas Sepez <tse...@google.com> wrote:

I'm fine with doing this, I'm just not sure that in the end finer-grained permissions buy all that much, because it is rare where a process could have delete but not write (or vice versa) and still accomplish all it needs to do.

[Greg Billock]

I'm doing some exploration on implementing this. Here's my current plan:

1. Replace all calls to ChildProcessSecurityPolicy::GrantPermissionsForFile which pass bitfields to directly call specific members of ChildProcessSecurityPolicy. Make GrantPermissionsForFile private.

This is intended to do two things: first, consolidate PlatformFileFlag as an internal detail of CPSP, and second, to disallow random assemblages of permissions, forcing callers to use explicit permission bundles that are under the control of CPSP itself. I don't see that we're misusing this capability anywhere, but I think tightening this down is an advantage of the suggestion to move away from PlatformFileFlags.

2. Replace internal use of PlatformFileFlags with specific fine-grained CPSP permissions. Since these will be implementation details they can be expanded and translated at will.

3. Add in further fine-grained permission calls as we establish use cases (i.e. delete-without-write, or add-files-to-directory-but-not-overwrite-existing-ones).

[Greg Billock]

On Tue, Jun 25, 2013 at 4:57 PM, Thomas Sepez <tse...@google.com> wrote:

On Tue, Jun 25, 2013 at 4:43 PM, Greg Billock <gbil...@google.com> wrote:

I'm doing some exploration on implementing this. Here's my current plan:

1. Replace all calls to ChildProcessSecurityPolicy::GrantPermissionsForFile which pass bitfields to directly call specific members of ChildProcessSecurityPolicy. Make GrantPermissionsForFile private.

This is intended to do two things: first, consolidate PlatformFileFlag as an internal detail of CPSP, and second, to disallow random assemblages of permissions, forcing callers to use explicit permission bundles that are under the control of CPSP itself. I don't see that we're misusing this capability anywhere, but I think tightening this down is an advantage of the suggestion to move away from PlatformFileFlags.

+1. Yay.

Did I hear a volunteer reviewer? :-)

 

 

2. Replace internal use of PlatformFileFlags with specific fine-grained CPSP permissions. Since these will be implementation details they can be expanded and translated at will.

3. Add in further fine-grained permission calls as we establish use cases (i.e. delete-without-write, or add-files-to-directory-but-not-overwrite-existing-ones).

If you'd like.  I don't think this is as important as the first one.

Yeah. This'll be an as-needed thing. We'll see what other fine-grained permissions needs arise. Just to reiterate, the goal is that stuff like that would be surfaced through particular methods on the security policy, rather than hopeful assemblies of platform flags. (I found one potential problem in the existing flag-set that we can sort out in review.)