From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 4 05:29:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E901316A4CE for ; Tue, 4 Jan 2005 05:29:03 +0000 (GMT) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A75E843D2F for ; Tue, 4 Jan 2005 05:29:03 +0000 (GMT) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.1/8.13.1) with ESMTP id j045T2dK050760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2005 21:29:03 -0800 (PST) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.1/8.13.1/Submit) id j045T0LV050759; Mon, 3 Jan 2005 21:29:00 -0800 (PST) (envelope-from steve) Message-Id: <200501040529.j045T0LV050759@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: <41D8859E.4080609@rojer.pp.ru> Organization: Watt Consultants From: steve@Watt.COM (Steve Watt) Date: Mon, 3 Jan 2005 21:29:00 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: myself@rojer.pp.ru X-Archived: 1104816543.013149506@wattres.Watt.COM cc: freebsd-hackers@freebsd.org Subject: Re: Determining userland return address (from syscall) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 05:29:04 -0000 In article <41D8859E.4080609@rojer.pp.ru> you write: [ snip ] >The solution I am about to implement is based on a custom setuid >syscall, that would allow limited list of processes to obtain root >privileges from a limited set of locations (supposedly, the trusted >ones, originating in the httpd's .text section). Unfortunately, the extremely powerful mmap() and munmap() system calls will allow remapping of text addresses, which kinda blows away your whole scheme. >The key point here is ability to trust a call being made from a specific >location. I assume that process cannot change its .text section once >loaded so this scheme would no be abused by overwriting the location >with malicious code. Am I correct here? What do you think of this scheme >overall? Probably insufficient. The safest way is still isolated processes, possibly one (or, worse resource-wise, more) per UID, and those processes communicate via pipes, unix-domain socket pairs, or similar controlled IPC. The parent vfork()s, does appropriate uid/gid/gidset rearrangement, and execs the "user server" process, which would then hang around servicing stuff for some time. There don't seem to be better alternatives for doing this securely and still keep reasonable *NIX-like behavior. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices...