Date: Sat, 12 Apr 2008 15:09:41 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: current@FreeBSD.org Cc: mezz7@cox.net, imp@FreeBSD.org Subject: mlock(2), unprivileged users, and RLIMIT_MEMLOCK Message-ID: <1208027381.1327.31.camel@localhost>
next in thread | raw e-mail | index | archive | help
--=-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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208027381.1327.31.camel>