Amazon-ssm-agent: Possible bug: Strange download location

[thedevopsmachine]

https://github.com/aws/amazon-ssm-agent/blob/e412ea59b9e1c94ce7fe194194395d05aff7026d/agent/appconfig/constants_unix.go#L53

Almost all of the other settings in that package have a root "/var/lib/amazon/ssm", but for some reason this one has "/var/log/amazon/ssm", which is a REALLY weird place to download files to.

I suspect this should be "/var/lib/amazon/ssm/download".

[nehalaws]

Thank you for posting your concern, download folder is under log directory.

[andyjp94]

It would be good to get a proper answer to this, I'm configuring logrotation policies atm and I've no idea what to do with this, not sure if I can bin the updates and everything will be fine or I'd have to keep them lying around. They are also the biggest files we have by a very considerable margin in the /var/log directory. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

[michaelsmoody]

@nehalaws I'd like to also chime in that this is an exceedingly odd download location, and violates a lot of compliance specifications. Also, a lot of default hardening baselines split /var, and /var/log into separate partitions, and the going default seems to be 4Gbyte. In addition to that, these mount points often have mount options that prevent execution (nosuid, noexec) from within those volumes.

For this to be properly resolved, the ideal solution is to:

• Move the downloads out to /var/lib/amazon/ssm/download (optimal)
• Cleanup the downloads folder after each download (less optimal, still inappropriate to put installers in /var/log)
• Allow this to be configurable with a default outside of /var/log (for backwards compatibility perhaps)
• Provide clear guidance on whether these files can be removed with other means, such as logrotate (unclear)

I looked at most of the STIG, CIS, C2S, and other compliance baselines, and pretty much _all_ of them separate /var/log into its own partition, with its own unique mount options. In almost all cases, the default is 4Gbyte (configurable in some cases, but not in all), and in almost all cases, this would mean that the /var/log/amazon/ssm/download folder is one of the largest folders after a year of running the system.

Please reconsider this behavior, as it is a potentially a compliance-breaking item (non logs in a logging folder, not handled via logrotate mechanisms, executables and packages contained in a blackbox folder without guidance on whether they can safely be removed, etc).

Thanks,
Michael

[jdavisp3]

Agreed the original answer is not very satisfactory.