[RFC] Allowed and protected file definitions within trusted parent folders

[fnerdman]

The current expansion algorithm for trusted files does not take protected and allowed files into consideration.

Example

...
sgx.trusted_files = [
  "file:/mydirectory",
]
sgx.protected_files = [
  "file:/mydirectory/secrets",
]
sgx.allowed_files = [
  "file:/mydirectory/config/system.yaml",
]
...

The current expansion algorithm will add both the protected folder /mydirectory/secrets as well as the allowed file /mydirectory/config/system.yaml to the list of trusted files. As they are trusted files now, gramine will ignore their protected or allowed status (?) and hence the application will fail due to false configuration.

Of course it depends on how we interpret the manifest syntax. My understanding would be, if I explicitly define something as protected or allowed then I want that to outweigh a parent directory defined as trusted.

[boryspoplawski]

I don't think we should support such cases, allowed,protected,trusted subtrees should not overlap.
BUT Gramine should fail with a clean error in such cases (if it does not do so right now).

[mkow]

Alternatively, we could make it work like mounts on Linux, but then we'd need to merge all of them into one list instead of three (to define the mounting order), which is probably not something we want to do.

[mkow]

btw. What does "RFQ" mean?

[fnerdman]

I don't think we should support such cases, allowed,protected,trusted subtrees should not overlap

Can you elaborate on that? Do you see security issues?

What does "RFQ" mean?

Sorry, typo

[dimakuv]

Yet another way of making the semantics explicit is to decide the order of precedence of these three lists. I think currently in our code we have the following order:

• First check if the file is under any of the directories/files in sgx.protected_files list
• Then in sgx.trusted_files list
• Finally in sgx.allowed_files list

But I'm not sure about this order, and if this order is indeed enforced across all our SGX code. We never bothered to define exact semantics.

Unifying the semantics of this ordering and explaining it in our documentation (https://gramine.readthedocs.io/en/latest/manifest-syntax.html#allowed-files -- somewhere around here) would be the easiest route. But I guess this is not very intuitive; and nobody reads our documentation anyway...

Alternatively, I like @boryspoplawski's suggestion for Gramine to fail since it follows the principle of least surprise.

Actually, @lead4good, do you have any particular use case that breaks because of this? Which of the proposed solutions would work for you, and which definitely wouldn't?

[boryspoplawski]

I don't think we should support such cases, allowed,protected,trusted subtrees should not overlap

Can you elaborate on that? Do you see security issues?

Not really security issues, but let's say "unclear" semantics with nesting trusted and protected directories. Trusted files are by definition read-only pre-created files. What should happend if you try to create a file at path /protected_directory/trusted_directory/a_file? Should that file be protected, or should creation fail? Lot's of corner cases, lot's of tricky scenarios, many things can go wrong and I'm not sue what is the use case for this.

[fnerdman]

nobody reads our documentation anyway...

I do :)

do you have any particular use case that breaks because of this?

My use case is very similar to GSC; there's no knowledge about a users application, so for improved compatibility in an initial step all existing files in a containerized application are added to the trusted files.

A user might provide a list of additional protected files, and of this list, some of the files had been in the container while scanning trusted files. According to the order described above, this is no issue, some files have both trusted and protected attributes but the protected file attribute counts first.

A user might provide a list of additional allowed files, and of this list, some of the files had been in the container while scanning trusted files. According to the order described above, this is an issue, some files have both trusted and allowed attributes but the allowed file attribute will be ignored.

Which of the proposed solutions would work for you, and which definitely wouldn't?

I think it is very important to define an order. One for the case when a file is found during execution that has more then one of three attributes. The other case is expanding folders in gramine-sgx-sign. If an order exists during execution and all folders, regardless the attribute, are expanded, then defining one order is sufficient. In the examples below I expect this case.

I think the order that makes most sense from a user perspective is allowed > protected > trusted. It might be more convenient to implement protected > allowed > trusted? Another possibility would be to have a default order, but allow for it to be changed in the manifest. There is no order that wouldn't work for me, what wouldn't work for me is if there were no order ;)

What should happend if you try to create a file at path /protected_directory/trusted_directory/a_file? Should that file be protected, or should creation fail?

Say we have defined the order protected > allowed > trusted, then everything within that protected_directory should be protected.

Say we have defined the order allowed > protected > trusted, and a_file has the allowed attribute, then this file should be allowed, otherwise protected.

[fnerdman]

Why do I think the allowed > protected > trusted order makes most sense from a user perspective? Allowed is least restrictive, allows for read and write access shared with the host. Protected is more restricted, allows for read and write access without sharing, and trusted is most restricted allowing only read access. We never know what kind of application a user might convert to gramine, in which case we should provide as much flexibility as possible for the user to define the file permission structure in a least restrictive way.

[fnerdman]

Sorry, another typo in the title.

[fnerdman]

Closing in favor if #371