Fwd: Private home directories for hirsute onwards

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Private home directories for hirsute onwards

Robie Basak-4
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 <[hidden email]> -----

Date: Thu, 26 Nov 2020 13:00:52 +1030
From: Alex Murray <[hidden email]>
To: [hidden email]
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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

----- End forwarded message -----

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Private home directories for hirsute onwards

Alex Murray
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 <[hidden email]>
> -----
>
> Date: Thu, 26 Nov 2020 13:00:52 +1030
> From: Alex Murray <[hidden email]>
> To: [hidden email]
> 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
> [hidden email]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> ----- End forwarded message -----


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel