On Sep 29, 2014, at 1:21 PM, Susan Hinrichs <shinr...@network-geographics.com> wrote:
> > 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. OK, I'll refrain from changing any of the capabilities. > 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? Good point, I'll try to make the errors pertinent. >> 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? We only support libcap on Linux. > Are there least privilege alternative mechanisms on those platforms? I'm not really sure. I don't have any objection to privilege elevation on those platforms, but it doesn't work today and I'm not proposing to alter that. If someone wants to implement and maintain that, I'll support them. > 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. I expect that traffic_manager would retain CAP_DAC_OVERRIDE, since it is the privileged helper to traffic_server. When traffic_server can't open a file, it will have to ask traffic_manager to do it. J
