From owner-freebsd-current@freebsd.org Thu Feb 2 22:01:42 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 55B05CCEF3D for ; Thu, 2 Feb 2017 22:01:42 +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 EE4AB124E for ; Thu, 2 Feb 2017 22:01:41 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id 196so9082024wmm.1 for ; Thu, 02 Feb 2017 14:01:41 -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:content-transfer-encoding; bh=yIXSfqxgSExlcZm56RVukkhOQs657V090S+YNlaRyzU=; b=DVlD8bs9iDInOCx/GxJtL0Z629mon9dDLSJiFAzaIHPoT0hvWFNwWMUV6mUsTyYFvA YObLCJqAlVr/8nsUPy8DpNZFnI4qivwTY0GFj34MSq0sqkKyoCcRhD3+n3CbAqfNuFjw ZkdNGsb5g9TRuc5wLkKnS5wIDIytrRPCAGrmRi+wk9wjCHnWrjciVTzt2PGSQI7H9sLI jjNPY80kFAxAibOTGaDIhvaMx4rWiu9Vk6apL5tZC+o8JIzFsGSQV5uRO8LJpTcbxM8z yXHiuuWq0Z5yha+oxCkmtmO3HpW4GcQqmSCN16Qjo1olTaL2/1EL1IHWir9DwAvJxnex qV+Q== 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:content-transfer-encoding; bh=yIXSfqxgSExlcZm56RVukkhOQs657V090S+YNlaRyzU=; b=bZbyszW0Q0DmxYzTLqlWXdBb6ujZ3VYDFp19GGyYbOkHPLSya3edZOnqjPc0aS4wWa 9Ai2v73l0tGi7ZXgFmK2D0oWqvTS5zN91LQaZSXb/4gyr6pJ58q4ZVd6CjDI2NYcesvt w33f9d/1Ga5Q+3EVttmRQFK2m1wz+RFXqY1dceEqFM/9+awAqAUXcTbmIVgSOtFXSfrl j3/GukP/5qbNCzNBMrlQYOsMQCZPdGgg45hkMB7/kkZc8mdMAio/EpPIATAI4i1lQG1g I4tSMurjHZRDSUMAe/EPhmS5GIk06fMuSP924/FW8iLqgAiXyr/vTPQ9HiumDSxsUv+L FwuQ== X-Gm-Message-State: AIkVDXLMNr6B8UentydJGItElTzFc9b3vIuqdLxjXPYUBQtq7dCiJWovBQauxtHIXp7H0bIOm2yf1/BtGdfVvw== X-Received: by 10.223.151.99 with SMTP id r90mr9075828wrb.183.1486072900011; Thu, 02 Feb 2017 14:01:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.145.133 with HTTP; Thu, 2 Feb 2017 14:01:39 -0800 (PST) In-Reply-To: References: From: Xin LI Date: Thu, 2 Feb 2017 14:01:39 -0800 Message-ID: Subject: Re: mlock and jail To: =?UTF-8?B?QnJ1bm8gTGF1esOp?= Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 22:01:42 -0000 On Thu, Feb 2, 2017 at 1:28 PM, Bruno Lauz=C3=A9 wrote= : > > > But a simple user with no rights can mlock (64kb by default) why a jail w= ould not be able? > No, I'm not, by any means, arguing against having jailed processes being able to mlock(), I'm just saying that we should have more fine grained control over it (a knob to allow system administrators to tweak it would be a good start). Cheers, > > From: Xin LI > Sent: Thursday, February 2, 2017 1:13 PM > To: Pavel Timofeev > Cc: Bruno Lauz=C3=A9; freebsd-current > Subject: Re: mlock and jail > > > > 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, > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= "