Bug 951728 - proftpd tries to close PAM session while running as non-root user
proftpd tries to close PAM session while running as non-root user
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: proftpd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-12 17:50 EDT by Michal Schmidt
Modified: 2013-04-26 02:32 EDT (History)
4 users (show)

See Also:
Fixed In Version: proftpd-1.3.4c-2.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-26 02:32:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2013-04-12 17:50:39 EDT
Description of problem:
Jason Burgess noticed (in https://bugzilla.redhat.com/show_bug.cgi?id=809214#c30) the following messages in system logs:

Apr 11 23:12:28 localhost dbus[594]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.174" (uid=505 pid=6971 comm="proftpd: ftpuser- 192.168.1.10: IDLE") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=578 comm="/usr/lib/systemd/systemd-logind ")

Note that logind's DBus method ReleaseSession is called from pam_systemd's pam_sm_close_session implementation.

So the error message tells us that a proftpd process tried to close a PAM session (i.e. by calling pam_session_close()) while running as a user other than root (uid=505).

This is incorrect use of PAM by proftpd. Both pam_open_session() and pam_close_session() must be called as root and in the same process.

Version-Release number of selected component (if applicable):
proftpd-1.3.4c-1.fc18

How reproducible:
always

Steps to Reproduce:
1. Start proftpd using the package's default config.
2. Login into FTP as a user, then log out.
3. journalctl -b | grep Reject
  
Actual results:
The above error message proving that pam_close_session was called by unprivileged process.

Expected results:
No error message. PAM session correctly closed.

Additional info:
From looking at proftpd sources I found that proftpd works roughly like this:

accept()
fork()
in the child {
    pam_auth() { /* in mod_auth_pam */
       pam_open_session()
    }
    drop privileges

    ...work..

    auth_pam_exit_ev() {  /* in mod_auth_pam */
       PRIVS_ROOT  /* tries to regain root privileges */
       pam_close_session()
    }
}

PRIVS_ROOT does not have the desired effect because session.disable_id_switching is set. It is set by mod_cap. This leads us to an ugly but effective workaround: Use "CapabilitiesEngine off" in the config file to disable mod_cap.

A proper fix should likely consist of adding another fork(), where the parent would open the PAM session, wait for the child to exit, then close the session. The child would drop privileges and would never have to regain them.

This view on using PAM sessions is supported for example by:
Tomáš Mráz, the PAM maintainer, in an old discussion about a similar issue in OpenSSH:
https://bugzilla.mindrot.org/show_bug.cgi?id=926#c21
Lennart Poettering, more recently about PAM handling in xrdp:
https://bugzilla.redhat.com/show_bug.cgi?id=821569#c23
Comment 1 Paul Howarth 2013-04-13 03:27:59 EDT
(In reply to comment #0)
> PRIVS_ROOT does not have the desired effect because
> session.disable_id_switching is set. It is set by mod_cap. This leads us to
> an ugly but effective workaround: Use "CapabilitiesEngine off" in the config
> file to disable mod_cap.

Which capability should proftpd retain in order for this to work properly with mod_cap enabled? Upstream has been receptive to retaining needed capabilities for proper PAM operation in the past: http://bugs.proftpd.org/show_bug.cgi?id=3257
Comment 2 Michal Schmidt 2013-04-15 13:03:27 EDT
(In reply to comment #1)
> Which capability should proftpd retain in order for this to work properly
> with mod_cap enabled?

I really think the proper way is to split it into two processes as I described in my original comment.

[Adding Tomáš Mráz to CC].

Tomáš,
would you have any comments on the proper way to open and close PAM sessions?
Comment 3 Tomas Mraz 2013-04-15 13:37:34 EDT
I don't have much else to comment than just confirm what you said in the bug description as the proper way to call the pam_close_session(). Additional fork is needed also for the situation where the unprivileged child crashes.
Comment 4 Paul Howarth 2013-04-16 08:54:41 EDT
Raised upstream: http://bugs.proftpd.org/show_bug.cgi?id=3929
Comment 5 Fedora Update System 2013-04-16 15:38:48 EDT
proftpd-1.3.4c-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/proftpd-1.3.4c-2.fc19
Comment 6 Fedora Update System 2013-04-16 15:38:59 EDT
proftpd-1.3.4c-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/proftpd-1.3.4c-2.fc18
Comment 7 Michal Schmidt 2013-04-17 04:51:13 EDT
I see that proftpd upstream refused to add the fork(), because :
  """
  we'd have another process which does absolutely nothing but shadow the
  original session, taking a slot in the process table, solely for purposes
  of closing some PAM session (which, for some reason, *requires root privs*)
  """

So instead they made sure to restore root privileges before closing the PAM session in the same process:
http://pkgs.fedoraproject.org/cgit/proftpd.git/plain/pam-close-bug3929.patch?id=9f2fb5f2fa5ae0f9cc576ca985f97bc2a8f3e22a

I must say, having a process partially drop privileges, but only so that it can restore them at will later, does not appear as a secure design.

I'll let Jason comment on whether it gets rid of the DBus error messages.
Comment 8 Fedora Update System 2013-04-21 20:41:04 EDT
proftpd-1.3.4c-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2013-04-25 20:58:37 EDT
proftpd-1.3.4c-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.