From owner-freebsd-security Mon Aug 11 12:36:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA25085 for security-outgoing; Mon, 11 Aug 1997 12:36:46 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA25061; Mon, 11 Aug 1997 12:36:29 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA23907; Mon, 11 Aug 1997 15:29:20 -0400 (EDT) Date: Mon, 11 Aug 1997 15:29:20 -0400 (EDT) From: Brian Mitchell To: Sean Eric Fagan cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >I think any access to memory must be disallowed immediately after exec of > >setuid program issued by user (not setuid root) program. I.e. exec call > >must set some flag (in struct proc?) disabling procfs access and procfs > >call need to check this flag only. > > Gosh, that's what I had originally, and everyone didn't like *that*. > (Frankly, neither did I.) Yes, I advise everyone to try just denying access when P_SUGID is enabled. This is what my patch does, and it is simply unacceptable. I'm not sure sef's patch is perfect, but it's not bad. As for the kmem stuff, I originally did not like that, but look at the perms on the mem device! It allows kmem to be readable. I think we should duplicate those perms whenever possible. Granted this allows people who have managed to break gid kmem to look at privledged data (shadow files is one big example I can think of) it is certainly better than nothing. Besides. if they have gid kmem, they can do the exact same thing by munging through /dev/kmem, so denying them proc/#/mem is not a real big win in my book. There is a situation where we could get into trouble, although I don't think it occurs. exec suid program setuid(0) exec non suid program I don't know that this occurs anywhere, but things like this concern me and leave me wondering if perhaps we should revoke the fd(s) when we execute a setuid program.