..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 <mmo...@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.h...@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:shaz...@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.h...@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-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> >
