From: Jiri Slaby <jslaby@suse.cz>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Raymond Jennings <shentino@gmail.com>,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
john_paul.perry@alcatel-lucent.com, stable@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/1] tty: fix up atime/mtime mess, take four
Date: Wed, 11 Mar 2015 09:09:38 +0100 [thread overview]
Message-ID: <54FFF842.1010504@suse.cz> (raw)
In-Reply-To: <20150310224100.48b1adf6@lxorguk.ukuu.org.uk>
On 03/10/2015, 11:41 PM, One Thousand Gnomes wrote:
> On Mon, 09 Mar 2015 11:01:12 +0100
> Jiri Slaby <jslaby@suse.cz> wrote:
>
>> On 03/06/2015, 02:16 PM, Raymond Jennings wrote:
>>> On Fri, 2015-02-27 at 18:40 +0100, Jiri Slaby wrote:
>>>> So check the absolute difference of times and if it large than "8
>>>> seconds or so", always update the time. That means we will update
>>>> immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
>>>> check, but it was always that way.
>>>
>>> If I may ask, what is supposed to happen normally when you write to a
>>> tty device? I always thought the tty device was treated just like a
>>> normal file wrt. timestamps.
>>>
>>> Now I see a patch for 8 seconds something.
>>
>> Yes, because you do not want to be given any clue when users are typing
>> passwords. You could intercept the length of the password from the
>> pauses between key strokes (tty timestamps).
>
> On any vaguely idle box I can do the same and in fact probably far
> better by measuring latencies via rdtsc and continually forcing a dword
> out of cache in a tight loop.
I don't know, I have to study and try this first, before I can take any
action.
> It's a pointless change, second granularities are not useful for most
> kinds of attack of this nature.
Yes, that was actually the whole point of the exercise: move from
current_fs_time() (one nanosecond granularity (for devtmpfs)) to
get_seconds() & 7 (8 seconds).
thanks,
--
js
suse labs
prev parent reply other threads:[~2015-03-11 8:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 17:40 [PATCH 1/1] tty: fix up atime/mtime mess, take four Jiri Slaby
2015-02-27 18:33 ` Linus Torvalds
2015-02-27 19:23 ` Greg KH
2015-02-27 21:27 ` Perry, John Paul G (John Paul)** CTR **
2015-03-06 13:16 ` Raymond Jennings
2015-03-09 10:01 ` Jiri Slaby
2015-03-10 22:41 ` One Thousand Gnomes
2015-03-11 8:09 ` Jiri Slaby [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FFF842.1010504@suse.cz \
--to=jslaby@suse.cz \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=john_paul.perry@alcatel-lucent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shentino@gmail.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.