Date: Tue, 16 Sep 1997 21:55:40 -0600 (MDT) From: tqbf@silence.secnet.com To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: BSD I/O Signals Message-ID: <Pine.BSI.3.96.970916214830.1368A-100000@silence.secnet.com> In-Reply-To: <199709170335.UAA26150@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Sep 1997, Don Lewis wrote: > Should the argument to F_SETOWN undergo similar checks as the argument to > tcsetpgrp()? I don't think it makes sense to allow F_SETOWN to enable It does. Note that F_SETOWN is literally a generic-file-descriptor wrapper around TIOCSPGRP (check out the source), as well. > I think a better cure for the wraparound problem is to solve it the same > was as it is handled for controlling terminals. When the process group The terminal code deals with pointers to proc structures, and the generic device code deals with indexes into the process table; this is the reason credential checking was added. > process group and it no longer can send signals. This would have to be > extended to handle either processes or process groups for F_SETOWN. This Can you explain how this is a security-relevant proposal? The fix we've provided is addressed at a very specific problem; it wasn't anyone's intentions to change expected semantics, as you appear to suggest. > I've got mixed feelings about credential checking. It doesn't eliminate > inadvertent interference between processes with matching credentials when This would appear to be a general programming concern, and not a security issue. > bogus is done with F_SETOWN, and there may be cases where someone wants to > use several cooperating processes with different credentials but sharing > the same socket (though I really can't think of any and it looks like the If you could point out a specific instance in the code distributed with FreeBSD, it'd be helpful (to clarify your meaning here). > IMHO, the change to disable signal sending when the process or process group > disappears should definitely be implemented. It increases security, there > is no loss of functionality, and there is likely to be increased performance. How does this increase security in the presence of strict credential checking at signal delivery (a la csignal())? > Something else to consider is whether it makes sense to only send the signal > to processes that have the object open. Given that this is not an established semantic and it isn't documented anywhere, I think this might not be the most appropriate forum within which to suggest such a change. Neh? > In the case of the log device, F_SETOWN should probably be limited to > root. In the case of the log device, F_SETOWN should be eliminated. Special-cases inside the 4.4BSD kernel have been a fairly consistant source of problems, have they not? (Reference init(8)). ---------------------------------------------------------------------- Thomas H. Ptacek Secure Networks, Inc. ---------------------------------------------------------------------- "mmm... sacrilicious..."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.96.970916214830.1368A-100000>