linux-kernel - PROBLEM: Namespaced PID 1 ignoring SIG

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]

Date:	Fri, 20 Feb 2015 15:39:10 -0600
From:	vcaputo@...generation.com
To:	linux-kernel@...r.kernel.org
Cc:	vito.caputo@...eos.com
Subject: PROBLEM: Namespaced PID 1 ignoring SIG_DFL signals

Hello lkml,

According to the comment:

> * Note that if global/container-init sees a sig_kernel_only()
> * signal here, the signal must have been generated internally
> * or must have come from an ancestor namespace. In either
> * case, the signal cannot be dropped.

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/signal.c?id=refs/tags/v3.19#n2290]

Killing a container's PID1 shouldn't be ignored when the default-handled
signal originated from an ancestor namespace or internally.

When executing via `unshare --fork --pid` a trivial "for(;;) pause();" C
program that installs no signal handlers,  then sending SIGTERM to the
namespaced process from the parent namespace, the pause() syscall just
returns EINTR and loops rather than the process terminating.

This does not seem consistent with the intention documented in the code.

Additionally, if using a more comprehensive executor than unshare which
allocates a pty for the child and sets the pty slave as the controlling
tty pre-exec, running the same test the signals delivered by the pty
slave are identically ignored.  It's unclear to me whether signals
originating from the process' own controlling tty would be classified as
"generated internally".

IMHO both of these scenarios should result in the signal being handled,
but if that's inappropriate I'd appreciate any clarification.

Please CC me with any responses, as I'm not subscribed.

Thanks,
Vito Caputo
--
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/