| Message ID | 20230608101616.44152-1-msekleta@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 360c11e2258ce4269441a5ab6d43d0b202f4261b |
| Headers | show |
| Series | [v2,1/2] tty: tty_io: update timestamps on all device nodes | expand |
On Thu, Jun 08, 2023 at 12:16:15PM +0200, Michal Sekletar wrote: > User space applications watch for timestamp changes on character device > files in order to determine idle time of a given terminal session. For > example, "w" program uses this information to populate the IDLE column > of its output [1]. Similarly, systemd-logind has optional feature where > it uses atime of the tty character device to determine if there was > activity on the terminal associated with the logind's session object. If > there was no activity for a configured period of time then logind will > terminate such session [2]. > > Now, usually (e.g. bash running on the terminal) the use of the terminal > will update timestamps (atime and mtime) on the corresponding terminal > character device. However, if access to the terminal, e.g. /dev/pts/0, > is performed through magic character device /dev/tty then such access > obviously changes the state of the terminal, however timestamps on the > device that correspond to the terminal (/dev/pts/0) are not updated. > > This patch makes sure that we update timestamps on *all* character > devices that correspond to the given tty, because outside observers (w, > systemd-logind) are maybe checking these timestamps. Obviously, they can > not check timestamps on /dev/tty as that has per-process meaning. So how are you protecting this from being an information leak like we have had in the past where you could monitor how many characters were being sent to the tty through a proc file? Seems like now you can just monitor any tty node in the system and get the same information, while today you can only do it for the tty devices you have permissions for, right? thanks, greg k-h
On Thu, Jun 08, 2023 at 07:52:54PM +0200, Michal Sekletar wrote: > On Thu, Jun 8, 2023 at 1:51 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > So how are you protecting this from being an information leak like we > > have had in the past where you could monitor how many characters were > > being sent to the tty through a proc file? Seems like now you can just > > monitor any tty node in the system and get the same information, while > > today you can only do it for the tty devices you have permissions for, > > right? > > Hi Greg, > > I am not protecting against it in any way, but proposed changes are only > about timestamp updates which still happen in at least 8 seconds intervals > so exact timing of read/writes to tty can't be inferred. Frankly, I may > have misunderstood something. It would be great if you could mention a bit > more details about CVE you had in mind. Ah, I missed that this is in 8 second increments, nevermind then! thanks, greg k-h
On Tue, Jun 13, 2023 at 12:23:41PM +0200, Greg KH wrote: > On Thu, Jun 08, 2023 at 07:52:54PM +0200, Michal Sekletar wrote: > > On Thu, Jun 8, 2023 at 1:51 PM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > So how are you protecting this from being an information leak like we > > > have had in the past where you could monitor how many characters were > > > being sent to the tty through a proc file? Seems like now you can just > > > monitor any tty node in the system and get the same information, while > > > today you can only do it for the tty devices you have permissions for, > > > right? > > > > Hi Greg, > > > > I am not protecting against it in any way, but proposed changes are only > > about timestamp updates which still happen in at least 8 seconds intervals > > so exact timing of read/writes to tty can't be inferred. Frankly, I may > > have misunderstood something. It would be great if you could mention a bit > > more details about CVE you had in mind. > > Ah, I missed that this is in 8 second increments, nevermind then! > Note, I still can't take this series for the obvious reason in patch 2/2. Please fix. thanks, greg k-h
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index c84be40fb..a505d2c49 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -101,6 +101,7 @@ #include <linux/compat.h> #include <linux/uaccess.h> #include <linux/termios_internal.h> +#include <linux/fs.h> #include <linux/kbd_kern.h> #include <linux/vt_kern.h> @@ -811,18 +812,26 @@ void start_tty(struct tty_struct *tty) } EXPORT_SYMBOL(start_tty); -static void tty_update_time(struct timespec64 *time) +static void tty_update_time(struct tty_struct *tty, bool mtime) { time64_t sec = ktime_get_real_seconds(); + struct tty_file_private *priv; - /* - * We only care if the two values differ in anything other than the - * lower three bits (i.e every 8 seconds). If so, then we can update - * the time of the tty device, otherwise it could be construded as a - * security leak to let userspace know the exact timing of the tty. - */ - if ((sec ^ time->tv_sec) & ~7) - time->tv_sec = sec; + spin_lock(&tty->files_lock); + list_for_each_entry(priv, &tty->tty_files, list) { + struct inode *inode = file_inode(priv->file); + struct timespec64 *time = mtime ? &inode->i_mtime : &inode->i_atime; + + /* + * We only care if the two values differ in anything other than the + * lower three bits (i.e every 8 seconds). If so, then we can update + * the time of the tty device, otherwise it could be construded as a + * security leak to let userspace know the exact timing of the tty. + */ + if ((sec ^ time->tv_sec) & ~7) + time->tv_sec = sec; + } + spin_unlock(&tty->files_lock); } /* @@ -928,7 +937,7 @@ static ssize_t tty_read(struct kiocb *iocb, struct iov_iter *to) tty_ldisc_deref(ld); if (i > 0) - tty_update_time(&inode->i_atime); + tty_update_time(tty, false); return i; } @@ -1036,7 +1045,7 @@ static inline ssize_t do_tty_write( cond_resched(); } if (written) { - tty_update_time(&file_inode(file)->i_mtime); + tty_update_time(tty, true); ret = written; } out:
User space applications watch for timestamp changes on character device files in order to determine idle time of a given terminal session. For example, "w" program uses this information to populate the IDLE column of its output [1]. Similarly, systemd-logind has optional feature where it uses atime of the tty character device to determine if there was activity on the terminal associated with the logind's session object. If there was no activity for a configured period of time then logind will terminate such session [2]. Now, usually (e.g. bash running on the terminal) the use of the terminal will update timestamps (atime and mtime) on the corresponding terminal character device. However, if access to the terminal, e.g. /dev/pts/0, is performed through magic character device /dev/tty then such access obviously changes the state of the terminal, however timestamps on the device that correspond to the terminal (/dev/pts/0) are not updated. This patch makes sure that we update timestamps on *all* character devices that correspond to the given tty, because outside observers (w, systemd-logind) are maybe checking these timestamps. Obviously, they can not check timestamps on /dev/tty as that has per-process meaning. [1] https://gitlab.com/procps-ng/procps/-/blob/v4.0.0/w.c#L286 [2] https://github.com/systemd/systemd/blob/v252/NEWS#L477 Signed-off-by: Michal Sekletar <msekleta@redhat.com> --- v1 -> v2: Minor style tweaks based on code review comments drivers/tty/tty_io.c | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-)