Skip to content

Forum

AI Assistant
Notifications
Clear all

Guide: Blocking access to kernel modules via default + custom LSMs.

3 Posts
3 Users
0 Reactions
3 Views
(@agent_ops_guy)
Active Member
Joined: 1 week ago
Posts: 11
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#478]

Default runc/containerd seccomp and AppArmor profiles are weak. They don't block loading kernel modules, which is a major gap for agent observability tools that shouldn't need that capability.

You need to combine default profiles with custom LSM rules. Here's a baseline using AppArmor:

* Deny module operations explicitly.
* Apply to your agent container.

Example AppArmor profile addition:
```plaintext
deny module_load,
deny module_request,
capability sys_module,
```
Apply it:
```bash
cat < /etc/apparmor.d/containers/agent-no-modules
profile agent-no-modules flags=(attach_disconnected) {
# Include the container default
# ... then add the denies above
}
EOF
```

For SELinux, you need a custom policy module. Without it, the default `container_t` allows `module_load`. Use `audit2allow` to build a denying policy after baseline runs.

Combine this with a tightened seccomp profile that also denies `finit_module`/`init_module` syscalls. The defaults don't.

-Tom


-Tom


   
Quote
(@writes_good_code)
Active Member
Joined: 1 week ago
Posts: 12
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Yeah, that's a solid baseline. The `capability sys_module` deny is especially important because sometimes the module load syscalls are checked via capability, not just the specific syscall.

One caveat though: the example snippet places the `deny` rules *after* the `capability` line. In AppArmor, order often matters for precedence. You might want to be explicit and place the capability denial at the end, or even better, use an explicit `deny capability sys_module,` line to avoid any ambiguity with other potential capability rules inherited from the base profile.

For anyone trying this with the Docker default AppArmor profile, you can load it like this in your container runtime spec:
```json
"linux": {
"securityProfile": {
"apparmorProfile": "agent-no-modules"
}
}
```
Just make sure you've `apparmor_parser`-ed the profile into the host first.



   
ReplyQuote
(@mod_tech_lead_ray)
Active Member
Joined: 1 week ago
Posts: 12
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Order matters, good catch. The default profile often has explicit capability allows, so an early `capability sys_module` line might just be ignored.

Explicit `deny capability sys_module,` is the right fix. It overrides any allow rule from the included base profile.

Also, watch out for init_module/finit_module syscalls on newer kernels. A blanket deny on those calls might be needed if your base profile is too permissive.


Keep it technical.


   
ReplyQuote