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 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.
Posted Oct 14, 2016 6:56 UTC (Fri)
by roc (subscriber, #30627)
[Link]
Posted Oct 14, 2016 8:59 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (7 responses)
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?
Posted Oct 14, 2016 10:30 UTC (Fri)
by matthias (subscriber, #94967)
[Link] (3 responses)
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.
Posted Oct 14, 2016 11:55 UTC (Fri)
by Karellen (subscriber, #67644)
[Link] (2 responses)
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?
Posted Oct 14, 2016 11:57 UTC (Fri)
by Karellen (subscriber, #67644)
[Link]
*sigh*. Read more slowly next time...
Posted Oct 14, 2016 12:19 UTC (Fri)
by matthias (subscriber, #94967)
[Link]
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.
Posted Oct 14, 2016 15:22 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
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.
Posted Oct 14, 2016 15:42 UTC (Fri)
by niner (subscriber, #26151)
[Link] (1 responses)
My faith in a working solution with added security is less than noteworthy.
Posted Oct 14, 2016 16:46 UTC (Fri)
by drag (guest, #31333)
[Link]
$ echo 'cow' > 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'?
Guile security vulnerability w/ listening on localhost + port
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.?
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
Guile security vulnerability w/ listening on localhost + port
$ xdg-open index.html