agent/runtime: Add seccomp feature #1788

ManaSugi · 2021-05-02T09:18:02Z

The agent supports seccomp capability based on the OCI runtime specification.
This seccomp capability in the agent is enabled by default.
However, it is not enforced by default: users need to enable that in the main configuration file.

Fixes: #1476

Signed-off-by: Manabu Sugimoto Manabu.Sugimoto@sony.com

ManaSugi · 2021-05-02T09:48:04Z

Change history:
Updated on July 2 2021
Updated on June 30 2021

Experiments of the seccomp feature

Apply a seccomp profile to kata container using crictl
Restricted system calls in the seccomp profiles are as follows.

getuid
chdir
dup2
- The dup2 syscall will fail only the new file descriptor is zero (stdin).

For more details of the seccomp profile, please see the seccomp.json in the following config files.

Conduct experiments using `crictl`

$ sudo crictl run -r kata container.json sandbox.json
---
97b17cdf8fe4e3093f8a695dd9b4d1a60167326edc021018de6516e3805a830b

$ sudo crictl attach --stdin --tty 97b17cdf8fe4e3093f8a695dd9b4d1a60167326edc021018de6516e3805a830b
# id
uid=4294967295 gid=0(root) euid=0(root) groups=0(root)

# cd
/usr/bin/sh: 2: cd: can't cd to /root

# ls -l | grep home
ls: write error: Broken pipe

Each command inside the container fails due to the seccomp profile.

Config files

