Re: Which package is responsible for setting rlimits?

[Russ Allbery <rra@debian.org>]

Simon McVittie <smcv@debian.org> writes:

> The reason I ask about this is that I want to make sure we are setting
> rlimits, and in particular RLIMIT_MEMLOCK, to a realistic value for
> 2021.  The wider context here is that gnome-keyring-daemon, GNOME's
> implementation of the org.freedesktop.Secrets interface, is currently
> setcap cap_ipc_lock=ep so that it can mlock(2) secrets and stop them
> from getting swapped out. This is ineffective on systems that can
> hibernate, at which point everything (even locked memory) has to be
> written to swap in any case, but it's better than nothing.

Does this serve any useful purpose?  If someone cares about this type of
security, they should put swap on an encrypted file system, at which point
these machinations don't achieve much in the way of security.  Encrypted
swap works fine with hibernation, as long as you're willing to unlock the
drive when booting back up (which is an unavoidable requirement for any
sort of persistent encryption).

If you don't care about hibernation, it's trivial to configure swap to use
an ephemeral encryption key [1], which solves this problem more thoroughly
and completely and doesn't require each application to do complex security
configuration.

I think adding this capability to gnome-keyring-daemon makes the whole
system less secure, not more secure, compared to using encrypted swap,
since managing escalated privileges in a program is far more complicated
and failure-prone.

[1] https://feeding.cloud.geek.nz/posts/encrypted-swap-partition-on/

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>