{"id":20268,"date":"2026-08-02T18:19:04","date_gmt":"2026-08-02T16:19:04","guid":{"rendered":"https:\/\/webhosting.de\/seccomp-linux-kernel-sicherheit-anwendungen-einschraenken-sandbox-guard\/"},"modified":"2026-08-02T18:19:04","modified_gmt":"2026-08-02T16:19:04","slug":"seccomp-linux-kernel-security-restrict-applications-sandbox-guard","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/seccomp-linux-kernel-sicherheit-anwendungen-einschraenken-sandbox-guard\/","title":{"rendered":"Seccomp on Linux: Targeted Restrictions on Applications for Greater Security"},"content":{"rendered":"<p><strong>Seccomp Linux<\/strong> limits applications to only the system calls they actually need, thereby significantly reducing the kernel's attack surface. I specifically use this mechanism to isolate containers, microservices, and sensitive services within a <strong>Sandbox<\/strong> to lock them down without blocking their core functions.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>I\u2019ll summarize the key points for a quick overview and highlight how I use Seccomp in practice. This provides a clear introduction to policies, filters, and workload protection. These points serve as a guiding thread for me in planning, operation, and review. They help prioritize risks and choose sound default settings. With these core elements in mind, the <strong>Security<\/strong> understandable and manageable.<\/p>\n<ul>\n  <li><strong>Filter Mode<\/strong>: Fine-grained BPF profiles allow only the necessary system calls.<\/li>\n  <li><strong>Attack surface<\/strong>: Fewer accessible kernel paths reduce the risk of exploitation.<\/li>\n  <li><strong>Container<\/strong>: Default profiles reliably block risky requests.<\/li>\n  <li><strong>Kubernetes<\/strong>: seccompProfile and seccompDefault provide consistent protection.<\/li>\n  <li><strong>Workflow<\/strong>: Analyze, profile, harden, test, roll out.<\/li>\n<\/ul>\n<p>I evaluate each workload, define an appropriate profile, and monitor its performance in operation. This is how a resilient <strong>Baseline<\/strong>-Protection that can be expanded as needed at a later date.<\/p>\n\n<h2>Seccomp Explained in a Nutshell: Secure Computing Mode<\/h2>\n\n<p>Seccomp stands for \u201eSecure Computing Mode\u201c and limits <strong>System Calls<\/strong> of a process to a clearly defined set. I apply the filter where applications interact with the kernel\u2014for example, when opening files, sockets, or creating additional processes. The idea is simple: allow what is necessary and block unauthorized actions via an error code or by killing the process. Anyone who understands how to interact with the kernel can quickly build solid profiles; a good place to start is the article <a href=\"https:\/\/webhosting.de\/en\/understanding-system-calls-communication-between-the-kernel-and-applications-controlled-access\/\">Understanding System Calls<\/a>. This creates an effective <strong>Sandbox<\/strong>, which makes escapes more difficult and closes unintended kernel paths.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-sicherheit-serverraum-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why Seccomp Reduces Linux's Attack Surface<\/h2>\n\n<p>Each additional system call potentially increases the <strong>Attack surface<\/strong>. I reduce this surface area by allowing only those system calls that the application has been proven to use. As a result, many exploit chains lose access to critical kernel functions. Even when code is executed within the process, an attacker often finds the doors closed. This is how I prevent access to sensitive subsystems such as <strong>ptrace<\/strong>, BPF, or certain debug interfaces.<\/p>\n\n<h2>Whitelist Instead of Blacklist: The Right Strategy<\/h2>\n\n<p>In productive environments, I rely on <strong>Whitelisting<\/strong>: The default action is \u201edeny,\u201c and only a carefully curated set of system calls is allowed. For compatibility reasons, many runtimes provide blocklist profiles that block only particularly risky calls. For sensitive services, I tighten the restrictions and allow only what runtime analysis actually confirms. This reduces surprises when kernel changes are made and shifts the focus from \u201eWhat is dangerous?\u201c to \u201eWhat is required?\u201c For generic workloads, a solid blocklist can be a good starting point, but for gateways, payment flows, or authentication services, it\u2019s worth making the switch to an allowlist policy with explicit exceptions.<\/p>\n\n<h2>Modes and Filter Logic: Strict to BPF<\/h2>\n\n<p>Seccomp has a strict mode that allows only read, write, exit, and sigreturn, and the highly flexible <strong>Filter Mode<\/strong> via BPF. In practice, I almost always use filters, since they allow me to analyze syscalls and their arguments in detail. The kernel checks each call against the stored program and decides whether to allow it, return an error, or terminate the process. This allows me to block individual variants of a system call, such as specific flags of `clone` or `unshare`. This level of granularity makes <strong>Policies<\/strong> Sleek and effective at the same time.<\/p>\n\n<h2>Return Campaigns and Level of Oversight<\/h2>\n\n<p>I use specific actions to control the behavior in the event of violations: allow, defined errors (usually <em>EPERM<\/em> or <em>EACCES<\/em>) return, via <em>TRAP<\/em> trigger a signal, using <em>TRACE<\/em> Enable debugging, or terminate the process\/thread completely. Simply returning an error is often sufficient and improves fault tolerance; for particularly sensitive paths, however, I use kill actions. When I need to troubleshoot, I use kernel logging or logging actions to gradually narrow down the scope in staging environments without unnecessarily disrupting operations.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/seccomp-security-linux-8943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sandboxing and Container Protection in Practice<\/h2>\n\n<p>Container runtimes provide proven <strong>Default<\/strong>-Profiles that block risky system calls. Building on that, I further restrict `mount`, `unshare`, `bpf`, `ptrace`, as well as `keyctl` and `perf_event_open`. Applications that process untrusted input benefit in two ways: fewer kernel interfaces and a clear error condition in case of violations. Even web browsers and sandbox tools rely on this separation of necessary and dangerous access. This keeps the runtime system manageable and <strong>predictable<\/strong>.<\/p>\n\n<h2>User-Space Notification: Controlled Exceptions<\/h2>\n\n<p>For rare but legitimate exceptions, I use the <strong>User-Space Notifier<\/strong>-Approach: A monitoring process receives requests regarding blocked system calls and can selectively approve or reject them. This is how I implement broker patterns, for example, to allow only certain <em>mount<\/em>-Allowing operations in specific directories. This reduces the need to include general exceptions in the policy while still maintaining operational flexibility. Clear governance is key here: Which commands are allowed, how are they audited, and how do I prevent the notifier itself from becoming a single point of failure?<\/p>\n\n<h2>Seccomp in Kubernetes and OpenShift<\/h2>\n\n<p>In Kubernetes, I use the SecurityContext in the pod manifest to specify which profile is active. `seccompDefault` on the node ensures that workloads without their own specification are automatically assigned a sensible <strong>Standard<\/strong>-profile. OpenShift and Podman also support this, including passing it via the \u2013security-opt flag. I can provision profiles centrally and apply them using annotations or field bindings. This way, I can enforce clean rules across all <strong>Namespaces<\/strong> away.<\/p>\n\n<h2>Policy Design for Teams and Platforms<\/h2>\n\n<p>I organize profiles by <em>Workload Classes<\/em> rather than by team: web front ends, workers, DB clients, data pipelines. Each class is assigned a tested profile, which I modify only minimally for special cases. In Kubernetes, I use an admission policy to ensure that pods have at least <em>RuntimeDefault<\/em> use, while particularly sensitive namespaces require strict <em>Localhost<\/em>-Enforce the profile. For debugging or incident situations, there is a well-defined exception path with a limited duration and additional network and capability restrictions, so that diagnostics remain possible without generally lowering the security level.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-security-seccomp-shield-4092.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Building Profiles: Workflow from Analysis to Rollout<\/h2>\n\n<p>I'll start with a runtime analysis and see which <strong>System Calls<\/strong> that the application uses during normal operation. I then create an initial profile that allows exactly these calls and excludes rare paths. Next, I further harden the code by removing or narrowing down rare or risky calls. A testing phase uncovers gaps and reveals whether functions are missing or error codes are appropriate. Only then do I roll out the <strong>Policy<\/strong> in production and assign a version number to each change.<\/p>\n\n<h2>Architecture and ABI Considerations<\/h2>\n\n<p>System calls vary depending on the architecture and kernel generation. I make sure that profiles <strong>Multi-Arch<\/strong> cover the range thoroughly (e.g., x86_64 and arm64) and that newer variants such as <em>openat2<\/em> or time64 system calls are supported. In containers with older base systems, I check whether legacy paths (such as via <em>socketcall<\/em> or certain IPC calls). Anyone who <em>libseccomp<\/em> or uses the runtime for generation benefits from stable mappings between symbol names and syscall numbers\u2014I deliberately avoid hard-coded numbers to maintain portability. Important: Filters are <strong>heritable<\/strong> and only <em>monotonous<\/em> can be tightened; once something is banned, it remains banned, even after <em>execve<\/em>.<\/p>\n\n<h2>Upgrade and Compatibility Management<\/h2>\n\n<p>Library and kernel updates introduce new system calls or change calling patterns. I therefore plan to implement targeted <em>Smoke tests<\/em> after upgrades and maintain a staging environment that, if necessary, can be used with <em>LOG<\/em>-actions. This way, I can see what new requests are coming in before I deploy to production. I also make a point of documenting differences between images (e.g., musl- vs. glibc-based containers), since these may use different paths to the kernel API. Clear versioning of the profiles is crucial for rollbacks; in the event of an incident, I temporarily switch to a less strict policy with a short expiration time and close monitoring.<\/p>\n\n<h2>Identifying Error Patterns: Logging and Triage<\/h2>\n\n<p>Blocked system calls must be traceable; otherwise, you're in the dark <strong>Dark<\/strong>. I enable logging at runtime and analyze metrics that reveal clusters and outliers. Messages containing EPERM or EACCES often indicate that rules are too restrictive. I attribute unexpected terminations to the affected component and check the corresponding flags or arguments. Afterward, I adjust the <strong>Filter<\/strong> Set it to the minimum and test it again.<\/p>\n\n<h2>Troubleshooting playbook<\/h2>\n\n<ul>\n  <li><strong>Reproduce<\/strong>: Repeat the exact same input\/traffic and correlate the logs.<\/li>\n  <li><strong>Identify<\/strong>: Record the relevant system call along with its arguments (e.g., via runtime logs or audit output).<\/li>\n  <li><strong>Rate<\/strong>: Is this call necessary? Is there a lower-risk alternative (e.g., `openat` instead of `open`, more specific flags)?<\/li>\n  <li><strong>Customize<\/strong>: Set to \"minimal\"; ideally, use argument filters; leave the default action set to \"strict.\".<\/li>\n  <li><strong>Secure<\/strong>: For sensitive exceptions, further refine capability reduction, read-only file systems, or namespaces.<\/li>\n  <li><strong>Retest &amp; Telemetry<\/strong>: After the fix, perform targeted testing, monitor metrics, and set up alerts.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_linux_security_8432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparison with SELinux, AppArmor, and Capabilities<\/h2>\n\n<p>Seccomp operates at the application-kernel interface, while SELinux and AppArmor primarily regulate object access. Capabilities control privileged operations, which I also significantly reduce. Together with <a href=\"https:\/\/webhosting.de\/en\/server-context-isolation-namespaces-cgroups-hosting-security\/\">Namespaces and Cgroups<\/a> This creates a multi-layered security model. I segregate resources, revoke unnecessary privileges, and restrict kernel paths via <strong>Seccomp<\/strong>. This combination keeps workloads tightly managed and easy to control.<\/p>\n\n<h2>Performance and Overhead<\/h2>\n\n<p>A well-designed Seccomp profile causes only minimal <strong>Overhead<\/strong>: The kernel executes a small BPF program for each syscall. In practice, this has a negligible impact on typical web and service workloads. However, high-frequency, syscall-intensive paths (e.g., packet processing, IPC-heavy workers) can become critical. I therefore keep the number of rules focused, use argument filters instead of long lists, and test hot paths with benchmarks. If a profile causes a measurable slowdown, I first check for duplicates, imprecise matches, and whether certain rare calls can be offloaded to a separate process.<\/p>\n\n<h2>Best Practices for Secure Defaults<\/h2>\n\n<p>I start with the runtime's default profile and refine it depending on <strong>Workload<\/strong>. Highly sensitive services, such as gateways or authentication services, are subject to particularly strict rules. I integrate changes to profiles into CI\/CD and test them automatically. In addition, I recommend a significant reduction in capabilities, read-only file systems, and the \u201cNoNewPrivs\u201d policy. A guide to comprehensive host protection mechanisms can be found at <a href=\"https:\/\/webhosting.de\/en\/kernel-hardening-linux-security-features-for-hosting-servers-secure\/\">Kernel Hardening<\/a>, which works well in conjunction with Seccomp.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_seccomp_sicherheit_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Advanced Hardening: What Else I Check<\/h2>\n\n<p>In addition to the usual suspects (<em>mount<\/em>, <em>unshare<\/em>, <em>bpf<\/em>, <em>ptrace<\/em>, <em>keyctl<\/em>, <em>perf_event_open<\/em>) I review the following requests and, depending on the context, either restrict them significantly or block them entirely:<\/p>\n<ul>\n  <li><strong>setns<\/strong>: Prevents jumping to other namespaces.<\/li>\n  <li><strong>process_vm_readv\/process_vm_writev<\/strong>: Prevents direct memory access to other processes.<\/li>\n  <li><strong>kexec_load<\/strong> and <strong>reboot<\/strong>: Protect against attempts to reboot or replace the kernel.<\/li>\n  <li><strong>swapon\/swapoff<\/strong> and <strong>init_module\/finit_module<\/strong>: restrict system and module loading mechanisms.<\/li>\n  <li><strong>clone3<\/strong> For risky flags (e.g., namespaces): Limit them granularly using arguments.<\/li>\n  <li><strong>io_uring_setup<\/strong>: Depending on the workload, allow it or limit it strictly, since it's a powerful interface.<\/li>\n<\/ul>\n<p>The guiding principle is: As much as necessary, as little as possible\u2014and it\u2019s better to have a small, documented exception than a broad, open-ended standard rule.<\/p>\n\n<h2>Integration with CI\/CD and Teams<\/h2>\n\n<p>I treat Seccomp profiles as <strong>Code<\/strong>: version control, review, testing. Pipeline jobs check whether profiles match the image and whether any blockages occur. Smoke tests using test data detect behavioral changes faster than manual clicking. Developers receive a brief playbook that explains what logging looks like and where they can customize signatures. This is how the <strong>Security<\/strong> directly within the development workflow and stays up to date.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/seccomp-linux-server-8765.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Briefly summarized<\/h2>\n\n<p>Seccomp limits the <strong>System Calls<\/strong> limiting an application to only what\u2019s necessary, thereby cutting off many attack vectors. I start with a strong default, measure actual behavior, and then narrow it down step by step. Container platforms like Kubernetes or OpenShift take a lot of the groundwork off my hands when I set `seccompDefault` and distribute profiles centrally. Combined with capabilities, SELinux\/AppArmor, as well as namespaces and cgroups, this creates effective multi-layered protection. Those who consistently follow this approach reduce the risk of kernel exploits while also keeping workloads well-protected. <strong>controllable<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Seccomp Linux is a key component of kernel security. Learn how Secure Computing Mode restricts system calls, sandboxes containers, and effectively protects your workloads.<\/p>","protected":false},"author":1,"featured_media":20261,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20268","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"114","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Seccomp Linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20261","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20268","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=20268"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20268\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20261"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20268"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20268"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20268"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}