Upgrade to -3.2.5: permissions question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrade to -3.2.5: permissions question

Rich Shepard
   I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop
and /usr/sbin/postqueue were set gid:

-rwxr-sr-x 1 root root  13888 Jan 28 08:58 /usr/sbin/postdrop*
-rwxr-sr-x 1 root root  18012 Jan 28 08:58 /usr/sbin/postqueue*

   Yet, when I start postfix I see these messages:

Jan 28 09:31:55 salmo postfix/postfix-script[16119]: warning: not owned by
group postdrop: /usr/sbin/postqueue
Jan 28 09:31:55 salmo postfix/postfix-script[16120]: warning: not owned by
group postdrop: /usr/sbin/postdrop
Jan 28 09:31:55 salmo postfix/postfix-script[16124]: starting the Postfix mail
system
Jan 28 09:31:55 salmo postfix/master[16126]: daemon started -- version 3.2.5,
configuration /etc/postfix

   I've not seen these warnings in prior upgrades and would appreciate
learning what I need to change to remove them.

Regards,

Rich


Reply | Threaded
Open this post in threaded view
|

RE: Upgrade to -3.2.5: permissions question

Robert Wolfe
I would first check and see if group "postdrop" exists.  Then, if so, I
would recommend running a "chown root:postdrop" on these files.  But, of
course, YMMV.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Rich Shepard
Sent: Sunday, January 28, 2018 12:12 PM
To: [hidden email]
Subject: Upgrade to -3.2.5: permissions question

   I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop
and /usr/sbin/postqueue were set gid:

-rwxr-sr-x 1 root root  13888 Jan 28 08:58 /usr/sbin/postdrop* -rwxr-sr-x 1
root root  18012 Jan 28 08:58 /usr/sbin/postqueue*

   Yet, when I start postfix I see these messages:

Jan 28 09:31:55 salmo postfix/postfix-script[16119]: warning: not owned by
group postdrop: /usr/sbin/postqueue Jan 28 09:31:55 salmo
postfix/postfix-script[16120]: warning: not owned by group postdrop:
/usr/sbin/postdrop Jan 28 09:31:55 salmo postfix/postfix-script[16124]:
starting the Postfix mail system Jan 28 09:31:55 salmo
postfix/master[16126]: daemon started -- version 3.2.5, configuration
/etc/postfix

   I've not seen these warnings in prior upgrades and would appreciate
learning what I need to change to remove them.

Regards,

Rich



Reply | Threaded
Open this post in threaded view
|

RE: Upgrade to -3.2.5: permissions question

Rich Shepard
On Sun, 28 Jan 2018, [hidden email] wrote:

> I would first check and see if group "postdrop" exists. Then, if so, I
> would recommend running a "chown root:postdrop" on these files. But, of
> course, YMMV.

Robert,

   postdrop still is a group. What I had neglected in my post-installation
notes was to change the group to postdrop for those two scripts prior to
running set-gid on them.

Thanks very much,

Rich


Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Viktor Dukhovni
In reply to this post by Rich Shepard


> On Jan 28, 2018, at 1:11 PM, Rich Shepard <[hidden email]> wrote:
>
>  I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop
> and /usr/sbin/postqueue were set gid:
>
> -rwxr-sr-x 1 root root  13888 Jan 28 08:58 /usr/sbin/postdrop*
> -rwxr-sr-x 1 root root  18012 Jan 28 08:58 /usr/sbin/postqueue*
>
>  Yet, when I start postfix I see these messages:
>
> Jan 28 09:31:55 salmo postfix/postfix-script[16119]: warning: not owned by group postdrop: /usr/sbin/postqueue
> Jan 28 09:31:55 salmo postfix/postfix-script[16120]: warning: not owned by group postdrop: /usr/sbin/postdrop
> Jan 28 09:31:55 salmo postfix/postfix-script[16124]: starting the Postfix mail system
> Jan 28 09:31:55 salmo postfix/master[16126]: daemon started -- version 3.2.5, configuration /etc/postfix
>
>  I've not seen these warnings in prior upgrades and would appreciate
> learning what I need to change to remove them.

You're not supposed to do this "by hand".  Instead, when upgrading from source, run:

  # postfix set-permissions upgrade-configuration

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Rich Shepard
On Sun, 28 Jan 2018, Viktor Dukhovni wrote:

>  # postfix set-permissions upgrade-configuration

Viktor,

   I thought there was a procedure for post-upgrade configuration but had
forgotten where I had seen it.

   Thanks very much for the information. It now resides where I'll see it
(and use it) from now on.

Regards,

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Viktor Dukhovni


> On Jan 28, 2018, at 2:08 PM, Rich Shepard <[hidden email]> wrote:
>
> On Sun, 28 Jan 2018, Viktor Dukhovni wrote:
>
>> # postfix set-permissions upgrade-configuration

Note that "make; make upgrade" would normally take care of this, perhaps you're
doing something else (needlessly complicated)?

> I thought there was a procedure for post-upgrade configuration but had
> forgotten where I had seen it.

