From owner-freebsd-current@FreeBSD.ORG Sat Apr 12 19:23:38 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 5F3CF106564A; Sat, 12 Apr 2008 19:23:38 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id EC2178FC0A; Sat, 12 Apr 2008 19:23:37 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.2/8.14.2) with ESMTP id m3CJOEeU074942; Sat, 12 Apr 2008 15:24:14 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Coleman Kane In-Reply-To: <1208027381.1327.31.camel@localhost> References: <1208027381.1327.31.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RtEYSYLihVDY0kdXO1EC" Organization: FreeBSD, Inc. Date: Sat, 12 Apr 2008 15:23:37 -0400 Message-Id: <1208028217.82222.32.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on creme-brulee.marcuscom.com 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:23:38 -0000 --=-RtEYSYLihVDY0kdXO1EC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 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=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 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 >=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 even > 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. 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 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-RtEYSYLihVDY0kdXO1EC 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) iEYEABECAAYFAkgBDDkACgkQb2iPiv4Uz4dkwwCfUhDYykGn3s4XbIqpAkV9H1VR rVIAnj+J1Gtij0ElerHb5wo8ppHCTQ1k =YAF7 -----END PGP SIGNATURE----- --=-RtEYSYLihVDY0kdXO1EC--