1 |
On 8/28/20 6:10 PM, Michael Orlitzky wrote: |
2 |
> I think I see where we're diverging: I'm assuming that the employees of |
3 |
> the VPS provider can hop onto any running system with root privileges. |
4 |
|
5 |
Perhaps I'm woefully ignorant, but my current working understanding is |
6 |
that no virtual machine hypervisor solution provides a way for someone |
7 |
at the hypervisor level to access a guest VM as if they were root. They |
8 |
still need to connect to a terminal (be it console or serial or ssh or |
9 |
other), log in (with credentials that they should not have) and access |
10 |
things that way. |
11 |
|
12 |
I see little difference in the full (fat) VM compared to a stand alone |
13 |
server. Safe for the fact that there are ways to cross access memory. |
14 |
Though I think those types of things are decidedly atypical. |
15 |
|
16 |
My mental security model probably completely fails for containers. |
17 |
|
18 |
> I suppose you can make that pretty annoying to do. If you're willing to |
19 |
> encrypt everything, then you can even put /boot on the encrypted disk, |
20 |
> unlocking it in (say) grub. The VPS provider can still replace grub |
21 |
> with something that faxes them your password, but it's not totally |
22 |
> trivial. (How are you accessing the console at boot time? Is it using |
23 |
> software from the VPS provider? It's turtles all the way to hell.) |
24 |
|
25 |
I'm actually not encrypting the full VM. I have an encrypted disk. The |
26 |
VM boots like normal, I log in, unlock the encrypted disk, mount it, and |
27 |
start services. |
28 |
|
29 |
So, I feel like I've done the things that I reasonably can do to protect |
30 |
my email. |
31 |
|
32 |
Or said another way, I'm not sure what else I could do that would not |
33 |
also apply to a co-lo server. |
34 |
|
35 |
My VPS provider does offer the ability to access a console so I could |
36 |
use full encrypted system. |
37 |
|
38 |
|
39 |
|
40 |
-- |
41 |
Grant. . . . |
42 |
unix || die |