02:57:17 <cmurf> #startmeeting Workstation WG (2021-07-28)
02:57:17 <zodbot> Meeting started Thu Jul 29 02:57:17 2021 UTC.
02:57:17 <zodbot> This meeting is logged and archived in a public location.
02:57:17 <zodbot> The chair is cmurf. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:57:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
02:57:17 <zodbot> The meeting name has been set to 'workstation_wg_(2021-07-28)'
02:57:19 <cmurf> #meetingname workstation
02:57:19 <zodbot> The meeting name has been set to 'workstation'
02:57:21 <cmurf> #chair Neal
02:57:21 <zodbot> Current chairs: Neal cmurf
02:57:34 <cmurf> #topic Rollcall
02:57:36 <cmurf> #info present:  Matthias, Neal, Chris (secr), Allan, Jens, Michael, Owen, Tomas
02:57:38 <cmurf> #info regrets: Kalev
02:57:40 <cmurf> #info present guests: Felipe, Lennart Poettering, Davide
02:57:42 <cmurf> #topic Approval of July 13 minutes
02:57:44 <cmurf> https://meetbot.fedoraproject.org/teams/workstation/workstation.2021-07-13-17.40.html
02:57:46 <cmurf> #agreed Approved - no objections
02:57:48 <cmurf> #topic Announcements, Status Reports
02:57:50 <cmurf> - GUADEC last week, office hours and ask me anything went well, gave a good impression of Fedora and GNOME community
02:57:52 <cmurf> - libdecor is in F34 and Rawhide
02:57:54 <cmurf> - 3rd party repositories work, freeze is getting close, we need to land UI changes soon
02:57:56 <cmurf> - Fedora Nest (Flock) starts next week
02:57:58 <cmurf> #topic Encryption of user data (excludes system)
02:58:00 <cmurf> #link https://pagure.io/fedora-workstation/issue/82
02:58:02 <cmurf> + Lennart Poettering coming to talk about systemd-homed
02:58:04 <cmurf> Lennart, looked at what other platforms do and I feel sad because other platforms do all these security related things. Trying to add components to make it smoother and possible to use security chips, and encryption, so it just works. For user encryption is the central part of homed.
02:58:06 <cmurf> Why?
02:58:08 <cmurf> - uid's are terrible idea, only reason is because we inherited this, the model in homed is different where the uid becomes something local. The uid is assigned when the user logs in.
02:58:10 <cmurf> - emphasis on the cryptography correctly, the user login password/phrase both authenticates the login and unlocks the encrypted user data; ties those things together rather than computer access granting file access
02:58:12 <cmurf> - programs of the user cannot run anymore when they log out, eject the key
02:58:14 <cmurf> - very clear lifecycle for login, where it matters that data is not accessible prior to login or after logout
02:58:16 <cmurf> - backends: the interesting one is the one based on LUKS; password, FIDO2, security cards, tokens; not just gluing new things on old things, but doing it correctly
02:58:18 <cmurf> - fscrypt: I don't like it, it doesn't deliver what needs to be delivered, fscrypt the metadata is still accessible and that's inherently problematic, I think it's too much information;
02:58:20 <cmurf> - I really doubt whether it's compatible with the model we want for homed because of all the metadata leakage
02:58:22 <cmurf> Michael: you're recommending that we use LUKS, and not fscrypt?
02:58:24 <cmurf> Lennart: correct
02:58:26 <cmurf> Michael: this applies equally to ext4 and btrfs?
02:58:28 <cmurf> Neal: clarification, fscrypt/btrfs
02:58:30 <cmurf> Lennart: I don't think it's worth the effort, just encryption isn't enough if leaving out metadata, we can derive too much information; major issue is linux fs developers make no guarantees about external modification/intentional corruption; systemd-homed we make sure only trusted home directories can be used.
02:58:32 <cmurf> Michael: how do we protect against root?
02:58:34 <cmurf> Lennart: my take is to use dm-integrity with hmac on root; require a cryptographic key for making changes but not for reading, rather than encrypt twice; we should protect the OS from offline modification, it's a big problem all the other OS's have addressed this, there's no security checks like this at all in the linux world; but ultimately it is a different question from homed. I would
02:58:36 <cmurf> not entrust my data to anything but LUKS, I want the metadata encrypted. It's not hard to infer that I have certain data. Resize is currently manual, typically not a problem because there's usually just one user. Automatic method is still in progress, using a weighting system to reassess to grow or shrink the home directory backing files. Login grow, logout shrink. The more users the more
02:58:38 <cmurf> complex it gets, but we take into consideration the free space everywhere. The right policy logic might depend on more heavily weighting particular users. Btrfs resize is quite fast for the most part. homed doesn't do tpm stuff, like other operating systems, but we probably need to do this; extended user records, systemd can use this for resource management, homed requires the user record
02:58:40 <cmurf> stuff to work, sssd doesn't generate extended user records at the moment. I use homed everyday, works well for me. Looking into a time machine like thing, if we have all the home directories on btrfs we can take snapshots every now and then, reflinks or snapshots, so people could go back in time if they wish, get a list of mountable datetime based images, to extract a file out of or
02:58:42 <cmurf> whatever the UI would be; so the considerations there are vacuuming and keeping the space consumption sane.
02:58:44 <cmurf> Neal: one big challenge we're working through, mass deployment, requirements for encryption, recovery, override with enterprise login. How does homed fit into this picture?
02:58:46 <cmurf> Lennart: doesn't manage the data for you, it's strictly authentication to a system; homed doesn't help with this, it's parrallel. There can be multiple backends.
02:58:48 <cmurf> Neal: user record is something that comes from elsewhere, the user data is local;
02:58:50 <cmurf> Lennart: homed doesn't do that, it manages one unit you don't get to opt into manage the storage but not the record; not likely LDAP is doing to feed into homed any time soon; I have no intention to break into this very conservative area. The people who deploy this stuff, really are tied to a classic model.
02:58:52 <cmurf> Neal: I think that's a bit pessimistic but I get your point
02:58:54 <cmurf> Lennart: we could trivially bind the oauth stuff to homed, but i'm more interested in the future
02:58:56 <cmurf> Neal: I just care there's a way to do it, as a working group we need to be able to support it because it's a real need
02:58:58 <cmurf> Lennart: if you subscribe to the current models, it's fine, homed doesn't bring anything to the table
02:59:00 <cmurf> Michael: why are we talking about web based login?
02:59:02 <cmurf> Neal: when we provision workstation we need to support the enterprise network login scenario, central login systems, web authentication single login is increasingly considered what people should be doing and tying encryption to it makes sense; if homed can provide a mechanism to help do this easily, it's a good way to solve the problem.
02:59:04 <cmurf> Lennart: homed will not do OAUTH, something else will have to do that
02:59:06 <cmurf> Owen: how do we do recovery? what key is actually used?
02:59:08 <cmurf> Lennart: built on LUKS keyslots, so we can have multiple passphrases; as well as a bunch of other necessary metadata for FIDO2 keys just like a password would be used, you can enroll it and remove it; the recovery passphrase is modhex based works for most keyboards unlike other encoding methods helps ensure we're not stuck with keymapping problems when doing recovery; could also display
02:59:10 <cmurf> this as a QR code in GNOME; typical would be one FIDO key and one recovery key, we could enroll multiple FIDO keys but there's some complexity there about which slot to look into...
02:59:12 <cmurf> Lennart: we support this for fscrypt too, it has no key management on its own, so right now we're doing our own by modeling it off LUKS. Everyone who uses fscrypt does their own, user space lack of interoperability. Funny and sad.
02:59:14 <cmurf> Michael: long conversation your recommendation is use homed with LUKS
02:59:16 <cmurf> Lennart: soft advisory that I sort out the automatic resize stuff first; ext4 or XFS as the root hosting the backing; we currently use nodatacow on btrfs backing files; dm-integrity stuff I mentioned it should be on the radar; the OS immutable resources should be verity, the user space plumbing for this is still bad we don't have any key management for this. dm-integrity for everything,
02:59:18 <cmurf> Owen: user session is logged in journal?
02:59:20 <cmurf> Lennart: yes so /var needs to be encrypted; /etc and /var are encrypted, bound to tpm; everything is on integrity with hmac protected in tpm, and homed is fully encrypted.
02:59:22 <cmurf> Michael: /etc and /var, does the metadata need to be encrypted?
02:59:24 <cmurf> Lennart: they should be properly encrypted, LUKS; no role for fscrypt at all for root or home; it's for fine grained access control, flatpaks and so forth to implicitly have a per application key without any manual invocation, and always encrypt that data separately. Great technology, but not for homed. Millions of files gives away too much metadata; it's so skewed toward metadata.
02:59:26 <cmurf> Lennart: summary, way forward is use btrfs on LUKS, use XFS or maybe btrfs or ext34 for rootfs, delay until I have the automatic grow/shrink figured out; history stuff future; dm-integrity for offline security; and all the user space key management stuff is weak now. Until we have a properly locked down workstation, the initrd isn't protected either which is complete rubish, so lots of
02:59:28 <cmurf> work to do on the security front. I'd love to be able to fix this and make it easy.
02:59:30 <cmurf> Working group thanks Lennart for his time.
02:59:32 <cmurf> #agreed meeting adjourned
03:03:20 <cmurf> #endmeeting