You're right, ?Carlos?. In an environment where all apps are contained, Shell extensions would be a very very neat entry point for malware. Jasper probably is the authority on this but I have serious doubts that anything can be done to secure Shell extensions. From the fact that extensions shouldn't do sync I/O, I understand that their code runs in the same thread(s) as the rest of the shell. This effectively prevents making only the extensions' API's memory pages executable to extension-running threads, for instance. It also doesn't make sense to sandbox something which is expected to have such a central access to your system.
In other words, extension code is very dangerous and reviews should be very thorough. The problem is when it comes to security, an extension won't be bad because it looks bad or code like "myVariable = allUserData; update_to_evil_website(myVariable)". It'll be funky pointer arithmetic? and variable contents that nobody really understands, or shellcodes hidden inside an alleged Web API's application key, etc. It'll be subtle and you'll probably need to be very good at JS, know GJS very well and have good security credentials to spot it. Then beyond exploits within the code (of various degrees of clarity), you should look out for any processing of untrusted data: app windows, documents, absolutely anything coming from the Internet without authentication on an encrypted channel. How does it interact with the program? Are you absolutely certain that there is no bug or no quirky operation that could result in e.g. buffer overflows, strange operations on potentially-shellcode-containing variables, etc.? I wouldn't risk myself at it since I don't have much JS experience: I don't even know how one'd break a JS interpretor (and specifically GJS). From my (external, non-GNOME, non-authoritative) viewpoint anybody who doesn't know this either shouldn't be trusted with security reviews. Cheers, -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670 ________________________________ From: gnome-shell-list <gnome-shell-list-boun...@gnome.org> on behalf of Carlos Soriano Sánchez <carlos.sorian...@gmail.com> Sent: 25 May 2014 21:31 To: Sriram Ramkrishna Cc: Albert; gnome-shell-list Subject: Re: Extensions review Florian, Drago, Even more, Gnome is moving to application containers, but we are allowing those things in extensions? Seems just against all the work and a hole of security/privacy/what-I-think-application-does-or-permission-to-acces-my-things on the user POV. But I'm the new here... so maybe I'm wrong. Florian, so are you still reviewing extensions? Maybe the situation was not that bad then... from the emails I though "nobody" was reviewing currently. Sriram, Right, still imho we should encourage to work together if possible (like seems it is currently working as drago advised). 2014-05-25 22:23 GMT+02:00 Sriram Ramkrishna <s...@ramkrishna.me<mailto:s...@ramkrishna.me>>: On Sun, May 25, 2014 at 12:57 PM, drago01 <drag...@gmail.com<mailto:drag...@gmail.com>> wrote: > 2) Duplicates: Yeah forgot to tell you about that in the last mail > while doing a review check for dupes and if there is one don't approve > it either get both authors to work together or if one gets abounded > let the new user become the owner (i.e send mail wait two weeks if he > does not respond transfer ownership). That would eliminate a lot of the dock extensions, no? We'll need to let people who such extensions explain what is different about the way they solve a dock as opposed to someone else. (applicable to any other duplicate extension as well)
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
