OneAgent Permissions (in particular the 777 of the log directories)
I have to write a technical justification for a customer, in regards to the 777 permissions, especially in the dynatrace log directory. They would like to change it and lock it down but base on experience and from documentation, I know that this is not recommended. I came up with this, anybody has any inputs to this?
"In regard to the 777 permissions visible in certain Dynatrace directories (especially the log directory within the dynatrace install directory), at this point in time there is no recommended way (or supported way) to lock all those directories down. One reason is, that at the time of instrumenting, you do not know yet all the processes that OneAgent will be injected into when Full Stack mode is turned on, neither do you know what users those potential processes are running as. The user under which potential apps or processes that are being instrumented are running, will actually be the user that writes into those directories, hence, if that user would not have the proper permissions, no logs could be written, and certain procedures, such as the health check, will fail. Hence, these directories must be world writeable to ensure that every needed process will always be able to write into them.
Another reason is to ensure that every instrumented process will be able to write data into certain log directories (e.g. the crash report directory) since the instrumented processes do not run as the dtuser (or whatever user you have used when you installed OneAgent). Instrumentation may on occasion fail and not produce the expected outcome if those directory permissions are changed.
Also note that these directories are log directories, by definition, Dynatrace does not place any sensitive information into these directories, and there is no way to compromise the system by modifying files and content within those directories.
Modifying these permissions will potentially stop Dynatrace from investigating errors and incidents on OneAgent, ass logs that cannot be written because of permission issues, will be missing. Same goes for utilities such as the health check, that will fail when detecting unsupported permission sets."
Any comments welcome :D
Best Answer
Hello @Sigmund B.
We've just recently published official documentation on this matter, you can find it here:
- https://www.dynatrace.com/support/help/shortlink/oneagent-security-linux#globally-writable-directories
- https://www.dynatrace.com/support/help/shortlink/oneagent-security-aix#globally-writable-directories
- https://www.dynatrace.com/support/help/shortlink/oneagent-security-windows#globally-writable-directories
Furthermore, the log files are now stored in /var/log by default. You can read more in the following blog post: https://www.dynatrace.com/news/blog/further-improved-handling-and-reliability-of-oneagent-deployments/
Further information that might be useful:
Thank's - yes I also found these. That and the email we got from Dynatrace Support saying that you can not change the permissions, and that if you do, the installation will become unsupported, will have to do I guess, wish they would add that somewhere in the documentation, including the reason why.
Just my two cents on this... as I also work in security...
First of all, not sure what position you are in, but presuming your are a consultant/partner. I would suggest you contact Dynatrace on this positioning, as it might hurt only having your position and the Community's.... If a customer has asked for it, they are probably very knowledgeable in this domain...
I would also check that you are using OneAgent in non privileged mode. I have not checked it in that mode, but would say some of the restrictions you are seeing might not apply. Please note that you have used some comments in this Community made before this applied, so they might not be current:
Now, 777 permissions is definitely not a good thing, especially at the directory level. But given some restrictions, it might be necessary. And in all cases, restricting it without checking with Dynatrace could give even worse results... 622 would probably be sufficient at the file level, and 633 at the directory level, with the correct ownership.
Having 777 permissions at the directory/file level in /opt directory might compromise your system indirectly in several ways. One quick example is just a DoS, with the creation of such a file that it occupies all disk space. Depending on configuration, it might bring the system down. Don't forget that most sysadmins expect logs to be in /var/log, and even there, not everyone has full write access. Other situations might apply. Please check with Dynatrace directly!
Thanks for your inputs, actually, Security is my main Domain as well which is why i have been asked to explain this to the customer :)
The above is actually coming out of a discussion we had with Dynatrace One Premium Support, over a few weeks, who in the end sticked to the statement that changing the permissions renders the installation unsupported.
That said, there is not much we can do then to explain that to the customer, and provide some justification, to which we have attached the written comments of Dynatrace support. Of course i would first utilize One Premium support before considering to justify something that i personally do not agree to.
And since unfortunately there is no other article, white paper, or write up that Support could point me to, that explains why the permissions are needed as they are and can not be changed without rendering the installation unsupported, all i can do is try to write something myself.
Personally I agree with the Customer on not having 777 permissions, but since the take of support is, if we change it, it will become unsupported, will for now have to live with it.
Aslo, yes, we did install OneAgent in privileged mode, however, that does not change the fact that some directories under /opt/dynatrace still do have the 777 permissions. And of course those will trigger on certain tools as a finding.
In regards to this:
"622 would probably be sufficient at the file level, and 633 at the directory level, with the correct ownership. "
In fact, we tested this extensively in our own managed cluster in in the lab, and had different outcomes on different Linux flavours interestingly, in 2 out of 3, after locking down directories in the same way that the customer wanted, there was no issue at all and instrumentation worked, but in one case, instrumentation failed.
Lastly, even I myself would also expect logs to be in /var/log, however, as far as i know, there is no way of changing only the log directory at this time, and that was also what support told us.
That looks good!
