From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Kza9r-0006Wb-1W for garchives@archives.gentoo.org; Mon, 10 Nov 2008 17:02:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 48C7BE032A; Mon, 10 Nov 2008 17:02:35 +0000 (UTC) Received: from atoth.sote.hu (atoth.sote.hu [195.111.75.211]) by pigeon.gentoo.org (Postfix) with ESMTP id E699EE032A for ; Mon, 10 Nov 2008 17:02:34 +0000 (UTC) Received: from atoth.sote.hu (apache@localhost [127.0.0.1]) by atoth.sote.hu (8.14.2/8.14.2/atoth@atoth.sote.hu) with ESMTP id mAAH2RFa029540 for ; Mon, 10 Nov 2008 18:02:29 +0100 Received: from 195.111.75.211 (SquirrelMail authenticated user atoth) by atoth.sote.hu with HTTP; Mon, 10 Nov 2008 18:02:29 +0100 (CET) Message-ID: <2ce09a640f3a2b0bafb5a96ffb8aa1ae.squirrel@atoth.sote.hu> In-Reply-To: <49183A77.9865.1577A2D@pageexec.freemail.hu> References: , , <20081110132427.GB19578@gmail.com> <49183A77.9865.1577A2D@pageexec.freemail.hu> Date: Mon, 10 Nov 2008 18:02:29 +0100 (CET) Subject: Re: [gentoo-hardened] what RLIMIT_STACK mean? From: atoth@atoth.sote.hu To: gentoo-hardened@lists.gentoo.org User-Agent: SquirrelMail/1.4.16 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, DNS_FROM_SECURITYSAGE autolearn=disabled version=3.2.1-gr1 X-Spam-Checker-Version: SpamAssassin 3.2.1-gr1 (2007-05-02) on atoth.sote.hu X-Virus-Scanned: ClamAV version 0.94, clamav-milter version 0.94 on atoth X-Virus-Status: Clean X-List-Milter: non-list mail Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c2064e6e-43eb-4daf-9a89-b24a43a5186d X-Archives-Hash: 6ba9bd1fd230d882752cba3429a28dfa On H=C3=A9t, November 10, 2008 13:43, pageexec@freemail.hu wrote: > On 10 Nov 2008 at 7:24, Brian Kroth wrote: > >> atoth@atoth.sote.hu 2008-11-10 12:31: >> > I usually have some of these while I'm listening to music: >> > grsec: (atoth:U:/usr/bin/audacious) denied resource overstep by >> requesting >> > 135168 for RLIMIT_MEMLOCK against limit 32768 for >> > /usr/bin/audacious[audacious:24077] uid/euid:1000/1000 >> gid/egid:100/100, >> > parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 >> > and usual report about signal 11s for eg. with java while browsing. = Of >> > course that RLMIT_MEMLOCK value requested is not so insane like that >> for >> > perl & pwd. >> >> Same here: >> >> grsec: denied resource overstep by requesting 69632 for RLIMIT_MEMLOCK >> against limit 32768 for /usr/bin/aplay[aplay:16674] uid/euid:1000/1000 >> gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/= 0 > > the memlock limit overstep is harmless, it won't cause any application > per se and you can get rid of it by granting the user in question a hig= her > limit for mlockable pages (the 32k is the linux default since 2.6.9 or > so). That's why I ignored these. > >> And for the perl forloop: >> >> grsec: denied resource overstep by requesting 4511036391424 for >> RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18765] >> uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:18636] >> uid/euid:1000/1000 gid/egid:1000/1000 > > now this one definitely looks fishy and spender's looking into it alrea= dy. > > If the representation of the resource's amount requested is correct, than there must be something odd with the userland. I tend to suspect the latter. Regards, Dw.