| View previous topic :: View next topic |
| Author |
Message |
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
 Posted: Sat Dec 30, 2017 11:00 pm Post subject: |
 |
|
[removed to hide my lack of observation]
Last edited by keet on Sun Dec 31, 2017 12:01 am; edited 1 time in total |
|
| Back to top |
|
 |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3134
|
| Posted: Sat Dec 30, 2017 11:46 pm Post subject: |
|
|
| Quote: | | How can vg01-root have more used space than its total size? |
It doesn't. T is a bigger unit multiplier than G. |
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Sun Dec 31, 2017 12:02 am Post subject: |
|
|
| Ok, goodness, I wish I could think of an excuse for that. |
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Sun Dec 31, 2017 3:53 am Post subject: |
|
|
| Everything seems to be working. I am not sure at all how I made the bridged networking work. I wanted for each guest to get an address on my local network from my home router, and that seems to be working. The V.M.s seem to be working... now the next thing to try is V.G.A. passthrough. If I can make that work, that should be all that I hoped for. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Sun Dec 31, 2017 6:17 am Post subject: |
|
|
| keet wrote: | 1clue, it sounds to me like you are discouraging full-disk encryption. However, it doesn't seem that much more difficult simply to encrypt the whole thing. If I encrypt selectively, it just becomes more complicated. Full-disk encryption (apart from the bootloader) has been easy and reliable in my experience; I've never had any problems with it.
|
First, let me remind everyone that I am in no way an expert on this.
Second, yes I'm discouraging full-disk encryption. Let's say you have full-disk encryption. Including the OS and whatever else. It pretty much means that the entire system can read the disk right? So any malware or intrusion running under your account is able to read and write data in the clear? I'm not sure on this, but from what I understand the system behaves as though it's not encrypted from a user's standpoint right?
What I'm getting at is, if somebody can get into your running system somehow then they have full access to everything.
| Quote: |
As szatox said, I'm going to keep the decryption key separate (written on a flash drive, or as a password...).
The part that complicates it for me is that I have multiple disks that I want to encrypt as one container. Making them into a RAID array seems to accomplish this as well as giving me some redundancy/protection against disk failure (which is certainly not to say that I'm going to eschew backups; I'll definitely still back it up periodically).
|
So if you encrypt a volume group or a raid mdX device, what happens when one drive fails? In my experience when you encrypt a thing, it's pretty much all-or-nothing getting it back. Surely there must be some exception for a block device, but what are the details there?
As well, what happens when you have device failure and you need to do diagnostics on another system?
Speaking as somebody who has been in data storage/IT/backups/software development since the late 80s, I've had my share of system failures. The early ones involved catastrophic loss of data because I hadn't thought it through and above all, hadn't tested my backups for their restorability. And hadn't maintained my backup plan in terms of what data needed to be backed up, and hadn't fully understood what scenarios my backup plan covered and what it didn't.
RAID pretty much covers one or two scenarios. It covers drive failure, leaving the system usable while somebody digs a spare out of the closet and puts it back in. It does not cover stupid users deleting data, or programs crashing and writing garbage to the file, or intrusion or fire or flood or theft or malware, or any of the other dozen or so reasons I can think of right now but am too lazy to type. RAID is in no way a backup. RSYNC is not a backup. Both of these can be parts of your backup or parts of your uptime strategy, but frankly I never use RSYNC and extremely rarely use RAID of any sort.
If you're talking about a server farm, then encryption falls in the same category as RAID: Really useful if you really need it, but a really bad placebo for people who didn't think it through. I can see a laptop (your scenario) benefiting from encryption so long as your key is not stored with the laptop, especially if the system won't boot without some sort of BIOS password or key.
| Quote: |
Thus, what I'm doing at the moment is a RAID 5 array (/dev/md0) using all three drives, which I'm encrypting using LUKS (/dev/mapper/encryptedmd0), and then LVM inside that encrypted container. That way (almost) everything is encrypted as one container and I have the benefits of RAID 5 and LVM. |
I'm not trying to be a pain in the ass here. If we were talking about something I'm truly familiar with like backups, then I could be extremely specific and pertinent. As it is I'm doing my best to make you examine your strategy and make sure you're not painting yourself into a corner. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3134
|
| Posted: Sun Dec 31, 2017 2:49 pm Post subject: |
|
|
The hard part to get right in case of encrypted server is.... Password management. It's surprisingly easy to lock the key in your safe. And as soon as you have a handful of passwords, you do need some sort of password management. Things are getting even more tricky when several people need some way to initiate decryption (AKA keep their passwords synchronised)
| Quote: | | So if you encrypt a volume group or a raid mdX device, what happens when one drive fails? In my experience when you encrypt a thing, it's pretty much all-or-nothing getting it back. Surely there must be some exception for a block device, but what are the details there? |
When 1 drive fails in raid5, MD will replace it with a hot-spare and start recovery. Filesystem is not affected in any way beside taking a (possibly significant) performance hit.
Things are getting more tricky when you lose 2 devices. Do you have a backup? Restore is likely to be much cheaper than any other option at this point. If you don't, you probably didn't take care to align encryption blocks with raid strips, so you lose everything. However, if you did (accidentally) align it properly, (and you do have the actual encryption key) you are only slightly worse than without encryption at all. It does not mean your situation is any good though: you have already lost some data.
| Quote: | | It does not cover stupid users deleting data, or programs crashing and writing garbage to the file, or intrusion or fire or flood or theft or malware, or any of the other dozen or so reasons I can think of right now but am too lazy to type. RAID is in no way a backup. RSYNC is not a backup. |
Yes, RAID and backup protect you from different sorts of problems.
What's wrong with rsync? I find its copy-changes/hardlink-the-rest feature pretty neat, even though (obviously) there are some ways to achieve higher compression ratios than file-level deduplication can provide. |
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Sun Dec 31, 2017 5:29 pm Post subject: |
|
|
| Password management is definitely tricky. I once forgot the password for one of my encrypted hard drives -- it was in a server that hadn't been rebooted in 200 days, and I thought that I knew the password, so I rebooted it. Oops, I couldn't decrypt the drive... fortunately, I knew most of the password, so I used hashcat to find the rest that I didn't know. However, I wouldn't want to need to do that again. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21624
|
| Posted: Sun Dec 31, 2017 6:39 pm Post subject: |
|
|
| 1clue wrote: | Second, yes I'm discouraging full-disk encryption. Let's say you have full-disk encryption. Including the OS and whatever else. It pretty much means that the entire system can read the disk right? So any malware or intrusion running under your account is able to read and write data in the clear? I'm not sure on this, but from what I understand the system behaves as though it's not encrypted from a user's standpoint right?
What I'm getting at is, if somebody can get into your running system somehow then they have full access to everything. |
Correct. Full disk encryption is a countermeasure for adversaries who have physical access to the hardware (whether through theft, inadequate physical security, etc.), but any code run in the live system can be assumed to be bound by the security model of the live system. So if you assume nobody can break into root, and only root has permission to read the files, then the files are secure even if the attacker can run code as you. If the files are readable to your personal account, or if the attacker can break into root, then the attacker can read anything that is mounted. (A rare exception applies in the case of things like eCryptFS, where a logged out user has his/her home directory unmounted and inaccessible, since that provides transparent-to-user encryption while allowing the filesystem to be unmounted when not in use. Traditional full-disk-encryption is to leave the encrypted volumes mounted until the system shuts down.)
Full disk encryption is most helpful when the attacker model is assumed to be that the attacker is only permitted to power down your system, then boot it with his choice of media, but has no ability to run any code on the live system. | 1clue wrote: | So if you encrypt a volume group or a raid mdX device, what happens when one drive fails? In my experience when you encrypt a thing, it's pretty much all-or-nothing getting it back. Surely there must be some exception for a block device, but what are the details there?
As well, what happens when you have device failure and you need to do diagnostics on another system? |
At a minimum, you need access to the key material, which is stored in the LUKS header (and can be exported separately for backups, but must be protected carefully if exported). As you say, it's relatively easy to get into a situation that you can access the ciphertext, but you cannot get the key from the LUKS header (main copy unreadable/trashed, and no backups available), at which point your data is lost.
I would advocate that the LUKS header be exported along with the regular system backup. Both must then be secured at least as well as the encrypted disk, else an adversary can opt to restore from backup more readily than break into your encrypted disk. Depending on the threat model, it may be possible to secure the backup by storing it unencrypted in a physically secure location (e.g. fire safe) rather than encrypted in a physically insecure location (shelf in another room/building). As a counterpoint to security, since backups are rarely used, the security for the backup must be something that the authorized user can satisfy without much familiarity. keet's example of a 200-day uptime causing him to forget part of the password is a real danger with encrypted backups, too. |
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Mon Jan 01, 2018 11:52 pm Post subject: |
|
|
To return to the main topic, I have a Windows 10 virtual machine with V.G.A. passthrough working successfully. Just in case anyone is curious, this is the configuration:
| Code: | qemu-system-x86_64 -enable-kvm \
-cpu host,hv_vendor_id=Nvidia43FIX,kvm=off -smp 4 \
-drive file=Windows10.img,if=virtio \
-boot d -drive file=Win10_1709_English_x64.iso,media=cdrom \
-drive file=virtio-win.iso,media=cdrom \
-m 4G \
-M q35 \
-device ich9-usb-ehci1,id=usb \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,multifunction=on \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4 \
-soundhw hda \
-netdev bridge,id=mynet1 -device virtio-net-pci,netdev=mynet1,id=nic2,mac=52:54:00:12:34:58 \
-name "Windows 10" \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-bios /usr/share/qemu/bios.bin -vga none \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=01:00.1,bus=pcie.0 \
-usb -usbdevice host:04d9:2013 \
-vga none -nographic
$@ |
Unfortunately, I need to run it as root for the passthrough to work, which I would much rather avoid. There must be a way to give my user access to /dev/vfio and the related files, but I'm not sure what it is yet.
At least ArmA 3 is working quite well. 
Last edited by keet on Tue Jan 02, 2018 3:07 am; edited 1 time in total |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3134
|
| Posted: Tue Jan 02, 2018 10:15 pm Post subject: |
|
|
| Quote: | | There must be a way to give my user access to /dev/vfio and the related files, |
consolekit/polkit can help with that.
There is also the good, old-fashioned way with using unix groups:
| Code: | ls -lh /dev/kvm
crw-rw----+ 1 root kvm 10, 232 12-29 11:47 /dev/kvm |
Being in kvm group allows me to run VMs with hardware support. Good stuff, check it out.
| Quote: | | For me, encryption is more for someone with physical access but not userspace access, since I protect data in userspace using other methods. |
That's pretty much what full-disk encryption offers. Protection against physical attack but not against malicious user. Fortunately the OS can take care of the latter.
| Quote: | So Joe was on the file server and, not being properly acquainted with the procedure, did some of the books wrong. But he did it last week.
How do you find out what he changed? |
Joe does not run backups. Let's be honest, he'd forget to do that anyway, so I suckered cron instead.
| Code: |
# ls -lahs /mnt/bkp/
razem 92K
4,0K drwx------ 20 root root 4,0K 01-02 03:17 .
4,0K drwxr-xr-x 19 root root 4,0K 01-02 22:17 ..
4,0K drwxr-xr-x 23 root root 4,0K 12-05 12:23 20171213-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-05 12:23 20171214-1950
4,0K drwxr-xr-x 23 root root 4,0K 12-05 12:23 20171215-2030
4,0K drwxr-xr-x 23 root root 4,0K 12-05 12:23 20171216-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171217-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171218-1930
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171219-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171220-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171221-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171222-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171223-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171224-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171229-1120
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171230-1526
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20171231-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20180101-0310
4,0K drwxr-xr-x 23 root root 4,0K 12-16 19:12 20180102-0310
16K drwx------ 2 root root 16K 2015-07-12 lost+found
|
Now, this script launched by cron _COULD_ run incremental forever, but I decided to do a full every week, so I can have 2 or 3 independent sets of backups at any time. Independent like in not linked to each other, though yes, they do reside on the same physical volume. If I were to protect that backup from another administrator, rsync pull performed by server instead of push done by client should do the trick (as long as I keep that pest Joe out of my precious backup server ^^).
Anyway, if Joe screws up one of my backup sets, I may still be able to weed the corrupted data based on their timestamps (Hint: anything newer than the backup date cies "do not use"), and then recover those parts from an older set, which is not hardlinked to the corrupted one.
Feel free to point out any flaws I missed. I will have to redeploy soon™ anyway, so I might just as well fix my earlier mistakes. |
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Wed Jan 03, 2018 1:30 am Post subject: |
|
|
V.G.A. passthrough as the normal user is working now; I just needed to make a udev rule and modify the permissions of /dev/vfio (it's a directory, not a device node):
| Code: | $ cat /etc/udev/rules.d/10-qemu-hw-users.rules
SUBSYSTEM=="vfio", USER="root", GROUP="kvm", MODE="0770"
KERNEL=="vfio", SUBSYSTEM=="misc", OWNER="root", GROUP="kvm", MODE="0660"
KERNEL=="1", SUBSYSTEM=="vfio", OWNER="root", GROUP="kvm", MODE="0660"
chmod ug+X /dev/vfio
|
I also needed to give the user access to use more memory (or to allocate more to a static address?):
| Code: | $ grep myaccount /etc/security/limits.conf
myaccount soft memlock 16777216
myaccount hard memlock 16777216 |
I'm reading about exactly what that does, though, since it looks like quite a lot. The V.M. has 8GB of R.A.M., but maybe it also needs 8GB for the video card (its amount of R.A.M.). Without those lines, starting the V.M. fails:
| Code: | qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: VFIO_MAP_DMA: -12
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x55cd327060f0, 0x0, 0x80000000, 0x7f2e0be00000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: VFIO_MAP_DMA: -12
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x55cd327060f0, 0x100000000, 0x180000000, 0x7f2e8be00000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio error: 0000:01:00.0: failed to setup container for group 1: memory listener initialization failed for container: Cannot allocate memory |
|
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Wed Jan 03, 2018 6:29 pm Post subject: |
|
|
| 1clue wrote: | | I feel like we're hijacking the thread with this backup talk. |
I was asking about R.A.I.D., which turned into a backup discussion. This discussion is interesting, but I agree that it maybe borders on hijacking due to the volume that it's taking up -- I considered requesting a separate backup thread, but oh well.
I wouldn't mind if anyone had comments regarding:
1. Permanently changing the permissions of /dev/vfio (which is a directory and not a device node, and thus, as far as I can tell, not subject to udev rules), apart from manually making a script to do it at boot.
2. The 'memlock' option in /etc/security/limits.conf.
3. Anything else about K.V.M./QEmu performance tuning and configuration, especially related to V.G.A. passthrough. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Thu Jan 04, 2018 12:34 am Post subject: |
|
|
I did read that and use some of the information while configuring it, but I see that I didn't use all of the options, such as the ones for storage tuning. Thank you for reminding me of that one. |
|
| Back to top |
|
|
keet
Guru
Joined: 09 Sep 2008
Posts: 568
|
| Posted: Sat Jan 06, 2018 4:04 am Post subject: |
|
|
| I converted my Gentoo virtual machine to U.E.F.I. using sys-firmware/edk2-ovmf, and it actually seems smoother, at least in terms of the mouse movement. I didn't compile the E.F.I. framebuffer into the kernel, so I am blind during the boot process, but at least it's working. I'll try to switch the Windows one soon, as well, though I expect for that to be trickier; I might need to reinstall Windows to really convert it to U.E.F.I. booting. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
