Fwd: Private home directories for hirsute onwards

Wed Jan 13 06:38:15 UTC 2021

Just to follow up on this thread - since there was no opposition to this
proposal, I have uploaded updated adduser and shadow packages to
hirsute-proposed to support setting the mode of home directories to 750
by default when they are created via either adduser or useradd.

Let me know if you encounter any significant issues :)

On Mon, 2020-11-30 at 16:54:08 +1030, Robie Basak wrote:

> Forwarding here in case there are Ubuntu developers who might want to
> comment but don't read the ubuntu-devel-discuss@ list.
>
> Since there's already a thread there, I suggest replying there if you
> want to reply to avoid splitting the discussion.
>
> There's also a cross-post to
> https://discourse.ubuntu.com/t/private-home-directories-for-ubuntu-21-04-onwards/19533
>
> HTH,
>
> Robie
>
> ----- Forwarded message from Alex Murray <alex.murray at canonical.com> 
> -----
>
> Date: Thu, 26 Nov 2020 13:00:52 +1030
> From: Alex Murray <alex.murray at canonical.com>
> To: ubuntu-devel-discuss at lists.ubuntu.com
> Subject: Private home directories for hirsute onwards
> User-agent: mu4e 1.4.13; emacs 28.0.50
>
> Hi folks,
>
> After more than 14 years[1] of debate, I propose that it is time we
> moved ahead and stopped creating home directories as world-readable on
> Ubuntu for hirsute onwards. The old arguments from the bug referenced in
> [1] mainly centered on the convenience of this feature when considered
> in regards to a shared desktop machine with multiple user accounts
> wanting to easily share files with one-another. However, a lot of things
> have changed in the last 14 years, not least of which that Ubuntu has a
> significant customer and user-base in the public cloud and server
> space. For these users, there is generally 1 admin account and perhaps a
> number of less privileged worker accounts, and so world-readable home
> directories now present more like a footgun than a feature - in this
> case, if a worker account is compromised, an attacker could now more
> easily access sensitive data from the other worker accounts or the admin
> account. Whilst the Ubuntu Security team does a great job of staying on
> top of security updates and keeping the distro packages as secure as
> possible, there will always be instances[2] where for whatever reason
> machines are not kept up-to-date or weak passwords are used and so they
> become compromised. We should therefore be taking an approach to limit
> access in this unlikely event.
>
> The other part of the past argument for this was that knowledgeable
> users / sysadmins will be aware of this default and will change it if
> they deem necessary. Whilst I am sure that we do have many knowledgeable
> users, we have many more who simply are deploying Ubuntu to solve other
> tasks - and I think it goes against the usability proposition of Ubuntu
> in these cases to expect admins to make this change. Instead we can
> ensure these deployments limit the chance for sensitive information to
> be compromised by changing this default.
>
> It should be noted too that from a regression point-of-view, changing
> this default will also not affect any permissions on existing installs
> (if it was perhaps decided to SRU this change back to older releases) or
> on upgrades - only if new users are created will they then have these
> more restrictive permissions. By making this change now, this also gives
> 3 development releases and 2 interim releases to work through any
> unforseen issues etc before landing in an LTS release. Without some
> widespread testing it is not possible to know in advance all of the
> possible use-cases that have depended on this behaviour which may then
> have issues so I feel now is the time to make such a change so we can
> determine any appropriate work-arounds and associated documentation etc
> as needed.
>
> As such, for a concrete proposal, I suggest changing /etc/adduser.conf
> to specify DIR_MODE=0750 instead of the current DIR_MODE=0755 - this
> will ensure any users created via adduser have their home-directory
> non-readable and non-executable by others.
>
> In the case of useradd[3] (the low-level util) this is a bit trickier -
> whilst the documentation suggests we can set HOME_MODE in
> /etc/login.defs this does not appear to be respected and only if we set
> say UMASK=027 in /etc/login.defs and then create a user
> (useradd -m -d /home/test test) does the home dir have the expected
> permissions. However, modifying the default umask has other consequences
> so I am not suggesting we consider that at this point. So this will need
> some more investigation, for now I would like to focus on adduser as
> this is the documented approach for adding new Ubuntu users .
>
> If you want to try this yourself, you can simply:
>
>
> # ensure future users homes are safe
> sudo sed -i s/DIR_MODE=0755/DIR_MODE=0750/ /etc/adduser.conf
>
> # then get your own house in order
> chmod 750 $HOME
>
>
> In regards to things to watch out for, one use-case that I have come
> across myself is libvirt VMs where the disk image is stored in your home
> directory - these become unreadable now to the libvirt-qemu user and so
> you can't launch these anymore 🙁 - however, there is a simple fix for
> this 🙂 - you can use an ACL entry to re-enable this access for just the
> libvirt-qemu user:
>
> setfacl -m u:libvirt-qemu:rx $HOME
>
> (or you could just store your images under /var/lib/libvirt/images)
>
> I suspect this ACL approach may be needed for other common use-cases but
> like I said above this remains to be seen so any testing others could
> give of this would be really appreciated in helping to decide whether to
> try and proceed with this change.
>
> Finally, if there is a strong case for deployments who rely on the
> existing functionality (say universities etc) where having to manually
> roll-back the setting on each machine install would be painful, we could
> look at adding some functionality to the installer/preseed/whatnot to
> create initial users etc with the old permissions.
>
> Thanks for taking the time to read this - any constructive feedback is
> welcome.
>
> Thanks,
> Alex
>
>
>
> [1] https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734
> [2] 
> https://ruffell.nz/reverse-engineering/writeups/2020/10/27/analysis-of-the-dovecat-and-hy4-linux-malware.html
> [3] https://manpages.ubuntu.com/manpages/hirsute/en/man8/useradd.8.html
>
> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> ----- End forwarded message -----