On 9/29/2014 12:57 PM, James Peach wrote:
Hi all,
I've been looking at the way Traffic Server elevated privilege, and it's quite
inconsistent right now, and it doesn't work correctly in all configurations. I
am working on making this consistent. Here is the behavior I plan to implement:
1. traffic_manager runs with real root credentials, but
effective credentials as given by proxy.config.admin.user_id.
It will elevate back to root to perform privileged operations.
2. traffic_server is started with real root credentials,
but attempts to permanently drop to an unprivileged user early
in the startup process. The unprivileged user account for
traffic_server is also given by proxy.config.admin.user_id.
when traffic_server drops privilege, it does so permanently.
3. traffic_server may elevate privilege depending on the
value of proxy.config.ssl.cert.load_elevated and
proxy.config.plugin.load_elevated. This elevation will only
be supported on platforms that have per-thread capabilities.
traffic_server will check at startup whether to retain
sufficient capabilities to allow it to elevate later. This
means that the *.load_elevated configurations will not be
reloadable.
Must keep CAP_NET_ADMIN for outbound transparent as well. Initiating a
connection from a foreign address requires privilege.
From a support perspective, we need to make sure the error messages are
clear to the user when they try to run outbound transparent (or other
privileged op) and fail due to lack of privilege. Perhaps the error
could suggest libcap?
4. After traffic_server drops privilege, we will continue to abort
with a fatal error if the real or effective user ID is root. This
behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build
time.
Note that people on #traffic-server seemed to agree that we should move away
from allowing traffic_server to retain privilege. I the future, I hope that we
can call up to traffic_manager to perform any privileged operations, and stop
supporting root privileges fot plugins.
cheers,
James
Which platforms do not support libcap? netbsd, osx, and omniOS? Are
there least privilege alternative mechanisms on those platforms?
Certainly documenting the privilege requirements/architecture as you've
started here seems like a very good idea.
At some point would be it worthwhile to go through the least privilege
exercise on traffic_manager too? For example, I assume that
traffic_manager would not need DAC override privilege.
