-
Notifications
You must be signed in to change notification settings - Fork 541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Carry #1111: specs-go/config: add Landlock LSM support #1241
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -352,6 +352,52 @@ For Linux-based systems, the `process` object supports the following process-spe | |
for `initial`. If omitted or empty, runtime SHOULD NOT change process' | ||
CPU affinity after the process is moved to container's cgroup, and the | ||
final affinity is determined by the Linux kernel. | ||
* **`landlock`** (object, OPTIONAL) specifies the Landlock unprivileged access control settings for the container process. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What happens if the runtime doesn't know this field? I guess in runc it will be completely ignored, right? In that case, I think we at least need to expose landlock support via the features command too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, the runtime will ignore the field. I think it's not necessary to add feature command like other optional features. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Zheaoli why not? This is a security feature, I can see use cases where upper layers want to enforce this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. friendly ping? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry for replying late. I misunderstand something before. I think it's necessary to export the feature we support for landlock in features command |
||
Note that `noNewPrivileges` must be set to true to use this feature. | ||
For more information about Landlock, see [Landlock documentation][landlock]. | ||
`landlock` contains the following properties: | ||
|
||
* **`ruleset`** (object, OPTIONAL) the `ruleset` field identifies a set of rules (i.e., actions on objects) that need to be handled (i.e., restricted). | ||
The `ruleset` currently contains the following types: | ||
* **`handledAccessFS`** (array of strings, OPTIONAL) is an array of FS typed actions that are handled by a ruleset. | ||
If no rule explicitly allow them, they should then be forbidden. | ||
Comment on lines
+362
to
+363
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How does this work on overlayfs? https://docs.kernel.org/userspace-api/landlock.html#bind-mounts-and-overlayfs It is very widely used, can you clarify what works and what doesn't? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, I'm not testing it on overlayfs yet. But I think it still work on overlayfs. Because we will always target to restrict the rule on the merged hierarchy. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe you want to figure out is it working on the following circumstance?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understandig of the link is, if C is the merged dir by overlayfs, then no, you don't have permissions to write even if you can write to A and B. But I think if we use C for the rules, it might work. I don't know if we also need permissions in A and B (not 100% clear to me when reading the doc), in which case it will be tricky. IMHO, it will be nice to understand that, as overlay is a widely used fs for containers. But not sure that will change something on how we support it in OCI, so maybe it is okay? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. https://github.com/Zheaoli/py-landlock/blob/main/examples/demo.py I have some overlayfs test case here. PTAL if you got time There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Zheaoli I can try to download the python modules and run that locally. But it would be way simpler if you just share what works and what doesn't :) At the OCI layer we don't know the lowerdir nor the upperdir, we just know the merged dir. It will be great to find if we apply a landlock policy restricting the merged dir, what effect that has on reading files AND also writing files. Knowing if it works, or its limitations, is key to evaluate a PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry for the confusion. Here's the full test result:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Zheaoli thanks! This LGTM. I was playing with this, to make sure I'm not missing any case and indeed it seems to work just fine. To play further, I used the example from: https://github.com/landlock-lsm/go-landlock/blob/efb66220540a9ef86aa0160d15e55f429d5b94d9/examples/go-landlock-configurable/main.go With this json config:
And rootfs-merged is an overlayfs that I mounted manually. I tried it works as expected (can't create files on any paths except on ./rootfs-merged/tmp/, can't ls/read files except in that path), also if I chroot into that ( The files are created by overlayfs in the upper dir and all is as expected. |
||
* **`handledAssessNetwork`** (array of strings, OPTIONAL) is an array of NETWORK typed actions that are handled by a ruleset. (The NETWORK typed actions are avaliable when the ABI version >= 4. the behavior of the NETWORK typed actions is not used when the ABI version is less than 4 will depend on the **`disableBestEffort`**) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm sure you meant "Access" here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (The sentences in parenthesis have broken grammar) |
||
* **`rules`** (object, OPTIONAL) the `rules` field specifies the security policies (i.e., actions allowed on objects) to be added to an existing ruleset. | ||
The `rules` currently contains the following types: | ||
* **`pathBeneath`** (array of objects, OPTIONAL) is an array of the file-hierarchy typed rules. | ||
Entries in the array contain the following properties: | ||
* **`allowedAccess`** (array of strings, OPTIONAL) is an array of FS typed actions that are allowed by a rule. The actions are grouped by the ABI version in the following description: | ||
1. ABI version >= 1: | ||
1. exectute | ||
2. write_file | ||
3. read_file | ||
4. read_dir | ||
5. remove_dir | ||
6. remove_file | ||
7. make_char | ||
8. make_dir | ||
9. make_reg | ||
10. make_sock | ||
11. make_fifo | ||
12. make_block | ||
13. make_sym | ||
2. ABI version >= 2: | ||
1. refer | ||
3. ABI version >= 3: | ||
1. truncate | ||
* **`paths`** (array of strings, OPTIONAL) is an array of files or parent directories of the file hierarchies to restrict. | ||
* **`portBeneath`** (array of objects, OPTIONAL) is an array of the network-hierarchy typed rules. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. portBeneath? Is this for all ports below the number? Or is this just a c&p mistake? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it's for all ports below the number. Actually I follow style with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, okay, thanks. I'm in an off-site this week, so I'll check this up next week. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can't make sense out of that. If I want to have a rule for port 21, 22, 53 and 80, it seems complicated to have a portBeneath rule. For filesystems that makes a lot of sense, because is all beneath this (i.e. subdirs and everything below that), this is applied. It's in the nature of fs. But what does it mean for ports? It seems like a complicated way to express it. Am I missing something? Oh, it seems @gnoack already commented on this. I fully agree: https://github.com/opencontainers/runtime-spec/pull/1241/files#r1508607132 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, exactly -- this is still confusing and would better be named "net port" in line with the It does not permit access for all ports below a given number, but only for that specific port number itself, and the word "hierarchy" is also misleading, as there is nothing hierarchical about that (probably copied over from the file system access rights documentation). |
||
Entries in the array contain the following properties: | ||
* **`allowedAccess`** (array of strings, OPTIONAL) is an array of NETWORK typed actions that are allowed by a rule. The actions are grouped by the ABI version in the following description: | ||
1. ABI version >= 4: | ||
1. bind | ||
2. connect | ||
* **`ports`** (array of strings, OPTIONAL) is an array of network ports to restrict. | ||
* **`disableBestEffort`** (bool, OPTIONAL) the `disableBestEffort` field disables the best-effort security approach for Landlock access rights. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (This is slightly confusing in my mind that the boolean condition has the "inverted" logic here. I assume that in this config format, it is not possible to call this variable "bestEffortFallback" and to make There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This can't completely work, sadly, due to some historic reasons. I've mentioned this also here: #1241 (comment) The thing is, if the container runtime doesn't know about landlock, the whole landlock section will be silently ignored. So, you might think you will have this landlock policy or an error, but the truth is, if the runtime doesn't know about landlock, you can end up without a landlock policy at all. For this reason, we should expose this in the features section too. This way, users of the OCI runtime can know if the runtime knows about landlock and handle that case properly. Without exposing it there, it is not really usable for this security features. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, we can remove the disableBestEffort field and export the features we support in features command instead There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can do boths, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe we can output the feature check like this ? {
"linux": {
"landlock": {
"enabled": true,
"bestEffort": {
"enabled": true // False
},
"fs":{
"enabled": true,
"actions": [
"exectute",
"write_file",
"read_file",
"read_dir",
"remove_dir",
"remove_file",
"make_char",
"make_dir",
"make_reg",
"make_sock",
"make_fifo",
"make_block",
"make_sym",
"refer",
"truncate"
]
},
"network": {
"enabled": true,
"actions": [
"bind",
"connect"
]
}
}
}
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we need to expose all of that. I think just the landlock object with the enabled field will be enough. Then, if the runtime doesn't recognize some of the constants or if the kernel ABI is not the one needed, then make the runtime fail? |
||
This is for conditions when the Landlock access rights explicitly configured by the container are not supported or available in the running kernel. | ||
If the best-effort security approach is enabled (`false`), the runtime SHOULD enforce the strongest rules configured up to the current kernel support, and only be [logged as a warning](runtime.md#warnings) for those not supported. | ||
If disabled (`true`), the runtime MUST [generate an error](runtime.md#errors) if one or more rules specified by the container is not supported. | ||
Default is `false`, i.e., following a best-effort security approach. | ||
|
||
### <a name="configUser" />User | ||
|
||
|
@@ -397,6 +443,79 @@ _Note: symbolic name for uid and gid, such as uname and gname respectively, are | |
"class": "IOPRIO_CLASS_IDLE", | ||
"priority": 4 | ||
}, | ||
"landlock": { | ||
"ruleset": { | ||
"handledAccessFS": [ | ||
"execute", | ||
"write_file", | ||
"read_file", | ||
"read_dir", | ||
"remove_dir", | ||
"remove_file", | ||
"make_char", | ||
"make_dir", | ||
"make_reg", | ||
"make_sock", | ||
"make_fifo", | ||
"make_block", | ||
"make_sym", | ||
"refer", | ||
"truncate" | ||
], | ||
"handledAssessNetwork": [ | ||
"bind", | ||
"connect" | ||
] | ||
}, | ||
"rules": { | ||
"pathBeneath": [ | ||
{ | ||
"allowedAccess": [ | ||
"execute", | ||
"read_file", | ||
"read_dir" | ||
], | ||
"paths": [ | ||
"/usr", | ||
"/bin" | ||
] | ||
}, | ||
{ | ||
"allowedAccess": [ | ||
"execute", | ||
"write_file", | ||
"read_file", | ||
"read_dir", | ||
"remove_dir", | ||
"remove_file", | ||
"make_char", | ||
"make_dir", | ||
"make_reg", | ||
"make_sock", | ||
"make_fifo", | ||
"make_block", | ||
"make_sym" | ||
], | ||
"paths": [ | ||
"/tmp" | ||
] | ||
} | ||
], | ||
"portBeneath": [ | ||
{ | ||
"allowedAccess": [ | ||
"bind", | ||
"connect" | ||
], | ||
"ports": [ | ||
80, | ||
443 | ||
] | ||
} | ||
] | ||
}, | ||
"disableBestEffort": false | ||
}, | ||
"noNewPrivileges": true, | ||
"capabilities": { | ||
"bounding": [ | ||
|
@@ -1151,7 +1270,8 @@ Here is a full example `config.json` for reference. | |
|
||
[apparmor]: https://wiki.ubuntu.com/AppArmor | ||
[cgroup-v1-memory_2]: https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt | ||
[selinux]:http://selinuxproject.org/page/Main_Page | ||
[selinux]: http://selinuxproject.org/page/Main_Page | ||
[landlock]: https://landlock.io | ||
[no-new-privs]: https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt | ||
[proc_2]: https://www.kernel.org/doc/Documentation/filesystems/proc.txt | ||
[umask.2]: http://pubs.opengroup.org/onlinepubs/009695399/functions/umask.html | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -46,6 +46,11 @@ | |
"minimum": 0, | ||
"maximum": 100 | ||
}, | ||
"port": { | ||
"type": "integer", | ||
"minimum": 0, | ||
"maximum": 65535 | ||
}, | ||
"mapStringString": { | ||
"type": "object", | ||
"patternProperties": { | ||
|
@@ -75,6 +80,12 @@ | |
"type": "string" | ||
} | ||
}, | ||
"ArrayOfPorts":{ | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/definitions/port" | ||
} | ||
}, | ||
"FilePath": { | ||
"type": "string" | ||
}, | ||
|
@@ -165,6 +176,98 @@ | |
}, | ||
"annotations": { | ||
"$ref": "#/definitions/mapStringString" | ||
}, | ||
"LandlockFSAction": { | ||
"type": "string", | ||
"enum": [ | ||
"execute", | ||
"write_file", | ||
"read_file", | ||
"read_dir", | ||
"remove_dir", | ||
"remove_file", | ||
"make_char", | ||
"make_dir", | ||
"make_reg", | ||
"make_sock", | ||
"make_fifo", | ||
"make_block", | ||
"make_sym", | ||
"refer", | ||
"truncate" | ||
] | ||
}, | ||
"LandlockNetworkAction": { | ||
"type": "string", | ||
"enum": [ | ||
"bind", | ||
"connect" | ||
] | ||
}, | ||
"ArrayOfLandlockFSActions": { | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/definitions/LandlockFSAction" | ||
} | ||
}, | ||
"ArrayOfLandlockNetworkActions": { | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/definitions/LandlockNetworkAction" | ||
} | ||
}, | ||
"LandlockRuleset": { | ||
"type": "object", | ||
"properties": { | ||
"handledAccessFS": { | ||
"$ref": "#/definitions/ArrayOfLandlockFSActions" | ||
}, | ||
"handledAssessNetwork": { | ||
"$ref": "#/definitions/ArrayOfLandlockNetworkActions" | ||
} | ||
} | ||
}, | ||
"LandlockRulePathBeneath": { | ||
"type": "object", | ||
"properties": { | ||
"allowedAccess": { | ||
"$ref": "#/definitions/ArrayOfLandlockFSActions" | ||
}, | ||
"paths": { | ||
"$ref": "#/definitions/ArrayOfStrings" | ||
} | ||
} | ||
}, | ||
"LandlockRulePortBeneath": { | ||
"type": "object", | ||
"properties": { | ||
"allowedAccess": { | ||
"$ref": "#/definitions/ArrayOfLandlockNetworkActions" | ||
}, | ||
"paths": { | ||
"$ref": "#/definitions/ArrayOfPorts" | ||
} | ||
} | ||
}, | ||
"ArrayOfLandlockRulePathBeneaths": { | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/definitions/LandlockRulePathBeneath" | ||
} | ||
}, | ||
"ArrayOfLandlockRulePortBeneaths": { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See comment on the other file about the word "beneath" when talking about network ports |
||
"type": "array", | ||
"items": { | ||
"$ref": "#/definitions/LandlockRulePortBeneath" | ||
} | ||
}, | ||
"LandlockRules": { | ||
"type": "object", | ||
"properties": { | ||
"pathBeneath": { | ||
"$ref": "#/definitions/ArrayOfLandlockRulePathBeneaths" | ||
} | ||
} | ||
} | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -96,7 +96,86 @@ type Process struct { | |
IOPriority *LinuxIOPriority `json:"ioPriority,omitempty" platform:"linux"` | ||
// ExecCPUAffinity specifies CPU affinity for exec processes. | ||
ExecCPUAffinity *CPUAffinity `json:"execCPUAffinity,omitempty" platform:"linux"` | ||
} | ||
// Landlock specifies the Landlock unprivileged access control settings for the container process. | ||
// `noNewPrivileges` must be enabled to use Landlock. | ||
Landlock *Landlock `json:"landlock,omitempty" platform:"linux"` | ||
} | ||
|
||
// Landlock specifies the Landlock unprivileged access control settings for the container process. | ||
type Landlock struct { | ||
// Ruleset identifies a set of rules (i.e., actions on objects) that need to be handled. | ||
Ruleset *LandlockRuleset `json:"ruleset,omitempty" platform:"linux"` | ||
// Rules are the security policies (i.e., actions allowed on objects) to be added to an existing ruleset. | ||
Rules *LandlockRules `json:"rules,omitempty" platform:"linux"` | ||
// DisableBestEffort disables the best-effort security approach for Landlock access rights. | ||
// This is for conditions when the Landlock access rights explicitly configured by the container are not | ||
// supported or available in the running kernel. | ||
// Default is false, i.e., following a best-effort security approach. | ||
DisableBestEffort bool `json:"disableBestEffort,omitempty" platform:"linux"` | ||
} | ||
|
||
// LandlockRuleset identifies a set of rules (i.e., actions on objects) that need to be handled. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Documentation nit: "The Ruleset identifies a set of rules" is a trivial statement which does not provide much additional value, IMHO. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. BTW, I think the naming of the "Landlock" and "LandlockRuleset" types is a bit backwards: In Landlock, the "ruleset" (which is a file descriptor under the hood), is actually the thing where users add their "path beneath" and "net port" rules. (Whereas, in this proposal, the "Ruleset" type does not actually hold the rules...? %-)) The "handled access rights" are just the information needed when creating the initial (empty) ruleset. If the kernel, the struct with the access rights is called the "ruleset attributes", but you might as well call it "handled access rights" or something like that, if you have the flexibility in your code to change that name later on. |
||
type LandlockRuleset struct { | ||
// HandledAccessFS is a list of actions that is handled by this ruleset and should then be | ||
// forbidden if no rule explicitly allow them. | ||
HandledAccessFS []LandlockFSAction `json:"handledAccessFS,omitempty" platform:"linux"` | ||
// HandledAccessNetwork is a list of actions that is handled by this ruleset and should then be | ||
// forbidden if no rule explicitly allow them. | ||
HandledAccessNetwork []LandlockNetworkAction `json:"handledAccessNetwork,omitempty" platform:"linux"` | ||
} | ||
|
||
// LandlockRules represents the security policies (i.e., actions allowed on objects). | ||
type LandlockRules struct { | ||
// PathBeneath specifies the file-hierarchy typed rules. | ||
PathBeneath []LandlockRulePathBeneath `json:"pathBeneath,omitempty" platform:"linux"` | ||
// PortBeneath specifies the network-socket typed rules. | ||
PortBeneath []LandlockRulePortBeneath `json:"portBeneath,omitempty" platform:"linux"` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The two types of rules that exist in Landlock are "path beneath" and "net port", in the Linux headers. I would encourage you to stay consistent with that naming, as it will make it easier for users to map your API to the Landlock documentation. The word "beneath" is referring to the hierarchical nature of file systems -- when an access right is granted on a directory, it also applies to the files beneath that directory. The word "beneath" is inappropriate when used together with ports, as we have no such hierarchy there. |
||
} | ||
|
||
// LandlockRulePathBeneath defines the file-hierarchy typed rule that grants the access rights specified by | ||
// `AllowedAccess` to the file hierarchies under the given `Paths`. | ||
type LandlockRulePathBeneath struct { | ||
// AllowedAccess contains a list of allowed filesystem actions for the file hierarchies. | ||
AllowedAccess []LandlockFSAction `json:"allowedAccess,omitempty" platform:"linux"` | ||
// Paths are the files or parent directories of the file hierarchies to restrict. | ||
Paths []string `json:"paths,omitempty" platform:"linux"` | ||
} | ||
|
||
type LandlockRulePortBeneath struct { | ||
// AllowedAccess contains a list of allowed network actions for the network sockets. | ||
AllowedAccess []LandlockNetworkAction `json:"allowedAccess,omitempty" platform:"linux"` | ||
// Ports are the network ports to restrict. | ||
Ports []string `json:"ports,omitempty" platform:"linux"` | ||
} | ||
|
||
// LandlockFSAction used to specify the FS actions that are handled by a ruleset or allowed by a rule. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "LandlockFSAction specifies the FS actions that are handled by a ruleset or allowed by a rule." ("used to specify" is also past tense, which is a bit confusing to read) |
||
type LandlockFSAction string | ||
|
||
// Define actions on files and directories that Landlock can restrict a sandboxed process to. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Documentation nit: The word "define" is usually unnecessary in docstrings (all of the exported symbols are defining something after all) |
||
const ( | ||
LLFSActExecute LandlockFSAction = "execute" | ||
LLFSActWriteFile LandlockFSAction = "write_file" | ||
LLFSActReadFile LandlockFSAction = "read_file" | ||
LLFSActReadDir LandlockFSAction = "read_dir" | ||
LLFSActRemoveDir LandlockFSAction = "remove_dir" | ||
LLFSActRemoveFile LandlockFSAction = "remove_file" | ||
LLFSActMakeChar LandlockFSAction = "make_char" | ||
LLFSActMakeDir LandlockFSAction = "make_dir" | ||
LLFSActMakeReg LandlockFSAction = "make_reg" | ||
LLFSActMakeSock LandlockFSAction = "make_sock" | ||
LLFSActMakeFifo LandlockFSAction = "make_fifo" | ||
LLFSActMakeBlock LandlockFSAction = "make_block" | ||
LLFSActMakeSym LandlockFSAction = "make_sym" | ||
LLFSActRefer LandlockFSAction = "refer" | ||
LLFSActTruncate LandlockFSAction = "truncate" | ||
) | ||
|
||
type LandlockNetworkAction string | ||
|
||
const ( | ||
LLNetworkActConnect LandlockNetworkAction = "connect" | ||
LLNetworkActBind LandlockNetworkAction = "bind" | ||
) | ||
|
||
// LinuxCapabilities specifies the list of allowed capabilities that are kept for a process. | ||
// http://man7.org/linux/man-pages/man7/capabilities.7.html | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR should be carefully updated following the latest advances of landlock (rather than simply carried) as some of the spec proposals might be stale now. Pls see https://docs.kernel.org/userspace-api/landlock.html and https://github.com/landlock-lsm/go-landlock for details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you got time to continue this PR or I can continue carry(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pls go ahead updating this PR. I'll need some time to follow up and dive into the updates of landlock (even for review).