FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-22-2010, 11:14 AM
Martin-Éric Racine
 
Default Bug#582441: /var/spool/cups-pdf/ANONYMOUS is inappropriately owned by nobody:nogroup

On Thu, May 20, 2010 at 10:26 PM, Roger Leigh <rleigh@debian.org> wrote:
> Package: cups-pdf
> Version: 2.5.0-14
> Severity: normal
>
> % ls -ld /var/spool/cups-pdf/ANONYMOUS
> drwxrwxrwt 2 nobody nogroup 4096 Jan 27 *2009 /var/spool/cups-pdf/ANONYMOUS
>
> This directory is world-writable with the sticky-bit set, which allows
> any user to create files and directories in this location. *However, the
> ownership is not appropriate; compare with /tmp:
>
> % ls -ld /tmp
> drwxrwxrwt 13 root root 300 May 20 20:20 /tmp
>
> The ownership by nobody:nogroup gives processes run under this
> UID and/or GID additional privileges to delete content under this
> location. *Given that they are intended to be a restricted-privilege
> user/group, this is not appropriate. *Ownership by root:root is
> perfectly acceptable here (if you're creating files in here owned
> by nobody:nogroup that will still work fine).

If I recall correctly, it was suggested that I'd make this directory
owned by nobody:nogroup to give it the lowest possible priority,
because of the risky way that Samba accesses this spool when offering
login-free guest printer access. I welcome debian-devel's input on
whether this statement is correct or not.

Martin-Éric


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTimv2eZRwR6NORhSXDExNCXzW5thVWOIdBYvnfDj@mail .gmail.com">http://lists.debian.org/AANLkTimv2eZRwR6NORhSXDExNCXzW5thVWOIdBYvnfDj@mail .gmail.com
 
Old 05-22-2010, 08:55 PM
Roger Leigh
 
Default Bug#582441: /var/spool/cups-pdf/ANONYMOUS is inappropriately owned by nobody:nogroup

On 22/05/2010 12:14, Martin-Éric Racine wrote:

On Thu, May 20, 2010 at 10:26 PM, Roger Leigh<rleigh@debian.org> wrote:

Package: cups-pdf
Version: 2.5.0-14
Severity: normal

% ls -ld /var/spool/cups-pdf/ANONYMOUS
drwxrwxrwt 2 nobody nogroup 4096 Jan 27 2009 /var/spool/cups-pdf/ANONYMOUS

This directory is world-writable with the sticky-bit set, which allows
any user to create files and directories in this location. However, the
ownership is not appropriate; compare with /tmp:

% ls -ld /tmp
drwxrwxrwt 13 root root 300 May 20 20:20 /tmp

The ownership by nobody:nogroup gives processes run under this
UID and/or GID additional privileges to delete content under this
location. Given that they are intended to be a restricted-privilege
user/group, this is not appropriate. Ownership by root:root is
perfectly acceptable here (if you're creating files in here owned
by nobody:nogroup that will still work fine).


If I recall correctly, it was suggested that I'd make this directory
owned by nobody:nogroup to give it the lowest possible priority,
because of the risky way that Samba accesses this spool when offering
login-free guest printer access. I welcome debian-devel's input on
whether this statement is correct or not.


This probably needs some clarification from the Samba maintainers, but I
don't at first glance see why it's any safer than root:root; from the
way I see it, it's actually less secure due to the unwarranted extra
authority you're granting the nobody user.


If Samba is running with an EUID/EGID of root/root, it has the ability
to read/write in that location under any circumstances. Given that
other has rwx/sticky, any user can read/write here whatever their
EUID/EGID, including Samba. So I'm not sure what's different between
root:root and nobody:nogroup from the Samba POV: it has equal rights
under both circumstances.


From the system POV, if owned by root:root with 01777 perms, any user
may create and delete *their own* files. Only root may delete files
owned by non-root users (since they own the directory). Likewise if
owned by nobody:nogroup, any user may create and delete their own files,
but in this case any file may be deleted *by user nobody*.


Given that user nobody is a minimum-privilege account, you've actually
escalated the privileges nobody has by creating a directory owned by
nobody--the nobody user, and any daemons running as nobody, now have the
power to delete other users' files under this location. Clearly, this
is no longer "minimum privilege". i.e. nobody is kept having minimal
privs by not creating files/directories owned by nobody which can allow
situations like this to arise.


Hopefully you can see where I'm coming from with this, and appreciate
the potential for abuse and the security considerations related to that;
I'd be interested to know more about the rationale from the Samba side.



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BF844CB.20806@codelibre.net">http://lists.debian.org/4BF844CB.20806@codelibre.net
 

Thread Tools




All times are GMT. The time now is 08:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org