linux-kernel - Re: [PATCH] user namespace: make signal.c respect user namespaces

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Sep 2011 10:27:11 -0500
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, richard@....at,
	Andrew Morton <akpm@...gle.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tejun Heo <tj@...nel.org>, serge@...lyn.com
Subject: Re: [PATCH] user namespace: make signal.c respect user namespaces

Quoting Oleg Nesterov (oleg@...hat.com):
> On 09/27, Serge Hallyn wrote:
> >
> > Quoting Oleg Nesterov (oleg@...hat.com):
> > > On 09/25, Serge E. Hallyn wrote:
> > > >
> > > > Yes, that's the case I was talking about.  That then proceeds through
> > > > send_signal().
> > >
> > > It doesn't?
> >
> > No, I was saying it *does*.
> 
> But it doesn't ;)
> 
> Serge, there is some misunderstanding. And I do not know who is confused,
> me or your.
> 
> ptrace_signal() simply fills *info with some "random" data before
> processing the signal. It doesn't pass this info to send_signal().

Oh, well not always, but it does in the case where
	sigismember(&current->blocked, signr);
But I suppose that's not a common path :)

> If the debuggure wants something meaningfull in *info, it should
> fill it itself via PTRACE_SETSIGINFO. This handles the case when
> the debugger doesn't really care and only changes signr.

Ok.

> > > +static inline fixup_uid(struct siginfo *info, struct task_struct *t)
> > > +{
> > > +#ifdef CONFIG_USER_NS
> > > +	if (current_user_ns() == task_cred_xxx(t, user_ns)))
> > > +#endif
> > > +		return;
> > > +
> > > +	if (SI_FROMKERNEL(info))
> > > +		switch (info->si_code & __SI_MASK) {
> > > +			default:
> > > +				return;
> > > +
> > > +			case __SI_CHLD:
> > > +			case __SI_MESGQ:
> > > +				break;
> > > +		}
> > > +
> > > +	info->si_uid = user_ns_map_uid(task_cred_xxx(t, user_ns),
> > > +					current_cred(), info->si_uid);
> > > +}
> > > +
> > >  static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
> > >  			int group, int from_ancestor_ns)
> > >  {
> > > @@ -1088,6 +1109,9 @@ static int __send_signal(int sig, struct
> > >  				q->info.si_pid = 0;
> > >  			break;
> > >  		}
> > > +
> > > +		fixup_uid(info, t);
> > > +
> > >  	} else if (!is_si_special(info)) {
> > >  		if (sig >= SIGRTMIN && info->si_code != SI_USER) {
> > >  			/*
> >
> > It certainly is much simpler.  I'll take some time to walk through all
> > of send_signal again and make sure I understand what it does in all
> > the cases.
> 
> Thanks.
> 
> 
> 
> As for ptrace_signal(), it can use the same helper too. Once again,
> debugger can use PTRACE_SETSIGINFO, if we really want to fixup si_uid
> we should do this even if signr == info->si_signo. OTOH, we do not
> know what debugger puts in this chunk of memory. This is like
> sigqueueinfo().

True.

> Or we can simply leave this code as is. I do not think this si_uid
> (in this case) is really important.

Ok, that sounds good to me.

thanks,
-serge
--
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/