Fwd: Private home directories for hirsute onwards

Mon Nov 30 06:24:08 UTC 2020

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 -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20201130/b293cdda/attachment.sig>