bottlerocket-os / bottlerocket-os/bottlerocket-core-kit

SELinux policy: container_t cannot execute files labelled local_t

Open Beginner friendly
#959 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
34
Forks
77
Avg merge
2d 23h
Merged PRs (30d)
23

Description

## Summary

`container_t` is denied `execute_no_trans` and `entrypoint` on files labelled `local_t`. This breaks workloads where one container writes an executable to a shared volume and another container executes it (e.g., CrowdStrike Falcon init-container pattern).

### SELinux denial

```json
{
"scontext": "system_u:system_r:container_t:s0",
"tcontext": "system_u:object_r:local_t:s0",
"tclass": "file",
"perms": ["execute_no_trans"],
"permissive": 1,
"pid": 1686,
"comm": "runc:[2:INIT]"
}
```

A second related denial for entrypoint:

```
avc: denied { entrypoint } for pid=53503 comm="runc:[2:INIT]" path="/managed-agents/execute-command/amazon-ssm-agent" dev="nvme0n1p8" ino=202 scontext=system_u:system_r:container_t:s0 tcontext=system_u:object_r:s0 tclass=file permissive=0
```

### Root cause

[local_t is not included in container_exec_o](https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/8071dcf77e9e241cbf69128bc54d3fbd71c2e934/packages/selinux-policy/object.cil#L216-L218):
```
(typeattributeset container_exec_o (data_t cache_t secret_t cni_exec_t csi_exec_t))
```
So the existing rule `(allow container_s container_exec_o (file (entrypoint)))` does not cover files labelled local_t.

### Reproduction

Register an ECS Managed Instances task with two containers sharing a volume:

An init container copies a binary (e.g., /bin/sh) into the shared volume.
The application container uses that binary as its entrypoint.
The file written to the shared volume gets labelled local_t. The application container is denied execution and exits 255.

Example task definition (abbreviated):

```
{
"volumes": [{"name": "shared-volume"}],
"containerDefinitions": [
{
"name": "init",
"entryPoint": ["sh", "-c"],
"command": ["cp /bin/sh /tmp/shared/bin/run && chmod a+rx /tmp/shared/bin/run"],
"mountPoints": [{"sourceVolume": "shared-volume", "containerPath": "/tmp/shared"}]
},
{
"name": "app",
"entryPoint": ["/tmp/shared/bin/run", "-c", "echo hello"],
"mountPoints": [{"sourceVolume": "shared-volume", "containerPath": "/tmp/shared", "readOnly": true}],
"dependsOn": [{"containerName": "init", "condition": "COMPLETE"}]
}
]
}
```

### Suggested fix

Add local_t to container_exec_o, or add a standalone rule:

```
(allow container_s local_t (file (entrypoint)))
```

Contributor guide

Open the contributing guide

Research direction

Open packages/selinux-policy/object.cil around lines 216-218 and compare the container_exec_o type set with the existing container_s allow rule. Validate the policy using the shared-volume reproduction described in the issue, and confirm that container_t can execute files labelled local_t without the reported entrypoint or execute_no_trans denials.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
operating-systems, security
Issue type
Bug
Difficulty
1/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
82/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.