Rationale for not using loader.insecure__use_cmdline_argv, sgx.allowed_files and others

[pbeza]

I've been experimenting a lot with Gramine lately, especially. with manifest files and noticed that it is not recommended to pass arbitrary file and command line arguments to applications launched with gramine-sgx. This is what I get when there are some unsafe options in the manifest file:

  - loader.insecure__use_cmdline_argv = true   (forwarding command-line args from untrusted host to the app)                                                                                                                                        
  - sys.insecure__allow_eventfd = true         (host-based eventfd is enabled)                                                                                                                                                                      
  - sgx.allowed_files = [ ... ]                (some files are passed through from untrusted host without verification)

What is the rationale for that? How does it impact security (or remote attestation in particular)? Is this because MRENCLAVE doesn't take into account command line files/arguments that were not provided upfront? I don't have a clear understanding of the potential risks.

What is the safest/recommended way to design an application if I have to accept user input? Let's say I need to sign a user-supplied input file/string and I want to do it in an SGX enclave.

[dimakuv]

Is this because MRENCLAVE doesn't take into account command line files/arguments that were not provided upfront?

Yes, this is the exact reason.

Basically, if the application has a lot of different configurations based on command-line args, then the runtime behavior of the application may vary widely. For example, Redis server has tons of command-line options, see https://redis.io/docs/management/config/.

Typically, you want to run a very particular configuration of the application with SGX. Otherwise the attacker can choose to run a configuration of the app that does something weird/unexpected, and it will not be reflected in the SGX remote attestation in any way. E.g., Redis is safe to be used with the save '' configuration, because it won't dump any unencrypted logs/files on the hard disk, so that's why we have this config in our example: https://github.com/gramineproject/gramine/tree/master/CI-Examples/redis

What is the safest/recommended way to design an application if I have to accept user input?

If you design/modify the application yourself, then you can weigh the risks of different command-line arguments. If you find that the configuration space due to command-line args is safe, then feel free to use loader.insecure__use_cmdline_argv = true. It will still show the annoying warning at Gramine startup, but you can "hide it" by redirecting Gramine logs to /dev/null or whatever.

Let's say I need to sign a user-supplied input file/string and I want to do it in an SGX enclave.

I'm not sure about your particular scenario, but you could have a requirement on a particular filename. E.g. the file passed as an input to Gramine must be named file_for_signing.txt.

[dimakuv]

Same story for sgx.allowed_files. You need to weigh the risks of consuming/producing completely plaintext and unprotected files by your application.

[dimakuv]

But a bit different story for sys.insecure__allow_eventfd = true. The warning simply means that the host could potentially send some malicious values on the eventfd channel. And you need to analyze how your application uses eventfd. It may be totally safe, but may be problematic (e.g., the attacker can confuse your app with sending a ridiculous number on eventfd).

Unfortunately, there is no generic way to "make it more secure". So we opted to print a warning always, just so that it's clear to users that Gramine cannot do the "protect transparently" magic in this particular case.

[pbeza]

As always, very quick and detailed answer! I appreciate it, thank you!