Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Jan 2002 17:46:33 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Alfred Perlstein <bright@mu.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern kern_sig.c
Message-ID:  <Pine.NEB.3.96L.1020106174532.96164A-100000@fledge.watson.org>
In-Reply-To: <20020106164340.B14427@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 6 Jan 2002, Alfred Perlstein wrote:

> * Robert Watson <rwatson@FreeBSD.org> [020105 18:54] wrote:
> > rwatson     2002/01/05 16:54:47 PST
> > 
> >   Modified files:
> >     sys/kern             kern_sig.c 
> >   Log:
> >   - Teach SIGIO code to use cr_cansignal() instead of a custom CANSIGIO()
> >     macro.  As a result, mandatory signal delivery policies will be
> >     applied consistently across the kernel.
> >   
> >   - Note that this subtly changes the protection semantics, and we should
> >     watch out for any resulting breakage.  Previously, delivery of SIGIO
> >     in this circumstance was limited to situations where the subject was
> >     privileged, or where one of the subject's (ruid, euid) matched one
> >     of the object's (ruid, euid).  In the new scenario, subject (ruid, euid)
> >     are matched against the object's (ruid, svuid), and the object uid's
> >     must be a subset of the subject uid's.  Likewise, jail now affects
> >     delivery, and special handling for P_SUGID of the object is present.
> >     This change can always be reversed or tweaked if it proves to disrupt
> >     application behavior substantially.
> 
> Please provide a report on how previous SIGIO exploits behave with
> this code.  You can find mention of them in the cvs logs and most
> likely at CERT.  Basically make sure you haven't opened up any races
> wrt falsely sending sigio to processes one shouldn't be able to.

Arguably, this actually narrows the opportunity for vulnerabilities: 
previously, if a daemon set its euid to that of a user temporarily, the
user processes could signal it using SIGIO.  This is now prevented.  I
will review the various SIGIO exploits in the past and see if I can dig
anything up.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020106174532.96164A-100000>