Loading ...
Sorry, an error occurred while loading the content.
 

Re: virtual permissions and virtual_gid_maps problems

Expand Messages
  • Wietse Venema
    ... Turn off the SETGID bit in the PARENT directory. Wietse
    Message 1 of 19 , Dec 1, 2010
      Dan:
      >
      > Gid inherits top level directory GID?

      Turn off the SETGID bit in the PARENT directory.

      Wietse
    • Dan
      There is no setgid bit set. I had to chmod 777 the /website/vuser directory just so that new user creates would work otherwise when it changes uid to some
      Message 2 of 19 , Dec 1, 2010
        There is no setgid bit set.
        I had to chmod 777 the /website/vuser directory just so that new user
        creates would work otherwise when it changes uid to some virtual id such
        as 2003, it would not be allowed to create anything in the directory to
        begin with no matter who owned it.

        Its really problematic because even if end user creates the
        /website/vuser/test.com directory ahead of time with correct uid and gid
        like postfix seems to need to work, the uids are an autoincrement field
        starting at 2002 for each new added user, so you can see how this could be
        cumbersome quickly.

        The way postfix is currently working only feasible way to do it would be
        every virtual user on system share same uid then that parent directory
        could be
        owned by that user. In that system, every ftp account, imap, pop3, email
        account would be owned by same id. I'm almost considering moving to doing
        it that way just to avoid these issues with postfix, as I'm really trying
        to see any kind of security issues rising from a parent process forking to
        the same uid for everything. Only one I can see is if ftp users were not
        chrooted to their homedirectory they could go around deleting other users
        files. SInce reason I am sharing same gid across all virtual users to
        begin with is to chroot ftp users to their home directory, maybe any
        security risk may be alleviated.

        A correct solution I think however for postfix would be if mkdir fails
        with permission denied errors on parent directory, to change uid to root,
        create directory and change permissions on it.

        I think I may move to sharing same virtual uid and gid for all virtual
        users since ftp chroot is only security risk I can see, and if I ever had
        to move users to a new system and lost permissions on all directories
        would be cumbersome to chown -R each user to respective uid again.


        Dan.



        On Wed, 1 Dec 2010, Wietse Venema wrote:

        > Dan:
        >>
        >> Gid inherits top level directory GID?
        >
        > Turn off the SETGID bit in the PARENT directory.
        >
        > Wietse
        >
      • Jeroen Geilman
        ... What does namei -m /website/vuser say about it ? 777 is almost always wrong; logically, it just needs to be chown :2001 and chmod 775. ... You should not
        Message 3 of 19 , Dec 1, 2010
          On 12/01/2010 01:35 PM, Dan wrote:
          >
          >
          > There is no setgid bit set.
          > I had to chmod 777 the /website/vuser directory just so that new user
          > creates would work otherwise when it changes uid to some virtual id
          > such as 2003, it would not be allowed to create anything in the
          > directory to begin with no matter who owned it.

          What does

          namei -m /website/vuser

          say about it ?

          777 is almost always wrong; logically, it just needs to be chown :2001
          and chmod 775.

          > Its really problematic because even if end user creates the
          > /website/vuser/test.com directory ahead of time

          You should not need to do that with vmailboxes.

          Either the MDA or the IMAP server will create them when needed.

          > with correct uid and gid like postfix seems to need to work, the uids
          > are an autoincrement field starting at 2002 for each new added user,
          > so you can see how this could be cumbersome quickly.
          >
          > The way postfix is currently working only feasible way to do it would
          > be every virtual user on system share same uid then that parent
          > directory could be owned by that user.

          That's the usual way to host virtual mailboxes, yes.

          > In that system, every ftp account, imap, pop3, email account would be
          > owned by same id.

          The same physical *system* ID, yes.
          If this is not what you desire, then using virtual mailbox users makes
          no sense for you at all.

          Just use system users, optionally with an invalid shell if you wish to
          prevent them logging in.

          > I'm almost considering moving to doing it that way just to avoid these
          > issues with postfix, as I'm really trying to see any kind of security
          > issues rising from a parent process forking to the same uid for
          > everything.

          Minor to non-existent, as long as you don't go around chmodding stuff to
          777.

          > Only one I can see is if ftp users were not chrooted to their
          > homedirectory they could go around deleting other users files.

          Use proftpd, it does a virtual chroot.

          > SInce reason I am sharing same gid across all virtual users to begin
          > with is to chroot ftp users to their home directory, maybe any
          > security risk may be alleviated.

          Yes - use proftpd.

          >
          > A correct solution I think however for postfix would be if mkdir fails
          > with permission denied errors on parent directory, to change uid to
          > root, create directory and change permissions on it.

          Absolutely not.
          Postfix wil never execute commands with root privileges unless
          specifically configured to do so, and only then in very limited
          circumstances.

          Allowing postfix to arbitrarily escalate privileges is fail.

          > I think I may move to sharing same virtual uid and gid for all virtual
          > users since ftp chroot is only security risk I can see, and if I ever
          > had to move users to a new system and lost permissions on all
          > directories would be cumbersome to chown -R each user to respective
          > uid again.

          It sounds like you've been unnecessarily complicating things.
          Setting up virtual users for multiple services is fairly easy to
          accomplish, as long as you have some way of making the userdb available
          to all services.

          --
          J.
        • Dan
          Thanks for your input, as far as proftpd goes: The distribution file available at the main distribution site and all mirrors has been compromised. The new file
          Message 4 of 19 , Dec 1, 2010
            Thanks for your input, as far as proftpd goes:

            The distribution file available at the main distribution site and all
            mirrors has been compromised.
            The new file contains a rootkit.

            Original file:
            Name: proftpd-1.3.3c.tar.bz2
            Size: 4166609
            MD5: 8571bd78874b557e98480ed48e2df1d2
            SHA256: ea7f02e21f81e6ce79ebde8bbbd334bd269a039ac9137196a35309f791b24db1

            Compromised file:
            Name: proftpd-1.3.3c.tar.bz2
            Size: 4203030
            MD5: a43df54cc0b16c9e63a1045129d7b144
            SHA256: d56d6d643534fe618b26807948b3cfe43c02b3f7abf7f4a073778c9c1666d1eb

            The difference between original and compromised file (rootkit) is
            attached to this e-mail.


            Dan.



            On Wed, 1 Dec 2010, Jeroen Geilman wrote:

            > On 12/01/2010 01:35 PM, Dan wrote:
            >>
            >>
            >> There is no setgid bit set.
            >> I had to chmod 777 the /website/vuser directory just so that new user
            >> creates would work otherwise when it changes uid to some virtual id such as
            >> 2003, it would not be allowed to create anything in the directory to begin
            >> with no matter who owned it.
            >
            > What does
            >
            > namei -m /website/vuser
            >
            > say about it ?
            >
            > 777 is almost always wrong; logically, it just needs to be chown :2001 and
            > chmod 775.
            >
            >> Its really problematic because even if end user creates the
            >> /website/vuser/test.com directory ahead of time
            >
            > You should not need to do that with vmailboxes.
            >
            > Either the MDA or the IMAP server will create them when needed.
            >
            >> with correct uid and gid like postfix seems to need to work, the uids are
            >> an autoincrement field starting at 2002 for each new added user, so you can
            >> see how this could be cumbersome quickly.
            >>
            >> The way postfix is currently working only feasible way to do it would be
            >> every virtual user on system share same uid then that parent directory
            >> could be owned by that user.
            >
            > That's the usual way to host virtual mailboxes, yes.
            >
            >> In that system, every ftp account, imap, pop3, email account would be owned
            >> by same id.
            >
            > The same physical *system* ID, yes.
            > If this is not what you desire, then using virtual mailbox users makes no
            > sense for you at all.
            >
            > Just use system users, optionally with an invalid shell if you wish to
            > prevent them logging in.
            >
            >> I'm almost considering moving to doing it that way just to avoid these
            >> issues with postfix, as I'm really trying to see any kind of security
            >> issues rising from a parent process forking to the same uid for everything.
            >
            > Minor to non-existent, as long as you don't go around chmodding stuff to 777.
            >
            >> Only one I can see is if ftp users were not chrooted to their homedirectory
            >> they could go around deleting other users files.
            >
            > Use proftpd, it does a virtual chroot.
            >
            >> SInce reason I am sharing same gid across all virtual users to begin with
            >> is to chroot ftp users to their home directory, maybe any security risk may
            >> be alleviated.
            >
            > Yes - use proftpd.
            >
            >>
            >> A correct solution I think however for postfix would be if mkdir fails with
            >> permission denied errors on parent directory, to change uid to root, create
            >> directory and change permissions on it.
            >
            > Absolutely not.
            > Postfix wil never execute commands with root privileges unless specifically
            > configured to do so, and only then in very limited circumstances.
            >
            > Allowing postfix to arbitrarily escalate privileges is fail.
            >
            >> I think I may move to sharing same virtual uid and gid for all virtual
            >> users since ftp chroot is only security risk I can see, and if I ever had
            >> to move users to a new system and lost permissions on all directories would
            >> be cumbersome to chown -R each user to respective uid again.
            >
            > It sounds like you've been unnecessarily complicating things.
            > Setting up virtual users for multiple services is fairly easy to accomplish,
            > as long as you have some way of making the userdb available to all services.
            >
            > --
            > J.
            >
            >
          • Jeroen Geilman
            ... I downloaded the 1.3.3c source and confirmed. Passed it on to the ProFTPd authors and they re looking into it. I will also provide them with the below diff
            Message 5 of 19 , Dec 1, 2010
              On 12/01/2010 02:30 PM, Dan wrote:
              >
              > Thanks for your input, as far as proftpd goes:
              >
              > The distribution file available at the main distribution site and all
              > mirrors has been compromised.
              > The new file contains a rootkit.
              >

              I downloaded the 1.3.3c source and confirmed.
              Passed it on to the ProFTPd authors and they're looking into it.
              I will also provide them with the below diff if you don't mind.

              How did you catch this ?
              Is it a FreeBSD checker of some sort, or do you habitually peruse the
              entire source of new programs :)

              I have used Proftpd many years without it being the victim of such
              abuse, though :)

              > Original file:
              > Name: proftpd-1.3.3c.tar.bz2
              > Size: 4166609
              > MD5: 8571bd78874b557e98480ed48e2df1d2
              > SHA256: ea7f02e21f81e6ce79ebde8bbbd334bd269a039ac9137196a35309f791b24db1
              >
              > Compromised file:
              > Name: proftpd-1.3.3c.tar.bz2
              > Size: 4203030
              > MD5: a43df54cc0b16c9e63a1045129d7b144
              > SHA256: d56d6d643534fe618b26807948b3cfe43c02b3f7abf7f4a073778c9c1666d1eb
              >
              > The difference between original and compromised file (rootkit) is
              > attached to this e-mail.
              >
              >
              > Dan.
              >
              >
              >
              > On Wed, 1 Dec 2010, Jeroen Geilman wrote:
              >
              >> On 12/01/2010 01:35 PM, Dan wrote:
              >>>
              >>>
              >>> There is no setgid bit set.
              >>> I had to chmod 777 the /website/vuser directory just so that new
              >>> user creates would work otherwise when it changes uid to some
              >>> virtual id such as 2003, it would not be allowed to create anything
              >>> in the directory to begin with no matter who owned it.
              >>
              >> What does
              >>
              >> namei -m /website/vuser
              >>
              >> say about it ?
              >>
              >> 777 is almost always wrong; logically, it just needs to be chown
              >> :2001 and chmod 775.
              >>
              >>> Its really problematic because even if end user creates the
              >>> /website/vuser/test.com directory ahead of time
              >>
              >> You should not need to do that with vmailboxes.
              >>
              >> Either the MDA or the IMAP server will create them when needed.
              >>
              >>> with correct uid and gid like postfix seems to need to work, the
              >>> uids are an autoincrement field starting at 2002 for each new added
              >>> user, so you can see how this could be cumbersome quickly.
              >>>
              >>> The way postfix is currently working only feasible way to do it
              >>> would be every virtual user on system share same uid then that
              >>> parent directory could be owned by that user.
              >>
              >> That's the usual way to host virtual mailboxes, yes.
              >>
              >>> In that system, every ftp account, imap, pop3, email account would
              >>> be owned by same id.
              >>
              >> The same physical *system* ID, yes.
              >> If this is not what you desire, then using virtual mailbox users
              >> makes no sense for you at all.
              >>
              >> Just use system users, optionally with an invalid shell if you wish
              >> to prevent them logging in.
              >>
              >>> I'm almost considering moving to doing it that way just to avoid
              >>> these issues with postfix, as I'm really trying to see any kind of
              >>> security issues rising from a parent process forking to the same uid
              >>> for everything.
              >>
              >> Minor to non-existent, as long as you don't go around chmodding stuff
              >> to 777.
              >>
              >>> Only one I can see is if ftp users were not chrooted to their
              >>> homedirectory they could go around deleting other users files.
              >>
              >> Use proftpd, it does a virtual chroot.
              >>
              >>> SInce reason I am sharing same gid across all virtual users to begin
              >>> with is to chroot ftp users to their home directory, maybe any
              >>> security risk may be alleviated.
              >>
              >> Yes - use proftpd.
              >>
              >>>
              >>> A correct solution I think however for postfix would be if mkdir
              >>> fails with permission denied errors on parent directory, to change
              >>> uid to root, create directory and change permissions on it.
              >>
              >> Absolutely not.
              >> Postfix wil never execute commands with root privileges unless
              >> specifically configured to do so, and only then in very limited
              >> circumstances.
              >>
              >> Allowing postfix to arbitrarily escalate privileges is fail.
              >>
              >>> I think I may move to sharing same virtual uid and gid for all
              >>> virtual users since ftp chroot is only security risk I can see, and
              >>> if I ever had to move users to a new system and lost permissions on
              >>> all directories would be cumbersome to chown -R each user to
              >>> respective uid again.
              >>
              >> It sounds like you've been unnecessarily complicating things.
              >> Setting up virtual users for multiple services is fairly easy to
              >> accomplish, as long as you have some way of making the userdb
              >> available to all services.
              >>
              >> --
              >> J.
              >>
              >>


              --
              J.
            • Wietse Venema
              ... Apparently, FreeBSD copies the GID of a new directory from its parent, even when the parent does not have sticky/setwhatever bits set. bristle# mkdir
              Message 6 of 19 , Dec 1, 2010
                Dan:
                > Gid inherits top level directory GID?

                Wietse:
                > Turn off the SETGID bit in the PARENT directory.

                Dan:
                > There is no setgid bit set.

                Apparently, FreeBSD copies the GID of a new directory from its
                parent, even when the parent does not have sticky/setwhatever
                bits set.

                bristle# mkdir /var/spool/wietse
                bristle# chown wietse /var/spool/wietse
                bristle# ls -la /var/spool/wietse
                total 4
                drwxr-xr-x 2 wietse wheel 512 Dec 1 09:02 .
                drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                bristle# su wietse -c 'mkdir /var/spool/wietse/test1'
                bristle# ls -la /var/spool/wietse
                total 6
                drwxr-xr-x 3 wietse wheel 512 Dec 1 09:03 .
                drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                drwxr-xr-x 2 wietse wheel 512 Dec 1 09:03 test1

                The test1 directory has group wietse, even though my process
                has GID 'wietse'.

                Now, I change the parent directory group to 'wietse'
                and create a new directory:

                bristle# chgrp wietse /var/spool/wietse
                bristle# su wietse -c 'mkdir /var/spool/wietse/test2'
                bristle# ls -la /var/spool/wietse
                total 8
                drwxr-xr-x 4 wietse wietse 512 Dec 1 09:03 .
                drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                drwxr-xr-x 2 wietse wheel 512 Dec 1 09:03 test1
                drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test2

                And test2 has the group of 'wietse'.

                bristle# su wietse -c 'chgrp wietse /var/spool/wietse/test1'
                bristle# ls -la /var/spool/wietse
                total 8
                drwxr-xr-x 4 wietse wietse 512 Dec 1 09:03 .
                drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
                drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test1
                drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test2

                To force the group, change the group after mkdir. This
                does not require switching euid to root.

                Wietse

                In src/util/make_dirs.c:
                if ((ret = mkdir(saved_path, perms)) < 0) {
                if (errno != EEXIST)
                break;
                /* Race condition? */
                if ((ret = stat(saved_path, &st)) < 0)
                break;
                if (!S_ISDIR(st.st_mode)) {
                errno = ENOTDIR;
                ret = -1;
                break;
                }
                }
                ===> if ((ret = chown(saved_path, -1, getegid())) < 0)
                ===> break;


                Wietse
              • lst_hoe02@kwsoft.de
                ... They have corrected it, the infected source for download is replaced, but no warning at all for the ones who already downloaded and now using the
                Message 7 of 19 , Dec 1, 2010
                  Zitat von Jeroen Geilman <jeroen@...>:

                  > On 12/01/2010 02:30 PM, Dan wrote:
                  >>
                  >> Thanks for your input, as far as proftpd goes:
                  >>
                  >> The distribution file available at the main distribution site and all
                  >> mirrors has been compromised.
                  >> The new file contains a rootkit.
                  >>
                  >
                  > I downloaded the 1.3.3c source and confirmed.
                  > Passed it on to the ProFTPd authors and they're looking into it.
                  > I will also provide them with the below diff if you don't mind.

                  They have corrected it, the "infected" source for download is
                  replaced, but no warning at all for the ones who already downloaded
                  and now using the trojaned version...

                  Not very encouraging to use Proftpd.

                  Regards

                  Andreas
                • Victor Duchovni
                  ... It seems this applies not just to sub-directories, but also to new files: http://www.manpages.info/freebsd/open.2.html When a new file is created it is
                  Message 8 of 19 , Dec 1, 2010
                    On Wed, Dec 01, 2010 at 10:09:30AM -0500, Wietse Venema wrote:

                    > Apparently, FreeBSD copies the GID of a new directory from its
                    > parent, even when the parent does not have sticky/setwhatever
                    > bits set.

                    It seems this applies not just to sub-directories, but also to new
                    files:

                    http://www.manpages.info/freebsd/open.2.html

                    When a new file is created it is given the group of the directory which
                    contains it.

                    http://www.manpages.info/freebsd/mkdir.2.html

                    The directory's owner ID is set to the process's effective user ID. The
                    directory's group ID is set to that of the parent directory in which it
                    is created.

                    And in http://www.manpages.info/freebsd/mount.2.html, we see:

                    MNT_SUIDDIR Directories with the SUID bit set chown new files to
                    their own owner.

                    without any corresponding mechanism to adjust group ownership inheritance.

                    The OpenGroup POSIX spec says:

                    http://www.opengroup.org/onlinepubs/009695399/functions/mkdir.html

                    The directory's user ID shall be set to the process' effective user
                    ID. The directory's group ID shall be set to the group ID of the parent
                    directory or to the effective group ID of the process. Implementations
                    shall provide a way to initialize the directory's group ID to the
                    group ID of the parent directory. Implementations may, but need not,
                    provide an implementation-defined way to initialize the directory's
                    group ID to the effective group ID of the calling process.

                    http://www.opengroup.org/onlinepubs/009695399/functions/open.html

                    O_CREAT
                    ... the user ID of the file shall be set to the effective user
                    ID of the process; the group ID of the file shall be set to
                    the group ID of the file's parent directory or to the effective
                    group ID of the process; ... Implementations shall provide a
                    way to initialize the file's group ID to the group ID of the
                    parent directory. Implementations may, but need not, provide an
                    implementation-defined way to initialize the file's group ID to the
                    effective group ID of the calling process.

                    --
                    Viktor.
                  • Voytek Eymont
                    ... Andreas, ... Subject: [ProFTPD-announce] ProFTPD ftp.proftpd.org compromise From: TJ Saunders Date: Thu, December 2, 2010 10:43
                    Message 9 of 19 , Dec 2, 2010
                      On Thu, December 2, 2010 7:20 am, lst_hoe02@... wrote:

                      > They have corrected it, the "infected" source for download is
                      > replaced, but no warning at all for the ones who already downloaded and now
                      > using the trojaned version...
                      >
                      > Not very encouraging to use Proftpd.

                      Andreas,

                      fwiw, I got this email today:

                      ---------------------------- Original Message ----------------------------
                      Subject: [ProFTPD-announce] ProFTPD ftp.proftpd.org compromise
                      From: "TJ Saunders" <tj@...>
                      Date: Thu, December 2, 2010 10:43 am
                      To: proftp-announce@...
                      Cc: proftp-devel@...
                      proftp-user@...
                      --------------------------------------------------------------------------

                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      ProFTPD Compromise Report

                      On Sunday, the 28th of November 2010 around 20:00 UTC the main
                      distribution server of the ProFTPD project was compromised. The
                      attackers most likely used an unpatched security issue in the FTP daemon
                      to gain access to the server and used their privileges to replace the
                      source files for ProFTPD 1.3.3c with a version which contained a backdoor.
                      The unauthorized modification of the source code was noticed by
                      Daniel Austin and relayed to the ProFTPD project by Jeroen Geilman on
                      Wednesday, December 1 and fixed shortly afterwards.

                      The fact that the server acted as the main FTP site for the ProFTPD
                      project (ftp.proftpd.org) as well as the rsync distribution server
                      (rsync.proftpd.org) for all ProFTPD mirror servers means that anyone who
                      downloaded ProFTPD 1.3.3c from one of the official mirrors from 2010-11-28
                      to 2010-12-02 will most likely be affected by the problem.

                      The backdoor introduced by the attackers allows unauthenticated users
                      remote root access to systems which run the maliciously modified version
                      of the ProFTPD daemon.

                      Users are strongly advised to check systems running the affected code for
                      security compromises and compile/run a known good version of the code.
                      To verify the integrity of the source files, use the GPG signatures
                      available on the FTP servers as well on the ProFTPD homepage at:

                      http://www.proftpd.org/md5_pgp.html.
                      ---snip-----


                      --
                      Voytek
                    Your message has been successfully submitted and would be delivered to recipients shortly.