From owner-freebsd-current@FreeBSD.ORG Sat Apr 12 19:20:17 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 D04CF106566B for ; Sat, 12 Apr 2008 19:20:17 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 56CFE8FC15 for ; Sat, 12 Apr 2008 19:20:17 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Cf901Z0050QuhwU530D700; Sat, 12 Apr 2008 19:08:43 +0000 Received: from discordia ([24.60.135.75]) by OMTA02.westchester.pa.mail.comcast.net with comcast id CjAC1Z0051dmTCQ3N00000; Sat, 12 Apr 2008 19:10:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=BT51vwXGU8wA:10 a=RFvLIk3JUtEA:10 a=XFsXuKNdAAAA:8 a=rwswzoD3Tlg9ix5qVh4A:9 a=DnymF-scuYK6KtxZv8gA:7 a=7ABqGe-pt2QGgK0ESncmNinmudEA:4 a=b8hG5vVbyAkA:10 a=pS80HJfSSACpi75mMxsA:9 a=9kVr3eBBIn50NyjRN7goD21yUJYA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 555F51636F9; Sat, 12 Apr 2008 15:10:12 -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 835111636F8; Sat, 12 Apr 2008 15:09:55 -0400 (EDT) From: Coleman Kane To: current@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pNBM3N+0X1s1k9rkRMVh" Organization: FreeBSD Project Date: Sat, 12 Apr 2008 15:09:41 -0400 Message-Id: <1208027381.1327.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: mezz7@cox.net, imp@FreeBSD.org Subject: 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:20:18 -0000 --=-pNBM3N+0X1s1k9rkRMVh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=20 =46rom 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. 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. -- Coleman Kane --=-pNBM3N+0X1s1k9rkRMVh 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) iEYEABECAAYFAkgBCPMACgkQcMSxQcXat5eI0ACeLD3koqIYXXZ8lA4bIXnt4RQb lWYAoICQkCfqjM9ywKXBmoZz0IsSD+Jx =O08o -----END PGP SIGNATURE----- --=-pNBM3N+0X1s1k9rkRMVh--