From owner-freebsd-current@freebsd.org Thu Feb 2 18:13:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61BF6CCE426 for ; Thu, 2 Feb 2017 18:13:31 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC834C10 for ; Thu, 2 Feb 2017 18:13:30 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id v77so99446595wmv.0 for ; Thu, 02 Feb 2017 10:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WTiW/OfcYg4nGg0DjDLEzB97Hp9cD1Bp23sQGUnbQ5c=; b=O9dNoM+KUwSwFG6Ikwe3T+kIHQwiAYx+xzYBThq+FuBP6M/+dha0RwSltfnLVP6Y3X m0InpEqpNEy8Tyuyfmz4qBf8nycqB1gVjMX8O4gAyDnz1uVib/01cNYGcs7ASn+hcS/E Mv1dqeS8vaapgUafd0hltR8t1F9S7R1A4uDhmmkSKlAoQsrveU4vDdXouHIVihnP1G3J z+CwyFKRUqTBGnZLllaXwjJ750LaeEdO2O/5f4oRDlYqbggdK48gxosgw9N2jYnUggms 3ThxQTkoz7zh4UbqP9+l2DX98jjaoMPhKqNHyQ5bC/Fa4oLE4GJ3M9Y0WrYCALap0ZRC kngA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WTiW/OfcYg4nGg0DjDLEzB97Hp9cD1Bp23sQGUnbQ5c=; b=JMnUjjtnLIRToRTWi0rYU4Vo2b8E2hdQNKHc63Fex253XdrrJoFv2HHlzkn8QfnbaH CQNk1PcS7BITLjO8MrVcSZwvHFx5DfcqhS01M1cHZBrA80esh67Q2a7otgHjI/IMlmh8 LYxS+FbXKGg09uAOgHNWCBkth73FJ5rjhC5Pl8OEMwjC6TkgDHcQReGdRHMZ4a6UVjxn YOH6miJr6mXquFeLDgVd9LwdvP3U8pIZHoEcLIfsTr+qw9b59i8G6eoMwoUzwMFr/QcW JFam2RMt7ClGqSUIjpnwqtdP7m/2d8ZW6GtKE3/u+a6cEABUT7VJCkVzncduu21fJxB/ cHlA== X-Gm-Message-State: AIkVDXLfauiWw8VCHp1ZsmxuWsq8LgxVAtHBCfQquWaEm4Vjw4ncYkfXOwe1QRvSoNYLOgRJJ34irj2QcZrB1g== X-Received: by 10.28.91.19 with SMTP id p19mr26997883wmb.49.1486059209336; Thu, 02 Feb 2017 10:13:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.145.133 with HTTP; Thu, 2 Feb 2017 10:13:28 -0800 (PST) In-Reply-To: References: From: Xin LI Date: Thu, 2 Feb 2017 10:13:28 -0800 Message-ID: Subject: Re: mlock and jail To: Pavel Timofeev Cc: =?UTF-8?B?QnJ1bm8gTGF1esOp?= , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:13:31 -0000 On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev wrote: > 2017-02-02 4:31 GMT+03:00 Xin LI : >> 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. Cheers,