On Mon, Oct 03, 2016 at 04:48:56PM +0100, Pádraig Brady wrote: > On 03/10/16 16:04, Karel Zak wrote: > > On Thu, Sep 29, 2016 at 04:40:15PM +0200, Karel Zak wrote: > >> On Tue, Mar 08, 2016 at 05:02:44PM +0100, Stanislav Brabec wrote: > >>> On Mar 7, 2016 at 14:13 Karel Zak wrote: > >>>> On Wed, Mar 02, 2016 at 08:35:54PM +0100, Stanislav Brabec wrote: > >>>>> There are some controversial things with the straightforward fix: > >>>>> > >>>>> setsid() prevents TIOCSTI attack described in the report (easy to > >>>>> reproduce), but it has side effects: It disconnects the task from job > >>>>> control. With setsid(), ^Z cannot be used for sending the application > >>>>> to background any more (easy to reproduce by calling setsid() > >>>>> unconditionally in the same place). > >>>>> > >>>>> su-common.c now calls setsid() only if new session is requested. > >>>> > >>>> Yes, it's pretty stupid situation. > >>>> > >>>> We have exactly specified setsid() use-cases and now TIOCSTI ioctl > >>>> forces us to modify the things (and maybe introduce regressions), > >>>> because the crazy ioctl is not possible to disable by any another > >>>> way... > >>> > >>> I would like to see a kernel support for selective disabling of TIOCSTI > >>> without side effects like setsid() has. > >>> > >>> setsid() fallback would be used for kernels that don't support it. > >>> > >>> I am not sure, how complicated would be adding of such feature to the > >>> kernel. > >> > >> I have applied patch based on libseccomp syscall filter: > >> > >> https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2 > >> > >> it works as expected, but IMHO it's workaround for our stupid kernel... > > > > Reverted. We need something else, something better. > > > > I'll try to play su/runuser pty container to fix this issue, it seems > > sudo also support this use-case by use_pty flag. > > I was wondering would the secomp solution be (more) appropriate for runcon(1), > since that's selinux specific? For me seccomp is ugly solution, because it does not resolve the core of the issue. It's extra barrier and nothing more. It's the same like ignore security bugs in network daemons, because you have iptables... Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
