Ed, I get your point. However, Eclipse running under my user account won't be able to alter my executables in /usr/bin.
Installing some great looking plugin from Marketplace could overwrite Eclipse jars that capture credentials. If it's possible to verify the signature of mission-critical jars at startup, would it make sense to offer it as an option (at the cost of slower startup) ? Denis On 2020-09-25 4:10 a.m., Ed Merks wrote: > > Denis, > > If one has a rogue running process that can write arbitrarily to your > file system (or parts thereof), it could tamper *anything*, so it > would seem that at that point you would have arbitrary security risks > even without an Eclipse IDE. Even Windows doesn't prevent a tampered > or unsigned executable from running. I don't think that Linux even > has signed executables, given there is no signing of such things in > the Tycho builds. > > Looking at this search: > > https://www.google.com/search?q=java+run+only+signed+jars > > and at answers like these: > > https://stackoverflow.com/questions/54011270/allow-a-jar-to-run-only-if-it-is-signed > https://stackoverflow.com/questions/34641305/is-it-possible-to-force-jvm-to-check-that-every-jar-must-be-signed > > suggests that it's not really so feasible to prevent Java from running > unsigned jars, though I expect from Thomas' answer that OSGi can do > verification with its specialized class loader (though presumably that > has a performance impact). > > Running Java with a security manager enabled for the purpose of > running an IDE I think makes zero sense, so generally the IDE can do > anything and can itself be a rogue process (if and when the user > installs arbitrary things from the marketplace). > > Even if the jars are verified, I can still personally think of a > number of ways that I could tamper data files used by the IDE that > would make the IDE "do bad things". I'll not outline the possible > ways that I can think of... :-P > > I think a fundamental aspect (assumption?) of security is that the > machine itself is secure, sufficiently so that a process that does > rogue things never runs in the first place. Verifying signatures and > checksums ensures that only known content is downloaded and installed > in order to keep the machine secure. > > Regards, > Ed > > On 24.09.2020 19:53, Denis Roy wrote: >> >> So it's possible for another process to tamper with jars and have >> Eclipse run them blindly. >> >> Do we know if that is industry practice? >> >> >> >> On 2020-09-24 12:07 p.m., Thomas Watson wrote: >>> Yes, p2 verifies the signatures and content of the JARs to confirm >>> it hasn't been tampered with before installing the JAR. At runtime >>> the verification of JARs is not enabled by default. Otherwise what >>> you did would have resulted in a runtime exception for the class you >>> changed. >>> >>> >>> Tom >>> >>> >>> >>> >>> ----- Original message ----- >>> From: Wim Jongman <wim.jong...@gmail.com> >>> Sent by: cross-project-issues-dev-boun...@eclipse.org >>> To: Cross project issues <cross-project-issues-dev@eclipse.org> >>> Cc: >>> Subject: [EXTERNAL] [cross-project-issues-dev] (Mirror) security >>> Date: Thu, Sep 24, 2020 10:18 AM >>> >>> Hi, >>> >>> This is probably a silly question but I was wondering how we >>> protect the content of jar files as they are being pulled from >>> mirrors all over the world. >>> >>> Due to a recent break in the Platform class, I compiled my own >>> version of the Platform class where I re-added the removed >>> method. Then I replaced it in the plugins/o.e.c.runtime jar >>> using 7-zip. >>> >>> This solved my issue but it also made me wonder how this was >>> protected if some mirror-server user used the same hack to dope >>> our jars. >>> >>> I assume this is being done by p2 when downloading the jar files >>> by comparing some MDA hash? >>> >>> Please enlighten me. >>> >>> Cheers, >>> >>> Wim >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >>> >>> >>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> -- >> >> *Denis Roy* >> >> *Director, IT Services | **Eclipse Foundation, Inc.* >> >> /Eclipse Foundation/ <http://www.eclipse.org/>/: The Platform for >> Open Innovation and Collaboration/ >> >> Twitter: @droy_eclipse >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- *Denis Roy* *Director, IT Services | **Eclipse Foundation, Inc.* /Eclipse Foundation/ <http://www.eclipse.org/>/: The Platform for Open Innovation and Collaboration/ Twitter: @droy_eclipse
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
