Sandboxed Browser has access to /etc

Bug Reports
#1

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
#2

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.

#3

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:

2 Likes
#4

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.

#5

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

#6

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
#7

do mind the bug report is not referring particularly to passwd but in general to system-specific fs

#8

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
#9

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)

#10

Firefox on the desktop has access to /etc. Whats the issue here?

#11

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)

#12

Same non-issue brought up here

But for what reason?
Plaese elaborate.

#13

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.

3 Likes
#14

@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
#15

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.

#16

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

3 Likes
#17

s/user/customer :wink:

#18

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…

1 Like
#19

But why does it work with view-source?

#20

Just readable /etc files. My firejailed/apparmored end user software on the desktop is not able to do that.

2 Likes