From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267846AbUGWRfp (ORCPT ); Fri, 23 Jul 2004 13:35:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267854AbUGWRfp (ORCPT ); Fri, 23 Jul 2004 13:35:45 -0400 Received: from mx1.redhat.com ([66.187.233.31]:16595 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S267846AbUGWRfm (ORCPT ); Fri, 23 Jul 2004 13:35:42 -0400 Date: Fri, 23 Jul 2004 13:34:25 -0400 From: Alan Cox To: Tigran Aivazian Cc: Solar Designer , Alan Cox , Marcelo Tosatti , linux-kernel@vger.kernel.org Subject: Re: question about /proc//mem in 2.4 (fwd) Message-ID: <20040723173425.GA15472@devserv.devel.redhat.com> References: <20040707234852.GA8297@openwall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 18, 2004 at 01:41:34PM +0100, Tigran Aivazian wrote: > > | setuidapp < /proc/self/mem > > > > ... > > See Alan's example I've quoted above. In this scenario, it would be > > the program being attacked which will be checked for possession of the > > capability... if it is SUID root, the attack will succeed. > > In the above example there is nothing forbidden and the current state of > things doesn't prevent the program from reading it's own address space. I meant to say exec setuidapp