But a simple user with no rights can mlock (64kb by default) why a jail would 
not be able?

From: Xin LI<mailto:delp...@gmail.com>
Sent: Thursday, February 2, 2017 1:13 PM
To: Pavel Timofeev<mailto:tim...@gmail.com>
Cc: Bruno Lauzé<mailto:brunola...@msn.com>; 
Subject: Re: mlock and jail

On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote:
> 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>:
>> I like this idea.
>> Note that potentially your patch would make it possible for a jailed
>> root to DoS the whole system by locking too much of pages in memory.
>> I think it would be sensible to provide a per-jail flag to enable
>> doing it, or better, have some finer grained control (e.g. per jail
>> quota of permitted locked pages).
>> Why did the application want to lock pages in main memory, though?
> For example, this secret management tool
> https://www.vaultproject.io/docs/config/ wants to lock memory for
> security (surprise) reason.
> It's available as security/vault in our ports tree.

No it's not surprise but overkill IMHO.  Here is why:

Locking memory does prevent swapping, but in a typical multi-user
system, if an attacker is already able to read swap (keep in mind that
disks are by default owned by root and can not be read in a typical
setup), then the administrator already have much bigger problem to
worry about, and the attacker would have much more powerful tools to
steal the secrets.

Additionally, if one really cares about safety of swap, they should
have used encrypted swap in the first place.  On FreeBSD, appending
'.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
/dev/ada0p3.eli) would automatically do one-time keyed swapping.

Moreover, I don't think it's a good idea to use an application that
advocates locking all memory that it owns for "security" reasons: if
the application writer does not know which memory pages would contain
sensitive information, good chances that the application writer have
no idea what is privilege separation and the design they have created
could be fundamentally flawed.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to