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

Re: virtual permissions and virtual_gid_maps problems

Expand Messages
  • Dan
    Gid inherits top level directory GID? sunsaturn:/website/vuser# rm -rf test2.com sunsaturn:/website/vuser# echo test|mail sdfs@test2.com
    Message 1 of 19 , Dec 1, 2010
    • 0 Attachment
      Gid inherits top level directory GID?

      sunsaturn:/website/vuser# rm -rf test2.com
      sunsaturn:/website/vuser# echo test|mail sdfs@...
      sunsaturn:/website/vuser# ls -al test2.com/test2/Maildir/new/
      total 6K
      drwx------ 2 2003 postfix 512 Dec 1 05:45 .
      drwx------ 5 2003 postfix 512 Dec 1 05:45 ..
      -rw------- 1 2003 postfix 345 Dec 1 05:45
      1291203903.V59I11b8c3fM163820.sunsaturn.com
      sunsaturn:/website/vuser#

      sunsaturn:/website/vuser# rm -rf test2.com
      sunsaturn:/website/vuser# mkdir test2.com
      sunsaturn:/website/vuser# chown 2003:vuser test2.com/
      sunsaturn:/website/vuser# echo test|mail sdfs@...
      sunsaturn:/website/vuser# ls -al test2.com/test2/Maildir/new/
      total 6K
      drwx------ 2 2003 vuser 512 Dec 1 05:46 .
      drwx------ 5 2003 vuser 512 Dec 1 05:46 ..
      -rw------- 1 2003 vuser 345 Dec 1 05:46
      1291203979.V59I11b8c44M498531.sunsaturn.com
      sunsaturn:/website/vuser#


      A patch just to euid change to root, create directory and change
      permissions of directory to correct uid and gid would solve this issue
      completely as it seems it inherts gid.


      Dan.



      On Tue, 30 Nov 2010, Dan wrote:

      >
      >
      > maildir.c mods:
      >
      > msg_info("TESTING1 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
      > (long) usr_attr.gid);
      > set_eugid(usr_attr.uid, usr_attr.gid);
      > msg_info("TESTING2 set_eugid: euid %ld egid %ld", (long) usr_attr.uid,
      > (long) usr_attr.gid);
      >
      >
      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: deliver_maildir[3]: recip
      > test2@... deliver test2@...
      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING1 set_eugid: euid
      > 2003 egid 2001
      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 2003 egid
      > 2001
      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: TESTING2 set_eugid: euid
      > 2003 egid 2001
      > Nov 30 22:21:55 sunsaturn postfix/virtual[53617]: set_eugid: euid 125 egid
      > 125
      >
      > Appears to be a freebsd issue with GID from what I can see if this works for
      > linux users.
      >
      > Either way I was hoping for a mod on maildir.c for initial create of
      > directory as root.
      >
      > Can debug gid issue more if you like to get freebsd to play nice, but uid is
      > only thing that will matter regardless for permissions, but be nice to fix
      > anyways.
      >
      >
      >
      > Dan.
      >
      >
      >
      > On Tue, 30 Nov 2010, Dan wrote:
      >
      >>
      >> #####################Chmod 755 mkdir problem#########################
      >>
      >> Ok enabling "virtual -v" and nuking /website/vuser with chmod 755 on it we
      >> have:
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: recip
      >> test2@... deliver test2@...
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
      >> attempting to connect to host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
      >> connection to host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
      >> query from host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
      >> retrieved 1 rows
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
      >> virtual_mailbox_maps:
      >> mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
      >> test2@... = test2.com/test2/Maildir/
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
      >> test2@... -> test2.com/test2/Maildir/
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
      >> attempting to connect to host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
      >> connection to host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
      >> query from host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
      >> retrieved 1 rows
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
      >> virtual_uid_maps:
      >> mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
      >> test2@... = 2003
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
      >> test2@... -> 2003
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_get_active:
      >> attempting to connect to host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
      >> connection to host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql: successful
      >> query from host unix:/tmp/mysql.sock
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: dict_mysql_lookup:
      >> retrieved 1 rows
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: maps_find:
      >> virtual_gid_maps:
      >> mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
      >> test2@... = 2001
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: mail_addr_find:
      >> test2@... -> 2001
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_mailbox[2]: set
      >> user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: deliver_maildir[3]: recip
      >> test2@... deliver test2@...
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 2003 egid
      >> 2001
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: set_eugid: euid 125 egid
      >> 125
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: maildir access
      >> problem for UID/GID=2003/2001: create maildir file
      >> /website/vuser/test2.com/test2/Maildir/tmp/1291172927.P25625.sunsaturn.com:
      >> Permission denied
      >> Nov 30 21:08:47 sunsaturn postfix/virtual[25625]: warning: perhaps you need
      >> to create the maildirs in advance
      >>
      >> #####################Chmod 777 GID problem#########################
      >>
      >> lets go back to chmod 777 /website/vuser and check GID issues:
      >>
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: recip
      >> test2@... deliver test2@...
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
      >> attempting to connect to host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
      >> connection to host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
      >> query from host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
      >> retrieved 1 rows
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
      >> virtual_mailbox_maps:
      >> mysql:/usr/local/etc/postfix/mysql_mailbox.cf(0,lock|no_regsub|no_proxy|no_unauth):
      >> test2@... = test2.com/test2/Maildir/
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
      >> test2@... -> test2.com/test2/Maildir/
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
      >> attempting to connect to host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
      >> connection to host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
      >> query from host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
      >> retrieved 1 rows
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
      >> virtual_uid_maps:
      >> mysql:/usr/local/etc/postfix/mysql_uids.cf(0,lock|no_regsub|no_proxy|no_unauth):
      >> test2@... = 2003
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
      >> test2@... -> 2003
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_get_active:
      >> attempting to connect to host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
      >> connection to host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql: successful
      >> query from host unix:/tmp/mysql.sock
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: dict_mysql_lookup:
      >> retrieved 1 rows
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: maps_find:
      >> virtual_gid_maps:
      >> mysql:/usr/local/etc/postfix/mysql_gids.cf(0,lock|no_regsub|no_proxy|no_unauth):
      >> test2@... = 2001
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: mail_addr_find:
      >> test2@... -> 2001
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_mailbox[2]: set
      >> user_attr: /website/vuser/test2.com/test2/Maildir/, uid = 2003, gid = 2001
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_maildir[3]: recip
      >> test2@... deliver test2@...
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 2003 egid
      >> 2001
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: set_eugid: euid 125 egid
      >> 125
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: 6FE80119C5B:
      >> to=<test2@...>, relay=virtual, delay=0.06, delays=0.03/0.02/0/0.01,
      >> dsn=2.0.0, status=sent (delivered to maildir)
      >> Nov 30 21:13:24 sunsaturn postfix/virtual[25712]: deliver_request_final:
      >> send: "" 0
      >>
      >>
      >>> src/virtual/mailbox.c:deliver_maildir():
      >>>
      >>> set_eugid(usr_attr.uid, usr_attr.gid);
      >>>
      >>> /* Creates files, writes data, ... */
      >>
      >> I can only think there is an issue here with usr_attr.gid for GID problem.
      >>
      >> For creating initial directory it should set_eugid(0,0); create directory
      >> then change permissions on it because how are we suppose to not 777 the
      >> directory if everytime it creates a new file in there its owned by uid 2002
      >> then 2003 then 2004 and so on...
      >>
      >> Code is fine way it is except for initial creation.
      >>
      >> Another note: I beleive you made a typo?
      >>> src/virtual/mailbox.c:deliver_maildir():
      >> should be src/virtual/maildir.c:deliver_maildir():
      >>
      >> Lets modify src/virtual/maildir.c to just touch a /tmp/file after
      >> set_eugid(usr_attr.uid, usr_attr.gid);
      >> by placing
      >> system("/usr/bin/touch /tmp/gid_debug.txt");
      >>
      >> right after and see what /tmp/gid_debug.txt looks like.
      >>
      >> sunsaturn:/usr/ports/mail/postfix-current# echo test|mail test2@...
      >> sunsaturn:/usr/ports/mail/postfix-current# ls -al /tmp/gid*
      >> -rw------- 1 2003 wheel 0 Nov 30 21:54 /tmp/gid_debug.txt
      >> sunsaturn:/usr/ports/mail/postfix-current#
      >>
      >> so we definately have an issue with usr_attr.gid here somewhere.
      >>
      >>
      >> for your own reference:
      >>
      >> sunsaturn:/website/vuser# tmp=$(mktemp /tmp/test.XXXXXX)
      >> sunsaturn:/website/vuser# chown 2003:2001 "$tmp"
      >> sunsaturn:/website/vuser# ls -l "$tmp"
      >> -rw------- 1 2003 vuser 0 Nov 30 21:19 /tmp/test.Kev8V1
      >> sunsaturn:/website/vuser# rm "$tmp"
      >>
      >>
      >> Dan.
      >>
      >>
      >>
      >> On Tue, 30 Nov 2010, Victor Duchovni wrote:
      >>
      >>> On Tue, Nov 30, 2010 at 07:39:39PM -0600, Dan wrote:
      >>>
      >>>> virtual_gid_maps = mysql:$config_directory/mysql_gids.cf
      >>>> virtual_minimum_uid = 2002
      >>>> virtual_uid_maps = mysql:$config_directory/mysql_uids.cf
      >>>>
      >>>> Mysql relevant table entries:
      >>>>
      >>>> email domain maildir
      >>>> test2@... test2.com test2.com/test2/Maildir/
      >>>>
      >>>> uid gid
      >>>> 2003 2001
      >>>
      >>> And in /etc/group, what is group 2001?
      >>>
      >>>> Now lets chmod 777 /website/vuser so that it can create directories under
      >>>> UID/GID=2003/2001 as it wants but in fact see that gid never is 2001.
      >>>> Gid 2001 under my system is vuser:
      >>>> sunsaturn:~# grep 2001 /etc/group
      >>>> vuser:*:2001:
      >>>
      >>> Prove this by posting the output of:
      >>>
      >>> # tmp=$(mktemp /tmp/test.XXXXXX)
      >>> # chown 2003:2001 "$tmp"
      >>> # ls -l "$tmp"
      >>> # rm "$tmp"
      >>>
      >>>> sunsaturn:~# chmod 777 /website/vuser; cd /website/vuser
      >>>
      >>> Never use world-writable directories in this context.
      >>>
      >>>> Nov 30 19:28:03 sunsaturn postfix/virtual[23237]: DC276119C60:
      >>>> to=<test2@...>, relay=virtual, delay=0.01, delays=0.01/0/0/0,
      >>>> dsn=2.0.0, status=sent (delivered to maildir)
      >>>> Nov 30 19:29:03 sunsaturn postfix/virtual[23237]: 3EA8C119C56:
      >>>> to=<test2@...>, relay=virtual, delay=372, delays=372/0/0/0,
      >>>> dsn=2.0.0, status=sent (delivered to maildir)
      >>>
      >>>> -rw------- 1 2003 postfix 347 Nov 30 19:28
      >>>> test2.com/test2/Maildir/new/1291166883.V59Ib97008M906598.sunsaturn.com
      >>>> -rw------- 1 2003 postfix 347 Nov 30 19:29
      >>>> test2.com/test2/Maildir/new/1291166943.V59Ib97001M911353.sunsaturn.com
      >>>
      >>> Well Postfix asks the operating system nicely by setting its effective
      >>> uid and gid. If the operating system does not cooperate, you need to
      >>> find out why.
      >>>
      >>> src/virtual/mailbox.c:deliver_mailbox():
      >>>
      >>> /* Look up the mailbox owner rights. Defer in case of trouble. */
      >>> uid_res = mail_addr_find(virtual_uid_maps, state.msg_attr.user,
      >>> IGNORE_EXTENSION);
      >>> if (uid_res == 0) { /* error handling */ }
      >>> if ((n = atol(uid_res)) < var_virt_minimum_uid) { /* error handling */
      >>> }
      >>> usr_attr.uid = (uid_t) n;
      >>>
      >>> /* Look up the mailbox group rights. Defer in case of trouble. */
      >>> gid_res = mail_addr_find(virtual_gid_maps, state.msg_attr.user,
      >>> IGNORE_EXTENSION);
      >>> if (gid_res == 0) { /* error handling */ }
      >>> if ((n = atol(gid_res)) <= 0) { /* error handling */ }
      >>> usr_attr.gid = (gid_t) n;
      >>>
      >>> if (msg_verbose)
      >>> msg_info("%s[%d]: set user_attr: %s, uid = %u, gid = %u",
      >>> myname, state.level, usr_attr.mailbox,
      >>> (unsigned) usr_attr.uid, (unsigned) usr_attr.gid);
      >>>
      >>> You can configure "virtual -v" in master.cf to see the uid/gid logged.
      >>>
      >>> /* Deliver to mailbox or to maildir. */
      >>> #define LAST_CHAR(s) (s[strlen(s) - 1])
      >>>
      >>> if (LAST_CHAR(usr_attr.mailbox) == '/')
      >>> *statusp = deliver_maildir(state, usr_attr);
      >>> else
      >>> *statusp = deliver_mailbox_file(state, usr_attr);
      >>>
      >>> src/virtual/mailbox.c:deliver_maildir():
      >>>
      >>> set_eugid(usr_attr.uid, usr_attr.gid);
      >>>
      >>> /* Creates files, writes data, ... */
      >>>
      >>> set_eugid(var_owner_uid, var_owner_gid);
      >>>
      >>> --
      >>> Viktor.
      >>>
      >>
      >
    • Wietse Venema
      ... Turn off the SETGID bit in the PARENT directory. Wietse
      Message 2 of 19 , Dec 1, 2010
      • 0 Attachment
        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 3 of 19 , Dec 1, 2010
        • 0 Attachment
          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 4 of 19 , Dec 1, 2010
          • 0 Attachment
            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 5 of 19 , Dec 1, 2010
            • 0 Attachment
              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 6 of 19 , Dec 1, 2010
              • 0 Attachment
                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 7 of 19 , Dec 1, 2010
                • 0 Attachment
                  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 8 of 19 , Dec 1, 2010
                  • 0 Attachment
                    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 9 of 19 , Dec 1, 2010
                    • 0 Attachment
                      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 10 of 19 , Dec 2, 2010
                      • 0 Attachment
                        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.