c#中的反射的高级语法_Kubernetes第3部分中的seccomp新语法以及一些高级主题

程序员文章站 2022-06-17 07:59:48

...

c#中的反射的高级语法

On this part I want to cover a few isolated points that hopefully together would give a bit more depth to your seccomp knowledge.

在这一部分中，我想介绍一些孤立的观点，希望它们在一起可以使您对seccomp的知识有更多的了解。

Seccomp GA终于... (Seccomp GA at last…)

Back in 2016 jessfrazz added seccomp support into Kubernetes v1.3. It stayed in alpha for several years, despite loads of different efforts to get this over the line, until it finally made it to GA on version v1.19 this month — big shout out to everybody involved throughout this journey!

早在2016年， jessfrazz 就在Kubernetes v1.3中添加了对seccomp的支持。尽管为此付出了很多努力，但它仍处于alpha状态，直到本月终于在v1.19版本上进入了GA –在此过程中，涉及到的每个人都大声疾呼！

The existing annotation based support is now deprecated and will be removed from Kubernetes on version v1.23. From now on you will be able to add seccomp based on the new field seccompProfile at Pod or/and Container levels:

现有的基于注释的支持现已弃用，并将从v1.23版本的Kubernetes中删除。从现在开始，您将能够在Pod或/和Container级别基于新字段seccompProfile添加seccomp：

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-seccomp-profile.json

The type field can have three values: Localhost, Unconfined and RuntimeDefault. And the field localhostProfile allows for setting the path of a file from disk. Some details can be found here.

该type字段可以有三个值： Localhost ， Unconfined和RuntimeDefault 。并且localhostProfile字段允许设置磁盘中文件的路径。一些细节可以在这里找到。

GA来解决过去的问题 (GA came to fix issues of the past)

Back on the first part of this series I mentioned about a bug I raised that showed that seccomp profiles applied at pod level were always greedier than the ones implemented at container level.

在本系列的第一部分中，我提到了我提出的一个错误，该错误表明在pod级别应用的seccomp配置文件总是比在容器级别实现的配置更贪婪。

That is now fixed, and the solution was to apply a default seccomp profile to the sandbox container, which now will always run with the seccomp profile RuntimeDefault.

现在，此问题已得到解决，解决方案是将默认的seccomp配置文件应用于沙盒容器，该沙箱容器现在将始终与seccomp配置文件RuntimeDefault一起运行。

From Kubernetes v1.19 it will make little difference between defining seccomp profiles at pod or container levels. Now that decision can be made considering other factors alone, like whether or not you plan to have sidecars added to the pod and what restrictions you want to impose on them — if any.

从Kubernetes v1.19起，在pod或容器级别定义seccomp配置文件之间几乎没有什么区别。现在，可以仅考虑其他因素来做出决定，例如您是否计划将小车添加到吊舱中，以及要对它们施加什么限制(如果有)。

没有seccomp的特权！ (No seccomp for the privileged!)

I recently tried to create a seccomp profile for kured from Weavework. That effort soon got halted as I realised that privileged containers always have its seccomp setting ignored and run as unconfined when the container runtime is docker or CRI-O (potentially others too). This is not consistent with the usage of AppArmor, which can still have custom profiles applied on privileged workloads.

最近，我试图创建一个配置文件的Seccomp为kured从Weavework。当我意识到特权容器总是忽略其seccomp设置并在容器运行时是docker或CRI-O (可能还有其他)时以unconfined的方式运行时，这种努力很快就停止了。这与AppArmor的用法不一致，后者仍然可以将自定义配置文件应用于特权工作负载。

A quick example of that behaviour is as per below when trying to create a file, chmod it and then test the results. Without seccomp it works fine:

当尝试创建文件，对其进行chmod然后测试结果时，该行为的一个简单示例如下所示。没有seccomp，它可以正常工作：

c#中的反射的高级语法_Kubernetes第3部分中的seccomp新语法以及一些高级主题

Applying a “block all” seccomp, makes the container to fail — which is the expected behaviour here:

应用“全部阻止” seccomp，会使容器失败-这是预期的行为：

However, if the container is running as --privileged the seccomp profile is completely ignored:

但是，如果容器以--privileged身份运行，则seccomp配置文件将被完全忽略：

Key point to bear in mind here is, be extra careful with privileged containers as you have very few security controls to keep them in check, which will always make them a bigger target — remember this when threat modelling.

这里要记住的关键点是，对特权容器要格外小心，因为您很少有安全控件可以对其进行检查，这将始终使它们成为更大的目标-在进行威胁建模时请记住这一点。

通过功能控制系统调用 (Gating syscalls through capabilities)

Seccomp filters can also be gated by Linux Capabilities, which will then only be added if the container is running with the given capability. For example, the default profile gates reboot with the CAP_SYS_BOOT capability:

