* a configuration problem - '''zimbraReverseProxySSLToUpstreamEnabled''' has been set to '''FALSE''' instead of '''TRUE'''

* a configuration problem - '''zimbraReverseProxySSLToUpstreamEnabled''' has been set to '''FALSE''' instead of '''TRUE'''

* a site that is performing SSL/TLS offloading - consider adding the '''Secure''' attribute via the device that is performing the offloading

* a site that is performing SSL/TLS offloading - consider adding the '''Secure''' attribute via the device that is performing the offloading

+

+

=== JSESSIONID is sometimes exposed in a URL, is that a problem? ===

+

Generally speaking, the fact that this occurs is related to the server not yet being sure about the client supporting/allowing cookies. In ZCS, the use of JSESSIONID is limited to some client state management (ref: [https://bugzilla.zimbra.com/show_bug.cgi?id=30319 bug 30319] and [https://bugzilla.zimbra.com/show_bug.cgi?id=71982 bug 71982]). As such, there is no security risk associated with authentication or authorization by having JSESSIONID in a URL.

=== Can you explain the relationship between the <u>UNIX user/group</u> '''zimbra''' and '''root'''? ===

=== Can you explain the relationship between the <u>UNIX user/group</u> '''zimbra''' and '''root'''? ===

Security Pointers and Tidbits

Release Specific Settings

Odds and Ends

Here are a few questions that come up from time to time...

An OS Patch/Bug/Vulnerability was announced, is Zimbra affected?

Best practice dictates that you always stay up to date with vendor provided OS patches. Also, be sure to follow OS recommended best practices when applying patches (e.g. restarting affected services, tools like needs-restarting, needrestart and checkrestart may be helpful when trying to understand which processes are using files that were replaced by a patch). When in doubt about the status of a system after a patch, go ahead and reboot to ensure the patches take effect.

Cookie ZM_TEST cookie is missing the HttpOnly attribute, is this a problem?

The ZM_TEST cookie in ZCS is used solely to determine if cookies are enabled a the browser. There are no privileges associated with that cookie. As such, there is no inherent risk with not having an HttpOnly attribute on this cookie.

Cookies JSESSIONID and ZM_AUTH_TOKEN are missing the Secure attribute, why?

Typically this is an indication of one of the following (ref: bug 91298):

a configuration problem - zimbraReverseProxySSLToUpstreamEnabled has been set to FALSE instead of TRUE

a site that is performing SSL/TLS offloading - consider adding the Secure attribute via the device that is performing the offloading

JSESSIONID is sometimes exposed in a URL, is that a problem?

Generally speaking, the fact that this occurs is related to the server not yet being sure about the client supporting/allowing cookies. In ZCS, the use of JSESSIONID is limited to some client state management (ref: bug 30319 and bug 71982). As such, there is no security risk associated with authentication or authorization by having JSESSIONID in a URL.

Can you explain the relationship between the UNIX user/groupzimbra and root?

Historically the zimbra UNIX account and group has been treated as trusted from the UNIX process perspective. It is important to note that this goes against many common trust models, where accounts that provide network services would be considered untrusted. With that in mind, if one has access to UNIX user/groupzimbra, then one has that ability to obtain root privilege. While there are explicit abilities identified via sudoers (ref: Sudoers), there are also implicit abilities due to limitations of the tools currently being used and the weak trust model.

Please be aware that there is potential for user/group zimbra to escalate to root privileges via nginx (ref: https://trac.nginx.org/nginx/ticket/376) as well as other utilities allowed in the sudoers configuration. This is not an ideal situation and will likely change over time, but that is the status quo within the product.