https://bz.apache.org/bugzilla/show_bug.cgi?id=69724

            Bug ID: 69724
           Summary: OPENSSL_CONF etc not respected by openssl when httpd
                    is run with capabiities, suid, or sgid
           Product: Apache httpd-2
           Version: 2.4.63
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_ssl
          Assignee: bugs@httpd.apache.org
          Reporter: jsolomon8...@gmail.com
  Target Milestone: ---

httpd uses openssl to implement mod_ssl. openssl users frequently set the
environment variables OPENSSL_MODULES and OPENSSL_CONF and others to configure
the behavior of the openssl library.

One common way to run httpd is as a non-privileged user who use Linux file
capabilities to give the httpd binary the ability to bind to a privileged port.
This is done with a command like:

    sudo setcap cap_net_bind_service+ep /path/to/httpd

When httpd is run in this manner, the Linux kernel sees it as a "secure binary"
and treats it differently. Most importantly, the libc function secure_getenv()
will return NULL for every call, which means that when httpd is run with
privileges to bind to a privileged port, openssl, which relies on
secure_getenv() to read environment variables, will not respect any environment
variables.

Dropping privileges does not help. Once the kernel thinks a process is
"secure", it cannot be made "regular" at runtime such that secure_getenv() will
return the actual env var value.

Users who run httpd as root will not see this behavior because the process
isn't "secure", it's just running as root.

Openssl will still read its configuration from the hard-coded compiled-in
default locations, but those paths and values could be totally unrelated to the
environment in which the binaries will actually run on some other machine.

I propose an addition to mod_ssl. A new directive named SSLOpenSSLPassEnv
which, similar to the SSLOpenSSLConfCmd, directive gives users a way to have
apache programmatically set openssl configuration instead of relying on
environment variables. This directive will do nothing unless
getauxval(AT_SECURE) returns 1 because openssl will simply respect the given
environment variables. Otherwise, the user can specify environment variables
that apache will set using the openssl API. There are only a small number of
relevant environment variables that openssl recognizes so the surface area of
this new directive is limited.

I'm happy to submit a PR to implement this feature, but I wanted to verify that
the current behavior would be considered a bug and should be improved. I
believe that relying on openssl env vars as well use relying on "setcap
cap_net_bind_service" is common enough that the mod_ssl community would benefit
from this change.

This openssl issue is described here:
https://github.com/openssl/openssl/issues/21770. I believe that httpd is the
correct place to address this issue. Addressing it directly in openssl is hard
and was discussed in the proposed "fix" in openssl was rejected:
https://github.com/openssl/openssl/pull/22186

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to