Thanks for the detailed explanations, Ed.
Denis On 2020-09-25 10:52 a.m., Ed Merks wrote: > > Denis, > > Comments below. > > On 25.09.2020 16:01, Denis Roy wrote: >> >> Ed, >> >> I get your point. However, Eclipse running under my user account >> won't be able to alter my executables in /usr/bin. >> > No, it can't modify files for which the user account doesn't have > write access, but it could delete every file in your user account, or > could transmit some or all of them to a server. It could also send > all your passwords that you've stored in your Eclipse password file. >> >> Installing some great looking plugin from Marketplace could overwrite >> Eclipse jars that capture credentials. >> > That wound be a very round-about way of accomplishing something the > plugin could just do itself. All plugins have access to the > credentials, for example. >> >> 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) ? >> >> > I think you're assuming some jars a special in some way. That's not > the case. Any plugin could do anything any other plugin can do. > Without a security manager running, there's really nothing to stop > destructive behavior, and there's no need to tamper other plugins to > accomplish that goal. > > For those truly paranoid, verifying jar signatures (only run with > signed jars) might grant some sense of security, but no user has ever > asked for this as far as I know and even Java doesn't have a simple > flag for such a thing... > >> 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 > > _______________________________________________ > 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
