From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25805 invoked from network); 21 Dec 2020 20:50:16 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 21 Dec 2020 20:50:16 -0000 Received: from icebubble.org ([174.136.103.210]) by ewsd; Mon Dec 21 15:39:36 -0500 2020 Received: from petunia by icebubble.org with local-bsmtp (Exim 4.76) (envelope-from ) id 1krS3F-0002vB-Eg for 9front@9front.org; Mon, 21 Dec 2020 20:45:05 +0000 Received: from rusat by cmarib.ramside with local (Exim 4.72) (envelope-from ) id 1krQHn-0007kg-IL for 9front@9front.org; Mon, 21 Dec 2020 18:51:59 +0000 From: magma698hfsp273p9f@icebubble.org To: 9front@9front.org References: Date: Mon, 21 Dec 2020 18:51:59 +0000 In-Reply-To: (ori@eigenstate.org's message of "Sun, 20 Dec 2020 13:52:23 -0800") Message-ID: <867dpbj8kw.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtual pipelining SVG over HTML package hosting Subject: Re: [9front] RFNOMNT vs unmount Reply-To: 9front@9front.org Precedence: bulk ori@eigenstate.org writes: > Luckily, we have rfork m to prevent new mounts. > Unluckily, rfork m still allows unmounting, > which means that if you mount a constructed > naemspace over /, that can be undone. What?! Has that flaw been in the kernel since day one? > Quoth cinap_lenrek@felloff.net: > Right, and I don't *intend* to allow mounts and arbitrary > commands in other scripts, but bugs happen and lead to RCE > or shell escapes. > > I see namespaces as something that could be a tool to help > make those harder to exploit. I agree w/ori. You can't rely on server application program logic to enforce security. Sometimes, it helps to have assistance from the operating system.