Debian Bug report logs - #782001
general: access granted to /home files of another user

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Björn <b.siebke@web.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: general: access granted to /home files of another user

Date: Mon, 06 Apr 2015 12:46:30 +0200

Package: general
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Created new user from a non-root account (using root password prompt within
non-root account).
Started that new user.
Tried to read files from /home of first user.
Succeeded.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
See above.

   * What was the outcome of this action?
See above.

   * What outcome did you expect instead?
That a user's files are only accessible with the respective password and not
the password of another user.



-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Message #10 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: debian-devel@lists.debian.org

Cc: 782001@bugs.debian.org

Subject: Re: Bug#782001: general: access granted to /home files of another user

Date: Mon, 6 Apr 2015 17:20:23 +0200

On Mon, Apr 06, 2015 at 12:46:30PM +0200, Björn wrote:
>    * What led up to the situation?
> Created new user from a non-root account (using root password prompt within
> non-root account).
> Started that new user.
> Tried to read files from /home of first user.
> Succeeded.
>    * What outcome did you expect instead?
> That a user's files are only accessible with the respective password and not
> the password of another user.

This is not an error, works as designed.  You can "dpkg-reconfigure adduser"
to change this behaviour for newly added users (ie, not the first one),
existing users' homes need manual chmodding.

I do agree that this design seems bad, though.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.

Message #19 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Octavio Alvarez <alvarezp@alvarezp.ods.org>

To: Adam Borowski <kilobyte@angband.pl>, debian-devel@lists.debian.org

Cc: 782001@bugs.debian.org

Subject: Re: Bug#782001: general: access granted to /home files of another user

Date: Tue, 07 Apr 2015 00:23:52 -0700

On 04/06/2015 08:20 AM, Adam Borowski wrote:
> On Mon, Apr 06, 2015 at 12:46:30PM +0200, Björn wrote:
>>     * What led up to the situation?
>> Created new user from a non-root account (using root password prompt within
>> non-root account).
>> Started that new user.
>> Tried to read files from /home of first user.
>> Succeeded.
>
> This is not an error, works as designed.  You can "dpkg-reconfigure adduser"
> to change this behaviour for newly added users (ie, not the first one),
> existing users' homes need manual chmodding.

What about sane defaults? It could also be dpkg-reconfigured the other 
way around.

Best regards.

Message #26 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Ansgar <ansgar@debian.org>

To: 782001@bugs.debian.org

Subject: Re: access granted to /home files of another user

Date: Sat, 02 Mar 2019 08:15:55 +0100

Control: tag -1 + security

I think this problem (having $HOME world-readable by default) should
really be fixed...  In installations sharing $HOME between multiple
users this means private data of all sorts (medical records, unpublished
scientific articles, exam results, ...) can be accessed by /all/ users
by default.  This seems a really bad idea.

