You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2014/09/29 19:57:53 UTC
privilege elevation in traffic_server
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.
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
Re: privilege elevation in traffic_server
Posted by James Peach <jp...@apache.org>.
On Sep 29, 2014, at 5:42 PM, Alan M. Carroll <am...@network-geographics.com> wrote:
> Monday, September 29, 2014, 4:21:02 PM, you wrote:
>
>>> 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.
>
> If traffic_server needs root level at startup, how can traffic_manager drop that privilege?
In the long term, we could exec traffic_server as an unprivileged user. I don't expect traffic_manager to ever run unprivileged
Re: privilege elevation in traffic_server
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Monday, September 29, 2014, 4:21:02 PM, you wrote:
>> 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.
If traffic_server needs root level at startup, how can traffic_manager drop that privilege?
Re: privilege elevation in traffic_server
Posted by James Peach <jp...@apache.org>.
On Sep 29, 2014, at 1:21 PM, Susan Hinrichs <sh...@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
Re: privilege elevation in traffic_server
Posted by Susan Hinrichs <sh...@network-geographics.com>.
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.
Re: privilege elevation in traffic_server
Posted by James Peach <jp...@apache.org>.
On Oct 6, 2014, at 11:28 AM, Bill Zeng <bi...@gmail.com> wrote:
> Hi James,
>
> Can you elaborate on the inconsistency problems a little bit more? To my
> understanding, traffic_cop runs as root. traffic_manager and traffic_server
> run as unprivileged nobody.
traffic_cop runs as root, traffic_manager retains privilege (but alters its effective credentials), and traffic_server drops privilege as much as possible. Prior to this change landing, traffic_server and traffic_manager had independent code paths for dropping privilege. If proxy.config.ssl.cert.load_elevated was used when traffic_server was built without POSIX capability support, it would silently fail to work.
>
> Thanks.
> Bill
>
>
> On Mon, Sep 29, 2014 at 10:57 AM, James Peach <jp...@apache.org> 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.
>>
>> 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
Re: privilege elevation in traffic_server
Posted by Bill Zeng <bi...@gmail.com>.
Hi James,
Can you elaborate on the inconsistency problems a little bit more? To my
understanding, traffic_cop runs as root. traffic_manager and traffic_server
run as unprivileged nobody.
Thanks.
Bill
On Mon, Sep 29, 2014 at 10:57 AM, James Peach <jp...@apache.org> 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.
>
> 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