2. August 2022 #792
Replies: 4 comments 8 replies
-
|
Entry into iDash, task 3 specifically, looks like a good challenge for the /dev/shm addition coming soon to gramine. http://www.humangenomeprivacy.org/2022/competition-tasks.html |
Beta Was this translation helpful? Give feedback.
-
|
Am I the only one that finds it ironic that a site with "privacy" in its domain doesn't support https? |
Beta Was this translation helpful? Give feedback.
-
|
The site seems to have many contributors/organisers chinese and from inside mainland china firewall https barely works, but that is no excuse as most devs have custom proxies/vpns anyways. |
Beta Was this translation helpful? Give feedback.
-
|
Question: How safe is /dev/sgx to be given to a non-sudo untrusted linux user. Our usecase is we want to (for KISS) expose /dev/sgx into a sandboxed non-root podman container that has memory and CPU limits set via cgroupsv2. If the arbitrary untrusted user of said container starts a SGX enclave can they exceed the memory limits of cgroupsv2? Cpu limits? Also is it safe to do this. Option 2 would be to write a wrapper API that will execute /dev/sgx with the requested parameters, but this is less flexibility for the end user and (much) more coding work for us. |
Beta Was this translation helpful? Give feedback.
-
No, they can't exceed the memory (assuming you're NOT talking about the EPC memory) or CPU limits as long as they don't have arbitrary acceess/privilege to manage cgroups. |
Beta Was this translation helpful? Give feedback.
-
|
As @kailun-qin said, no, SGX enclaves cannot exceed the memory or CPU limits of cgroups. This is because Intel SGX enclaves rely on the host OS kernel (Linux) to manage the memory and CPU resources. In particular, SGX enclave memory is actually backed by normal system memory, and SGX enclave threads are backed by normal system threads. So any system limitations like cgroups apply equally well to SGX enclaves (because from the perspective of the host OS, SGX enclaves are just normal processes). |
Beta Was this translation helpful? Give feedback.
-
|
@kailun-qin @dimakuv thank you! |
Beta Was this translation helpful? Give feedback.
-
|
From the security side option 2 would be a better idea probably, assuming you write the proxy carefully and ideally in a memory-safe language (because now you've shifted the attack surface from the SGX driver to your own code). SGX driver is relatively new and still evolving, so there is a risk that it will get vulnerable at some point (or already is). But as you said, this requires some additional work, so you need to weight the risks. |
Beta Was this translation helpful? Give feedback.
-
|
Will this meeting be on 1st August or 2rd August? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
My blooper. Fixed. Thanks. |
Beta Was this translation helpful? Give feedback.
-
(Please note that the meetings happen on Tuesdays from now on!)
Agenda
(please write your proposed agenda items in comments under this discussion)
loader.argv = ["arg0", "arg1", "arg2"](Support for hardcoding argv in the manifest #761)./etc/files (RFC: Sanitization of/etc/files #689)LD_LIBRARY_PATHhandling in Gramine, see discussion at [LibOS] Removemigrated_envp#781 (review)Meeting Notes for 9. August
Dmitrii is on vacation, so Vijay (@vijaydhanraj) will keep the meeting notes for the 9. August meeting.
Status update on
loader.argv = ["arg0", "arg1", "arg2"]No work is done currently. Mariusz (@oshogbo) was preempted to work on the "sanitization of
/etc/ files", and didn't have time to look into this issue.Status update on sanitization of
/etc/filesMariusz is actively working on this. See the proposal details here: #689 (comment)
Status update on Microsoft Azure Attestation
Dmitrii will present the MAA support in the meeting on 16. August. Ideally, we'd like to start the review process soon. The details about MAA were summarized here: #626
The MAA PR is here: #652. Note that there are no changes to the core Gramine, only to the RA-TLS library.
LD_LIBRARY_PATHhandling in GramineThe context is in the comments for this PR: #781
Gramine relies on a hacky trick in the manifest file: users are required to override
LD_LIBRARY_PATHsuch that the first path points to the Gramine-specific patched Glibc. See for example:gramine/CI-Examples/redis/redis-server.manifest.template
Line 32 in f91a2c1
This is hacky but usually works, since normal environments do not set
LD_LIBRARY_PATHand do not play tricks with this envvar. However, Woju experienced problems with it: if the native app runs with a customLD_LIBRARY_PATH, then Gramine manifest needs to reflect the customLD_LIBRARY_PATHpaths when overriding it. Also, Borys expects some Bash scripts to blow up, because sometimes Bash scripts changeLD_LIBRARY_PATHand then execute some app -- Gramine's child process will override that customLD_LIBRARY_PATHwith the default override, and standard libs may go out of sync.Proposals:
/etc/ld.so.confcontents that include our patched-Glibc/lib/:entry.use_our_patched_glibc = true, and this option will reconfigureLD_LIBRARY_PATHand/etc/ld.so.cache(output of/etc/ld.so.confcompilation) in Gramine-FS, then we can rely on the/lib(or/lib64, need to verify) having priority over other paths (e.g./usr/lib). We would use that directory in all of our examples and removeLD_LIBRARY_PATHfrom the manifests. The only caveat is that we either need to ask users to shadow/remove/not mount/etc/ld.so.cachein their manifests (to be fair they shouldn't do that even now) or do it implicitly (I don't like this option - surprising to the user).Beta Was this translation helpful? Give feedback.
All reactions