Using ChrootDirectory only makes sense with internal-sftp, which when used with ForceCommand means the users matched by that configuration will only be able to use the SFTP protocol to access that server through SSH.
This is incompatible with what you state about what you're trying to accomplish:
I would like to restrict users to their home directory so they can login, change their password, or manage their files with a shell.
To get a shell, you need full SSH and not SFTP only, so that's probably not what you want...
Regarding ChrootDirectory and ownership by root, that's not really about the home directory necessarily but about the top of the chroot environment. The issue you're having here is using the home directory as the top of the chroot, when that's not really how ChrootDirectory is meant to be used, not really how it makes most sense.
A better way would be to use a configuration to expose chrooted home directories through SFTP would be:
Subsystem sftp internal-sftp Match User brian ChrootDirectory /chroot/%u ForceCommand internal-sftp
Then, for each user, such as user brian, create a /chroot/brian which is owned by root:root (this is important, as it's a restriction for ChrootDirectory to work properly.) Then, inside /chroot/brian, create a home directory for the user, /chroot/brian/home/brian. This home directory can be writable by user brian, which is probably what you'd want (home directory fully manageable by its owner.)
The way ChrootDirectory works, the SFTP server will change to a home directory inside the chroot, if it can find one. The user accessing the server through SFTP will be able to go up to directory .. and ../.., but those will be mostly empty so nothing interesting will be exposed there.
You can link the "real" home directory with the one inside the chroot by using a bind mount:
$ sudo mkdir -p /chroot/brian/home/brian $ mount --bind /home/brian /chroot/brian/home/brian
You can configure this mount in /etc/fstab so it's mounted every time the server is rebooted. You'll need one such mount for each user you want to expose SFTP to, so this might become quite a maintenance burden.
In any case, it looks to me that SFTP is not necessarily what you want, so ChrootDirectory is probably not relevant for your setup.
If you want to expose shell, it's technically possible to set up a chroot for each user and have them SSH into a chroot. However:
The setup for this configuration is quite complex. In particular, you need to fully populate a chroot, since in a shell you typically need a whole set of external commands (such as ls, cp, tar, etc.) to do something useful. If you set up chroots for every user, you'll need to populate them all with all these binaries, libraries they depend upon, etc. Furthermore, you'll need to update those binaries to fix bugs and security issues with them. It's a lot of work. And, perhaps more importantly:
A chroot is quite fragile and, if you have unrestricted access to it (which you typically do with a shell), there are often ways to break out from it. It's not trivial to close all loopholes in a chroot, so it's unclear there's a lot to gain in security from this setup.
Due to the increased complexity and the small (possibly inexistent) gains in security, I'd recommend against looking into a chroot setup for shell in SSH.
So, the question is what you're trying to accomplish, that's not already accomplished by the default setup shipped by a Linux distribution.
Typically, the Unix permissions are enough to implement a good level of security and isolation between users.
Users are already prevented from writing files to other users' home directories by default.
You can prevent users from browsing and reading files from other users' home directories by setting the permissions on the home directory to 0700.
(Restricting permissions of /home itself to 0711 would prevent listing home directories with ls /home, but there's not much to gain from that, since you can typically find a list of all users reading from /etc/passwd, which is required to be readable by all users in Linux.)
Users will be able to browse and read most of the rest of the filesystem (binaries, etc.) but that's typically expected, since they need most of those to use a shell.
The mail system should take care of setting proper ownership and permissions to prevent users from reading each other's e-mail, so typically that's already done correctly for you.
Do you have specific security concerns that are not already covered by the defaults? Otherwise, keep it simple and just use them, it should be more than enough for most typical use cases.
/etc/passwdcontaining user-names). Or are are you trying to stop them reading and writing other users files? (The 2nd option is easy)