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@...172...net
https://lists.sourceforge.net/lists/listinfo/genode-main