|
|
Subscribe / Log in / New account

Guile security vulnerability w/ listening on localhost + port

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 5:52 UTC (Fri) by matthias (subscriber, #94967)
In reply to: Guile security vulnerability w/ listening on localhost + port by pabs
Parent article: Guile security vulnerability w/ listening on localhost + port

I prefer to have this boundary not in the browser, but in the operating system. Why not putting the browser into a container, where it has a network namespace restricted to the internet, a filesystem/mount namespace restricted to its configuration files and a directory for storing downloads, etc.? This has the advantage that also vulnerabilities in plugins as flash, java, etc. are not that easy to exploit.

I know that there are some tasks to solve. How to upload a file to the internet? The user prefers, not having to copy the file to the browsers container before. But there should be a way such that the browser can access the file open dialog from the desktop environment and then get a fd back.

The kernel should be roughly at a point, where this works. The userspace is not. Creation of containers for user applications would need to be (almost) transparent to the user.


to post comments

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 6:56 UTC (Fri) by roc (subscriber, #30627) [Link]

Chrome and Firefox on Linux are already doing a lot of this internally. Actually their Web-content processes are even more restricted, and talk to a master "broker" process via IPC to fetch configuration data etc.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 8:59 UTC (Fri) by NAR (subscriber, #1313) [Link] (7 responses)

Why not putting the browser into a container, where it has a network namespace restricted to the internet, a filesystem/mount namespace restricted to its configuration files and a directory for storing downloads, etc.?

Than how shall I check the generated HTML documentation for my project? Or read the the documentation from /usr/share/doc? Not to mention testing the web interface of my project?

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 10:30 UTC (Fri) by matthias (subscriber, #94967) [Link] (3 responses)

Using another instance of the browser that is outside the container (or inside a container with different restrictions).

Having these barriers in place would be a big improvement of security. Of course, as bferrell said, there are already some barriers inside the browser, but still there are too many vulnerabilities, where an exploit can manage to escape. The kernel can provide more security than the browsers are currently using. The main reason the browser don't use these is of course usability.

There would be quite a bit of work to be done to get this as transparent as possible. E.g., if you open some html documentation, the containing folder should be added to the container instance, such that browsing different files would work, etc. The web interface of your project is a bit different. A developer can be expected to do 1 or 2 minutes of configuration to get a container instance suited for testing, but the common case should just work out of the box.

The main reason, I would like this to be done on operating system level is that it could easily be applied to other processes, e.g., libreoffice, pdf readers. All of these had their pile of critical bugs that would be much more harmless, if the process would be restricted to the necessary resources.

Right now, most user programs have full access to the users home directory, because the user might want to open another file. This is exactly the directory that should have maximum protection, because it might contain sensitive or private data. Restricting the programs, that they cannot access the home directory, except through the file open dialog of the desktop environment that would pass a FD back, would give much more protection. The programs could only access files explicitly selected by the user.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 11:55 UTC (Fri) by Karellen (subscriber, #67644) [Link] (2 responses)

So, if I click <File>/<Open>, navigate to a directory, and select a file then it works, and the location bar shows file:///home/karellen/project/foo.html.

But if I type file:///home/karellen/project/foo.html into the location bar, it doesn't work - except maybe without extra clicking from some confirmation dialog?. And bookmarks to local files don't work (without extra clicking...)? And links between file:///.../chapter1.html and file:///.../chapter2.html don't work?

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 11:57 UTC (Fri) by Karellen (subscriber, #67644) [Link]

Sorry, I missed the "the containing folder should be added" part.

*sigh*. Read more slowly next time...

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 12:19 UTC (Fri) by matthias (subscriber, #94967) [Link]

I know that there are still problems with the idea. I would accept that I have to do an additional click in the file open dialog, if I could get my browser secure. The browser could open the dialog with some file preselected. Thus the navigation would not be needed. The user would only have to confirm (with one click) that the file should be opened, such that a malicious website cannot open your .ssh/id_rsa through some bug in the flash viewer without your approval.

With a bit more effort, the location bar could be operated by a different process than the renderer. This process could have the necessary permissions to open local files and pass them (by FD) to the renderer. I just want the fraction of the browser that has permissions to access my files to be small enough that there is a reasonable probability to get this fraction free from serious bugs. That means this fraction has to be tiny. Especially no plugin and no complex code like rendering complex stuff like images, pdfs, or even true-type-fonts should have the permissions to access my files without prior approval. Such code is much too complicated to really get it bug free. Thus it has to run in a restricted container.

For browsing html documentation of course this cannot be restricted to simple FDs. Instead, a possibility to pass entire directories into the container would be needed. It is not only browsing from chapter1 to chapter2, but also images in the documentation. For many other applications passing single files is fine, but html is a multi-file format.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 15:22 UTC (Fri) by drag (guest, #31333) [Link] (2 responses)

> Than how shall I check the generated HTML documentation for my project? Or read the the documentation from /usr/share/doc?

You need to map the files or directories containing the files you want to view to the browser's file system namespace.

Mount binds is one simple way to do it.

A more advanced theoretical 'user friendly' approach would be to use something like a Fuse file system that makes up the browser's file system namespace. When the browser is launched the fuse file system is launched to go along with it.

You could then run a command like 'html-browser-open' on a particular file or directory and have that file or directory mapped to the browser's namespace. The browser could be modified slightly to monitor the 'mapping directory' and automatically open up whatever shows up there.

'html-browser-open' could be command line, or issued from the GUI file manager, or a dbus instruction. Simple access control lists could control what applications are allowed to issue these types of requests. Users could control these lists and be notified in the case of some application sending a request to another application unexpectedly.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 15:42 UTC (Fri) by niner (subscriber, #26151) [Link] (1 responses)

Right now, half of the time I click a link in some application, the opened chromium window greets me with a failure to open my profile because it didn't notice that chromium was already running and started another one.

My faith in a working solution with added security is less than noteworthy.

Guile security vulnerability w/ listening on localhost + port

Posted Oct 14, 2016 16:46 UTC (Fri) by drag (guest, #31333) [Link]

bugs happen. You should file a report.

$ echo 'cow' > index.html
$ xdg-open index.html

works well for me.

I have found that a lot of applications try to be 'too smart' about things when trying to launch other 'helper' applications. They try to create their own solutions instead of just using the 'standardized' interfaces like the ones defined by the 'X Desktop Group'. Especially anything to do with email tends to be nightmarishly incorrect and/or cludgy since much of what gets installed pre-dates xdg stuff.

And, besides, even if your stuff is broken wouldn't it be better to have it 'broken and more secure' then 'broken and less secure'?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds