1 |
On 12/9/18 4:46 PM, Dale wrote: |
2 |
> Howdy, |
3 |
|
4 |
Hi, |
5 |
|
6 |
> As some may know, I'm making some changes and upgrades to my puter. |
7 |
> One thing I'm considering, encryption of a select directory/mount |
8 |
> point/file system. |
9 |
|
10 |
Please elaborate on a hypothetical setup that you would like. |
11 |
|
12 |
It might be worth starting with your current directory tree and calling |
13 |
out things you would like to see encrypted. |
14 |
|
15 |
> One thought I have, create a mount point named say "Encrypted" and put |
16 |
> anything I don't want widely seen or hacked in that directory. |
17 |
|
18 |
I understand why you are doing it. But I feel like having "Encrypted" |
19 |
in the name is like painting a target on it. |
20 |
|
21 |
> That would likely be on it's own partition or LVM setup. |
22 |
|
23 |
Depending on how you do things, it might be possible to have your |
24 |
encryption in the same LVM configuration. Or possibly a separate LVM |
25 |
configuration that has multiple logical volumes in it used by different |
26 |
mount points. |
27 |
|
28 |
> I would likely keep other things open. |
29 |
|
30 |
What is your reason for keeping other things open? |
31 |
|
32 |
Or, asked another way, why not use full disk encryption? Or at least |
33 |
encrypt the entire volume group? That way you don't need to worry about |
34 |
what is and is not encrypted. |
35 |
|
36 |
> Example, I may have /home on a partition of it's own but then have the |
37 |
> encrypted directory mounted on /home/dale/Desktop/Encrypted. I could |
38 |
> even let that be my Documents directory as well. I'm not to worried |
39 |
> about browser history etc. Plus, I could log into KDE and not have to |
40 |
> access the encrypted stuff if it is not needed. I don't need encryption |
41 |
> to check the weather. lol |
42 |
|
43 |
Since we're talking about LVM, please clarify if /home is it's own |
44 |
partition outside of LVM or if /home is it's own Logical Volume inside |
45 |
of LVM. It makes a difference. |
46 |
|
47 |
I strongly believe that you should not feel like you have to change your |
48 |
use case to use technology, encryption in this case. Rather the |
49 |
computer should change what it does so that what you have been doing and |
50 |
will continue to do is now encrypted. |
51 |
|
52 |
> How I do that isn't a big deal really. My main question is this. If I |
53 |
> go to the trouble of doing this, would I be *really* protected? |
54 |
|
55 |
It depends. |
56 |
|
57 |
> Is there a easily used encryption tool that isn't easily hacked? |
58 |
|
59 |
I believe so. |
60 |
|
61 |
> Also, when I login, I'd like to be able to type in password etc and it be |
62 |
> available from that point on, unless I do something to lock it up again. |
63 |
|
64 |
Are you implying that you want the encryption system to remember the |
65 |
password and unlock files as necessary? Or are you wanting to enter the |
66 |
password into something that uses it then and there to unlock things |
67 |
until you lock them back up? |
68 |
|
69 |
That's an important distinction. |
70 |
|
71 |
I have done a fair bit with LUKS, also LUKS and LVM. |
72 |
|
73 |
LUKS works by unlocking the encrypted block device and creating another |
74 |
virtual block device that is the unencrypted interface. It's trivial to |
75 |
put a file system on top of a LUKS device. |
76 |
|
77 |
So, my use case was to unlock a LUKS device and mount the file system |
78 |
that sits on top of it. Then anything on the system (with proper file |
79 |
system permissions) could access the files therein. Then when I was |
80 |
done, I would unmount the file system and lock (close) the encrypted device. |
81 |
|
82 |
I have also dabbled with eCryptFS, which applies encryption as an |
83 |
overlay. So when you access encrypted files through the overlay, they |
84 |
would be read from the unencrypted on the fly. Writing to the files to |
85 |
the unencrypted overlay would encrypt the files and write them to the |
86 |
underlay. |
87 |
|
88 |
Depending on the configuration, it's not possible to see the names of |
89 |
the files (or directories), much less actually read them from the |
90 |
encrypted underlay. |
91 |
|
92 |
> Reason, I may even put some of my videos on that. I watch TV from that |
93 |
> a lot. |
94 |
|
95 |
Okay. |
96 |
|
97 |
> Also, how hard would it be to do the same to my backups, since having |
98 |
> a open set of backups would render the encrypted part just available |
99 |
> elsewhere? |
100 |
|
101 |
Backups are another thing entirely. Things like LUKS will usually not |
102 |
translate to encryption with backups, because the backups see the |
103 |
mounted file system. Things like eCryptFS can work with encrypted |
104 |
backups, because they can work with the underlay file system that holds |
105 |
the encrypted files while ignoring the unencrypted overlay. |
106 |
|
107 |
There are also other possibilities of encrypting backups that are |
108 |
completely independent of the files that are being backed up. Sort of |
109 |
like a big encrypted tape drive or backing up files to a LUKS file |
110 |
system that is subsequently unmounted & locked. |
111 |
|
112 |
> While I get some of how encryption works, I don't keep up with it on a |
113 |
> weekly or even monthly basis. I just see the occasional articles on it. |
114 |
> I'd rather ask and get input from someone who uses and/or is more familiar |
115 |
> with this. In other words, if it is worthless and someone knows it is, |
116 |
> then let me know. If one tool is better/easier/etc than another, I'd |
117 |
> like to know that as well. |
118 |
|
119 |
I don't think encryption is worthless. I encrypt many of my emails and |
120 |
sign most others. I also have a LUKS encrypted file system on my VPS. |
121 |
|
122 |
It really depends on what your goal is and what you're trying to protect |
123 |
from / against. |
124 |
|
125 |
|
126 |
|
127 |
-- |
128 |
Grant. . . . |
129 |
unix || die |