1 |
Grant Taylor wrote: |
2 |
> On 12/9/18 4:46 PM, Dale wrote: |
3 |
>> Howdy, |
4 |
> |
5 |
> Hi, |
6 |
> |
7 |
>> As some may know, I'm making some changes and upgrades to my puter. |
8 |
>> One thing I'm considering, encryption of a select directory/mount |
9 |
>> point/file system. |
10 |
> |
11 |
> Please elaborate on a hypothetical setup that you would like. |
12 |
> |
13 |
> It might be worth starting with your current directory tree and |
14 |
> calling out things you would like to see encrypted. |
15 |
|
16 |
Well, I don't really think I need to encrypt the entire /home mount |
17 |
point. To me, that would be overkill. Of course, that may be easier. |
18 |
I would like to have certain directories that I can store things in that |
19 |
is encrypted. For example, I have some financial and medical stuff that |
20 |
I wouldn't want just anyone to get a hold of if for example my puter was |
21 |
stolen or hacked. |
22 |
|
23 |
|
24 |
> |
25 |
>> One thought I have, create a mount point named say "Encrypted" and |
26 |
>> put anything I don't want widely seen or hacked in that directory. |
27 |
> |
28 |
> I understand why you are doing it. But I feel like having "Encrypted" |
29 |
> in the name is like painting a target on it. |
30 |
|
31 |
True. I used that as a example mostly. |
32 |
|
33 |
> |
34 |
>> That would likely be on it's own partition or LVM setup. |
35 |
> |
36 |
> Depending on how you do things, it might be possible to have your |
37 |
> encryption in the same LVM configuration. Or possibly a separate LVM |
38 |
> configuration that has multiple logical volumes in it used by |
39 |
> different mount points. |
40 |
> |
41 |
>> I would likely keep other things open. |
42 |
> |
43 |
> What is your reason for keeping other things open? |
44 |
> |
45 |
> Or, asked another way, why not use full disk encryption? Or at least |
46 |
> encrypt the entire volume group? That way you don't need to worry |
47 |
> about what is and is not encrypted. |
48 |
|
49 |
|
50 |
Well, I thought it may be simpler. Since I've never tried encryption |
51 |
before, I don't know first hand how it works or what it takes to use the |
52 |
files. I've read where people password protect their mobo, bootloader |
53 |
and their entire storage system. Basically, without the proper |
54 |
passwords, you can't boot the system or access it from another system |
55 |
either. That is overkill for me for sure. If anything, I'm on the |
56 |
other end of the scale. I just want a directory, which could be a mount |
57 |
point, that is encrypted. Knowing what tool is best may help be figure |
58 |
out whether it is a mount point, a regular directory or what. I've read |
59 |
where some whole file systems can be encrypted or it can be done on a |
60 |
directory level. I'm not sure what works the best tho. |
61 |
|
62 |
|
63 |
> |
64 |
>> Example, I may have /home on a partition of it's own but then have |
65 |
>> the encrypted directory mounted on /home/dale/Desktop/Encrypted. I |
66 |
>> could even let that be my Documents directory as well. I'm not to |
67 |
>> worried about browser history etc. Plus, I could log into KDE and |
68 |
>> not have to access the encrypted stuff if it is not needed. I don't |
69 |
>> need encryption to check the weather. lol |
70 |
> |
71 |
> Since we're talking about LVM, please clarify if /home is it's own |
72 |
> partition outside of LVM or if /home is it's own Logical Volume inside |
73 |
> of LVM. It makes a difference. |
74 |
|
75 |
|
76 |
I have /boot and / on their own partition. Everything else is on LVM. |
77 |
I did that because it is easier to boot. While I have a init thingy, |
78 |
it's just enough to mount /usr. That's it. I don't like having a init |
79 |
thingy at all tho. I've had trouble with them in the past that left me |
80 |
with a unbootable system and no way to fix it since I don't really get |
81 |
them. It's one of those things that hasn't hit me yet, even after years |
82 |
of it. |
83 |
|
84 |
> |
85 |
> I strongly believe that you should not feel like you have to change |
86 |
> your use case to use technology, encryption in this case. Rather the |
87 |
> computer should change what it does so that what you have been doing |
88 |
> and will continue to do is now encrypted. |
89 |
|
90 |
True but I don't want it to get in my way to much. I'd like to be able |
91 |
to login into KDE without worrying if the password works or not. Once |
92 |
inside KDE and I need to access something encrypted, then I can deal |
93 |
with the password. |
94 |
|
95 |
|
96 |
> |
97 |
>> How I do that isn't a big deal really. My main question is this. If |
98 |
>> I go to the trouble of doing this, would I be *really* protected? |
99 |
> |
100 |
> It depends. |
101 |
> |
102 |
>> Is there a easily used encryption tool that isn't easily hacked? |
103 |
> |
104 |
> I believe so. |
105 |
> |
106 |
>> Also, when I login, I'd like to be able to type in password etc and |
107 |
>> it be available from that point on, unless I do something to lock it |
108 |
>> up again. |
109 |
> |
110 |
> Are you implying that you want the encryption system to remember the |
111 |
> password and unlock files as necessary? Or are you wanting to enter |
112 |
> the password into something that uses it then and there to unlock |
113 |
> things until you lock them back up? |
114 |
> |
115 |
> That's an important distinction. |
116 |
|
117 |
Let's say I encrypt the directory or mount point that contains both |
118 |
video and some financial/medical info in it. When I click to access it, |
119 |
it asks for a password. Once it does that, I'd like to be able to use |
120 |
that until I either logout of KDE or I tell it to lock it back up. That |
121 |
way I can watch TV for hours without interruption to type in a |
122 |
password. However, if I need to run to town, I can logout of the |
123 |
encrypted part and leave knowing it's secure. Make sense?? |
124 |
|
125 |
|
126 |
> |
127 |
> I have done a fair bit with LUKS, also LUKS and LVM. |
128 |
> |
129 |
> LUKS works by unlocking the encrypted block device and creating |
130 |
> another virtual block device that is the unencrypted interface. It's |
131 |
> trivial to put a file system on top of a LUKS device. |
132 |
> |
133 |
> So, my use case was to unlock a LUKS device and mount the file system |
134 |
> that sits on top of it. Then anything on the system (with proper file |
135 |
> system permissions) could access the files therein. Then when I was |
136 |
> done, I would unmount the file system and lock (close) the encrypted |
137 |
> device. |
138 |
> |
139 |
> I have also dabbled with eCryptFS, which applies encryption as an |
140 |
> overlay. So when you access encrypted files through the overlay, they |
141 |
> would be read from the unencrypted on the fly. Writing to the files |
142 |
> to the unencrypted overlay would encrypt the files and write them to |
143 |
> the underlay. |
144 |
> |
145 |
> Depending on the configuration, it's not possible to see the names of |
146 |
> the files (or directories), much less actually read them from the |
147 |
> encrypted underlay. |
148 |
|
149 |
|
150 |
Interesting. I've read that twice. May read that a couple more times. |
151 |
Letting that soak in a bit. That sounds like something I could use |
152 |
tho. It seems it would do just what I want. Question. Let's say I |
153 |
encrypt /home entirely as a partition of LVM group. When I login to KDE |
154 |
for example, how does that work? I already have to type in a password |
155 |
to login into KDE. Would that work for both or would it ask for a |
156 |
second password? Or would it ask even earlier than that? |
157 |
|
158 |
I may get on youtube and see if I can find some videos on this so I can |
159 |
see it actually working. Maybe find a couple different setups. I'm |
160 |
sure someone has done at least one. lol |
161 |
|
162 |
|
163 |
> |
164 |
>> Reason, I may even put some of my videos on that. I watch TV from |
165 |
>> that a lot. |
166 |
> |
167 |
> Okay. |
168 |
> |
169 |
>> Also, how hard would it be to do the same to my backups, since having |
170 |
>> a open set of backups would render the encrypted part just available |
171 |
>> elsewhere? |
172 |
> |
173 |
> Backups are another thing entirely. Things like LUKS will usually not |
174 |
> translate to encryption with backups, because the backups see the |
175 |
> mounted file system. Things like eCryptFS can work with encrypted |
176 |
> backups, because they can work with the underlay file system that |
177 |
> holds the encrypted files while ignoring the unencrypted overlay. |
178 |
> |
179 |
> There are also other possibilities of encrypting backups that are |
180 |
> completely independent of the files that are being backed up. Sort of |
181 |
> like a big encrypted tape drive or backing up files to a LUKS file |
182 |
> system that is subsequently unmounted & locked. |
183 |
> |
184 |
|
185 |
Keep in mind, my backups are a simple rsync to a external USB drive. I |
186 |
don't use fancy software. Usually I backup my videos and such once a |
187 |
day depending on what I've done that day. I may switch to a external |
188 |
SATA drive at some point which may make it even easier. Right now I use |
189 |
a script, if it even deserves to be called that, to do the backups. |
190 |
|
191 |
|
192 |
>> While I get some of how encryption works, I don't keep up with it on |
193 |
>> a weekly or even monthly basis. I just see the occasional articles |
194 |
>> on it. I'd rather ask and get input from someone who uses and/or is |
195 |
>> more familiar with this. In other words, if it is worthless and |
196 |
>> someone knows it is, then let me know. If one tool is |
197 |
>> better/easier/etc than another, I'd like to know that as well. |
198 |
> |
199 |
> I don't think encryption is worthless. I encrypt many of my emails |
200 |
> and sign most others. I also have a LUKS encrypted file system on my |
201 |
> VPS. |
202 |
> |
203 |
> It really depends on what your goal is and what you're trying to |
204 |
> protect from / against |
205 |
|
206 |
Mostly a common crook who just may have some puter skills. Wouldn't |
207 |
mind grinning at the likes of a NSA twerp with far to much nose. :-D |
208 |
|
209 |
Dale |
210 |
|
211 |
:-) :-) |