Sandboxed Browser has access to /etc

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.0.1.45
HARDWARE (Jolla1, Tablet, XA2,…): xperia x
UI LANGUAGE:browser
REGRESSION: (compared to previous public release: Yes, No, ?): no

DESCRIPTION:

browser has access to system partitions & files

PRECONDITIONS:

STEPS TO REPRODUCE:

  1. open stock browser
  2. enter view-source:file:///etc/passwd in the url
  3. see the content of the file displayed

EXPECTED RESULT:

The same way I would not expect a total stranger to be able to “dig in my pockets” when they feel like, so I would not expect a UserAgent with Javascript capabiliities to have rights to scoop freely around my file system (on a privacy-oriented product especially). Ideally;
i would need to be able to customize the accessible locations on the filesystem, out of a default setup.

ACTUAL RESULT:

File system is accessible.

ADDITIONAL INFORMATION:

N/A

1 Like

It’s not a bug but a feature. In version 4.0.1.45 sailfish-browser runs in a firejail environment and /etc/passwd is not available by intent.

Run your test with file:///etc/hosts and you will see that’s nothing wrong with file access.

For me both those files are accessible on 4.0.1.45, and i believe that is the issue being reported; that they are still accessible.

@tortoisedoc
Please consider filling in “EXPECTED RESULT” and “ACTUAL RESULT” to make it more obvious what the issue is :slight_smile:

1 Like

You are right, /etc/passwd is visible on my XA2 as well and that’s not a good idea though shadow passwords are in use.

I would but -sorry for the roasting - native browser keyboard hides half the
dialog, plus copy/paste is not working so… :slight_smile:

FWIW, the same is happening on my desktop computer’s Firefox, which does NOT run in a jail.

However, the system knows which files should not be readable by a normal user.
It might appear wrong to allow viewing access to /etc/passwd, but for some reason the underlying Linux system does not consider this dangerous. Access to /etc/shadow, however, is denied.

1 Like

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?

1 Like

i dont know if security is an issue here(im way not as knowledgeable as any of you guys :slight_smile: ). 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.

2 Likes

@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.

1 Like

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.

2 Likes

s/user/customer :wink:

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.

1 Like