From owner-freebsd-current@FreeBSD.ORG Sat Apr 12 19:30:49 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A86011065674 for ; Sat, 12 Apr 2008 19:30:49 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2F63C8FC25 for ; Sat, 12 Apr 2008 19:30:48 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id ChDT1Z04J0vyq2s5705U00; Sat, 12 Apr 2008 19:29:24 +0000 Received: from discordia ([24.60.135.75]) by OMTA05.westchester.pa.mail.comcast.net with comcast id CjWo1Z0011dmTCQ3R00000; Sat, 12 Apr 2008 19:30:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=uaUJgS5ZL84A:10 a=FkP6uzeq5BwA:10 a=XFsXuKNdAAAA:8 a=6I5d2MoRAAAA:8 a=TmfPnutPwaJQbaAqmIMA:9 a=tRWZ9GHj4FVhq4G3bs0A:7 a=SMPeHxeDrqEvWlvmpuWfwSx6vPkA:4 a=LY0hPdMaydYA:10 Received: by discordia (Postfix, from userid 103) id 0AD8A1636F9; Sat, 12 Apr 2008 15:30:48 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 39B491636F8; Sat, 12 Apr 2008 15:30:39 -0400 (EDT) From: Coleman Kane To: Joe Marcus Clarke In-Reply-To: <1208028217.82222.32.camel@shumai.marcuscom.com> References: <1208027381.1327.31.camel@localhost> <1208028217.82222.32.camel@shumai.marcuscom.com> Content-Type: text/plain Organization: FreeBSD Project Date: Sat, 12 Apr 2008 15:30:24 -0400 Message-Id: <1208028624.1327.41.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: mezz7@cox.net, imp@FreeBSD.org, current@FreeBSD.org Subject: Re: mlock(2), unprivileged users, and RLIMIT_MEMLOCK X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 12 Apr 2008 19:30:49 -0000 On Sat, 2008-04-12 at 15:23 -0400, Joe Marcus Clarke wrote: > On Sat, 2008-04-12 at 15:09 -0400, Coleman Kane wrote: > > Hello, > > > > Recently we've been having a discussion on the GNOME list about fixing > > the seahorse breakage introduced with the latest GNOME 2.22, rooted in > > the fact that FreeBSD's mlock(2) implementation is only usable if you > > have superuser privileges. Due to bugs in seahorse, the lack of mlock(2) > > causes many seahorse applications to die. I've posted a suggested patch > > to > > > > From my understanding, a significant reasoning for this is because if > > unprivileged users could mlock(2), then they could incur a DoS attack on > > a system by spawning off at most RLIMIT_NPROC processes, each > > wiring-down RLIMIT_MEMLOCK bytes of memory in an effort to steal away > > all real system RAM from the rest of the system, and bring usage to a > > screeching halt. > > > > I've posted up a short page about it on my site here: > > http://www.cokane.org/dokuwiki/freebsd/mlock-support > > > > I'd like to know if there are any other patches that are floating around > > for the same thing, or even if there are some good alternatives to > > mlock(2) that yield similar results (secure memory accessible by the > > user). I'd also welcome any comments that others have on the topic, as I > > am looking for approaches to implement the support under FreeBSD without > > compromising the security of the OS. > > As mezz pointed out, Peter Jeremy commented on this a while ago: > > http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005496.html > > > > > An idea that came to mind, but I am less familiar with, is to also > > support some sort of MAC policy checks that can be enforced by the > > administrator on the system to provide some users with secure access > > support, while preventing others from using it. > > > > A second idea might be to turn RLIMIT_MEMLOCK into a per-user (or even > > system-wide) resource limit, rather than a per-process limit. > > > > As a third idea, we could leave the per-process limit (to abide by > > historical documentation), but also add a sysctl that enforces a > > system-wide "max mlock pages" which can be tested by the mlock(2) > > syscall, refusing to mlock(2) more memory if the limit is hit. > > I think this already exists in -CURRENT: vm.max_wired ("System-wide > limit to wired page count"). This is tested by mlock(2) in addition to > RLIMIT_MEMLOCK. > > I also looked through the kernel for instances where RLIMIT_MEMLOCK is > checked, and the only other place is in the vslock() function. The only > consumer of this function I could find is sysctl_wire_old_buffer() which > is used by quite a few sysctl handlers. If the rlimit is changed from > infinity, users might have problems getting results from certain > sysctls. > > Joe > Another thing that we're going to want to keep in mind is that the mlock(2)-memory is probably allocated on a page-by-page basis (so mlock(2) pointers point into mlock(2) pages). I *think* this means that the minimum per-process mlock(2) size (as far as in-kernel usage is concerned) is going to be 4096 Bytes. I'm setting up a kernel now with your patch so that I can test using rlimits on the system. I am guessing that mlock(2) pages are going to be distinct between processes, meaning that two processes that only want to mlock(2) 512-bytes of memory will end up incurring an 8192 Byte impact on on mlock(2) availability. Correct me if I am mistaken. -- Coleman Kane