linux-kernel - Re: [RFC][PATCH 3/3] Set si_pid to 0 for signals from ancestor namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20081114165809.GB7738@redhat.com>
Date:	Fri, 14 Nov 2008 17:58:09 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	Daniel Hokka Zakrisson <daniel@...ac.com>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Containers <containers@...ts.osdl.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 3/3] Set si_pid to 0 for signals from ancestor
	namespace

On 11/12, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@...hat.com> writes:
>
> > On 11/11, Sukadev Bhattiprolu wrote:
> >>
> >> +static void set_sigqueue_pid(struct sigqueue *q, struct task_struct *t,
> >> +                           struct pid *sender)
> >> +{
> >> +	struct pid_namespace *ns;
> >> +
> >> +	/* Set si_pid to the pid number of sender in the pid namespace of
> >> +	 * our destination task for all siginfo types that support it.
> >> +	 */
> >> +	switch(q->info.si_code & __SI_MASK) {
> >> +		/* siginfo without si_pid */
> >> +		case __SI_TIMER:
> >> +		case __SI_POLL:
> >> +		case __SI_FAULT:
> >> +			break;
> >> +			/* siginfo with si_pid */
> >> +		case __SI_KILL:
> >> +		case __SI_CHLD:
> >> +		case __SI_RT:
> >> +		case __SI_MESGQ:
> >> +		default:
> >> +			/* si_pid for SI_KERNEL is always 0 */
> >> +			if (q->info.si_code == SI_KERNEL || in_interrupt())
> >> +				break;
> >> +			/* Is current not the sending task? */
> >> +			if (!sender)
> >> +				sender = task_tgid(current);
> >> +			ns = task_active_pid_ns(t);
> >> +			q->info.si_pid = pid_nr_ns(sender, ns);
> >> +			break;
> >> +	}
> >> +}
> >
> > Why, why? Just: if from parent ns - clear .si_pid. No?
>
> We need the switch to know if we are a member of a union that supports
> si_pid.

Please look at http://marc.info/?l=linux-kernel&m=122634217518183

If SIG_FROM_USER is set, we know that .si_pid is "valid".

Yes, yes, yes. sys_rt_sigqueueinfo() is a problem, but in that
case we can't trust .si_code anyway.

> The in_interrupt thing is there simply because current is not
> useable from an interrrupt context, and there are some
> signals that get sent from an interrupt context.

Yes sure. But I don't think this check is enough, see other
emails. And this check is not needed once we have SIG_FROM_USER.

> Oh.  As for the chunk that is:
> ns = task_active_pid_ns(t)
> q->info.si_pid = pid_nr_ns(sender, ns);
>
> If we are sending from a child to a parent namespace.

The notify_parent() case is fine, afaics (again I assume the "patch"
above which sets SIG_FROM_USER).

> The name of the
> child changes.  There is some place F_SETSIG? sigfd?  where we have
> something that resembles the full general case of processes being able
> to send a signal to any other process.

Yes, this needs attention too.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/