reassign 407231 adduser retitle 407231 adduser: with addgroup, users may gain system group access on package installation by coincidence thanks
Quoting Leonard Norrgård ([EMAIL PROTECTED]): > Package: passwd > Version: 1:4.0.18.1-6 > Severity: critical > Tags: security > Justification: root security hole > > > An ordinary user may end up with group ownership of system files > in the following scenario [2]: > > 1. A user is added, and receives the user and group ids, <name>. > 2. Later, a package is installed that asks for an identically named > system group to be created, using 'addgroup --system <name>'. > 3. Addgroup returns with a success exit status, showing the message > 'The group `<name>' already exists as a system group. Exiting.", > even though the pre-existing <name> group, as a group added for > a user has a non-system id (ie. outside the range 100-999 [1]. > 4. The user <name> now has access to all system files that are > installed for the <name> group. > > The problem occurs because in /usr/sbin/addgroup, the code on/after > line 247 to existing_group_ok fails to check for and handle > the situation where the existing GID is outside of the system GID > boundaries. > > [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2) > [2] I discovered this while working on the packaging for kvm, which > will create a 'kvm' group, likely to collide with existing user > id:s on some systems. Thanks for your detailed explanations and bug report. I won't go into the details, essentially because this bug report is misdirected. At first glance, you seem to be right and the bug seems easy to handle. You identified the bug as a bug in the "addgroup" utility. However "dpkg -S /usr/sbin/addgroup" will show you that this utility belongs to the "adduser" package, not passwd. I'm therefore reassigning this bug to adduser. Again, thanks a lot for your care investigating this issue.
signature.asc
Description: Digital signature
