Bug#581729: [SQUEEZE] Document the umask change for new installs
Le Sat, May 15, 2010 at 02:16:43PM +0300, Andrei Popescu a écrit : Package: release-notes Severity: whishlist Tags: squeeze X-Debbugs-CC: debian-de...@lists.debian.org On Sat,15.May.10, 08:41:29, Christian PERRIER wrote: More generally speaking, this umask change probably deserves to be mentioned in the Release Notesalong with a good rationale about why, no, this isn't Debian giving up to years of being security-wise. Suggested text: --- The default 'umask' for new installs is changed === Starting with base-files version 5.4 the default umask for new installs is 0002 instead of 0022 for regular users (system users, like the ones used for various daemons and services are not affected). Dear all, because base-files does not set umask anymore since version 5.7, and because the default umask is currently 0022 again (through login.defs and pam_umask), I propose to close this bug. Alternatively, I can submit a patch to document the above. Have a nice day and a happy new year 2011. -- Charles Plessy Illkirch, France -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581729: [SQUEEZE] Document the umask change for new installs
Package: release-notes Severity: whishlist Tags: squeeze X-Debbugs-CC: debian-de...@lists.debian.org On Sat,15.May.10, 08:41:29, Christian PERRIER wrote: More generally speaking, this umask change probably deserves to be mentioned in the Release Notesalong with a good rationale about why, no, this isn't Debian giving up to years of being security-wise. Suggested text: --- The default 'umask' for new installs is changed === Starting with base-files version 5.4 the default umask for new installs is 0002 instead of 0022 for regular users (system users, like the ones used for various daemons and services are not affected). The new umask is more useful on systems where normal users are by default members of an own private group, which no other user belongs to. Such a scheme is known as 'User Private Groups' (UPG) and has been the default in Debian for several releases. This change can however create security and/or privacy issues if the system administrator is not aware of it and adds users to the private group of another user. Also, in order to prevent security issues, some software will detect this and refuse to operate when there are other members in the user's private group and relevant files have permissions as created with a umask of 0002. --- Comments welcome. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote: for regular users Would have to double check it,... but doesn't the current change also affect root? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
Hi Andrei, On Samstag, 15. Mai 2010, Andrei Popescu wrote: Suggested text: Thanks for that! I have one small addition...: This change can however create security and/or privacy issues if the system administrator is not aware of it and adds users to the private group of another user. Also, in order to prevent security issues, some software will detect this and refuse to operate when there are other members in the user's private group and relevant files have permissions as created with a umask of 0002. This paragraph should be accompanied by something like: Instead of adding users to other users private groups (which has issues as explained above) it is recommend to create dedicated groups for these users for collaboration. As in: not only describe how not to do it, but also how to do it. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#581729: [SQUEEZE] Document the umask change for new installs
Le samedi 15 mai 2010 à 13:26:29 (+0200), Christoph Anton Mitterer a écrit : Date: Sat, 15 May 2010 13:26:29 +0200 From: Christoph Anton Mitterer cales...@scientia.net To: 581...@bugs.debian.org Cc: debian-de...@lists.debian.org Subject: Re: Bug#581729: [SQUEEZE] Document the umask change for new installs On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote: for regular users Would have to double check it,... but doesn't the current change also affect root? It does: r...@gaia:~# umask 0002 r...@gaia:~# cd r...@gaia:~# touch test r...@gaia:~# ls -l test -rw-rw-r-- 1 root root 0 15 mai 14:43 test Cheers, Julien -- Julien Valroff jul...@kirya.net http://www.kirya.net GPG key: 4096R/290D20C5 092F 4CB5 5F19 E006 1CFD B489 D32B 8D66 290D 20C5 signature.asc Description: Digital signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
On Sat,15.May.10, 13:26:29, Christoph Anton Mitterer wrote: On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote: for regular users Would have to double check it,... but doesn't the current change also affect root? By default: # grep umask .bashrc umask 022 # Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
Le samedi 15 mai 2010 à 15:59:40 (+0300), Andrei Popescu a écrit : Date: Sat, 15 May 2010 15:59:40 +0300 From: Andrei Popescu andreimpope...@gmail.com To: debian-de...@lists.debian.org Cc: 581...@bugs.debian.org Subject: Re: Bug#581729: [SQUEEZE] Document the umask change for new installs On Sat,15.May.10, 13:26:29, Christoph Anton Mitterer wrote: On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote: for regular users Would have to double check it,... but doesn't the current change also affect root? By default: # grep umask .bashrc umask 022 # This entry is commented by default in /usr/share/base-files/dot.bashrc This file is simply copied to /root/.bashrc in base-file postinst script. Cheers, Julien -- Julien Valroff jul...@kirya.net http://www.kirya.net GPG key: 4096R/290D20C5 092F 4CB5 5F19 E006 1CFD B489 D32B 8D66 290D 20C5 signature.asc Description: Digital signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
On 05/15/2010 05:26 AM, Christoph Anton Mitterer wrote: On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote: for regular users Would have to double check it,... but doesn't the current change also affect root? This does, but root is also in his own UPG. If you add any user to the root group (same this as using wheel on other systems), you're effectively giving that user full root access to the system anyway. So, this change will not have any unsavory side effects for the root user or group. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
On Sat, 2010-05-15 at 15:59 +0300, Andrei Popescu wrote: By default: # grep umask .bashrc umask 022 # Not in the most recent version of base-files, which does not update most of it files. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
On Sat, 2010-05-15 at 07:32 -0600, Aaron Toponce wrote: This does, but root is also in his own UPG. If you add any user to the root group (same this as using wheel on other systems), you're effectively giving that user full root access to the system anyway. So, this change will not have any unsavory side effects for the root user or group. I just meant, that a release notes entry should use a different wording than regular user... Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
On 05/15/2010 05:50 AM, Christoph Anton Mitterer wrote: On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote: This paragraph should be accompanied by something like: Instead of adding users to other users private groups (which has issues as explained above) it is recommend to create dedicated groups for these users for collaboration. Perhaps I'm completely stupid,... but why do we have UPGs then at all? User private groups are NOT intended to add other users too. That's why it's called private. The motivation behind creating a UPG setup was to have more flexible group collaboration, without sacrificing security on the system, or changing how standard UNIX permissions work. This has been discussed already. For those rare cases like a user's wife/husband which is fully trusted? Personally, I trust my wife, and have no problem adding her to my own private group. However, it still is better to create a different group, add both myself and her too, and use that to share the files. There may be a time, when I am shopping online, or working on something I don't want my wife to see, so putting her in my private group might have been a mistake. Even if I fully trust how she'll handle those files. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Bug#581729: [SQUEEZE] Document the umask change for new installs
Le Sat, May 15, 2010 at 02:16:43PM +0300, Andrei Popescu a écrit : The default 'umask' for new installs is changed === Starting with base-files version 5.4 the default umask for new installs is 0002 instead of 0022 for regular users (system users, like the ones used for various daemons and services are not affected). The new umask is more useful on systems where normal users are by default members of an own private group, which no other user belongs to. Such a scheme is known as 'User Private Groups' (UPG) and has been the default in Debian for several releases. This change can however create security and/or privacy issues if the system administrator is not aware of it and adds users to the private group of another user. Also, in order to prevent security issues, some software will detect this and refuse to operate when there are other members in the user's private group and relevant files have permissions as created with a umask of 0002. --- Dear Andrei and DDP team, I would like to suggest a stronger wording, that underlines that user private groups are not designed to be shared. Also, I have not seen on -devel that the idea of having a different umask for system and regular users has been implemented in base-files yet. I propose to not mention this until base-files is updated to support it. I also propose to not mention the version of base-files where the change was done in the release notes, since this is not relevant for stable versions. However, I suggest that we post a very similar notice, but keeping the version information, to the Develpers News (I will do it if nobody is faster than me). I do not know where the announcment of the new umask default would fit the best: in the “What's new” (major changes) section, or in the “Potential problems”. Or what about both? Lastly, I mention the Securing Debian Manual below. I also have opened a bug to update it to the latest umask default (#581753). Have a nice week-end, -- Charles Plessy, Tsurumi, Kanagawa, Japan * For “What's new” (major changes): New default 'umask' for new installs The default 'umask' in Debian is now 0002 instead of 0022. This change takes only effect on fresh installations, and gives write permission to the members of the group owning the user's files (they already had read and access permissions with the previous default). Debian uses by default the 'User Private Groups' (UPG) scheme (URL to wikipedia), where users are members of their own private group, that is not shared with others. The new default simplifies the sharing of files in other (non-private) groups. * For “Potential problems” New default 'umask' for new installs The new default umask of 0002 [insert a convenience link to the “What's new” section] can surprise people used to the previous value of 0022. If the newly installed system is sharing its files, or if its users are copying their files to systems that are not implementing user private groups, write access could be inadvertently given to other group members. Also, the user private groups should never be shared with others. Instead, a collaboration group must be created for sets of users who want to share files. Please refer to the Securing Debian Manual (URL to section “Setting users umasks”) for more details. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581729: [SQUEEZE] Document the umask change for new installs
On Sun, 16 May 2010, Charles Plessy wrote: Also, I have not seen on -devel that the idea of having a different umask for system and regular users has been implemented in base-files yet. I propose to not mention this until base-files is updated to support it. The file /etc/profile is only read for login shells, or shells that pretend to be login shells. Do we really have to make /etc/profile more complex to deal with system users who login to the system? Are there any? (other than root, who already has its Private Group). Is it ok at all that a system user does a login to the system? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
