linux-kernel - Re: Testing lxc 0.6.5 in Fedora 13

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 26 Mar 2010 13:00:28 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Grzegorz Nosek <root@...aldomain.pl>
Cc:	Matt Helsley <matthltc@...ibm.com>,
	Roland McGrath <roland@...hat.com>,
	Sukadev Bhattiprolu <sukadev@...ibm.com>,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: Testing lxc 0.6.5 in Fedora 13

On 03/26, Grzegorz Nosek wrote:
>
> On Fri, Mar 26, 2010 at 12:11:31PM +0100, Oleg Nesterov wrote:
> > Yes, this is broken. More precisely, this wasn't even supposed to work.
> >
> > Even stracing of the sub-init itself (or global init btw) has problems,
> > the straced init is not protected from unwanted signals.
>
> Is this impossible/very hard to do cleanly? I understand that container's
> init becomes vulnerable to signals sent from root-owned processes in the
> container. If so, the impact of this issue should be quite limited, no?

Yes, probably we can ignore this.

> > Yes. First of all, tracehook_report_clone_complete() reports the wrong pid nr,
> > as it seen inside the init's namespace. This is easy to fix, but I doubt this
> > can help. IIRC strace doesn't use PTRACE_GETEVENTMSG at all, it looks at eax
> > after syscall.
> >
> > which patch?
>
> The patch below posted by Matt. AIUI, it fixes the
> tracehook_report_clone_complete() part, which results in an observable
> change in strace's behaviour (not that it makes strace work, though).

I guess it doesn't work because we need to fix strace, see "strace doesn't
use PTRACE_GETEVENTMSG" above.

> Anyway, are there any remaining issues on the kernel side or does strace
> have to be taught about pid namespaces?

At first glance, I don't see other problems, except sometimes the reported
pid is wrong (like in do_fork). 

> +               ptrace_pid_vnr = nr;
> +               if (unlikely(p->parent != p->real_parent)) {
> +                       rcu_read_lock();
> +                       ptrace_pid_vnr = task_pid_nr_ns(p, p->parent->nsproxy->pid_ns);

Yes, this is what I meant.

But we should not do this in do_fork().


But once again. This change fixes the value in "tracee->ptrace_message == newpid",
but a quick grep shows that strace-4.5.19 doesn't use PTRACE_GETEVENTMSG at all.

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/