is there protection agains gcode about secrets

[jorgeelmundoso]

here is the source code to gcore from gdb
https://github.com/bminor/binutils-gdb/blob/master/gdb/gcore.c

[stouset]

Was this built in --release mode? We call setrlimit to set the hard limit for RLIMIT_CORE to 0 in non-debug builds.

[stouset]

It looks like gcore ignores setrlimit. I'm not sure there's anything this (or any) library can do about a user that has root and can probe memory directly.

[jorgeelmundoso]

Was this built in --release mode? We call setrlimit to set the hard limit for RLIMIT_CORE to 0 in non-debug builds.

Yes it was build with --release.
I was looking for a way to protect secrets inside docker containers, guess that is a really hard one.

[stouset]

FWIW, libsodium recently added an mshield function that performs in-memory encryption. When that is stabilized and released, I'll be able to use it.

Of course, anyone with similar privileges can still find the key and IV in memory and decrypt the secret, but it does increase the level of effort for such an attach.

[stouset]

But yeah, fundamentally there's not much that can be done to protect against a user with root who can read arbitrary memory. Page-level protections like mprotect only affect the process' address space.

The main intent here is to protect against in-process bugs like those that resulted in heartbleed.

Closing since there's not much that can be done here, but when libsodium does release a version with mshield, I will use it for secrets allocated on the heap.

[jorgeelmundoso]

thanks