Date: Sat, 30 Aug 2003 15:50:41 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Joe Greco <jgreco@ns.sol.net> Cc: freebsd-current@freebsd.org Subject: Re: Someone help me understand this...? Message-ID: <Pine.NEB.3.96L.1030830154651.47993U-100000@fledge.watson.org> In-Reply-To: <200308282102.h7SL2tMo046811@aurora.sol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Aug 2003, Joe Greco wrote:
> > > > Could you confim this happens with 4.8? The access control checks there
> > > > are substantially different, and I wouldn't expect the behavior you're
> > > > seeing on 4.8...
> > >
> > > Rather difficult. I'll see if the client will let me trash a production
> > > system, but usually people don't like $40K servers handing out a few
> > > hundred megabits of traffic going out of service. We were trying to fix
> > > it on the scratch box (which happens to have 5.1R on it) and then were
> > > going to see how it fared on the production systems.
> >
> > I think it's safe to assume that if you're seeing a similar failure,
> > there's a different source given my reading of the code, but I'm willing
> > to be proven wrong. It's probably not worth the investment if you're
> > talking about large quantities of money, though.
>
> It's more like "large quantities of annoyance and work". Can you
> describe the case you're envisioning? If I can easily poke at it, I can
> at least get some clues.
I guess all I'm looking for is confirmation that your original statement
(happens in 4.8 and 5.1) is completely correct: the 5.1 behavior is
expected, but I'm surprised it happens with 4.8.
> Correct. The USR signals control debug levels. If it was a signal that
> was only used internally, it could be changed, of course, but changing a
> signal used by humans (and one used in the same manner as other
> programs) is probably a bad idea.
Try the patch attached, which introduces both the conservative_signals
sysctl, and adds SIGALRM to the list of acceptable signals for P_SUGID
processes.
> Yeah, if anything, we probably don't want to do that, because the
> resources set up as root are usually more attractive. I don't have a
> problem with coding in some FreeBSD-isms, but I don't see it as buying
> us anything, does it?
I'm not sure there are explicit benefits in this specific situation,
except that you can run Diablo with the resource limits of the user you
configure, and potentially those might be similar to (but perhaps not
identical to) those given to root. I.e., instead of hard-coding "use the
resource limits of root", you're saying "use the resource limits of the
user Diablo is run as, and set those to what you want". Given that
heavy-weight news servers are likely to be dedicated machines, it's a
subtle but perhaps useful semantic difference.
Updated patch below.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
Index: kern_prot.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.175
diff -u -r1.175 kern_prot.c
--- kern_prot.c 13 Jul 2003 01:22:20 -0000 1.175
+++ kern_prot.c 30 Aug 2003 19:45:50 -0000
@@ -1367,6 +1367,20 @@
return (cr_cansee(td->td_ucred, p->p_ucred));
}
+/*
+ * 'conservative_signals' prevents the delivery of a broad class of
+ * signals by unprivileged processes to processes that have changed their
+ * credentials since the last invocation of execve(). This can prevent
+ * the leakage of cached information or retained privileges as a result
+ * of a common class of signal-related vulnerabilities. However, this
+ * may interfere with some applications that expect to be able to
+ * deliver these signals to peer processes after having given up
+ * privilege.
+ */
+static int conservative_signals = 1;
+SYSCTL_INT(_security_bsd, OID_AUTO, conservative_signals, CTLFLAG_RW,
+ &conservative_signals, 0, "Unprivileged processes prevented from "
+ "sending certain signals to processes whose credentials have changed");
/*-
* Determine whether cred may deliver the specified signal to proc.
* Returns: 0 for permitted, an errno value otherwise.
@@ -1399,12 +1413,13 @@
* bit on the target process. If the bit is set, then additional
* restrictions are placed on the set of available signals.
*/
- if (proc->p_flag & P_SUGID) {
+ if (conservative_signals && (proc->p_flag & P_SUGID)) {
switch (signum) {
case 0:
case SIGKILL:
case SIGINT:
case SIGTERM:
+ case SIGALRM:
case SIGSTOP:
case SIGTTIN:
case SIGTTOU:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030830154651.47993U-100000>