do mind the bug report is not referring particularly to passwd but in general to system-specific fs
Simply being able to access local files by entering the URL is not a security issue. It would be a security issue, if websites (or: the JS code) could fetch and exfiltrate these resources. Is that the case on SFOS 4?
i dont know if security is an issue here(im way not as knowledgeable as any of you guys ). access to file system, on system partitions, seems a bit unorthodox (for a mobile)
Firefox on the desktop has access to /etc. Whats the issue here?
Though I suspect having access to /etc is a non-issue as long as you didn’t mess up permissions on /etc/ allowing the unprivileged user to read/write files that s/he should not have access to I think the point of the original reporter is that assuming the browser is running in a jail that jail should not allow access to /etc/ since there is no valid reason to allow that access (whitelist vs. blacklist permissions)
Same non-issue brought up here
But for what reason?
Plaese elaborate.
From what I could gather reading comments here, it may be an issue that Jolla Browser is able to access the system file /etc/passwd/
although sandboxed with firejail.
I’m no security expert so I won’t articulate any assumptions. Although with my knowledges of Unix sysems, I wonder how this is an issue.
As a side note: passwd
contains no passwords but a list of usernames with UUIDS present on the system.
@cy8aer, @tortoisedoc when it comes to reporting security issues, please be so kind as to properly explain the rationale. If you’re not sure there is a problem, state that clearly too, please. Otherwise you’re only causing confusion and speculation - as you can see looking at the posts in this topic.
Also some less techy users might be disconcerted.
@rozgwi im sorry I dont need to explain anything. First, I am the one who paid for this system and (even if only in part) your salary in case you work for Jolla;
second, my bug report is not about security (which you and others seem to keep liking to imply).
If you think my bug is not a bug, suck it up and close it, that is, in case you (or someone else) work for Jolla. Honestly I sincerely hope you do not work for them; if this is the attitude towards customers, I am not surprised of Jolla’s life in the past years.
Im wondering, if the files are sandboxed, are they “dummy” in the sense as default ones? Or are they the “real” files? The firejail per se might not be providing suck “mocking” feature. I am mainly wondering how does android / iOs handle the same cases; and considering the phone not being a desktop.
@tortoisedoc hold your horses. I am sorry if I offended you. It really was not my intention.
Also, I’m not working for nor affiliated with Jolla. Just a user, as you. Should I have been overzealous changing the topics title and asking for a more specific description , I apologize.
Anyways. Thank you for updating your description and explaining what’s the issue from your point of view.
s/user/customer
Same with me. passwd is no real issue as I told that shadow is not readable. But having the possibility to run around in /etc is no good choice…
But why does it work with view-source?
Just readable /etc files. My firejailed/apparmored end user software on the desktop is not able to do that.
Unlike a web server the filesystem does not provide content-types. Therefore the browser has to guess. In this case the outcome is most likely text/plain. At least that’s what file
proposes:
$ file --mime-type -b /etc/passwd
text/plain
And for web content with mimetype text/plain there is simply no difference between displayed content and source.
The cat’s out of the bag now. Accusing community members of not providing sufficient customer support in reply to unstructured complaints… haven’t seen that one before, have we?
AFAIU SFOS 4.x has introduced sandboxing for a few (more) apps, like Firefox? And it uses firejail for this?
Firejail has been doing this for a long time now (originally for Firefox as the name implies) and if they decided that the Firefox profile is allowed to read some files in /etc, just like a normal user can, then that’s it.
That’s the beauty of SFOS, it works like a Linux distro, no need to worry about Google’s mobile OS paradigm anymore.
That said, there’s been criticism of firejail not being secure enough. I suspect it’s the same security-buzzword-crazy Android millenials parroting that, but there it is.
But hey, I’m talking out my arse. I don’t positively know if SFOS 4.x uses firejail to sandbox Firefox, and whether it uses the default Firefox profile or something else…?
Clarifying that would be the next constructive step.
FYI the bug report has been updated.
JavaScript code is not allowed to access local files, which is enforced by the browser itself. This has been for quite a while (probably over 10 years by now), due to security concerns. But if an user manually enters a file-url in their browser address bar, the browser will go there.
If you’re not convinced, I’ve thrown together a quick test page you can test out if the browser blocks things. Note that if you download the page, using the link found at the bottom, and open it from your file system, some of the links will work!
Edit:
It seems like the browser has some interesting, unexpected behaviour:
- Open the link opened above in the Sailfish Browser (not in private browsing mode). It does not load the images linked from the local file system, as expected.
- Download the html file at the link at the bottom of the page and open it in the browser, while leaving the previous tab open. It does load the images from the file system, as expected.
- Close the browser.
- Reopen the browser. It will show the locally stored HTML file, with the images loaded from the file system, as expected.
- Switch to the tab you opened at step 1. It does show the images from the local file system, which should not happen!
Maybe these have been cached by FF? So it’s not actually showing the files from the filesystem, it’s showing those in FF’s cache?