Also see:

   http://www.postfix.org/PACKAGE_README.html

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Rich Shepard
On Sun, 28 Jan 2018, Viktor Dukhovni wrote:

> Note that "make; make upgrade" would normally take care of this, perhaps
> you're doing something else (needlessly complicated)?

Viktor,

   I use the SlackBuilds.org build script (as I do for all my installations
and upgrades).

> Also see:
>   http://www.postfix.org/PACKAGE_README.html

   Will do.

Thanks again,

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Wietse Venema
In reply to this post by Rich Shepard
Rich Shepard:
>    postdrop still is a group. What I had neglected in my post-installation
> notes was to change the group to postdrop for those two scripts prior to
> running set-gid on them.

You're not supposed to chown the files. That is part of the
Postfix installation/upgrade process. If you use some non-Postfix
installation/upgrade procedure, then that is broken.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Viktor Dukhovni
In reply to this post by Rich Shepard


> On Jan 28, 2018, at 2:41 PM, Rich Shepard <[hidden email]> wrote:
>
> I use the SlackBuilds.org build script (as I do for all my installations
> and upgrades).

Please file a bug report for the build scripts in question.  When it installs
Postfix, it should run "postfix set-permissions" and perform some equivalent
of "postfix upgrade-configuration".  Punting this step to the user is wrong:

   http://slackbuilds.org/repository/14.2/network/postfix/

   ...

   When upgrading from an older postfix version, make sure the variables such as
   html_directory and readme_directory in /etc/postfix/main.cf point to the new
   location. These can also be fixed later, afterwards make sure to run:

      postfix set-permissions

Not surprisingly, that bit of advice does not always followed.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Rich Shepard
On Sun, 28 Jan 2018, Viktor Dukhovni wrote:

>   When upgrading from an older postfix version, make sure the variables such as
>   html_directory and readme_directory in /etc/postfix/main.cf point to the new
>   location. These can also be fixed later, afterwards make sure to run:
>
>      postfix set-permissions
>
> Not surprisingly, that bit of advice does not always followed.

Viktor,

   It's been a very long time since I looked at that page and that advice
might well have been added since my last visit. I change the version number
in the build script and it Just Works.

   Thanks for pointing out that the maintainer does write to run the
set-permissions script.

Regards,

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Rich Shepard
In reply to this post by Wietse Venema
On Sun, 28 Jan 2018, Wietse Venema wrote:

> You're not supposed to chown the files. That is part of the Postfix
> installation/upgrade process. If you use some non-Postfix
> installation/upgrade procedure, then that is broken.

Wietse,

   Next upgrade I'll run the set-permissions script.

Thanks,

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Wietse Venema
Rich Shepard:
> On Sun, 28 Jan 2018, Wietse Venema wrote:
>
> > You're not supposed to chown the files. That is part of the Postfix
> > installation/upgrade process. If you use some non-Postfix
> > installation/upgrade procedure, then that is broken.
>
> Wietse,
>
>    Next upgrade I'll run the set-permissions script.

Please tell the maintainer that it they need to run the
command, not the user.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Rich Shepard
On Sun, 28 Jan 2018, Wietse Venema wrote:

> Please tell the maintainer that it they need to run the command, not the
> user.

Wietse,

   I'll do this.

Thanks,

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Michael Orlitzky-2
In reply to this post by Viktor Dukhovni
On 01/28/2018 01:53 PM, Viktor Dukhovni wrote:
>
> You're not supposed to do this "by hand".  Instead, when upgrading from source, run:
>
>   # postfix set-permissions upgrade-configuration
>

How sensitive is the $mail_owner account? From what I gather, the
set-permissions script (which defers to post-install) is intended to be
run more than once on the same system. It reads postfix-files, which
contains e.g.

  $queue_directory/active:d:$mail_owner:-:700:ucr

and then in post-install, lines like that are read...

  while IFS=: read path type owner group mode flags junk

and the flags are parsed:

  case $flags in *u*) upgrade_flag=1;; *) upgrade_flag=;; esac
  case $flags in *c*) create_flag=1;; *) create_flag=;; esac
  case $flags in *r*) recursive="-R";; *) recursive=;; esac