seccomp.json

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86"
  ],
  "flags": [
    "SECCOMP_FILTER_FLAG_TSYNC"
  ],
  "syscalls": [
    {
      "names": [
        "getuid",
        "chdir"
      ],
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "names": [
        "dup2"
      ],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 1,
          "value": 0,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

sandbox.json

{
    "metadata": {
        "name": "ubuntu-pod",
        "uid": "ubuntu-pod",
        "namespace": "test.kata"
    },
    "hostname": "ubuntu_host",
    "log_directory": "",
    "dns_config": {
    },
    "port_mappings": [],
    "resources": {
    },
    "labels": {
    },
    "log_path": "/var/run/kata.log",
    "linux": {
    }
}

container.json

{
    "metadata": {
        "name": "ubuntu",
        "namespace": "test.kata"
    },
    "image": {
        "image": "docker.io/ubuntu"
    },
    "command": [
        "/usr/bin/sh"
    ],
    "working_dir": "/",
    "envs": [
        {
            "key": "PATH",
            "value": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
        },
        {
            "key": "TERM",
            "value": "xterm"
        }
    ],
    "stdin": true,
    "stdin_once": true,
    "tty": true,
    "log_path": "/var/run/kata.log",
    "linux": {
        "security_context": {
            "seccomp_profile_path": "localhost/<path of seccomp.json>/seccomp.json"
        }
    }
}

Evironment information

my experimental environment

$ uname -a
Linux #### 5.8.0-50-generic #56~20.04.1-Ubuntu SMP Mon Apr 12 21:46:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ containerd --version
containerd github.com/containerd/containerd v1.4.0-beta.1-55-gc7518074 c75180740937d4b2d44b9c1edc1c27b208e66e32

$ crictl --version
crictl version v1.21.0

libseccomp version
2.5.1

How to enable the seccomp feature

To enable the seccomp feature, we need to take the following 3 steps.

Enable seccomp support for the kata-runtime
- Set disable_guest_seccomp as false in configuration.toml to pass the seccomp profile to the kata-agent
- e.g.
  $ sudo sed -i '/^disable_guest_seccomp/ s/true/false/' /etc/kata-containers/configuration.toml
Setup for libseccomp
- Installing the libseccomp library
  - We need to build the libseccomp library from sources to create a static library for musl libc.
  - We can use ci/install_libseccomp.sh that is script to build and install the libseccomp library for the musl libc.
  - Usage:
```
$ ./install_libseccomp.sh ${install_dir_libseccomp} ${install_dir_gperf}
```
- Set the environment variables for libseccomp crate
  $ export LIBSECCOMP_LINK_TYPE=static
  $ export LIBSECCOMP_LIB_PATH= ${install_dir_libseccomp}/lib
- Note:
  We should use the crate with statically linked the libseccomp library because the agent runs inside the VM. It is possible to use the crate with dynamically linked the library, but we must set the correct path of libseccomp.so inside the kata image. That is not best solution because we need to set rpath properly.
Enable agent seccomp support
- The kata-agent is built with seccomp capability by default.
- If we do not want to build the agent without seccomp capability, we need to set SECCOMP to no when building the agent as follows.
  make SECCOMP=no
- When we create rootfs without seccomp capability, we need to run the rootfs.sh script with SECCOMP=no as follows.
  $ cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/rootfs-builder
  $ script -fec 'sudo -E GOPATH=$GOPATH AGENT_INIT=yes USE_DOCKER=true SECCOMP=no ./rootfs.sh ${distro}'

We used to use SECCOMP=yes|no in rootfs.sh to determine whether seccomp package (libseccomp2) is included in the image. In this commit, we use it for passing the flag to the agent's Makefile. The libseccomp package in the image is no longer needed, so I'll remove the package the next pull request.

How to enoforce the seccomp

We need to provide a seccomp profile when we use k8s or crictl like the above experiments.

Summary of the way to enable seccomp feature

Seccomp profile provided? ¹	Runtime seccomp enabled? ²	Agent seccomp enabled? ³	Seccomp enforced? ⁴	Notes
no	no	no	no	No seccomp profile
no	yes	no	no	No seccomp profile
no	no	yes	no	No seccomp profile
no	yes	yes	no	No seccomp profile
yes	no	no	no	Seccomp profile is not passed to the runtime. Therefore, `grpc.Linux.Seccomp` is `null`.
yes	yes	no	no	Profile provided and `grpc.Linux.seccomp` is passed to the agent, but the agent disables seccomp feature. The runtime exits conservatively with an error message.
yes	no	yes	no	Seccomp profile is not passed to the runtime.Therefore, `grpc.Linux.Seccomp` is `null`.
yes	yes	yes	yes	Now, seccomp rule is enforced. 😄

Footnotes:

1: Implicitly or explicitly. If the seccomp profile is provided, the seccomp object will be present in the OCI config.json file.
2: Whether the seccomp support is enabled in the runtime's configuration.toml configuration file.
3: Whether the seccomp feature of the agent is enabled in the agent's Makefile.
4: Whether the seccomp rule will be applied.

Notes

If we use the libseccomp crate with statically linked the libsecomp library, we should comply with GNU LGPL-2.1 licensed the libseccomp library when we distribute the kata agent binary.
Therefore, we must attach the complete source code for the libraries with annotations about the license in order to comply with the LGPL-2.1 (6(a)).

Next actions

Modify CI test to verify this seccomp feature
Remove the libseccomp package (libseccomp) in the rootfs
- If the agent always uses the libseccomp crate with statically linked, we do not need the libseccomp in rootfs anymore.
Update documents
Discuss the type of linking the libseccomp library
Need to include the libseccomp source code into artifacts in order to comply with GNU LGPL-2.1

fidencio · 2021-05-02T10:05:24Z

This is really cool, I'll take a closer look at this in the coming week, @ManaSugi!

Thanks a lot for working on this one!

fidencio · 2021-05-02T10:05:40Z

/test

ManaSugi · 2021-05-03T14:05:33Z

Sorry.
I fixed no newline at end of file in rustjail's Cargo.toml and removed warning in agent's Makefile that I was using for just debugging.

mxpv

🎉 A couple of comments

src/agent/rustjail/src/container.rs

src/agent/rustjail/src/seccomp.rs

src/agent/rustjail/Cargo.toml

egernst · 2021-05-03T23:55:24Z

src/agent/protocols/protos/agent.proto

-
-	// Set only if the agent is built with seccomp support and the guest
-	// environment supports seccomp.
-	bool supports_seccomp = 5;


Do we want to update the agent API?

Yes.
I think that supports_seccomp flag always will be true, so the flag is not used anymore.
In addition, we can control whether the agent's seccomp support is enabled when building the agent.
If users want to control the flag through the agent API, we should leave it, but I'm not sure if there is such a use case.
Could you give me your thoughts?

If we don't use a field, we should leave it here for rpc protocol compatibility. Please don't remove it.

And in fact, the field is useful on the runtime side so that we can dynamically determine if seccomp info should be passed to the agent or not. Please look at src/runtime/virtcontainers/kata_agent.go and see how it works currently.

ManaSugi · 2021-05-04T11:04:07Z

src/agent/rustjail/src/container.rs

+    #[cfg(feature = "seccomp")]
+    if !oci_process.no_new_privileges {
+        if let Some(ref scmp) = linux.seccomp {
+            seccomp::init_seccomp(scmp)?;


Shoud we implement the errror handling like below?

if !oci_process.no_new_privileges { if let Some(ref scmp) = linux.seccomp { #[cfg(feature = "seccomp")] seccomp::init_seccomp(scmp)?; #[cfg(not(feature = "seccomp"))] return Err(anyhow!("Seccomp config provided but seccomp not supported")); } }

This error tells users that the runtime enables seccomp support, but the agent does not enable seccomp.

This error is handled in the runtime by the commit.

I think this approach is safer: if the admin asked for seccomp but it isn't available, I'd prefer to get a hard error telling me that immediately. The current code doesn't error, which may lead an admin to think seccomp is being enforced when it isn't (which would be surprising and potentially dangerous).

Yes. Hence, I have already added the error in kata-runtime at the following point.
https://github.com/kata-containers/kata-containers/pull/1788/files#diff-6fb7f551035031ed29ad100c61f1a7e92b0fa15d2f67e4c7ea7ebf3b715583f4R1424

If the user enables seccomp in the runtime using disable_guest_seccomp, but the agent does not have seccomp capability, the runtime exits conservatively with the error message. Therefore, we can guarantee that the agent has seccomp capability when seccomp profiles are passed to the agent.

liubin · 2021-05-06T03:09:14Z

Thank you @ManaSugi for this great PR.
I just have one question about why make seccomp a feature in agent source code. Only for easy delivering of agent binary for the license issue?

ManaSugi · 2021-05-06T10:03:41Z

I just have one question about why make seccomp a feature in agent source code. Only for easy delivering of agent binary for the license issue?

@liubin
There are two reasons I'd like to make seccomp a feature in agent code.
One is making easy delivering of agent binary for the license issue as you mentioned.
Another one is that I'd like to offer users an option of disabling seccomp feature.
Without the option, they need to install libseccomp library (e.g. libseccomp-dev) on their host machine when building the agent (actually compiling libseccomp crate) even if they does not have plan to use seccomp feature.
That may be annoying for some users.

liubin · 2021-05-06T11:01:16Z

@ManaSugi thank you for the clarification.

src/agent/Makefile

ManaSugi · 2021-05-10T03:58:53Z

Now, I'm creating unit test inside the seccomp.rs, so I'll send it as an additional commit when I'm done.

ManaSugi · 2021-05-11T09:17:30Z

This test runs only as a root because loading seccomp filter (filter.load()) fails if the user does not have CAP_SYS_ADMIN by unsetting no new privileges bit.
Regarding flags in seccomp profile, I selected SECCOMP_FILTER_FLAG_LOG because we can check the behavior easily than other flags.
We can check if the system call in profile is logged properly by SECCOMP_FILTER_FLAG_LOG as follows.

# ausearch -i -m SECCOMP -x kata

In addition, bump libseccomp crate version to 0.1.3.

bergwolf · 2021-05-14T02:37:41Z

What is the cost of running a seccomp capable agent but do not enforce it? I'm wondering if we should just always enable the capability, and optionally enforce it when starting the agent.

ManaSugi · 2021-05-14T09:42:17Z

@bergwolf
Thank you for the comment.

From a performance point, the cost may be nothing.
Therefore, when we destribute the agent binary, it is always better to enable the seccomp feature.

However, if we always enforce the seccomp feature in the agent srouce code, users who build the agent from the source code need to install libsecomp library (e.g. libseccomp-dev) even if they do not use the feature.
I guess it may be annoying for some users.
Therefore, I think it is better not to enforce the feature.

Could you give me your thoughts?

bergwolf · 2021-05-17T02:56:48Z

@ManaSugi Thanks for the explanation! Then how about building it by default, and we ship the agent with seccomp capability builtin but disabled by default? And we can provide a For those who don't have libseccomp dev library and want to build agent by themselves. The benefit is that we don't have to ship two versions of kata agent (which means two versions of guest images).

ManaSugi · 2021-05-17T04:48:11Z

@bergwolf
Thanks for the reply.
Yes, the kata agent we ship is only one version that has seccomp capability.

we ship the agent with seccomp capability builtin but disabled by default?

I have a question.
Does disabled by default mean SECCOMP=no in the agent's Makefile, doesn't it?

I'm sorry for the lack of explanation and let me check we're on the same page here.
We do not need libseccomp-dev in the rootfs of kata because the agent always uses the libseccomp crate with statically linked.
libseccomp-dev is required only when we build the agent (actually build libseccomp crate)
Therefore, we should remove the libseccomp-dev in the rootfs in next actions as I mentioned eariler.
e.g.
https://github.com/kata-containers/kata-containers/blob/main/tools/osbuilder/rootfs-builder/ubuntu/config.sh#L33
I'll remove the libseccomp package inside the above script in the next pull request.

bergwolf

@ManaSugi Sorry for the delay. By disabled by default I mean disabling it by the runtime. The agent binary has the secomp capability built-in. The capability is exposed to the runtime and runtime can then decide if seccomp info needs to be passed to the agent. So here is my proposal:

we add a runtime config option to enable seccomp, and disable it by default
we add kata-agent build flag to control if seccomp it builtin, and enable it by default
for those who want seccomp support, they can just use the prebuilt agent and alter runtime config to enable it
for those who don't even want seccomp be built, they can build their own agent w/o seccomp support

Also please keep the supports_seccomp bit in the agent protocol, so that runtime can know if seccomp is supported by agent when runtime config asks for it, and fail properly if the required feature is not supported.

wdyt?

bergwolf · 2021-05-25T02:29:49Z

src/agent/protocols/protos/agent.proto

-
-	// Set only if the agent is built with seccomp support and the guest
-	// environment supports seccomp.
-	bool supports_seccomp = 5;


If we don't use a field, we should leave it here for rpc protocol compatibility. Please don't remove it.

And in fact, the field is useful on the runtime side so that we can dynamically determine if seccomp info should be passed to the agent or not. Please look at src/runtime/virtcontainers/kata_agent.go and see how it works currently.

ManaSugi · 2021-05-27T16:12:28Z

@bergwolf, Thank you for your kind reply and proposal.

I understand clearly and agree with your proposal. Also, I keep the supports_seccomp bit in the agent protocol.
I fixed the points that were pointed out.

I reverted the supports_seccomp bit.
I added the seccomp feature in the kata agent's Cargo.toml.
If the agent is built with the feature, the rustjail's seccomp feature also turns on and supports_seccomp bit is set.
In addition, if the runtime enables seccomp in configuration.toml and the agent does not support seccomp (supports_seccomp==false), the runtime fails properly with an error message.
I enabled the seccomp feature by default.

bergwolf

lgtm! Thanks @ManaSugi !

bergwolf · 2021-05-28T07:27:21Z

@ManaSugi Please rebase to solve code conflicts. Thanks!

jodh-intel

Thanks @ManaSugi.

A few comments.

src/agent/Makefile

jodh-intel · 2021-05-28T10:17:24Z

src/agent/rustjail/src/container.rs

+#[cfg(feature = "seccomp")]
+use crate::seccomp;


If this feature is optional, we should specify whether it is available in announce() (for the logs). We already have a seccomp field in the GetGuestDetails() ttRPC response so in fact it might be worth just adding the output of get_agent_details() to the output of announce().

I understand.
I added the information of seccomp capability in the agent to AgentConfig.
So, announce() can output the information through AgentConfig.
Could you give me your thoughts about that?

jodh-intel · 2021-05-28T10:19:25Z

src/agent/rustjail/Cargo.toml

+[features]
+seccomp = ["libseccomp"]


This has a CI impact: strictly, we'll need a new CI with this feature enabled. Is that something we can accommodate @GabyCT and @chavafg? In fact, really we'd need one new CI per architecture.

Yes, we need to modify the CI.
~~Fortunately, all distributions in CI already have libseccomp-dev package and the agent enables seccomp capability by default.~~
Regarding a unit test, we need to install the libseccomp library and set the environment variables of the libseccomp crate because the agent has seccomp feature by default.
First, we have to build the libseccomp libraries for the <arch>-unknown-linux-musl target to link the libseccomp statically and install it.
e.g.,

$ wget https://github.com/seccomp/libseccomp/releases/download/v2.5.1/libseccomp-2.5.1.tar.gz $ tar xvf libseccomp-2.5.1.tar.gz $ cd libseccomp-2.5.1 $ ./configure CPPFLAGS="-I/usr/include/x86_64-linux-musl" --enable-static --disable-shared $ make $ sudo make install

Second, set the environment variables for libseccomp crate before building the agent.
e.g.

$ export LIBSECCOMP_LINK_TYPE=static $ export LIBSECCOMP_LIB_PATH=/usr/local/lib

Regarding an integration test with k8s, we have to add a seccomp profile for k8s in k8s-security-context.bats.
In that case, we also have to set disable_guest_seccomp as false in runtime's configuration like below.
$ sudo sed -i '/^disable_guest_seccomp/ s/true/false/' /etc/kata-containers/configuration.toml

I'm sorry if I'm wrong about CI.

tools/osbuilder/rootfs-builder/rootfs.sh

jodh-intel · 2021-05-28T10:28:43Z

src/agent/rustjail/src/seccomp.rs

+            "architectures": [
+                "SCMP_ARCH_X86",
+                "SCMP_ARCH_X32",
+                "SCMP_ARCH_X86_64",
+                "SCMP_ARCH_AARCH64",
+                "SCMP_ARCH_ARM"


Kata also works on PPC64 and s390x so won't this test fail unless you add them here?

I added PPC64 and S390X in the unit test.
To avoid endian mismatch error of libseccomp, I divided the architecture by endian.
Ref: seccomp/libseccomp@2745d8a

jodh-intel · 2021-06-08T08:13:40Z

Any update on this @ManaSugi?

ManaSugi · 2021-06-08T14:49:24Z

I apologize for the late reply and thank you for the review @jodh-intel @bergwolf.
I updated and resolved the conflicts.

Jakob-Naucke · 2021-10-26T10:46:18Z

@jongwu sorry, no -- I don't do a ton of musl obv 😁

ManaSugi · 2021-10-26T10:51:52Z

@jongwu
Could you compile libseccomp with -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 flag on arm again?

jongwu · 2021-10-26T11:00:09Z

I'm not sure I can fix the error quickly. Maybe we can skip this feature on arm temporarily and get it fixed later.

-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2

I tried, but it doesn't work. I'm not sure we can fix it quickly. maybe we can skip it on arm temporarily and get it fixed later.

ManaSugi · 2021-10-27T06:42:18Z

@jongwu @Jakob-Naucke
This failure on ARM will occur because the agent tries to link libseccomp library of the distro package dynamically at the following location in CI.
https://github.com/kata-containers/tests/blob/main/.ci/jenkins_job_build.sh#L180

The reason why the failure does not occur in the case of s390x is that the agent uses gnu-libc on s390x (in the case of x86, the test is skipped).
To pass the test, we need to set LIBSECCOMP_LINK_TYPE and LIBSECCOMP_LIB_PATH env for the libseccomp crate and run install_libseccomp.sh as follows before building the agent with libseccomp statically. I'll create a PR to add them to jenkins_job_build.sh.
https://github.com/kata-containers/kata-containers/pull/1788/files#diff-c48d511a9715d535281eea19171682653656dc361be1547ac1a8cd9bc790edbfR568

ManaSugi · 2021-10-27T07:49:30Z

To run install_libseccomp.sh in test/.ci/jenkins_job_build.sh, I need to land install_libseccomp.sh at first.
Which is better, merging whole this PR with disabling seccomp feature on arm temporarily OR merging only install_libseccomp.sh at first?

jongwu · 2021-10-27T08:00:00Z

Hello @ManaSugi -, good new of finding the root cause. I prefer to skip it on arm and enable it back in the new PR. I don't want to block this so long.

The kata-agent supports seccomp feature based on the OCI runtime specification. This seccomp capability in the kata-agent is enabled by default. However, it is not enforced by default: users need to enable that by setting `disable_guest_seccomp` to `false` in the main configuration file. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

The osbuilder needs to set up libseccomp library to build the kata-agent because the kata-agent supports seccomp currently. The library is built from the sources to create a static library for musl libc. In addition, environment variables for the libseccomp crate are set to link the library statically. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

This adds a step for installing libseccomp because the kata-agent supports seccomp feature. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

This adds explanation about how to enable seccomp in the kata-runtime and build the kata-agent with seccomp capability. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

In order to pass CI test of aarch64, it is necessary to run `ci/install_libseccomp.sh` before ruuning unit tests in `jenkins_job_build.sh`. However, `ci/install_libseccomp.sh` is not available until PR kata-containers#1788 including this commit is merged in the mainline. Therefore, we disable seccomp feature on aarch64 temporarily. After kata-containers#1788 lands and CI is fixed, this commit will be reverted. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

ManaSugi · 2021-10-27T10:08:26Z

@jongwu Thank you for your comment. I added a commit to disable seccomp feature on aarch64.

jodh-intel

Thanks @ManaSugi.

lgtm

jodh-intel · 2021-10-27T10:14:43Z

/test

ManaSugi · 2021-10-27T11:41:21Z

/test-clh-k8s-containerd

ManaSugi · 2021-10-27T13:00:24Z

Thank you all for the great reviews for a long time.
After this is merged, I'll fix CI for aarch64, revert last commit in this PR, and try to use version database.
In addition, I'll create issue and PR about fixing release note because we should comply with GNU LGPL-2.1 licensed the libseccomp library when we distribute the kata-agent binary.
We have to attach the complete source code for the libseccomp library with annotations about the license in order to comply with the LGPL-2.1 (6(a)).

Need to install libseccomp library from sources before running unit tests because Kata agent enables seccomp feature Depends-on: kata-containers/kata-containers#1788 Fixes: kata-containers#4123 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

jodh-intel · 2021-10-27T13:52:11Z

@ManaSugi - Thank you for your patience and perisistence! 😄

Need to install libseccomp library from sources before running unit tests because Kata agent enables seccomp feature Depends-on: kata-containers/kata-containers#1788 Fixes: kata-containers#4123 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

Need to install libseccomp library from sources before running unit tests because Kata agent enables seccomp feature in the [kata-containers#1788](kata-containers/kata-containers#1788) Fixes: kata-containers#4123 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

Need to install libseccomp library from sources before running unit tests because Kata agent enables seccomp feature in the kata-containers/kata-containers#1788 Fixes: kata-containers#4123 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

Kata agent supports seccomp feature from kata-containers#1788. Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

ManaSugi force-pushed the add-seccomp-feature branch from f55d5d4 to 885b429 Compare May 3, 2021 14:01

mxpv reviewed May 3, 2021

View reviewed changes

src/agent/rustjail/src/container.rs Outdated Show resolved Hide resolved

src/agent/rustjail/src/seccomp.rs Outdated Show resolved Hide resolved

src/agent/rustjail/Cargo.toml Outdated Show resolved Hide resolved

egernst reviewed May 3, 2021

View reviewed changes

ManaSugi commented May 4, 2021

View reviewed changes

liubin reviewed May 7, 2021

View reviewed changes

src/agent/Makefile Show resolved Hide resolved

liubin requested a review from lifupan May 7, 2021 09:41

ManaSugi force-pushed the add-seccomp-feature branch 2 times, most recently from 82db087 to 4f8c213 Compare May 11, 2021 16:42

ManaSugi mentioned this pull request May 18, 2021

RFE: investigate Rust bindings seccomp/libseccomp#323

Open

bergwolf reviewed May 25, 2021

View reviewed changes

ManaSugi force-pushed the add-seccomp-feature branch from 8fdd58e to 4c60917 Compare May 28, 2021 01:22

bergwolf approved these changes May 28, 2021

View reviewed changes

jodh-intel reviewed May 28, 2021

View reviewed changes

ManaSugi added 5 commits October 27, 2021 19:06

static-checks: Add step for installing libseccomp

45e7c2c

This adds a step for installing libseccomp because the kata-agent supports seccomp feature. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

docs: Add explanation about seccomp

5dfedc2

This adds explanation about how to enable seccomp in the kata-runtime and build the kata-agent with seccomp capability. Fixes: kata-containers#1476 Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

ManaSugi force-pushed the add-seccomp-feature branch from ce9a898 to 42add7f Compare October 27, 2021 10:06

jodh-intel approved these changes Oct 27, 2021

View reviewed changes

liubin merged commit b85edbf into kata-containers:main Oct 27, 2021

ManaSugi mentioned this pull request Oct 27, 2021

test: Install libseccomp library before running unit tests kata-containers/tests#4123

Closed

ManaSugi mentioned this pull request Oct 27, 2021

test: Install libseccomp library before running unit tests kata-containers/tests#4124

Merged

This was referenced Oct 28, 2021

release: Upload libseccomp source code with notification to release page #2922

Closed

agent: Re-enable seccomp feature on aarch64 #2939

Closed

ManaSugi added a commit to ManaSugi/kata-containers that referenced this pull request Nov 4, 2021

runk: Mark seccomp support

abbc29b

Kata agent supports seccomp feature from kata-containers#1788. Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

ManaSugi added a commit to ManaSugi/kata-containers that referenced this pull request Nov 24, 2021

runk: Mark seccomp support

4a2802b

Kata agent supports seccomp feature from kata-containers#1788. Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>

agent/runtime: Add seccomp feature #1788

agent/runtime: Add seccomp feature #1788

Conversation

ManaSugi commented May 2, 2021 • edited

ManaSugi commented May 2, 2021 • edited

Experiments of the seccomp feature

Conduct experiments using crictl

Config files

Evironment information

How to enable the seccomp feature

How to enoforce the seccomp

Summary of the way to enable seccomp feature

Notes

Next actions

fidencio commented May 2, 2021

fidencio commented May 2, 2021

ManaSugi commented May 3, 2021 • edited

mxpv left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ManaSugi May 4, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ManaSugi Jul 11, 2021 • edited

Choose a reason for hiding this comment

liubin commented May 6, 2021

ManaSugi commented May 6, 2021 • edited

liubin commented May 6, 2021

ManaSugi commented May 10, 2021

ManaSugi commented May 11, 2021 • edited

bergwolf commented May 14, 2021

ManaSugi commented May 14, 2021

bergwolf commented May 17, 2021

ManaSugi commented May 17, 2021 • edited

bergwolf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ManaSugi commented May 27, 2021

bergwolf left a comment

Choose a reason for hiding this comment

bergwolf commented May 28, 2021

jodh-intel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ManaSugi Jun 8, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jodh-intel commented Jun 8, 2021

ManaSugi commented Jun 8, 2021 • edited

Jakob-Naucke commented Oct 26, 2021

ManaSugi commented Oct 26, 2021

jongwu commented Oct 26, 2021

ManaSugi commented Oct 27, 2021 • edited

ManaSugi commented Oct 27, 2021 • edited

jongwu commented Oct 27, 2021

ManaSugi commented Oct 27, 2021

jodh-intel left a comment

Choose a reason for hiding this comment

jodh-intel commented Oct 27, 2021

ManaSugi commented Oct 27, 2021

ManaSugi commented Oct 27, 2021

jodh-intel commented Oct 27, 2021

ManaSugi commented May 2, 2021 •

edited

ManaSugi commented May 2, 2021 •

edited

Conduct experiments using `crictl`

ManaSugi commented May 3, 2021 •

edited

ManaSugi May 4, 2021 •

edited

ManaSugi Jul 11, 2021 •

edited

ManaSugi commented May 6, 2021 •

edited

ManaSugi commented May 11, 2021 •

edited

ManaSugi commented May 17, 2021 •

edited

ManaSugi Jun 8, 2021 •

edited

ManaSugi commented Jun 8, 2021 •

edited

ManaSugi commented Oct 27, 2021 •

edited

ManaSugi commented Oct 27, 2021 •

edited