Dear security team, should such issues get a CVE id?  If one follows the
link from [1], one should contact the Debian security team to assign one
(even though [1] says Debian won't assign one?).

Ansgar

  [1] https://www.debian.org/security/faq#cveget

Message #33 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Ansgar <ansgar@debian.org>, 782001@bugs.debian.org

Subject: Re: Bug#782001: access granted to /home files of another user

Date: Sat, 02 Mar 2019 13:20:48 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, 2019-03-02 at 08:15 +0100, Ansgar wrote:
> I think this problem (having $HOME world-readable by default) should
> really be fixed...  In installations sharing $HOME between multiple
> users this means private data of all sorts (medical records, unpublished
> scientific articles, exam results, ...) can be accessed by /all/ users
> by default.  This seems a really bad idea.
> 
> Dear security team, should such issues get a CVE id?  If one follows the
> link from [1], one should contact the Debian security team to assign one
> (even though [1] says Debian won't assign one?).

Own opinion on this: I don't think it deserves a CVE but I'd be all for
changing the default. In 2019 I'd say most installations are single (human)
users but changing uids might be used for isolation between applications for
example.

Regards,
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlx6dSAACgkQ3rYcyPpX
RFudXwgAo3kS34+HRKrjxKug4I4SHa72sfw+EnddGD865Xp+C+/2PDRRyWYnFg+F
B5x82Mmr4iMkYbfjlZxLURRZkgSzdOu4Cbs99aq9ojhZs4yAHkbWhsZkvV/qb+3G
VjmunJe4g9eIuMurTMP08UaxN8+E3kkyhQBDCiz5oQI7lRI0/fh/dgS4iUWwrLJW
TOOrIw9ars97N7Ed4/fKeDQbaKKaEC2fbsM5DtNXM0iqP6EpqDE9YoenBOl4Lez+
RDkiV1ueG7ZyWhyrkPZnp9f+8dCNZB3+cqqaPqkN6ZRX1t7aGnxSXi6ue2nx4XAb
BIsfmRB1b/rvgkn0u0NiRo9wzozVHA==
=Ycaf
-----END PGP SIGNATURE-----

Message #38 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Ansgar <ansgar@debian.org>

To: Yves-Alexis Perez <corsac@debian.org>, 782001@bugs.debian.org

Subject: Re: Bug#782001: access granted to /home files of another user

Date: Wed, 01 May 2019 14:42:04 +0200

On Sat, 2019-03-02 at 13:20 +0100, Yves-Alexis Perez wrote:
> On Sat, 2019-03-02 at 08:15 +0100, Ansgar wrote:
> > I think this problem (having $HOME world-readable by default) should
> > really be fixed...  In installations sharing $HOME between multiple
> > users this means private data of all sorts (medical records, unpublished
> > scientific articles, exam results, ...) can be accessed by /all/ users
> > by default.  This seems a really bad idea.
> > 
> > Dear security team, should such issues get a CVE id?  If one follows the
> > link from [1], one should contact the Debian security team to assign one
> > (even though [1] says Debian won't assign one?).
> 
> Own opinion on this: I don't think it deserves a CVE but I'd be all for
> changing the default.

Well, it's local information disclosure.  It similar to having
/etc/shadow world-readable (though having $HOME world-readable is
actually worse as shadow only has hashed passwords).

> In 2019 I'd say most installations are single (human)
> users but changing uids might be used for isolation between applications for
> example.

I think world-readable home by default is totally inappropriate for any
multi-user system in 2019.

Note that the entire $HOME is also readable by system users, including
nobody, by default this way.  That just defeats the purpose of having
unpriviledged users on single-user systems...

On multi-user systems this is worse, more so when $HOME is on a network
system: every user can read other users' data, including private
information (unless applications take care to not make them world-
readable).

I think Debian should be usable with multiple local users by default,
without needing special configuration; there is no documentation what
users would have to do to be able to run a multi-user system.  So the
default should be safe.

Ansgar

Message #43 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Ansgar <ansgar@debian.org>, 782001@bugs.debian.org

Cc: Yves-Alexis Perez <corsac@debian.org>

Subject: Re: Bug#782001: access granted to /home files of another user

Date: Sun, 29 Sep 2019 10:46:03 +0200

Hi,

On Wed, May 01, 2019 at 02:42:04PM +0200, Ansgar wrote:
> On Sat, 2019-03-02 at 13:20 +0100, Yves-Alexis Perez wrote:
> > On Sat, 2019-03-02 at 08:15 +0100, Ansgar wrote:
> > > I think this problem (having $HOME world-readable by default) should
> > > really be fixed...  In installations sharing $HOME between multiple
> > > users this means private data of all sorts (medical records, unpublished
> > > scientific articles, exam results, ...) can be accessed by /all/ users
> > > by default.  This seems a really bad idea.
> > > 
> > > Dear security team, should such issues get a CVE id?  If one follows the
> > > link from [1], one should contact the Debian security team to assign one
> > > (even though [1] says Debian won't assign one?).
> > 
> > Own opinion on this: I don't think it deserves a CVE but I'd be all for
> > changing the default.
> 
> Well, it's local information disclosure.  It similar to having
> /etc/shadow world-readable (though having $HOME world-readable is
> actually worse as shadow only has hashed passwords).
> 
> > In 2019 I'd say most installations are single (human)
> > users but changing uids might be used for isolation between applications for
> > example.
> 
> I think world-readable home by default is totally inappropriate for any
> multi-user system in 2019.
> 
> Note that the entire $HOME is also readable by system users, including
> nobody, by default this way.  That just defeats the purpose of having
> unpriviledged users on single-user systems...
> 
> On multi-user systems this is worse, more so when $HOME is on a network
> system: every user can read other users' data, including private
> information (unless applications take care to not make them world-
> readable).
> 
> I think Debian should be usable with multiple local users by default,
> without needing special configuration; there is no documentation what
> users would have to do to be able to run a multi-user system.  So the
> default should be safe.

Was there any progress or objections towards changing this default?

Regards,
Salvatore

Message #48 received at 782001@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Salvatore Bonaccorso <carnil@debian.org>, 782001@bugs.debian.org, 782001-submitter@bugs.debian.org

Cc: Ansgar <ansgar@debian.org>, Yves-Alexis Perez <corsac@debian.org>

Subject: Re: Bug#782001: access granted to /home files of another user

Date: Mon, 7 Mar 2022 22:32:53 +0100

Control: severity -1 important
thanks

On Sun, Sep 29, 2019 at 10:46:03AM +0200, Salvatore Bonaccorso wrote:
> Was there any progress or objections towards changing this default?

Not yet. I dont feel that this should be a local decision of adduser.
This needs consensus on debian-devel. Feel free to start that
discussion. I will try doing this myself in due time, but I would
appreciate if somebody else would do it (time limiting factors...)

Greetings
Marc

Message #62 received at 202943-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 202943-close@bugs.debian.org

Subject: Bug#202943: fixed in adduser 3.122

Date: Wed, 13 Jul 2022 19:03:47 +0000

Source: adduser
Source-Version: 3.122
Done: Marc Haber <mh+debian-packages@zugschlus.de>

We believe that the bug you reported is fixed in the latest version of
adduser, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 202943@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marc Haber <mh+debian-packages@zugschlus.de> (supplier of updated adduser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 13 Jul 2022 20:30:00 +0200
Source: adduser
Architecture: source
Version: 3.122
Distribution: unstable
Urgency: low
Maintainer: Debian Adduser Developers <adduser@packages.debian.org>
Changed-By: Marc Haber <mh+debian-packages@zugschlus.de>
Closes: 202943 239825 398793 432562 520037 521883 588872 643559 664869 675804 679746 685532 701110 723572 774046 849265 874560 891748 896916 908997 920739 923059 925511 926262 969217 977678 979385 983405 992163 1001863 1006897 1006941 1006975 1007785 1008081 1008091 1014395 1014448
Changes:
 adduser (3.122) unstable; urgency=low
 .
   [ Marc Haber ]
   * improve package description.
   * Standards-Version: 4.6.1 (no changes necessary)
   * clean out EXTRA_GROUPS to only contain users.
     Thanks to Daniel Keast. (Closes: #849265)
   * add SECURITY section to manual pages.
   * add test for backups of home directory.
   * improve and update lintian overrides.
   * Formatting changes to manual pages.
     Thanks to Markus Hiereth. (Closes: #874560)
   * fix some typos in manual pages.
   * set VERBOSE and DEBUG envvars in deluser as well. (Closes: #1006897)
   * add documentation about adduser being a policy layer. (Closes: #1007785)
   * try to clarify system account terminology (policy vs system).
     (Closes: #1006975)
   * Document that only adduser --system is idempotent. (Closes: #723572)
   * error out for two-argument addgroup.
     Thanks to Mike Dornberger. (Closes: #664869)
   * make --add_extra_groups into --add-extra-groups. (Closes: #1014395)
   * --force-badname is now --allow-badname. (Closes: #1014448)
   * update turkish debconf translation.
     Thanks to Atila KOÇ. (Closes: #908997)
   * Update Russian debconf translation.
     Thanks to Lev Lamberov. (Closes: #920739)
   * Update Danish debconf translation (Closes: #923059)
   * Update Italian debconf translation.
     Thanks to Luca Monducci. (Closes: #969217)
   * Update German man page translation.
     Thanks to Helge Kreutzmann. (Closes: #977678)
   * Update European Portuguese translation of man page.
     Thanks to Américo Monteiro. (Closes: #925511)
   * disable translated manpages, none left for the time being.
   * deprecate planned directory service support.
   * Add docs about adduser.local being the place to interact with DS,
   * Some improvements to autopkgtests.
 .
   [ Matt Barry ]
   * System account home dir defaults to /nonexistent. (Closes: #679746)
   * do not accept all-numeric user names. (Closes: #891748)
   * prompts need y/n/empty(default).
   * Implement SYS_DIR_MODE. (Closes: #1008081, #202943, #398793)
   * Implement SYS_NAME_REGEX. (Closes: #521883, #432562)
   * Deprecate SETGID_HOME.
     Add NEWS/TODO items. (Closes: #643559, #979385, #1008091, #643559)
   * Fix ignored files for --remove-all-files.
     (Closes: #1001863, #588872, #926262, #992163)
   * Redefines the default NO_DEL_PATHS to avoid unnecessary
     scanning.
   * Change deluser_files test to use gzip.
   * Fix deletion of sockets/pipes. (Closes: #685532)
   * Simplify checkname sub.  (Closes: #1006941)
   * Adds support for lock files. (Closes: #983405)
   * Username validity testing framework.
   * Add --allow-all-names to bypass --force-badname.
     (Closes: #520037, #774046)
   * use warnf instead of printf in some places. (Closes: #675804)
   * Support tar --auto-compress for backups. (Closes: #896916)
   * Many improvements to autopkgtests. (Closes: 239825)
 .
   [ Jason Franklin ]
   * Allow for cloned-UID users in group member lists.
     Thanks to Daniel Heimann. (Closes: #701110)
Checksums-Sha1:
 5cbcec9f80e5c73198307edb7040c5c12bb35d3f 1683 adduser_3.122.dsc
 ccf7c4e3efec29257e3b484bb53c2a55d69e0455 230224 adduser_3.122.tar.xz
 27c0ec7f2d7048ddfd7f89dc33012bef7a8e5866 5697 adduser_3.122_source.buildinfo
Checksums-Sha256:
 584ed616d8ac705daffc96564ef45fb34f2eb9663f7348013adea0e4539a869c 1683 adduser_3.122.dsc
 5f093054c0f0c90c313d704f7af6d338f334df793942fafd43e5a8e6c63236c4 230224 adduser_3.122.tar.xz
 7f92d3de2b5ea8da31088424a2043831dedc8aab8f60158e37455cb3a350d63e 5697 adduser_3.122_source.buildinfo
Files:
 0c7d4c5bcd648b829bcaa58101fecbb7 1683 admin important adduser_3.122.dsc
 1da1b75966877f902c4b6d0d5f105609 230224 admin important adduser_3.122.tar.xz
 ab9602ba5d83a6de88ab29bb2e76d961 5697 admin important adduser_3.122_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE6QL5UJ/L0pcuNEbjj3cgEwEyBEIFAmLPEWMACgkQj3cgEwEy
BELCfhAAujNsWZNpvvi2vpDICGMPprz7MooXq5B4fe6fR6nR5Pizh+0E9Skh7NVl
Z5qJvIzcNcva+/TYkml0wO77H1fPefQ+sgxCHmtUTBwK9LZPdh0b6MrWK7hWnhk0
QI/mRMKoNUrMSpVz6suvetUrHvVymWBv/hsQHTt5uSOAB/Wqwbfdt0VFYgQ2i+Yd
Vtr1+U4yjPZ+j9kAFg7HYnVc2Jh8J07ipRrSRnC07AB3wvwcunUiv2fOzJi4S51S
9n/LllsXNS4629siVKDspKOtaak3dpXRPLHFgB+hPlZRhdCCKWoto9TrY1e3XY8N
zZRSYVULaH9OkuIFx6yoUuChhDmteyZ+C0TJlv+qaigf34/qaqF15pu4ee5ZlmuT
SYHI2vcYQ0yXJ92U2U56hYvlzFZufyopWUQkALKwGEzq13LMlMtTJhKypl2PnwzF
jL/n0r0P92kSUd0BAFuzsdp3PPkQoTG9hSTf5BQAXN9JR1dYkIjc95si8KKZ+FD+
Gda+o46EUo3tLgAYGxStxoPsgNb8n2mePrFB5cXERL84uimeVNMg4Hnmt8+cqnYw
jbdDxODIBNsgoCYEqqTe2NOyBQv5gPb0PXYekiHNFRH70sTJDPIjQkrnrYQX73xZ
W5ap2XFEMpqGrFa8VyUwRl15/MAg5Ds0bRi7GzlGPKIKKK8PFFI=
=6vgg
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.