ssm agent creating folders with wrong permissions

[mliang2]

OS: Ubuntu 16.04 Agent version: v2.3.1319.0 Downloaded from https://s3.us-west-2.amazonaws.com/amazon-ssm-us-west-2/latest/debian_amd64/amazon-ssm-agent.deb

when amazon-ssm-agent starts, it creates folders in /var/lib/amazon/ssm w/ the execute bit off. Eg:

# ls -l /var/lib/amazon/ssm
total 24
drw------- 2 root root 4096 Jun 10 20:21 daemons
drw------- 3 root root 4096 Jun 10 20:21 localcommands
drw------- 6 root root 4096 Jun 10 20:21 mi-035a1646cxxxxxxx
-rw------- 1 root root   65 Jun 10 20:20 registration
drw------- 3 root root 4096 Jun 10 20:20 Vault

Notice all the folders has permission of rw instead of the standard rwx. While this is not an issue since the agent run as root, this is a problem if I run the agent as non-root.

When running the agent as non-root, it results in an error as the process cannot chdir into the folders since the folders are missing the execute bit. Here's the error from syslog:

Jun 10 19:53:32 ubuntu-1604 systemd[1]: Started amazon-ssm-agent.
Jun 10 19:53:33 ubuntu-1604 amazon-ssm-agent[1162]: 2020/06/10 19:53:33 Failed to load instance info from vault. Failed to set permission for vault folder or its content. chown /var/lib/amazon/ssm/Vault: operation not permitted

[mliang2]

Some context as to why I want to run the agent as non-root:

We've installed the SSM agent to our on-premise server and it's running as the root user. The infrastructure team installs the agent since the infra team has root access. The application team does NOT have root access on the server.

The agent is registered to an AWS account belong to the application team. The app team has Admin access on their AWS account.

Since agent runs as root, the app team can use the ssm:SendCommand feature to execute root commands on the server. This is a security issue as the app team now has root access on the server via SSM

We're using SSM on-premise mainly because SSM automatically authenticates the instance to aws, giving the server an IAM role. Since the agent creates the AWS_SHARED_CREDENTIALS_FILE, our apps is using that file to access AWS resources, similar to how apps running on EC2 will use the EC2 instance profile.

[mliang2]

I've also tried fixing the directory permission manually, but the SSM Agent deletes and recreates the Vault folder w/ the wrong permission as describe above, even when running as non-root user.

[ilove2git]

@mliang2 hi, may i know did you run ssm agent as non-root successfully at last? I'm having the same requirement as you mentioned above. The capabilities we intend to use are RunCommand and SessionManager. I could bring the process up but failed to start web session on browser. The error i got is as below:

"Output": "\n----------ERROR-------\nUnable to start shell: Failed to start pty: fork/exec /usr/bin/sh: operation not permitted

Do you have any idea on this? or would you please help guide me how to run SSM Agent as non-root successfully on OS? thanks very much

[mliang2]

SSM needs to run as root, no work around. I disabled remote exec by removing the ssm-session-worker and ssm-document-worker executables.

On 11/15/20, ilove2git notifications@github.com wrote:

@mliang2 hi, may i know did you run ssm agent as non-root successfully at last? I'm having the same requirement as you mentioned above. The capabilities we intend to use are RunCommand and SessionManager. I could bring the process up but failed to start web session on browser. The error i got is as below:

"Output": "\n----------ERROR-------\nUnable to start shell: Failed to start pty: fork/exec /usr/bin/sh: operation not permitted

Do you have any idea on this? or would you please guide me how to run SSM Agent as non-root successfully on OS? thanks very much

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/aws/amazon-ssm-agent/issues/286#issuecomment-727533628

[ranjrish]

@mliang2 you can further reduce access using the following https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-restrict-root-level-commands.html

[kroening]

The folder permissions should be fixed with a5670e4fac3d205c7ded797c99f6f0cd7c70350a

[phonedph1]

Even with the above commit the permissions for the Vault directory (and everything below?) is still not going to work as it modifies these in harden_unix.go each time it starts (checking for 0600 and root:root).

You can crudely patch this out but YMMY about how well it works after that.

--- a/agent/fileutil/harden_unix.go
+++ b/agent/fileutil/harden_unix.go
@@ -17,7 +17,9 @@
 package fileutil

 import (
+       "fmt"
        "os"
+       "strings"
        "syscall"
 )

@@ -32,6 +34,11 @@ func Harden(path string) (err error) {

        var fi os.FileInfo

+       if strings.Contains(path, "Vault") {
+               fmt.Printf("Ignoring harden for %s\n", path)
+               return
+       }
+
        if fi, err = os.Stat(path); err != nil {
                return
        }

[NandGates]

We too need to run ssm as non-root, is there any movement on a fix for this? This is the exact error we receive on agent start.