Update config

[xyzzy42]

Bring the service configuration more in line with modern Linux.

Add some additional options to the systemd unit for proper start order and additional system protections.

Move log files to their own subdirectory.

Update PAM configuration.

[couling]

I'm not sure this is necessarily desirable. Certainly ProtectHome is undesirable. The primary purpose of this server is to allow access to Linux user's home, so that would be counter productive. Added protection can be added via the chroot option to protect the system.

However from memory, ProtectSystem causes the server to be run in it's own mount namespace. This would be tricky for some users who are unfamiliar with the effect because the server would not give access to (for example) USB drives manually mounted by the user.

[xyzzy42]

It would be nice if webdavd could be prevent from home dir access, but then webdav-worker, after authentication as the user, did have access. But I didn't see an easy way to do that. ProtectHome prevents authentication from even working.

I don't believe ProtectSystem creates a private mount namespace. There is PrivateMounts, but the mount namespace is still propagated in the direction system -> unit private, so usb drives (and the root fs!) still appear. But mount changes the unit makes will not propagate back to the system.

ProtectSystem=full makes some directories read-only, .e.g. /etc, /boot. Directories were it would be highly unusual to edit files via webdav and most if not all files will be own by root.

All the directories so modified are not reachable after being chrooted to ~, which the default config files does. So if someone does want to use webdav to get remote root write access to /etc, they already need to edit the webdav config file. It seems reasonable that they could also edit the unit file too.

[couling]

I've previously had mega problems with this feature (rooted from this bug) so I'm pretty cautious about it. Remember this config file is used by everyone who's installed this server for every use case. It might be worth checking how samba is packaged and if they use this feature.

Regarding the home directory thing, it's certainly not going to fit the general use case. I don't understand what you're trying to achieve. I imagine the easiest way to achieve it is to have a single directory somewhere (/share or /user/lib/share) with everyone's webdavd shares inside and then set the server to chroot.

[xyzzy42]

Network servers that I have installed and came with ProtectSystem on: openvpn-server, systemd-timedated, lldpd, rdisc, chronyd

There are more services that use it, but I've only looked at those that are network daemons.

It's also entirely possible for someone to change the config via a drop in file without even editing this unit file, which is easier than editing the webdavd config file.

Current best practices is to make the default secure. If someone wants to make it less secure, such as allowing editing their entire file system over webdav, then they can do that. Making the default insecure and expecting people to secure it themselves isn't recommended anymore.

Example, webdavd isn't even going to work until the default firewall config is edited to allow connections from outside of localhost to port 80 and/or 443.

WRT home dirs, my goal is to be more secure. There's no reason for webdavd, before authentication of the user, to be able to access any files in home directories. So it shouldn't have that. Unfortunately, dropping home dir access can not be undone via authentication as a user.

[xyzzy42]

I've also tested the additional mount, by serving /run, and then while a webdav session was open, mounting as a user a USB drive. The new mount appeared to webdavd just fine under /run/username.

This makes /usr read-only too, which doesn't cause a problem starting webdav-worker from /usr/lib or serving the static content in /usr/share.

It does provide an important security benefit knows as W^X. One can either write files or execute them, not both. If one is able to get write access to /usr/lib, then one gets the trivial ability to execute arbitrary code, by replacing webdav-worker with a new program which will be conveniently run on the next session.

[couling]

It would be good to get an explanation of these changes. The Redhat PAM file was provided by another user so I freely admit it might need securing. Have these been copied from another service? Does Redhat not have standard include files for this purpose?

[xyzzy42]

I copied them from sshd, omitting the password entries which do not apply and also pam_motd which doesn't make sense for a non-shell. They all appears to make sense, though some are a little unclear.

There are include files for password-auth and postlogin, but nothing for this whole sequence. Here's what proftpd does:

session    optional     pam_keyinit.so force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
auth       required     pam_shells.so
auth       include      password-auth
account    include      password-auth
session    required     pam_loginuid.so
session    include      password-auth

vsftpd is basically the same. Maybe that would be a better starting point?

[xyzzy42]

Might be good to add this:

auth            required        pam_succeed_if.so user != root quiet_success

This will disallow root access. sshd by default does not allow root logins on Fedora, and most other distros too, so it seems appropriate.