nfs can. At my last job, we setup DRBD to host all the server home directories over NFS with autos. Login happened via sssd and then their user specific home directory was mounted on login. The files didn’t exist on the server until the user logged in and could be mounted on multiple systems at once (NFS is also one of the few ways to do RWX volumes in Kubernetes).
With a regular nfs, if someone has access to the nfs server, they can access all the home directories, but doing it through DRBD adds another layer to that since DRBD is also managing the block devices underneath. (It appears Cisco has a doc on doing DRBD with LUKS in OpenStack.)
Ah, yeah - I think my trouble with initially understanding the point of this is that I’m coming from that world for these concepts and was trying to see how systemd-homed fit into that world instead of starting from a place of a regular user wanting portability/privacy with their own data. I think the scope and practical use cases of it are starting to make more sense to me now. Many thanks!
I think these warnings are due to current container-selinux and selinux-policy-devel packages being out of sync, and shouldn’t affect this. Possibly worth tracking down and filing a bug in one of those packages, though.
@richiedaze Thanks for this very nice guide. I think it might be helpful to have a “what this step does” explanation for each step (maybe using the drop-down markup that Sampson uses in his message, so it doesn’t become too cluttered for people who just want the recipe).
And, in Step 8 — it isn’t obvious to me that secure_home is the username to be created. That probably should be spelled out.
Assuming a predictable mount location for these home mounts, could this be handled with semanage fcontext -a -t user_home_dir_t /path/to/homed/mounts/[^/]+ ? If so, it would make step 8 cleaner.
Similarly, this could be defined in /etc/systemd/homed.conf so the individual mount command is cleaner. It looks like the default shipped in Fedora is already btrfs (commented out in the conf), so this arg might be redundant.
I posted this here to generally get ideas and different points of views on how to use systemd-homed on fedora. You and @vwbusguy have helped tremendously by giving us your point of views on networking aspects of this project.
I have written a SELinux policy for this project. I have to rewrite the policy every time to adjust to the users preferences. I would like to add rules for networking homes with homed. From your guys conversation, I would assume homed is a network client only or is it a network server as well?
Hopefully everyone with similar interest for this project will come here for a better understanding and use case for this project . My intent is to build a fedora wiki on this subject, but still lack information on different use cases and troubles that arise in these cases. An example below:
So in this case, new homes created by homed (or any mk.fs), selinux labels them “unlabeled_t”. So I adjusted my policy to include rules for home directories with proper labels and home directories without. I have searched and read that you have to manually label new filesystems on (RH,Fedora,etc). For this reason, policies for homed have been abandoned. SELinux ref also states that it’s incomplete because of the labeling issue.
By adding this rule to the policy fs_relabelfrom_xattr_fs(systemd_homework_t)
and adding –luks-extra-mount-options=defcontext=system_u:object_r:user_home_dir_t:s0 flag to the build command, would properly label it correctly on a default LUKS btrfs filesystem.
Note:
Using –luks-extra-mount-options=defcontext=system_u:object_r:user_home_dir_t:s0 homed build flag does not properly label other LUKS file types (ext4,xfs). It labels them user_home_t , which would still need a home directory relabeling, thus needing an another solution, hence why I added –fs-type=btrfs flag to the build command on step 8.
WIthout the –luks-extra-mount-options=defcontext=system_u:object_r:user_home_dir_t:s0 build flag, the administrator or logged in user must manually relabel the home directory with restorecon or an equivalent command. So in theory, step 8 saves you from manually relabeling your home.
How does this work on a mail server, where the Maildir is in the user’s home directory?
The LDA moves/transports the message to the user’s home dir. If the dir was not accessible to the LDA process (in my case dovecot’s LDA), how would this work?
@richiedaze , just tested your custom homed policy and it works with SELinux set to enforcing. Could you look in one more case with homed - there is possibility to use FIDO2 keys (e.g., Yubikey 5 ) when creating new user. Normal login using Yubikey is fine, no SELinux alerts. But after sleep/lock logging in with Yubikey gives this alert:
Summary
SELinux is preventing systemd-homewor from lock access on the chr_file /dev/hidraw1.
If you believe that systemd-homewor should be allowed lock access on the hidraw1 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
If I remember correctly, systemd-homed uses an encrypted BTRFS subvolume. Each users home is it’s own subvolume. With a LUKS encrypted /home file system, once it’s unlocked, anyone with sudo access can see others users home directories. Let me give you an example:
My partner and I share a computer running Fedora with systemd-homed configured. I have my home on a USB drive, so I plug it into the computer and when I log in it unlocks the subvolume and mounts the USB drive. My partners home directory is on the internal drive. When I sudo to root, I still can’t see their home or files. There’s just an encrypted subvolume assigned to them.
Yeah. I mean, I suppose they could? It’s probably just as easy to move to delivering under /var/mail or /srv/mail or something. I can see the general appeal of a blanket rule of “system daemons don’t mess with contents of users’ homes”. On the other hand, there’s crond — of course actually a system daemon, but it also runs user jobs, and the user doesn’t need to be logged in for that, and to me at least it doesn’t feel quite as invasive as a mail delivery agent dropping files somewhere.
For cases where that’s desired, I think this model just doesn’t work. Although one adaptation might be to use an overlay filesystem of some sort. I can think of several ways to do that: files could be dropped in place and then “absorbed” when the user logs in; or, there could be clearly-defined (per-system, of course) subdirectories which would be unencrypted…