From owner-freebsd-current@FreeBSD.ORG Sat Apr 12 20:23:20 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 C1DC2106564A for ; Sat, 12 Apr 2008 20:23:20 +0000 (UTC) (envelope-from cokane@cokane.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 7D09E8FC0C for ; Sat, 12 Apr 2008 20:23:20 +0000 (UTC) (envelope-from cokane@cokane.org) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id ChPn1Z00F0QkzPwA30Kl00; Sat, 12 Apr 2008 20:04:50 +0000 Received: from discordia ([24.60.135.75]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id Ck7K1Z0031dmTCQ8N00000; Sat, 12 Apr 2008 20:07:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=uaUJgS5ZL84A:10 a=FkP6uzeq5BwA:10 a=XFsXuKNdAAAA:8 a=6I5d2MoRAAAA:8 a=sTGlnqPMmMWeBAy6wdEA:9 a=tdUScSnqVVXreSmWPPkA:7 a=B0hdqVWqXSBdkA4qpblsfEj2xeIA:4 a=LY0hPdMaydYA:10 a=lcjrrK2uZ-FlamFAzxkA:9 a=uG-YngCqJYMvoIV-iorZXlmj08QA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id F22FC1636FA; Sat, 12 Apr 2008 16:07:18 -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,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 799A61636F8; Sat, 12 Apr 2008 16:07:03 -0400 (EDT) From: Coleman Kane To: Joe Marcus Clarke In-Reply-To: <1208028624.1327.41.camel@localhost> References: <1208027381.1327.31.camel@localhost> <1208028217.82222.32.camel@shumai.marcuscom.com> <1208028624.1327.41.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Txu9bkQnrhSTUxJmXX3W" Date: Sat, 12 Apr 2008 16:06:44 -0400 Message-Id: <1208030804.1360.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Sat, 12 Apr 2008 20:50:32 +0000 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 20:23:20 -0000 --=-Txu9bkQnrhSTUxJmXX3W Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-04-12 at 15:30 -0400, Coleman Kane wrote: > 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, > > >=20 > > > Recently we've been having a discussion on the GNOME list about fixin= g > > > the seahorse breakage introduced with the latest GNOME 2.22, rooted i= n > > > 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 pat= ch > > > to=20 > > >=20 > > > 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. > > >=20 > > > I've posted up a short page about it on my site here: > > > http://www.cokane.org/dokuwiki/freebsd/mlock-support > > >=20 > > > I'd like to know if there are any other patches that are floating aro= und > > > 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, a= s I > > > am looking for approaches to implement the support under FreeBSD with= out > > > compromising the security of the OS. > >=20 > > As mezz pointed out, Peter Jeremy commented on this a while ago: > >=20 > > http://lists.freebsd.org/pipermail/freebsd-arch/2006-July/005496.html > >=20 > > >=20 > > > 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. > > >=20 > > > A second idea might be to turn RLIMIT_MEMLOCK into a per-user (or eve= n > > > system-wide) resource limit, rather than a per-process limit. > > >=20 > > > 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. > >=20 > > 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. > >=20 > > I also looked through the kernel for instances where RLIMIT_MEMLOCK is > > checked, and the only other place is in the vslock() function. The onl= y > > consumer of this function I could find is sysctl_wire_old_buffer() whic= h > > is used by quite a few sysctl handlers. If the rlimit is changed from > > infinity, users might have problems getting results from certain > > sysctls. > >=20 > > Joe > >=20 >=20 > 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. >=20 > 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. >=20 > Correct me if I am mistaken. >=20 > -- > Coleman Kane >=20 Joe, I've modified the vm_mmap.c patch that you hosted. Your version applied the privilege fix to munlockall(2) [bad], so I un-did that part and applied the change in munlock(2) [good]. The fixed one: http://www.cokane.org/dokuwiki/_media/freebsd/vm_mmap.c.diff= ?id=3Dfreebsd%3Amlock-support Also, I discovered that gnome-keyring wants to pin down at least 16k of secure memory (so 4 pages-per-proc is necessary). I have added the following to my /etc/csh.login to force the limit to 16kB: limit memorylocked 16 I am currently running with that and the security.bsd.unprivileged_mlock=3D1 entry in my sysctl.conf. All seems well so far. I'm going to remove the csh.login line and instead apply the restriction in /etc/login.conf (and rebuild my db). -- Coleman Kane --=-Txu9bkQnrhSTUxJmXX3W Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgBFlIACgkQcMSxQcXat5eViACeOkOuwBEut4a7VHo+mRYnBOxB TKgAnRchxt+rsQoj96RUL3mXqQCl9T0P =fyme -----END PGP SIGNATURE----- --=-Txu9bkQnrhSTUxJmXX3W--