curl/https within sandbox fails with "insufficient randomness"

[hpcpony]

It's more likely that I'm missing something than that these are bugs so I'm submitting here. If this isn't the right place, please redirect me.

I ran into the following when trying to hookup my sandbox to a LiteLLM server but here's an even simpler example (based on the documentation: https://docs.nvidia.com/openshell/get-started/tutorials/first-network-policy).

Relevant environment:

[OpenShell] podman images
REPOSITORY                                         TAG                                       IMAGE ID      CREATED       SIZE
ghcr.io/nvidia/openshell/supervisor                8d67250a5d17348eb96c4fa46226b06d8041f2ba  6ff75988c133  7 days ago    33.4 MB
ghcr.io/nvidia/openshell-community/sandboxes/base  latest                                    65fa5d3d598a  2 months ago  3.42 GB

[OpenShell] openshell --version
openshell 0.0.109

[OpenShell] openshell-gateway --version
openshell-gateway 0.0.109

[OpenShell] podman --version
podman version 5.8.2

[OpenShell] cat /etc/redhat-release
Red Hat Enterprise Linux release 9.8 (Plow)

[OpenShell] uname -srv
Linux 5.14.0-687.38.1.el9_8.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Aug 9 21:18:40 EDT 2026

My simple policy:

[OpenShell] cat policy-test.yml 
version: 1

# Static: locked at sandbox creation. Paths the agent can read vs read/write.
filesystem_policy:
  include_workdir: true
  read_only: [/usr, /lib, /proc, /dev/urandom, /app, /etc, /var/log]
  read_write: [/sandbox, /tmp, /dev/null]

# Static: Landlock LSM kernel enforcement. best_effort uses highest ABI the host supports.
landlock:
  compatibility: best_effort

# Dynamic: hot-reloadable. Named blocks of endpoints + binaries allowed to reach them.
network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-write
    binaries:
      - path: /usr/bin/curl

When I create the sandbox and try to exercise a connection out of it there's a failure:

[OpenShell] openshell sandbox create --name test --policy policy-test.yml

Created sandbox: test

[OpenShell] openshell sandbox exec --name test --tty /usr/bin/bash
sandbox@sandbox-test:~$ curl https://api.github.com/zen
curl: (35) Insufficient randomness

Based on the log it seems to be finding the policy just fine:

[1787768202.366] [sandbox] [OCSF ] [ocsf] NET:OPEN [INFO] ALLOWED /usr/bin/curl(78) -> api.github.com:443 [policy:github_api engine:opa]

Any help appreciated.

[ChangkeunJ]

Your filesystem policy isn't the problem, and nothing you add to it will help — /dev/urandom is a red herring here.

Insufficient randomness is curl's own string, from ossl_seed() in lib/vtls/openssl.c, raised when RAND_status() comes back 0. It fires client-side after the connection is already established, which lines up with your log showing curl allowed through to api.github.com:443. The network policy did its job; OpenSSL just couldn't seed its DRBG.

Why the device entry can't matter: OpenSSL 3 doesn't read /dev/urandom on your kernel at all.

/* rand_unix.c */    if (wait_random_seeded()) { /* DEVRANDOM block */ }
/* crypto/rand.h */  # define DEVRANDOM_SAFE_KERNEL 4, 8

wait_random_seeded() returns 0 for any kernel at or above 4.8, so on RHEL 9.8's 5.14 that whole block is dead code and the only entropy source left is the getrandom(2) syscall reached through getentropy(). Landlock is a filesystem LSM with no hook on that syscall, so landlock.compatibility won't change the outcome either. Incidentally OpenShell already injects /dev/urandom into the read-only baseline for any policy carrying a network_policies block, so yours was covered before you listed it.

That leaves either getrandom(2) failing, or the DRBG failing to instantiate for a reason unrelated to entropy. Three commands inside the sandbox split those apart — head -c 16 /dev/urandom | wc -c should print 16 and proves the fs side is fine, openssl rand -hex 16 should fail and moves it off curl, and then python3 -c 'import os; print(len(os.getrandom(48)))' is the decisive one because it calls the syscall directly.

If that raises OSError, capture the errno — OpenShell's supervisor seccomp is default-allow and getrandom isn't in its block list, and the container profile is unconfined, so it would be coming from the host or podman rather than from OpenShell. If it prints 48, entropy is fine and it's DRBG instantiation, so try OPENSSL_CONF=/dev/null openssl rand -hex 16 next.

Two practical notes: strace won't work in there, the supervisor blocks ptrace with EPERM. And cat /proc/sys/crypto/fips_enabled on the host is worth including when you report back.

[hpcpony]

Thanks for the comprehensive discussion. I never would have figured this out on my own.

Python os.getrandom is not available in the container so I substituted urandom. I saw some stuff that said it calls the same underlying getrandom on modern linux, but...

From within the sandbox:

sandbox@sandbox-test:~$ head -c16 /dev/urandom | wc -c
16

sandbox@sandbox-test:~$ openssl version
OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
sandbox@sandbox-test:~$ openssl rand -hex 16
40F7968C7B7F0000:error:12800067:DSO support routines:dlfcn_load:could not load the shared library:../crypto/dso/dso_dlfcn.c:118:filename(/usr/lib/x86_64-linux-gnu/ossl-modules/fips.so): /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so: cannot open shared object file: No such file or directory
40F7968C7B7F0000:error:12800067:DSO support routines:DSO_load:could not load the shared library:../crypto/dso/dso_lib.c:152:
40F7968C7B7F0000:error:07880025:common libcrypto routines:provider_init:reason(524325):../crypto/provider_core.c:912:name=fips
40F7968C7B7F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:386:Global default library context, Algorithm (CTR-DRBG : 0), Properties (<null>)
40F7968C7B7F0000:error:12000090:random number generator:rand_new_drbg:unable to fetch drbg:../crypto/rand/rand_lib.c:577:

sandbox@sandbox-test:~$ python3 -c 'import os; print(len(os.getrandom(48)))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import os; print(len(os.getrandom(48)))
                         ^^^^^^^^^^^^
AttributeError: module 'os' has no attribute 'getrandom'. Did you mean: 'urandom'?

sandbox@sandbox-test:~$ uname -a
Linux sandbox-test 5.14.0-687.38.1.el9_8.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Aug 9 21:18:40 EDT 2026 x86_64 x86_64 x86_64 GNU/Linux
sandbox@sandbox-test:~$ python3 --version
Python 3.14.3

sandbox@sandbox-test:~$ python3 -c 'import os; print(len(os.urandom(48)))'
48

And the minute I saw FIPS in your response (and in the openssl error above) I got suspicious.

[OpenShell] cat /proc/sys/crypto/fips_enabled
1

It looks to me like the sandbox is picking up the FIPS requirement from the host through /proc/sys/crypto/fips_enabled, but the container/image lacks the libraries (ossl-modules?) to support. I can ask the sysadmins if they'll temporarily disable it on the host so I can verify, but in the long term they're going to require it be enabled.

I'd be grateful if you can elaborate on the underlying issues and suggest a solution. It's unclear to me if this is something that OpenShell should address, whether it's uniquely a problem on my side, or whether there's just a fundamental incompatibility that's never going to work.

Thanks again.

[hpcpony]

Our sysadmins termporarily rebooted the host without FIPS mode and things work properly:

sandbox@sandbox-test:~$ cat /proc/sys/crypto/fips_enabled
0
sandbox@sandbox-test:~$ curl -s https://api.github.com/zen
Practicality beats purity.