From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Year 2038 time set problem
Date: Mon, 5 Mar 2018 07:00:37 +0100 [thread overview]
Message-ID: <20180305060037.GC6670@kroah.com> (raw)
In-Reply-To: <43caf772-3de0-6823-7a31-a855ac576a42@mrbrklyn.com>
On Sun, Mar 04, 2018 at 10:14:58PM -0500, Ruben Safir wrote:
> Advice? Who am I to give advice? On the face of it, I would say they
> need to harden the kernel base release. But I am not qualified to give
> anyone advice. If a kernel can't be reasonably secure in a 2 year
> period, as a consumer I can only be unhappy about it and a bit dismayed.
Be dismayed, the state of computer security is not there yet, sorry, and
it's doubtful that it ever will be (although it keeps getting better...)
But seriously, if you have a system that is exposed to the world, you
have to change it all the time as the world changes. You don't live in
a bubble of a stable ecosystem, no one does.
Ok, yes, there are some systems that do. Take for example two of my
most favorite examples of the use of Linux:
- ballast stabilizer for super-mega-yachts
- automatic cow milking machines
The first one does not interact with the world in a manner that it needs
to be updated regularly, if ever, as communication from it to the kernel
comes in through a known "good" channel (i.e. the on-board ship network
which had better be firewalled from the world...) Same for the second
one.
Both of them interact with the physical world very directly (some might
say more directly than your laptop or phone), but both do not interact
with the digital world much, if at all. And that's the key here.
Just keep your systems updated, it's really simple. If you can't do
that, then prepare to have those systems be full of known security
issues very very quickly.
As someone said at a conference recently when they asked the audience
about the longest uptime for any of the attendees systems (which turned
out to be about 5 years.), "How many security issues were those systems
vulnerable to over that period of time? All of them."
good luck!
greg k-h
next prev parent reply other threads:[~2018-03-05 6:00 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 2:35 Year 2038 time set problem Alex Arvelaez
2018-03-05 3:14 ` Ruben Safir
2018-03-05 6:00 ` Greg KH [this message]
2018-03-05 6:15 ` Ruben Safir
2018-03-05 6:26 ` Greg KH
2018-03-05 19:52 ` Ruben Safir
2018-03-05 19:54 ` Ruben Safir
2018-03-05 15:43 ` Jeffrey Walton
2018-03-05 11:29 ` Bernd Petrovitsch
2018-03-05 12:20 ` Ruben Safir
2018-03-05 12:43 ` valdis.kletnieks at vt.edu
2018-03-05 12:54 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2018-03-05 15:35 Alex Arvelaez
2018-03-05 16:49 ` Greg KH
2018-03-05 4:07 Alex Arvelaez
2018-03-05 4:16 ` Ruben Safir
2018-03-05 5:53 ` Greg KH
2018-03-05 6:04 ` Ruben Safir
2018-03-04 20:47 Alex Arvelaez
2018-03-04 22:24 ` valdis.kletnieks at vt.edu
2018-03-05 2:21 ` Ruben Safir
2018-03-05 4:15 ` valdis.kletnieks at vt.edu
2018-03-05 4:50 ` Ruben Safir
2018-03-05 8:50 ` valdis.kletnieks at vt.edu
2018-03-05 12:15 ` Ruben Safir
2018-03-05 12:31 ` Ruben Safir
2018-03-05 12:34 ` Ruben Safir
2018-03-05 12:57 ` Darin Avery
2018-03-05 4:57 ` Ruben Safir
2018-03-05 5:03 ` Ruben Safir
2018-03-04 6:59 tali.perry at nuvoton.com
2018-03-04 18:31 ` valdis.kletnieks at vt.edu
2018-03-04 20:20 ` Ruben Safir
2018-03-04 20:54 ` Greg KH
2018-03-04 20:54 ` Greg KH
2018-03-04 22:25 ` valdis.kletnieks at vt.edu
2018-03-05 5:54 ` Greg KH
2018-02-23 9:43 techi eth
2018-02-23 13:18 ` valdis.kletnieks at vt.edu
2018-02-24 13:59 ` techi eth
2018-02-24 15:50 ` Greg KH
2018-02-26 13:15 ` Piotr Figiel
2018-02-26 14:16 ` Greg KH
2018-02-26 21:19 ` Dave Stevens
2018-02-27 9:22 ` Greg KH
2018-02-26 15:21 ` valdis.kletnieks at vt.edu
2018-02-26 15:36 ` Piotr Figiel
2018-03-01 9:19 ` techi eth
2018-03-01 12:04 ` Greg KH
2018-02-25 5:52 ` valdis.kletnieks at vt.edu
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=20180305060037.GC6670@kroah.com \
--to=greg@kroah.com \
--cc=kernelnewbies@lists.kernelnewbies.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).