Seccomp筛选器也可以由Linux功能控制，只有在容器以给定功能运行时才添加。例如，默认配置文件门使用CAP_SYS_BOOT功能reboot ：

{
   "names": [
    "reboot"
   ],
   "action": "SCMP_ACT_ALLOW",   "includes": {
    "caps": [
     "CAP_SYS_BOOT"
    ]
   },
   "excludes": {}
}

So although it is marked as allowed, this filter will only be added to the container if it also has that capability. Without the capability the call will be blocked.

因此，尽管已将其标记为允许，但只有具有此功能的过滤器才会添加到容器中。没有该功能，呼叫将被阻止。

建筑学 (Architectures)

Seccomp profiles are created and deployed using syscall names, making it easier to understand their intent. However, they are applied based off their actual syscall IDs, which will differ based on the running architecture (x64, x86, arm, arm64, etc). For example, the system call sys_reboot has different IDs for the architectures: x64 (169) and ARM (88) and ARM64 (142).

Seccomp配置文件是使用syscall名称创建和部署的，从而更易于理解其意图。但是，将根据实际的系统调用ID来应用它们，这些ID会根据运行的体系结构(x64，x86，arm，arm64等)而有所不同。例如，系统调用sys_reboot具有不同的体系结构ID：x64(169)和ARM(88)以及ARM64(142)。

If you define none, the final result will be dependent on how the container runtime chose to implement seccomp. For a more predictable result across runtimes, always define the target architectures for your profiles.

如果未定义，则最终结果将取决于容器运行时选择如何实现seccomp。为了在整个运行时中获得更可预测的结果，请始终为概要文件定义目标体系结构。

MinKernel (MinKernel)

Another powerful feature is the ability to allow a system call only when it is safe to do so. An example is ptrace which before kernel 4.8 was vulnerable to seccomp bypass — a PoC exploit can be found here. With that in mind, the default seccomp profile only allows for ptrace when running on kernel above that version:

另一个强大的功能是仅在安全的情况下才允许系统调用的功能。一个示例是ptrace ，它在内核4.8之前容易受到seccomp旁路的攻击-在此处可以找到PoC攻击。考虑到这一点，默认seccomp配置文件仅在该版本以上的内核上运行时才允许使用ptrace ：

{
   "names": [   "ptrace"   ],
   "action": "SCMP_ACT_ALLOW",   "includes": {
     "minKernel": "4.8"
   },
   "excludes": {}  
},

When creating smaller seccomp profiles, make sure you take this into account as potentially a smaller seccomp may become a useless one when running on an older kernel.

创建较小的seccomp配置文件时，请确保考虑到这一点，因为较小的seccomp可能在较旧的内核上运行时可能变得无用。

不同类型的动作 (The different types of actions)

Below is a list of all the different types of actions and what they do:

以下是所有不同类型的操作及其作用的列表：

SCMP_ACT_KILL_THREAD (or SCMP_ACT_KILL)
Does not execute the syscall and terminate the thread that attempted making the call. Note that depending on the application being enforced (i.e. multi-threading) and its error handling, syscalls blocked using this action may do so silently which may result in side effects on the overall application.SCMP_ACT_TRAPDoes not execute the syscall. The kernel will send a thread-directed SIGSYS signal to the thread that attempted making the call.SCMP_ACT_ERRNODoes not execute the syscall, returns error instead. Note that depending on the error handling of the application being enforced, syscalls blocked using this action may do so silently which may result in side effects on the overall application.SCMP_ACT_TRACEThe decision on whether or not to execute the syscall will come from a tracer. If no tracer is present behaves like SECCOMP_RET_ERRNO.
This can be used to automate profile generation and also can be used to change the syscall being made. Not recommended when trying to enforce seccomp to line of business applications.SCMP_ACT_ALLOWExecutes the syscall.SCMP_ACT_LOG (since Linux 4.14)
Executes the syscall. Useful for running seccomp in "complain-mode", logging the syscalls that are mapped (or catch-all) and not blocking their execution. It can be used together with other action types to provide an allow and deny list approach.SCMP_ACT_KILL_PROCESS (since Linux 4.14)
Does not execute the syscall and terminates the entire process with a core dump. Very useful when automating the profile generation.

Both SCMP_ACT_ALLOW and SCMP_ACT_ERRNO are the most useful actions for final profiles. Whilst SCMP_ACT_KILL_PROCESS and SCMP_ACT_LOG will be more useful when automating the generation of seccomp profiles.

对于最终概要文件， SCMP_ACT_ALLOW和SCMP_ACT_ERRNO都是最有用的操作。在自动生成seccomp配置文件时， SCMP_ACT_KILL_PROCESS和SCMP_ACT_LOG会更有用。

That is all for today folks! :)

这就是今天的人们！ :)