Conversation
| optional string localhost_profile = 2; | ||
| } | ||
|
|
||
| message HardeningDeclared { |
There was a problem hiding this comment.
Sorry for the bikeshedding but should this be something like SecurityContext ?
…erName) Co-authored-by: Cursor <cursoragent@cursor.com>
12158e2 to
44bb6d8
Compare
| } | ||
|
|
||
| Type type = 1; | ||
| // Set iff type == TYPE_LOCALHOST. |
| optional bool run_as_non_root = 5; | ||
| optional bool allow_privilege_escalation = 6; | ||
| optional bool read_only_root_filesystem = 7; |
There was a problem hiding this comment.
I don't think we should add those, as the raw information is already present on the profile itself, and we kind of agree with the backend to only share raw data
There was a problem hiding this comment.
ok I wasn't aware we could directly got those intel from workload meta, and I don't have a strong opinion about adding them or not 🤔
Add a new SeccompFilter proto message carrying the effective seccomp filter extracted at runtime via ptrace: - default_action: the fallback action for unmatched syscalls - syscalls: map of syscall name to its action (ALLOW, ERRNO, etc.) The filter is an optional field on SeccompProfile (field 3). Co-authored-by: Cursor <cursoragent@cursor.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 949802a991
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Set if type == TYPE_LOCALHOST. | ||
| optional string localhost_profile = 2; | ||
| // Effective filter extracted at runtime via ptrace. | ||
| optional SeccompFilter filter = 3; |
There was a problem hiding this comment.
The checked-in SecDumpProto.java was generated before this field and message were added: it contains neither SeccompFilter nor SeccompProfile.hasFilter()/getFilter(), and its embedded descriptor still defines SeccompProfile with only fields 1 and 2. Consequently Java consumers treat field 3 as unknown and cannot inspect it, while Java producers cannot populate the new effective filter; regenerate the Java output from the final proto.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca032512da
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Comparison operator: "==", "!=", "&", ">", ">=", "<", "<=". | ||
| string op = 2; | ||
| // Constant value compared against. | ||
| uint32 value = 3; |
There was a problem hiding this comment.
For filters comparing an argument with a constant above 0xffffffff, such as a 64-bit mask or pointer-valued argument, this field cannot encode the effective condition. Linux exposes every seccomp syscall argument as a 64-bit value, and this model has no separate high-word marker, so a producer must truncate or reject such a comparison and the receiver reconstructs a different filter. Use uint64 for the comparison value.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| message SecurityContext { | ||
| bool privileged = 1; |
There was a problem hiding this comment.
When a workload omits securityContext.privileged, this proto3 scalar decodes identically to an explicit privileged: false. Because these entries describe declared security settings, consumers cannot tell whether the workload explicitly disabled privileged mode or merely inherited the Kubernetes default; the neighboring nullable Kubernetes booleans preserve that distinction with optional. Make this field optional as well.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c4f68376c5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // Base action (evaluated with args=0). | ||
| string action = 1; | ||
| // Argument-level conditions extracted from the BPF filter. | ||
| repeated ArgCondition conditions = 2; |
There was a problem hiding this comment.
When an effective BPF rule reaches an action only after multiple argument checks (for example, arg0 == x && arg1 == y), this flat condition list cannot record the conjunction or decision-tree edges: every ArgCondition contains only one comparison and its terminal action. A consumer therefore cannot distinguish the compound rule from independent branches and may reconstruct a filter that allows the syscall too broadly; represent condition grouping or the BPF decision structure explicitly.
Useful? React with 👍 / 👎.
3 participants
What does this PR do?
Add declared Kubernetes security context to CWS activity dumps and security profiles
Motivation
Additional Notes
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
Reviewer's Checklist
Reviewers: please see the review guidelines.