In particular, that will result in "chown -R" being called on my active
queue directory whenever "postfix set-permissions" is run:

  test -n "$set_permission" && {
    chown $recursive $owner $path || exit 1

My question is, can't the $mail_owner -- who knows that this is going to
take place eventually -- throw a hard link into the active queue that
points to a sensitive file? Proof of concept:

  $ sudo su postfix -s /bin/sh -c 'ln /etc/passwd
                                    /var/spool/postfix/active/x'
  $ sudo postfix set-permissions
  $ ls /etc/passwd
  -rw-r--r-- 2 postfix root 1.4K 2018-01-27 11:47 /etc/passwd
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Michael Orlitzky-2
On 01/29/2018 12:25 PM, Joris (ideeel) wrote:
>
> Doesnt postfix use proxymap for that?
> http://www.postfix.org/proxymap.8.html
>

For what? I'm wondering whether or not the upgrade procedure is safe
w.r.t. the $mail_owner user.
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Viktor Dukhovni
In reply to this post by Michael Orlitzky-2


> On Jan 29, 2018, at 12:21 PM, Michael Orlitzky <[hidden email]> wrote:
>
> My question is, can't the $mail_owner -- who knows that this is going to
> take place eventually -- throw a hard link into the active queue that
> points to a sensitive file? Proof of concept:
>
>  $ sudo su postfix -s /bin/sh -c 'ln /etc/passwd
>                                    /var/spool/postfix/active/x'
>  $ sudo postfix set-permissions
>  $ ls /etc/passwd
>  -rw-r--r-- 2 postfix root 1.4K 2018-01-27 11:47 /etc/passwd

This issue affects a lot more than just Postfix, for example tar(1)
when run as root will chown files to the owner listed in the archive
metadata, and is almost certainly equally exposed.

Therefore, while it may be possible to attempt to work around this
in Postfix, the only sensible solution is at the OS level.  See

   https://danwalsh.livejournal.com/64493.html
   https://www.mjmwired.net/kernel/Documentation/sysctl/fs.txt#184

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Michael Orlitzky-2
On 01/29/2018 03:31 PM, Viktor Dukhovni wrote:
>
> This issue affects a lot more than just Postfix, for example tar(1)
> when run as root will chown files to the owner listed in the archive
> metadata, and is almost certainly equally exposed.

I'm not 100% sure, but it looks like GNU tar will use fchown on the
newly-extracted fd to avoid this problem. But you're right that a lot of
other software does the same thing.


> Therefore, while it may be possible to attempt to work around this
> in Postfix, the only sensible solution is at the OS level.

Alas, those linking restrictions are still disabled by default on a
vanilla linux kernel (upstream rejected the patch to enable them), and
on every non-linux OS.

If you absolutely must do a recursive, *automated* ownership change, the
best defense that I'm aware of is to immediately call fstatat() on the
fd obtained from openat() at each stage of the recursive traversal. If
the descriptor has more than one link, reject it as suspicious. There's
still a tiny window between openat() and fstatat() where the attacker
can delete his link (so that your fd points to something juicy, but the
link count is 1), but AFAIK that's as good as it gets.

If you need to do a recursive chown that isn't automated -- like for
example to update $old_mail_owner to $new_mail_owner -- then e.g. GNU
chown has the "--from" option to prevent $old_mail_owner from
introducing hard links.

The best case is when you don't really need to do the recursive chown at
all. Since we have

  $queue_directory:d:root:-:755:uc

it's safe for root to call chown non-recursively on "active/" and
friends. Afterwards, the $mail_owner himself should be creating things
in "active/" and the only way for them to have some other owner would be
if root changed it. Do we want postfix to "fix" things in that case?
Maybe as a last resort... but as part of the standard upgrade procedure?

Reply | Threaded
Open this post in threaded view
|

Re: Upgrade to -3.2.5: permissions question

Viktor Dukhovni

>> Therefore, while it may be possible to attempt to work around this
>> in Postfix, the only sensible solution is at the OS level.
>
> Alas, those linking restrictions are still disabled by default on a
> vanilla linux kernel (upstream rejected the patch to enable them), and
> on every non-linux OS.

Indeed, but Linux users can enable the sysctl in question.

> If you absolutely must do a recursive, *automated* ownership change, the
> best defense that I'm aware of is to immediately call fstatat() on the
> fd obtained from openat() at each stage of the recursive traversal. If
> the descriptor has more than one link, reject it as suspicious. There's
> still a tiny window between openat() and fstatat() where the attacker
> can delete his link (so that your fd points to something juicy, but the
> link count is 1), but AFAIK that's as good as it gets.

It is rather difficult to avoid the race, especially when using standard
command-line tools, rather than writing custom code.

> If you need to do a recursive chown that isn't automated -- like for
> example to update $old_mail_owner to $new_mail_owner -- then e.g. GNU
> chown has the "--from" option to prevent $old_mail_owner from
> introducing hard links.

This could still be subject to a race, if not done via fstat() + fchown().
And it is GNU-chown-specific, which makes it somewhat unattractive for
Postfix.

> The best case is when you don't really need to do the recursive chown at
> all. Since we have
>
>  $queue_directory:d:root:-:755:uc

Unfortunately, the recursion is needed, if a new package or a system
upgrade changes the mail_owner, with already queued mail then having
incorrect ownership.  Hence the use of "set-permissions" in package
upgrade scripts.

Doing this portably from the shell is too painful.  The Linux feature
should be enabled by default, and introduced in other systems.

Even doing this in C, without race conditions, takes some care when the
files in question are not newly created with O_EXCL.  One would have
to check with fstat() that each open file has link count 1 and still
matches the lstat() data of the path used to open it.  Then, if that's
true, one can perhaps safely fchown() the file descriptor.

Directories are generally simpler, except perhaps on MacOS/X systems
where HFS+ has some sort of directory hard-links, which could make
that rather complicated.

--
        Viktor.