On 2023-08-14 17:16, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
1. It makes it clear to users of the project the scope in which the project
could be used and what safety it could reasonably expect from the project. In
the context of GCC for example, it cannot expect the compiler to do a safety
check of untrusted sources; the compiler will consider #include "/etc/passwd"
just as valid code as #include <stdio.h> and as a result, the onus is on the
user environment to validate the input sources for safety.
Whoa, no. We shouldn't make such statements unless we are prepared to explain
to users how such validation can be practically implemented, which I'm sure
we cannot in this case, due to future extensions such as the #embed directive,
and ability to obfuscate filenames using the preprocessor.
There's no practical (programmatic) way to do such validation; it has to
be a manual audit, which is why source code passed to the compiler has
to be *trusted*.
I think it would be more honest to say that crafted sources can result in
arbitrary code execution with the privileges of the user invoking the compiler,
and hence the operator may want to ensure that no sensitive data is available
to that user (via measures ranging from plain UNIX permissions, to chroots,
to virtual machines, to air-gapped computers, depending on threat model).
Right, that's what we're essentially trying to convey in the security
policy text. It doesn't go into mechanisms for securing execution
(because that's really beyond the scope of the *project's* policy IMO)
but it states unambiguously that input to the compiler must be trusted:
"""
... It is necessary that
all source code inputs to the compiler are trusted, since it is
impossible for the driver to validate input source code beyond
conformance to a programming language standard...
"""
Resource consumption is another good reason to sandbox compilers.
Agreed, we make that specific recommendation in the context of libgccjit.
Thanks,
Sid
