jasongrossman has quit [Ping timeout: 245 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
jackdk has quit [Ping timeout: 245 seconds]
Jackneill has joined #nixos-chat
<elvishjerricco>
I think I found a shortcut for the secure booting things I was looking at before. Apparently Grub supports unlocking LUKS partitions. So I just have to encrypt /boot with LUKS, and the whole kernel / command line / initrd can be trusted. Still dunno if I want to use trustedgrub to unlock that partition automatically with TMP though.
<srhb>
elvishjerricco: Oooh, interesting!
<andi->
elvishjerricco: thats what I run. It is great :-)
<srhb>
elvishjerricco: What time is it there?! :P
<andi->
without the TPM yet.. just the secure boot part
<elvishjerricco>
srhb: ... Early. 4:38am EDT. Sleep is hard :P
<srhb>
Ouch...
<elvishjerricco>
andi-: Yea I'm unsure on the TPM. It's a very risky idea
<andi->
elvishjerricco: what I did was just wipe all the other trusted certificates from all my devics and the only certs supported are on the encrypted luks partition itself (And encrypted backups)..
<andi->
Makes me pretty confident security wise.. if a state level actor has means to circumvent secureboot well it's game over but at least it steps up the game a bit
<elvishjerricco>
andi-: Well even if they can circumvent secureboot, they're still relying on you to show up and type your password, aren't they?
<elvishjerricco>
In which case a keylogger is a much less sophisticated way to do the same thing :P
<andi->
elvishjerricco: yes but they can put a rigged grub on the EFI disk
<andi->
since it no longer has to carry my signature
<elvishjerricco>
andi-: Is that worse than a keylogger?
<andi->
at least that is my threat model.. (someone grabbing the device, playing with it, putting it back in the bag)
<andi->
elvishjerricco: depends, I would say they do similar things but not the same..
<elvishjerricco>
The main reason I want TPM to decrypt my disk is so that I can do remote reboots; restarting after power failures would just be icing on the cake. But I wonder if it's possible to somehow instruct the system to keep the LUKS partition unlocked through the reboot just once. i.e. so that I can say "Please reboot, and just remember the key from last time."
<andi->
mhm
<elvishjerricco>
Aw, but I guess you can't really have Grub unlock LUKS if you're using EFI, since y'know, /boot would be encrypted. I like my better boot graphics with EFI :P
<pie_>
so I'm wondering about the health of my ssd, I have 33273568619 for Total_LBAs_Written, thats 15 terabytes of writeS? that doesnt sound quite right?
<andi->
elvishjerricco: I use grub with efi to unlock /boot..
<andi->
A dedicated efi partition exists if that's the confusion you might have
<elvishjerricco>
andi-: Ahhh that makes sense
<elvishjerricco>
andi-: How do you configure NixOS to install grub there instead of /boot?
<andi->
elvishjerricco: well define the efi path variable
<andi->
I mount it in /boot/EFI and just defined the path in the config
<elvishjerricco>
defined what path?
<andi->
The efi dir
<andi->
boot.loader.efi.efiSysMountPoint is the option
<elvishjerricco>
andi-: Oh, does that not also change where the kernel gets copied to?
<andi->
No
<andi->
My efi partition isn't large enough...
<elvishjerricco>
andi-: Got it. So kernel / initrd is always on /boot, and grub is on efiSysMountPoint
<andi->
Yes
<andi->
Sorry for the brief responses.. On the phone on a conference.
<elvishjerricco>
Np, thanks for the info :)
__monty__ has joined #nixos-chat
<elvishjerricco>
There are rumblings that grub can boot ZFS. Can it do so with ZFS over LUKS, since it is also able to boot LUKS?
<andi->
Try :)
<andi->
I would like to know but it should be able to
<infinisil>
Currently thinking about backup timings
<infinisil>
Is there any reason to make backups e.g. everyday at 00:00?
<infinisil>
What I'm thinking of: Why not make backups every 1h, 2h, 4h, 8h, ... 2^n h. Then you have a regular increase in times, instead of the more common "keep hourly backup for the last day, daily for the last week, etc."
<infinisil>
Backup times won't be at the same time everyday though, but I don't think that's a problem
<infinisil>
ivan: Yeah I'll be doing something like that
<infinisil>
But without the ringbuffer thing, I'll be using ZFS snapshots
<__monty__>
I like the series of ringbuffer thing over the simple powers tbh.
<__monty__>
That's very similar to the usual approach though.
<infinisil>
Well I will not be using a ringbuffer, but the same data will be stored in the end
<infinisil>
The further back the more distance between snapshots/history points
<infinisil>
I guess I wasn't clear with the 1h, 2h, ... thing
<__monty__>
That's not what the series of ringbuffers does. It only increases distance when stepping to the next buffer, not within a buffer.
<infinisil>
Oh I see
<infinisil>
Many buffers, each of them having an increasing history delay
<__monty__>
Yes, and the increase is exponential. So a 1h buffer, then every other entry that overflows is added to the next buffer, etc.
<infinisil>
Ah neat, didn't think of it that way, but that's a bit nicer than what I thought of doing
* etu
is very happy that he got his Vega graphics running yesterday
<etu>
Got help from someone at the discourse :)
<elvishjerricco>
andi-: Holy crap, it actually worked. LUKS up some disks, make sure grub is installed to an unencrypted efi partition, put ZFS over the LUKS devices, and it boots just fine. Even /boot is on the ZFS pool, so my kernel store on ZFS. Excellent.
<elvishjerricco>
You have to enter the password for each LUKS device twice though, once in grub and once for NixOS. But you can put keyfiles on the LUKS devices for NixOS to decrypt the disks automatically. It'd be nice to find a way to enter only one password for grub.
<elvishjerricco>
(one password for grub, given that there are multiple disks for grub to decrypt)
<infinisil>
Nice, have thought of putting /boot on ZFS too
<andi->
elvishjerricco: yeah. I have been procrastinating that simplification... I only reboot so often...
<elvishjerricco>
I'm just stoked to have the kernel on a checksumming file system :P
<elvishjerricco>
encrypted too!
<infinisil>
Still waiting for native ZFS encryption
<{^_^}>
zfsonlinux/zfs#7153 (by ptx0, 32 weeks ago, open): grub support for zfs encryption
<elvishjerricco>
The tone in that thread is very much "Grub doesn't care about ZFS, why should we care about Grub?"
<elvishjerricco>
(I'm also still bitter that ZFS native encryption is ever so slightly leaky)
<infinisil>
But I mean, I've used encryption before with grub, where's the problem?
<infinisil>
Oh wait, maybe I didn't
<infinisil>
Nah I didn't
<elvishjerricco>
infinisil: Yea, Grub has to know how to decrypt /boot, so it needs to be taught how to do ZFS's decryption if /boot is in ZFS.
<gchristensen>
elvishjerricco: how is it leaky?
<elvishjerricco>
gchristensen: Nothing major for a personal machine. It leaks file sizes (not sure whether that's bytes or blocks..., also makes me worry that it leaks the number of existing files), dedup tables, and the entire pool hierarchy.
<elvishjerricco>
including pool metadata.
<elvishjerricco>
It wouldn't bother me on a personal machine, but it's frustrating since it doesn't seem necessary.
<infinisil>
elvishjerricco: Ahh, so that's not a problem when /boot is vfat (like most people have)
<elvishjerricco>
But on something with massive amounts of sensitive data, I'm guessing file sizes can be a substantial leak.
<gchristensen>
elvishjerricco: file size can be a huge problem... I wonder how they ended up with this
<elvishjerricco>
infinisil: Yea, this is if you want /boot to be encrypted AND on ZFS.
<infinisil>
elvishjerricco: There must be a reason those aren't encrypted. Maybe it would've made encryption unbearably slow or would've required a major rewrite of ZFS
<elvishjerricco>
gchristensen: I think it would have taken some substantial rewriting of the pool structure to allow encrypting it, and file sizes and dedup tables are probably just part of the pool structure.
<elvishjerricco>
the main thing, as I understand it, is that they wanted to be able to have individual datasets encrypted
<elvishjerricco>
so enabling that while encrypting the sub-hierarchy under that dataset would require rearchitecting the pool structure to support making a sub-hierarchy kind of its own thing
<gchristensen>
ouch
<elvishjerricco>
Yea. ZFS is the worst file system... except all the others :P
<infinisil>
What does LUKS leak anyways?
<srhb>
Nothing, really.
<elvishjerricco>
I don't think LUKS leaks anything
<elvishjerricco>
It's just "Your blocks are now just high entropy blocks" :P
<srhb>
And I agree with elvishjerricco that the pool structure is the problem :)
<infinisil>
elvishjerricco: So it takes the whole block device and writes random looking bytes all over the place on initialization?
<elvishjerricco>
infinisil: I dunno if it does anything like that. I think it might just cause all writes to be transformed into an encrypted form. So if you want the whole drive to have high entropy you'll have to randomize it yourself first
<infinisil>
Well because if it's like that, then it certainly leaks how full the device is
<elvishjerricco>
i.e. I guess LUKS leaks how much data you've ever written, unless you randomize yourself.
<infinisil>
But yeah, LUKS does sound better if you are concerned about the things zfs leaks
<elvishjerricco>
I suppose it would also leak which blocks are written often, but CoW filesystems should make that meaningless
<elvishjerricco>
s/should/might/ I am not a crypto expert :P
<andi->
jD91mZM2: do you have a use-case for that ? :D
<jD91mZM2>
andi-: None at all :)
<andi->
jD91mZM2: okay, was it fun? Did it provide pleasure? ;-)
<jD91mZM2>
andi-: It kept me occupied for the evening, so I guess :P
<infinisil>
jD91mZM2: Oh you should try to write a macro for morse!
<infinisil>
Such that one can just type morse!(..-.-.--..) and it will turn into the thing
<jD91mZM2>
Heh, fun idea
<infinisil>
Not sure if the macro system can do that
<jD91mZM2>
With perhaps a few syntax changes to your proposal, it surely will. Main problem is the spaces, they are discarded with macros
<samueldr>
I wonder if there's a tiling WM which could, using compositing, scale down the window instead of resizing the window (with rules probably); I would sometimes like to use such a layout
<gchristensen>
like Prezi?
<samueldr>
no huge zoom out and fanciness, thinking more about putting miniatures in the non-main area
<samueldr>
the actual resizing is often not as useful as a scaled down version could be in my use case
<samueldr>
another idea to add to the "want to do but probably won't" pile :)
jD91mZM2 has quit [Quit: WeeChat 2.0]
<sphalerit>
samueldr: sort of like plasma's expose thing but more versatile?
<sphalerit>
(Which I think is an imitation of exposé or something on macos)
<samueldr>
pretty much
<samueldr>
a permanent exposé of the non-main window, but still interactable
<samueldr>
and the whole cake too
<samueldr>
maybe the easiest way to get that is to somehow coax kwin into acting like I want to?
<elvishjerricco>
Is there a reason not to store your LUKS volume's decryption key in plaintext on the LUKS volume itself, with root permissions? If an attacker on your system acquires root access, they can acquire the key with `dmsetup table --show-key /dev/disk/by-uuid/...` anyway, so having a root-readable file with the same contents on the encrypted disk seems harmless.
jasongrossman has quit [Ping timeout: 245 seconds]
<emily>
I think it is roughly as harmless as you think it is, but IANACryptographer or disk encryption implementation expert
<simpson>
elvishjerricco: I'm not an expert in XTS or other HDD-specific "tweak" modes. You should be fine, although obviously it goes without saying that you should treat private keys as, well, private keys.
<elvishjerricco>
Yea it'd be crucial that I ensure the key file is never exposed to anything that can't login as root on the machine.
<samueldr>
name it .private; hidden files are more private *ducks*
<gchristensen>
.not-my-private-key
<infinisil>
Name it " " lol
<Ralith>
less effective now that ls automatically quotes
<infinisil>
Oh
<andi->
.not-the-key-you-are-looking-for
<Ralith>
name it '" and escape in the ensuing confusion
<infinisil>
". " seems pretty effective though
<infinisil>
Heh
<andi->
how about unicode characters that look like regular dots but arent?
* Ralith
legitimately does not understand the quoting logic that results from that one
<Ralith>
there are too many 's
* Ralith
wonders if ls handles ANSI escape sequences gracefully
jasongrossman has joined #nixos-chat
__monty__ has quit [Quit: leaving]
jasongrossman has quit [Ping timeout: 252 seconds]