From owner-freebsd-security@FreeBSD.ORG Tue Aug 28 20:20:47 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD897106564A; Tue, 28 Aug 2012 20:20:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 87FD58FC12; Tue, 28 Aug 2012 20:20:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA26585; Tue, 28 Aug 2012 23:20:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T6SHD-000LEK-Fk; Tue, 28 Aug 2012 23:20:43 +0300 Message-ID: <503D281A.3080107@FreeBSD.org> Date: Tue, 28 Aug 2012 23:20:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Andrey Zonov References: <503CF3B1.3050604@FreeBSD.org> <503D08D6.1040004@shatow.net> In-Reply-To: <503D08D6.1040004@shatow.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Aug 2012 20:49:34 +0000 Cc: freebsd-arch@FreeBSD.org, Bryan Drewery Subject: Re: [patch] unprivileged mlock(2) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:20:47 -0000 on 28/08/2012 21:07 Bryan Drewery said the following: > On 8/28/2012 11:37 AM, Andrey Zonov wrote: >> Hi, >> >> We've got RLIMIT_MEMLOCK for years, but this limit is useless, because >> only root may call mlock(2), and root may raise any limits. >> >> I suggest patch that allows to call mlock(2) for unprivileged users. >> Are there any objections to got it in tree? >> > > FYI, see previous recent thread on this here: > > http://lists.freebsd.org/pipermail/freebsd-arch/2012-May/012552.html > and > http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012606.html Yes, Andrey, I highly suggest that you read those threads completely. Here are some observations. It doesn't look like mlockall and mlockall(MCL_FUTURE) in particular properly honor RLIMIT_MEMLOCK. If this is not fixed, then it would be premature to enable the privilege for non-privileged users. I am against adding the sysctl knob. If RLIMIT_MEMLOCK limit is properly implemented then it is sufficient to effectively deny the privilege (and with much finer granularity). When the privilege is allowed to ordinary users, then memorylocked in the default login.conf would need to be set to something much lower than the current 'unlimited' :-) Also, note that currently RLIMIT_MEMLOCK is abused at least in vslock() (used at least by sysctl's kernel side). The temporary wirings performed as an implementation detail or side-effect should not be accounted against the limit. The limit is for wirings that a user makes and controls explicitly. It should not be applied to something that kernel does behind the scenes without user's knowledge. -- Andriy Gapon