cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Plugin Install Hooks
Date Tue, 10 Feb 2015 16:26:43 GMT
..Not to mention, these plugins will be running on end users' personal
devices.  That sounds vastly more concerning than running hooks on a server
you control and can sandbox.

On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny <mmocny@chromium.org> wrote:

> So, I think this is not different than downloading and running packages
> from any package manager.
>
> That said, I think a --suppress-hooks flag would be fine.  I suggest you
> file a JIRA so others can chime in, and if you want it to land soon I would
> take a stab at a PR.
>
> -Michal
>
> On Tue, Feb 10, 2015 at 10:02 AM, Horn, Julian C <julian.c.horn@intel.com>
> wrote:
>
>> Thanks for the pointer Shazron.  I read through all of this interesting
>> discussion.  I agree that sandboxing is hard and prompting is problematic.
>> But there's still an issue here.
>>
>> If there is no mechanism to exclude scripting in untrusted plugins then
>> build servers are unlikely to accept any uncurated plugin, which is what
>> PGBuild is doing.  The Intel XDK provides a build server.  We would like to
>> support arbitrary third party plugins, not just ones we have curated.  This
>> install-time hooks feature creates a major security issue for us. Under no
>> circumstances are we going to allow untrusted native code to run on our
>> build server.
>>
>> And thanks to Sergey for pointing out that issue with pre_package hooks!
>> We were under the impression that project-level hooks could be suppressed
>> by excluding the hooks directory. I see now that this isn't sufficient.
>>
>> I have a very simple suggestion: add a "--suppress-hooks" flag.  This
>> doesn't prompt: it assumes the answer to the prompt is "no".
>>
>> I don't have enough experience with install hooks to know if the plugin
>> is likely to be usable without running the install-time hook.  I expect
>> that if you add a plugin that contains an install time hook and
>> --suppress-hooks is present, then the plugin add should fail.  If there's
>> some reason to believe that a plugin could be usable without running the
>> install time hook, then maybe it would be interesting to have a variant of
>> --suppress-hooks that bypasses the hook but allows the plugin to be
>> installed anyway.
>>
>> I would also expect that --suppress-hooks would suppress pre_package time
>> hooks too.
>>
>>     Julian
>>
>> -----Original Message-----
>> From: Shazron [mailto:shazron@gmail.com]
>> Sent: Monday, February 09, 2015 4:21 PM
>> To: dev@cordova.apache.org
>> Subject: Re: Plugin Install Hooks
>>
>> We did discuss this, and we rejected:
>> 1. Having a prompt
>> 2. Sandboxing
>>
>> Check out the discussion, for reasons:
>> http://markmail.org/message/alknczhqdghaurrw
>>
>> On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C <julian.c.horn@intel.com>
>> wrote:
>> > We have identified a security issue with the recently added feature of
>> install-time plugin hooks.
>> >
>> > As far as I can tell, there is nothing that prevents creation of a
>> plugin with a malicious install-time hook script.  Adding that plugin to a
>> project could corrupt the user's host machine.  If that project using that
>> plugin is submitted to a build server, then the build server could be
>> corrupted.
>> >
>> > Yes, you can use lower level plugman scripts to fetch plugins and then
>> pre-scan them for install time hooks and track down all the dependencies
>> and scan them too.  So this is fixable (on a build server), but it's a lot
>> of extra work; "cordova plugin add" should not be an unsafe operation.
>> >
>> > I propose that the CLI should check to see if a plugin requires an
>> install-time hook and require the user to explicitly grant permission
>> before executing the install hook.  A build server would always deny
>> permission.
>> >
>> > Is there something I'm missing here?
>> >
>> >     Julian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message