Okay. I don't have code to make the measurement right now, so I suspect I'll start by using a single process for file identification, then later try dividing it into multiple processes. I'm not sure whether the division will add much security, given that a malicious file generally has much more to gain by disguising itself than by misidentifying other files. Either way, I won't be trusting the file identification component very much, and I plan to use content-based identification only when there is no file extension or the file extension is insufficient for identifying the file type.
Do we have any approximation on the time required to start a new process? I don't need anything precise, but I would like to at least know the order of magnitude to expect on a modern x86 processor. Currently, I don't even know whether the delay will be on the order of 10us, 10ms, or somewhere in between.
As for component preinitialization, would it be feasible to repeatedly reset a process? The code should be read-only, so it may be fastest just to clear the component's writeable memory and its capabilities, then reset or recreate the main thread.
On Wed, Dec 20, 2017 at 3:43 AM, Alexander Senier <alex@...331...> wrote:
Hi Ben,
IMO you're bringing up a very relevant and important question.
The file type identification could be severe for the users, as file parsing and media rendering libraries do not have a particularly good track record when it comes to security [1]. I guess this would not be as dramatic in your envisioned architecture, in case another component enforce read-only file access and results are exported through a report ROM.
Still, in the shared scenario we must assume the identification component to run arbitrary attacker-controlled code if it accesses one single malicious file. Then it could (a) attack its client through malformed ROM content and (b) provide valid, but misleading file information as you mention.
Case (a) could be mitigate through a trusted filter component between the indexer and its client. Case (b), however, may trick the user into treating one file type as another. Like, clicking on an executable masqueraded as a harmless text file. I have no real good scenario on that, yet, but it definitely feels bad.
It feels much worse when considering general-purpose image rendering or font rendering. In that case, none of your output handled by that central component would be trusted anymore. An attacker could trick you into digitally singing a contract you had no intention to sign, spending money etc.
I'd encourage you to actually *measure* the impact of file type identification with one fresh process per file versus one central component for all files it that's feasible. If the result is as poor as we expect, it would be interesting to find ways to improve performance while keeping separation.
To reflect a question back to the list: What would be a good concept to support a scenario where a complex component (like Ben's file identification or a heavyweight JVM) is preinitialized and used as a boilerplate to quickly spawn independent child processes?
Cheers, Alex
[1] https://nvd.nist.gov/vuln/detail/CVE-2017-11421
On 20.12.2017 03:16, Nobody III wrote:
For example, a file manager would benefit from content-based file type identification. However, identifying files within the file manager (e.g. using libmagic) could pose a security risk. However, using a discrete component for this could have a noticeable effect on performance. If we use a single component instance for all of the files, the only significant added overhead would be from IPC, AFAIK. This seems to be acceptable in terms of performance, but a malicious file may be able to cause the component to misidentify other files in the directory, which could be a security risk. A more secure method would be to run an instance of the component for each individual file in the directory. However, this may substantially reduce performance for large directories, depending on the overhead of component creation. Would performance be an issue here? (And am I overestimating the risk of file misidentification?)
Similar cases include icon/thumbnail rendering, general-purpose image loading, and text rendering from many different sources. Would there be any notable differences for these?
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main