Date: Mon, 11 Aug 1997 15:29:20 -0400 (EDT) From: Brian Mitchell <brian@firehouse.net> To: Sean Eric Fagan <sef@Kithrup.COM> Cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch Message-ID: <Pine.BSI.3.95.970811152213.23837D-100000@shell.firehouse.net> In-Reply-To: <199708111521.IAA07362@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.970811152213.23837D-100000>