Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-21 01:25:28 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5490] [DOCS]: Do not suggest --cap-add SYS_ADMIN for Docker usage, but provide a seccomp profile #5117

New Issue
Open
opened 2026-06-05 14:52:06 -04:00 by yindo · 3 comments
yindo commented 2026-06-05 14:52:06 -04:00
Owner
Copy Link
Copy Source

Originally created by @lungben on GitHub (Apr 23, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5490

Description

In the documentation https://docs.anythingllm.com/installation-docker/quickstart it is suggested to run the AnythingLLM container with --cap-add SYS_ADMIN. This is a security risk because it gives the container too many rights on the host system.

This flag is currently used to give chrome additional rights for its sandbox feature. However, it would be better to provide these extra rights more granular with a custom Docker seccomp profile.

This could be based on the (maybe outdated?) default profile https://github.com/docker-archive-public/docker.labs/blob/master/security/seccomp/seccomp-profiles/default.json, adding (only) the syscalls required for Chrome sandboxing.

First testing indicates that adding the following syscalls should make the Chrome sandbox working:

  • fanotify_init
  • mlock
  • mlockall
  • setdomainname
  • sethostname
  • setns
  • statx
  • unshare
  • vhangup

Most likely, this list could be shortened for more security.

Complete seccomp profile:
chrome.hardened.json

Originally created by @lungben on GitHub (Apr 23, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5490 ### Description In the documentation https://docs.anythingllm.com/installation-docker/quickstart it is suggested to run the AnythingLLM container with `--cap-add SYS_ADMIN`. This is a security risk because it gives the container too many rights on the host system. This flag is currently used to give chrome additional rights for its sandbox feature. However, it would be better to provide these extra rights more granular with a custom Docker seccomp profile. This could be based on the (maybe outdated?) default profile https://github.com/docker-archive-public/docker.labs/blob/master/security/seccomp/seccomp-profiles/default.json, adding (only) the syscalls required for Chrome sandboxing. First testing indicates that adding the following syscalls should make the Chrome sandbox working: - fanotify_init - mlock - mlockall - setdomainname - sethostname - setns - statx - unshare - vhangup Most likely, this list could be shortened for more security. Complete seccomp profile: [chrome.hardened.json](https://github.com/user-attachments/files/27013737/chrome.hardened.json)
yindo added the documentation label 2026-06-05 14:52:06 -04:00
yindo commented 2026-06-05 14:52:07 -04:00
Author
Owner
Copy Link
Copy Source

@lungben commented on GitHub (Apr 24, 2026):

Adding the following capabilities to the standard seccomp.json allows for me to use the Chrome sandbox in a much more secure way than with cap-add SYS_ADMIN:

	"syscalls": [
        {
          "names": [
            "fanotify_init",
            "setdomainname",
            "sethostname",
            "vhangup"
          ],
          "action": "SCMP_ACT_ALLOW",
          "args": [],
          "comment": "custom: allow without capabilities",
          "includes": {},
          "excludes": {}
        },
``
<!-- gh-comment-id:4314424249 --> @lungben commented on GitHub (Apr 24, 2026): Adding the following capabilities to the standard seccomp.json allows for me to use the Chrome sandbox in a much more secure way than with cap-add SYS_ADMIN: ``` "syscalls": [ { "names": [ "fanotify_init", "setdomainname", "sethostname", "vhangup" ], "action": "SCMP_ACT_ALLOW", "args": [], "comment": "custom: allow without capabilities", "includes": {}, "excludes": {} }, ``
yindo commented 2026-06-05 14:52:07 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Apr 24, 2026):

@lungben Can you share your full profile? Web scraping does not work with a profile like this:
https://gist.github.com/timothycarambat/38055eb92189c5d68f919c0efd396761

This is docker default, which includes those calls already? Not sure what the correct format is here

<!-- gh-comment-id:4316613062 --> @timothycarambat commented on GitHub (Apr 24, 2026): @lungben Can you share your full profile? Web scraping does not work with a profile like this: https://gist.github.com/timothycarambat/38055eb92189c5d68f919c0efd396761 This is docker default, which includes those calls already? Not sure what the correct format is here
yindo commented 2026-06-05 14:52:07 -04:00
Author
Owner
Copy Link
Copy Source

@lungben commented on GitHub (Apr 25, 2026):

chrome.json

This profile works for me with the following flags in docker-compose.yml:

    security_opt:
      - no-new-privileges:true
      - seccomp:chrome.json

I obtained this profile by extending the default profile (for me it was in /usr/share/containers/seccomp.json) with the rights stated above.

I have not done too much testing with AnythingLLM, but it seems to work, including web scrapping (which has not worked before without cap-add SYS_ADMIN or the custom seccomp profile).

<!-- gh-comment-id:4320371246 --> @lungben commented on GitHub (Apr 25, 2026): [chrome.json](https://github.com/user-attachments/files/27088715/chrome.json) This profile works for me with the following flags in docker-compose.yml: ``` security_opt: - no-new-privileges:true - seccomp:chrome.json ``` I obtained this profile by extending the default profile (for me it was in `/usr/share/containers/seccomp.json`) with the rights stated above. I have not done too much testing with AnythingLLM, but it seems to work, including web scrapping (which has not worked before without cap-add SYS_ADMIN or the custom seccomp profile).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label documentation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#5117
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?