All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: checksum error in metadata node - best way to move root fs to new drive?
Date: Mon, 15 Aug 2016 07:33:16 -0400	[thread overview]
Message-ID: <417d2c08-988d-c674-889a-ab9b564f7a3e@gmail.com> (raw)
In-Reply-To: <pan$c5e52$548e4e68$60e28d88$8f006dcd@cox.net>

On 2016-08-12 11:06, Duncan wrote:
> Austin S. Hemmelgarn posted on Fri, 12 Aug 2016 08:04:42 -0400 as
> excerpted:
>
>> On a file server?  No, I'd ensure proper physical security is
>> established and make sure it's properly secured against network based
>> attacks and then not worry about it.  Unless you have things you want to
>> hide from law enforcement or your government (which may or may not be
>> legal where you live) or can reasonably expect someone to steal the
>> system, you almost certainly don't actually need whole disk encryption.
>> There are two specific exceptions to this though:
>> 1. If your employer requires encryption on this system, that's their
>> call.
>> 2. Encrypted swap is a good thing regardless, because it prevents
>> security credentials from accidentally being written unencrypted to
>> persistent storage.
>
> In the US, medical records are pretty well protected under penalty of law
> (HIPPA, IIRC?).  Anyone storing medical records here would do well to
> have full filesystem encryption for that reason.
>
> Of course financial records are sensitive as well, or even just forum
> login information, and then there's the various industrial spies from
> various countries (China being the one most frequently named) that would
> pay good money for unencrypted devices from the right sources.
>
Medical and even financial records really fall under my first exception, 
but it's still no substitute for proper physical security.  As far as 
user account information, that depends on what your legal or PR 
department promised, but in many cases there, there's minimal 
improvement in security when using full disk encryption in place of just 
encrypting the database file used to store the information.

In either case though, it's still a better investment in terms of both 
time and money to properly secure the network and physical access to the 
hardware.  All that disk encryption protects is data at rest, and for a 
_server_ system, the data is almost always online, and therefore lack of 
protection of the system as a whole is usually more of a security issue 
in general than lack of protection for a single disk that's powered off.

  reply	other threads:[~2016-08-15 11:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11 20:23 checksum error in metadata node - best way to move root fs to new drive? Dave T
2016-08-12  4:13 ` Duncan
2016-08-12  8:14 ` Adam Borowski
2016-08-12 12:04 ` Austin S. Hemmelgarn
2016-08-12 15:06   ` Duncan
2016-08-15 11:33     ` Austin S. Hemmelgarn [this message]
2016-08-12 17:02   ` Chris Murphy
  -- strict thread matches above, loose matches on Subject: below --
2016-08-10  3:27 Dave T
2016-08-10  6:27 ` Duncan
2016-08-10 19:46   ` Austin S. Hemmelgarn
2016-08-10 21:21   ` Chris Murphy
2016-08-10 22:01     ` Dave T
2016-08-10 22:23       ` Chris Murphy
2016-08-10 22:52         ` Dave T
2016-08-11 14:12           ` Nicholas D Steeves
2016-08-11 14:45             ` Austin S. Hemmelgarn
2016-08-11 19:07             ` Duncan
2016-08-11 20:43               ` Chris Murphy
2016-08-12  3:11                 ` Duncan
2016-08-12  3:51                   ` Chris Murphy
2016-08-11 20:33             ` Chris Murphy
2016-08-11  7:18         ` Andrei Borzenkov
2016-08-11  4:50       ` Duncan
2016-08-11  5:06         ` Gareth Pye
2016-08-11  8:20           ` Duncan
2016-08-12 17:00     ` Patrik Lundquist
2016-08-10 21:15 ` Chris Murphy
2016-08-10 22:50   ` Dave T

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=417d2c08-988d-c674-889a-ab9b564f7a3e@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.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.