Permission denied error creating a simple file with fopen?

[Robert Oschler]

I have modified the Chromium code base to create a log file of certain activity I am interested in.  I'm using nothing more than simple fopen/fwrite/fclose calls to handle the file operations.  Unfortunately the fopen() call returns NULL and when I check the Windows error code in errno, I see error code 13 and that is a permission denied error code:

    FILE *f = fopen("c:\\temp\\logs\\test.log", "wb");

I tried moving the log file into a sub-directory of the user data directory ( i.e. - the directory returned by the Windows label  %APPDATA% ) in case it really was a permission denied error, but that didn't help.

I know web pages run in a sandbox but I don't think that would affect straight C++ code running in an unrelated module, would it?  Can anyone hazard a guess as to why such a basic function call would be failing with a permission denied error?

[Torne (Richard Coles)]

Everything running in the renderer process runs in the same sandbox; it's not just code directly related to rendering. So, if the code you are modifying is called by the renderer process, then it won't be able to open files.

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Robert Oschler]

Thanks.

Where can I read more about this sandbox?  Obviously other code is able to read/write directly to the local system to facilitate operations like the user downloading a file from a web server to their local hard disk.  Is this enforced at the process level?  I'm a veteran Windows programmer and I can't for the life of me figure out how you would sandbox a Windows EXE so that even a plain C++ CRT function call like fopen() would be unable to access the file system.  It must be something I never heard of?

Note, I'm not doing this to create some distributable version that has unsafe file operations.  I'm trying to enhance my debugging efforts in my own personal copy of Chromium that I'm building on my local system..

[PhistucK]

You can read more about the sandbox here -

https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md

What usually happens is when a renderer needs file access, as far as I know, the browser process opens the file and passes a file descriptor to the renderer (using Mojo or IPC - inter-process-communication methods) and it continues from there. For downloading, the renderer (using Mojo or IPC, or maybe the network stack, which is in the browser process, directly) passes the data to the browser/download subsystem and it stores the data as a file.

For debugging purposes only (dangerous for actual usage), you can start Chromium with the --no-sandbox flag. It will disable the sandbox and you should be able to do whatever you want from any process.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[Robert Oschler]

Hi PhistucK,

Thanks, that did the trick!  Thanks for the sandbox document link too.  That's a great document.  I wonder if there is a way to have only the Javascript engine sandboxed?  I know that still leaves potential holes for malicious iframe, css, etc. activity perhaps through URI manipulation, but it would be useful during debugging in case some ad network displayed a malicious ad containing hostile Javascript code on some web page you're testing with.

[PhistucK]

While security issues were discovered in the JavaScript engine itself as well, most of the discovered security issues were in renderer code and not in the JavaScript engine itself (in other words, parseInt("%00%00\u0000") and whatever are less likely to be vulnerable, but document.createElement("\u0000script") and whatever are more likely), so sandboxing the JavaScript engine will probably not keep you secure from hostile advertisements.

If you are debugging such a questionable website, you might want to do so in a virtual machine, or perhaps use a proxy/filter to block network activity.

Remember that having the sandbox is the normal mode, so unless what you are doing with files is only for debugging purposes, you should factor that into the implementation as well (and if you are debugging a potentially hostile website and do not want to employ the two suggestions above, implement the file storage in the usual Chrome manner - use Mojo/IPC to pass the data and let the browser process store it).

☆PhistucK

[Torne (Richard Coles)]

There have also been plenty of cases where security issues do not require any javascript at all: for example, exploitable bugs in image decoders that can be triggered merely by pointing an <img> tag at a malicious JPEG.

The sandbox is indeed at the process level, and uses various OS mechanisms together to accomplish this on Windows, not all of which are well-documented and many of which have only really seen use in sandboxing web browsers :)

Since the sandbox is at the process level there is no way to separate the JS engine from other rendering code - Chromium is not built with an IPC layer between those things, and the DOM implementation and JS implementation interact with each other directly.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[Robert Oschler]

Thanks PhistucK and Torne,

This is really good information.

>> perhaps use a proxy/filter to block network activity.

Is there a good open source proxy/filter you like?  Preferably something with decent docs?  It's too bad the sandbox isn't more granular at the permission layer so that you could, for example, leave the file system accessible but make TCP/IP or UDP activity impossible (or vice a versa).

[Torne (Richard Coles)]

Filesystem access is extremely dangerous; if you can create files in arbitrary places you can drop a malicious executable and get more privileges if you can trick the OS or user into launching it. This is why the renderer is only allowed to use already-open file handles: the browser process can make sure that only specific files in specific locations are accessible.

[PhistucK]

There are many NodeJS options in this space. I do not remember a specific one at the moment.

Fiddler (not open source, but free) can also be used (since you are debugging, it is a helpful tool for that as well).

☆PhistucK