linux-kernel - Re: [PATCH 1/2] serial: core: Don't drop DTR if system console

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

Message-ID: <5396FA75.8020400@hurleysoftware.com>
Date:	Tue, 10 Jun 2014 08:30:45 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	Valerio Vanni <valerio.vanni@...ind.it>
Subject: Re: [PATCH 1/2] serial: core: Don't drop DTR if system console

On 06/10/2014 07:01 AM, One Thousand Gnomes wrote:
>> This patch only affects the line state if the last tty reference is closed
>> or the tty is hung up by software (like on controlling process exit).
>> In this case, any login session is already dying, and it would not be possible
>> to hijack a live session. A successful re-login is still required.
>
> It breaks the other direction - yes sorry.
>
>> Notwithstanding what I wrote above, this patch does change behavior
>> with remote consoles, which may be unacceptable.
>
>> For example, if the remote user logs out, the current behavior hangs up
>> the modem (if HUPCL), whereas the patch behavior just presents a new
>> login prompt.
>
> which means the modem will probably no longer answer calls.

I would expect the vast majority of modems to be configured to hang-up
after carrier loss (when the remote user hangs up).

I think the more significant impact is that killing the login process
(by the sysadmin) wouldn't disconnect a malicious user (but would still
force the re-login). I see this as more nuisance value than any
realistic DoS.

>> So yeah, I agree; this patch should be dropped.
>
> Possibly we should also fix this the other way in tty_port_shutdown,
> which does wrongly skip dtr/rts handling of consoles.
>
> As far as I can see providing HUPCL is clear the desired console
> behaviour for most situations with a remote console link is obtained.

I agree that serial core and tty port should handle the console
identically, so if the serial core defaults are the expected behavior,
then, yes, tty_port_shutdown() should not skip dropping dtr/rts.

However, a console on USB tty is much more likely to be local, rather
than remote, so changing dtr/rts handling could impact these setups.

Since the termios c_cflag is inherited from the console, what about adding
new flow control flag decodes to uart_set_options(); eg.,
  'r'     =  CRTSCTS |  HUPCL  /* existing */
  'R'     =  CRTSCTS | !HUPCL
  default = !CRTSCTS |  HUPCL
  'd'     = !CRTSCTS | !HUPCL
?

Regards,
Peter Hurley

--
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/