Megosztás a következőn keresztül:

Az Azure Kubernetes Service (AKS) számítási feladataihoz való tárolóhozzáférés biztonságossá tételéhez beépített Linux biztonsági funkciókkal

Ebből a cikkből megtudhatja, hogyan védheti meg a tárolók hozzáférését az Azure Kubernetes Service (AKS) számítási feladatai erőforrásaihoz a felhasználónevek, az AppArmor és a seccomp beépített Linux biztonsági funkcióival.

A tárolóhozzáférés biztonságának áttekintése

Ugyanúgy, ahogyan a felhasználóknak vagy csoportoknak meg kell adnia a szükséges minimális jogosultságokat, a tárolókat is csak a szükséges műveletekre és folyamatokra kell korlátozni. A támadás kockázatának minimalizálása érdekében kerülje az eszkalált jogosultságokat vagy gyökérhozzáférést igénylő alkalmazások és tárolók konfigurálását.

A kubernetes-podok beépített biztonsági környezetei segítségével további engedélyeket határozhat meg, például a futtatandó felhasználót vagy csoportot, a közzéteendő Linux-képességeket vagy a podjegyzékben lévő beállításokat allowPrivilegeEscalation: false . További ajánlott eljárásokért tekintse meg az erőforrásokhoz való podhozzáférés biztonságossá tételét.

A gazdagép izolációjának javítása és az oldalirányú mozgás csökkentése érdekében Linuxon a felhasználói névterek használatával történhet meg. A tárolóműveletek még részletesebb szabályozásához olyan beépített Linux-biztonsági funkciókat használhat, mint az AppArmor és a seccomp. Ezek a funkciók segítenek korlátozni a tárolók által végrehajtható műveleteket a Linux biztonsági funkcióinak csomópontszinten történő meghatározásával és podjegyzéken keresztüli implementálásával.

A beépített Linux biztonsági funkciók csak Linux-csomópontokon és podokon érhetők el.

Feljegyzés

A Kubernetes-környezetek jelenleg nem biztonságosak az ellenséges, több-bérlős használathoz. Más biztonsági funkciók, például a Microsoft Defender for Containers, az AppArmor, a seccomp, a felhasználónevek, a Pod security Admission vagy a Kubernetes Role-Based Hozzáférés-vezérlés (RBAC) a csomópontokhoz, hatékonyan blokkolják a kihasználtságokat.

Az ellenséges több-bérlős számítási feladatok futtatásakor a valódi biztonság érdekében csak egy hipervizorban bízzon meg. A Kubernetes biztonsági köre a teljes fürtre vonatkozik, nem pedig egyetlen csomópontra.

Az ilyen típusú ellenséges, több bérlő által használt számítási feladatokhoz javasolt fizikailag izolált fürtöket használni.

A felhasználói névterek előfeltételei

A felhasználói névterek korlátozásai

A felhasználói névterek áttekintése

A Linux-podok alapértelmezés szerint több névtér használatával futnak: egy hálózati névtérrel, amely elkülöníti a hálózati identitást és egy PID-névteret a folyamatok elkülönítéséhez. A felhasználói névtér (user_namespace) elkülöníti a tárolóban lévő felhasználókat a gazdagép felhasználóitól. Emellett korlátozza a képességek hatókörét és a podnak a rendszer többi részével való interakcióját is.

A tárolón belüli UID-k és GID-k a gazdagépen nem jogosult felhasználókhoz vannak leképezve, így a gazdagép többi részével való minden interakció a nem megfelelő UID és a GID használatával történik. A tárolón belüli gyökér (UID 0) például leképezhető a gazdagép 65536-os felhasználójára. A Kubernetes létrehozza a leképezést, hogy garantálhassa, hogy ne legyen átfedésben más podokkal a rendszeren lévő felhasználónevek használatával.

A Kubernetes-implementációnak van néhány fontos előnye. További információ: Kubernetes User Namespaces dokumentáció.

Felhasználói névterek engedélyezése

  1. Hozzon létre egy fájlt, mypod.yaml és másolja a következő jegyzékbe. A felhasználónevek használatához a YAML-nek rendelkeznie kell a mezővel hostUsers: false.

    apiVersion: v1
kind: Pod
metadata:
  name: userns
spec:
  hostUsers: false
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian

  2. Telepítse az alkalmazást a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

    kubectl apply -f mypod.yaml

  3. Ellenőrizze az üzembe helyezett podok állapotát a kubectl get pods paranccsal.

    kubectl get pods

  4. A kubectl exec parancs segítségével futtassa az exec-et a podon.

    kubectl exec -ti userns -- bash

  5. A podon belül ellenőrizze /proc/self/uid_map a következő paranccsal:

    cat /proc/self/uid_map

    A kimenetnek 65536-nak kell lennie az utolsó oszlopban. Például:

    0  833617920      65536

    Ez a kimenet azt jelzi, hogy a tárolón belüli gyökér (UID 0) a gazdagépen a 65536-os felhasználóhoz van hozzárendelve.

A felhasználói névterek által elhárított gyakori biztonsági rések és kitettségek (CVE-k)

Az alábbi táblázat néhány olyan gyakori biztonsági rést és kitettséget (CVE-t) vázol fel, amelyek részben vagy teljesen enyhíthetők user_namespaces használatával:

CVE Súlyossági pontszám Súlyossági szint
CVE-2019-5736 8,6 High
CVE 2024-21262 8,6 High
CVE 2022-0492 7,8 High
CVE-2021-25741 8.1 / 8.8 Magas/Magas
CVE-2017-1002101 9.6 / 8.8 Kritikus / Magas

Ne feledje, hogy ez a lista nem teljes. További információkért lásd: Kubernetes v1.33: Felhasználói névterek alapértelmezés szerint bekapcsolva.

AppArmor előfeltételek

Feljegyzés

Az Azure Linux 3.0 a 2025. november 7-i VHD-kiadástól támogatja az AppArmort.

Az AppArmor áttekintése

A tárolóműveletek korlátozásához használhatja az AppArmor Linux kernelbiztonsági modult. Az AppArmor az alapul szolgáló AKS-csomópont operációs rendszerének (OS) részeként érhető el, és alapértelmezés szerint engedélyezve van. Létrehozhat AppArmor-profilokat, amelyek korlátozzák az olvasási, írási és végrehajtási műveleteket, illetve olyan rendszerfunkciókat, mint a fájlrendszerek csatlakoztatása. Az alapértelmezett AppArmor-profilok korlátozzák a különböző /proc helyekhez /sys való hozzáférést, és lehetővé teszik a tárolók logikai elkülönítését a mögöttes csomóponttól. Az AppArmor minden Linuxon futó alkalmazáshoz működik, nem csak a Kubernetes-podokhoz.

Feljegyzés

A Kubernetes 1.30-ás verzió előtt az AppArmor parancsot széljegyzetekkel adták meg. Az 1.30-tól kezdődően az AppArmor a pod specifikációjának securityContext mezőjén keresztül kerül meghatározásra. További információkért tekintse meg a Kubernetes AppArmor dokumentációját.

Az AKS-fürtben használt AppArmor-profilok a konténerek műveleteinek korlátozására

Podok biztonságossá tétele az AppArmor használatával

AppArmor-profilokat a pod vagy a tároló szintjén adhat meg. A tároló AppArmor profilja elsőbbséget élvez a pod AppArmor-profillal szemben. Ha egyik sincs megadva, a tároló korlátozás nélkül fut. További információkért az AppArmor-profilokról lásd a Securing a Pod with AppArmor Kubernetes dokumentáció című részt.

Egyéni AppArmor-profil konfigurálása

Az alábbi példa létrehoz egy profilt, amely megakadályozza a tárolón belüli fájlokba való írást.

  1. SSH egy AKS-csomópontra.

  2. Hozzon létre egy deny-write.profile nevű fájlt, és illessze be a következő tartalomba:

    #include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}

  3. Töltse be az AppArmor-profilt a csomópontra.

    # This example assumes that node names match host names, and are reachable via SSH.
NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))

for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}
EOF'
done

Pod üzembe helyezése egyéni AppArmor-profillal

  1. Helyezzen üzembe egy "Hello AppArmor" podot a megtagadási-írási profillal.

    apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

  2. Alkalmazza a podjegyzéket a kubectl apply paranccsal.

    kubectl apply -f hello-apparmor.yaml

  3. Lépjen be a podba, és ellenőrizze, hogy a konténer fut-e az AppArmor profillal.

    kubectl exec hello-apparmor -- cat /proc/1/attr/current

    A kimenetnek a használatban lévő AppArmor-profilt kell megjelenítenie. Például:

    k8s-apparmor-example-deny-write (enforce)

Seccomp előfeltételek

Regisztráld a KubeletDefaultSeccompProfilePreview funkciójelzőt

Fontos

Az AKS előzetes verziójú funkciói önkiszolgáló, opt-in alapon érhetők el. Az előzetes verziókat "ahogy van" és "rendelkezésre állóként" biztosítjuk, és a szolgáltatási szerződésekből és a korlátozott jótállásból kizárjuk őket. Az AKS előzetes verzióit az ügyfélszolgálat részben igyekezet szerint támogatja. Ezért ezek a funkciók nem éles használatra vannak szánva. További információkért tekintse meg az alábbi támogatási cikkeket:

  1. Regisztrálja a KubeletDefaultSeccompProfilePreview funkciójelzőt a az feature register paranccsal.

    az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"

    Néhány percig tart, amíg az állapot megjelenik a Regisztrált állapotban.

  2. Ellenőrizze a regisztrációs állapotot a az feature show paranccsal.

    az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"

  3. Ha az állapot a Regisztrált állapotot tükrözi, frissítse a Microsoft.ContainerService erőforrás-szolgáltató regisztrációját a az provider register paranccsal.

    az provider register --namespace Microsoft.ContainerService

Seccomp korlátozások

  • Az AKS csak az alapértelmezett seccomp profilokat támogatja (RuntimeDefault és Unconfined). Az egyéni seccomp profilok nem támogatottak.
  • SeccompDefault Nem támogatott paraméter a Windows-csomópontkészletekhez.

Az alapértelmezett seccomp-profilok áttekintése (előzetes verzió)

Bár az AppArmor bármilyen Linux-alkalmazáshoz működik, a seccomp (vagy a biztonságos számítástechnika) a folyamat szintjén működik. A Seccomp egy Linux kerneles biztonsági modul is. Az containerd AKS-csomópontok által használt futtatókörnyezet natív támogatást nyújt a seccomp számára. A seccomp használatával korlátozhatja a tároló rendszerhívásait. A Seccomp egy további védelmi réteget hoz létre a rosszindulatú szereplők által kihasznált gyakori rendszerhívási biztonsági rések ellen, és lehetővé teszi egy alapértelmezett profil megadását a csomópont összes számítási feladatához.

Új Linux-csomópontkészlet létrehozásakor egyéni csomópontkonfigurációkkal alkalmazhat alapértelmezett seccomp-profilokat. Az AKS támogatja a RuntimeDefault és Unconfined értékeket. Egyes számítási feladatokhoz alacsonyabb számú syscall-korlátozásra lehet szükség, mint mások. Ez azt jelenti, hogy a RuntimeDefault profil futásidőben meghiúsulhatnak. Az ilyen hibák elhárításához megadhat egy Unconfined profilt. Ha a számítási feladathoz egyéni profil szükséges, tekintse meg az egyéni seccomp-profil konfigurálását.

Tárolórendszer-hívások korlátozása seccomp használatával

  1. Kövesse a lépéseket egy seccomp profil alkalmazására a kubelet konfigurációjában a beállítás megadásával "seccompDefault": "RuntimeDefault".
  2. Csatlakozzon a gazdagéphez.
  3. Ellenőrizze, hogy a konfigurációt alkalmazták-e a csomópontokra.

Számítási feladatok hibáinak megoldása a seccomp használatával

Ha SeccompDefault engedélyezve van, a tároló futtatókörnyezetének alapértelmezett seccomp profilja alapértelmezés szerint a csomóponton ütemezett összes számítási feladathoz használható, ami miatt a számítási feladatok meghiúsulhatnak a blokkolt syscallok miatt. Számítási feladat meghibásodása esetén olyan hibák jelentkezhetnek, mint például:

  • A munkaterhelés váratlanul leáll a funkció engedélyezése után, "engedély megtagadva" hibaüzenettel.
  • A seccomp hibaüzenetek az auditd-ben vagy a syslogban is láthatók, ha az alapértelmezett profilban lecseréli az SCMP_ACT_ERRNO-t az SCMP_ACT_LOG-ra.

Ha ezeket a hibákat tapasztalja, javasoljuk, hogy módosítsa a seccomp profilt a következőre Unconfined: . Unconfined nem korlátozza a syscallokat, így az összes rendszerhívást végrehajthatja.

Az egyéni seccomp-profilok áttekintése

Egyéni seccomp profillal részletesebben szabályozhatja a tárolókhoz tartozó korlátozott syscallokat. Saját seccomp profilokat a következővel hozhat létre:

  • Szűrők használatával megadhatja, hogy milyen műveleteket engedélyezhet vagy tilthat le.
  • Megjegyzés a pod YAML-jegyzékében a seccomp szűrőhöz való társításhoz.

Feljegyzés

Ha segítségre van szüksége a seccomp-profil hibaelhárításához, olvassa el a seccomp profilkonfiguráció hibaelhárítását az Azure Kubernetes Service-ben (AKS).

Egyéni seccomp-profil konfigurálása

A seccomp működés közbeni megtekintéséhez hozzon létre egy szűrőt, amely megakadályozza a fájlok engedélyeinek módosítását.

  1. SSH egy AKS-csomópontra.

  2. Hozzon létre egy /var/lib/kubelet/seccomp/prevent-chmod nevű seccomp szűrőt.

  3. Másolja és illessze be a következő tartalmat:

    {
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "chmod",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "fchmodat",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "chmodat",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

    Az 1.19-es és újabb verziókban konfigurálnia kell a következőt:

    {
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod","fchmodat","chmodat"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

  4. A helyi gépről hozzon létre egy podjegyzéket aks-seccomp.yaml néven, és illessze be a következő tartalmat. Ez a jegyzék egy megjegyzést határoz meg a seccomp.security.alpha.kubernetes.io-ra és hivatkozik a meglévő prevent-chmod szűrőre.

    apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
spec:
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

    Az 1.19-es és újabb verziókban konfigurálnia kell a következőt:

    apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: prevent-chmod
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

  5. Telepítse a minta podot a kubectl apply következő paranccsal:

    kubectl apply -f ./aks-seccomp.yaml

  6. A pod állapotának megtekintése a kubectl get pods paranccsal.

    kubectl get pods

    A kimenetben látnia kell, hogy a pod hibát jelez. A chmod seccomp szűrő nem futtatja a parancsot, ahogy az a példakimenetben is látható:

    NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s

A Seccomp biztonsági profil beállításai

A Seccomp biztonsági profilok olyan meghatározott syscallok készletei, amelyek engedélyezettek vagy korlátozottak. A legtöbb tároló futtatókörnyezetének van egy alapértelmezett seccomp profilja, amely hasonló, ha nem ugyanaz, mint amit a Docker használ. Az elérhető profilokkal kapcsolatos további információkért tekintse meg a Docker vagy a tárolóalapú alapértelmezett seccomp profilokat.

Az AKS a tárolóalapú alapértelmezett seccomp profilt használja a RuntimeDefault seccomp egyéni csomópontkonfigurációval történő konfigurálásakor.

Az alapértelmezett profil által letiltott jelentős rendszerhívások

A Docker és a containerd is fenntartja az engedélyezett biztonságos syscallok listáit. A Docker és a tároló módosításakor az AKS frissíti az alapértelmezett konfigurációt. A lista frissítései számítási feladatok meghibásodását okozhatják. A kiadási frissítésekről lásd az AKS kibocsátási megjegyzéseit.

Az alábbi táblázat felsorolja azokat a jelentős syscallokat, amelyek ténylegesen le vannak tiltva, mert nem szerepelnek az engedélyezési listán. Ez a lista nem teljes. Ha a számítási feladathoz a blokkolt syscallok bármelyike szükséges, ne használja a RuntimeDefault seccomp profilt.

Letiltott syscall Leírás
acct Könyvelési rendszerhívás, amely lehetővé teheti, hogy a tárolók feloldhassák a saját erőforráskorlátaikat vagy feldolgozzák a folyamat könyvelést. Szintén korlátozott CAP_SYS_PACCT által.
add_key Megakadályozza, hogy a tárolók a nem névtérbe rendezett kernelkulcsot használják.
bpf Tiltsa le a potenciálisan állandó bpf-programok kernelbe való betöltését. Ez a folyamat már korábban is korlátozva volt a CAP_SYS_ADMIN által.
clock_adjtime Az idő/dátum nincs névtérben. Szintén korlátozott CAP_SYS_TIME által.
clock_settime Az idő/dátum nincs névtérben. Szintén korlátozott CAP_SYS_TIME által.
clone Új névterek klónozásának megtagadása. Szintén CAP_SYS_ADMIN for CLONE_* zászlókkal van vezérelve, kivéve CLONE_NEWUSER.
create_module Tiltsa le a kernelmodulok manipulációját és funkcióit. Elavult. Szintén korlátozott CAP_SYS_MODULE által.
delete_module Tiltsa le a kernelmodulok manipulációját és funkcióit. Szintén korlátozott CAP_SYS_MODULE által.
finit_module Tiltsa le a kernelmodulok manipulációját és funkcióit. Szintén korlátozott CAP_SYS_MODULE által.
get_kernel_syms Az exportált kernel és modulszimbólumok lekérésének megtagadása. Elavult.
get_mempolicy Syscall, amely módosítja a kernel memóriáját és a NUMA beállításait. Már le van zárva CAP_SYS_NICE által.
init_module Tiltsa le a kernelmodulok manipulációját és funkcióit. Szintén korlátozott CAP_SYS_MODULE által.
ioperm Megakadályozza, hogy a tárolók módosítsák a kernel I/O jogosultsági szintjét. Már le van zárva CAP_SYS_RAWIO által.
iopl Megakadályozza, hogy a tárolók módosítsák a kernel I/O jogosultsági szintjét. Már le van zárva CAP_SYS_RAWIO által.
kcmp Korlátozza a folyamatvizsgálati képességeket, amelyeket már blokkolt az elvetéssel CAP_SYS_PTRACE.
kexec_file_load A kexec_load rendszerhívás testvére, ami ugyanazt a dolgot végzi, kissé eltérő argumentumokkal. Szintén korlátozott CAP_SYS_BOOT által.
kexec_load Megtagadhatja az új kernel betöltését a későbbi végrehajtáshoz. Szintén korlátozott CAP_SYS_BOOT által.
keyctl Megakadályozza, hogy a tárolók a nem névtérbe rendezett kernelkulcsot használják.
lookup_dcookie Nyomkövetési/profilkészítési syscall, amely információkat szivárogtathat ki a gazdagépen. Szintén korlátozott CAP_SYS_ADMIN által.
mbind Syscall, amely módosítja a kernel memóriáját és a NUMA beállításait. Már le van zárva CAP_SYS_NICE által.
mount Megtagadja a csatlakoztatást, már korlátozva van CAP_SYS_ADMIN által.
move_pages Syscall, amely módosítja a kernel memóriáját és a NUMA beállításait.
nfsservctl Megtagadja a kernel nfs démonnal való interakciót. Linux 3.1 óta elavult.
open_by_handle_at Egy régi tároló kitörésének oka. Szintén korlátozott CAP_DAC_READ_SEARCH által.
perf_event_open Nyomkövetési/profilkészítési syscall, amely információkat szivárogtathat ki a gazdagépen.
personality Megakadályozza, hogy a tároló engedélyezze a BSD-emulációt. Nem eredendően veszélyes, de rosszul tesztelt, ezért potenciálisan vannak kernel sérülékenységek.
pivot_root A pivot_root megtagadása jogosultsági műveletnek kellene lennie.
process_vm_readv Korlátozza a folyamatvizsgálati képességeket, amelyeket már blokkolt az elvetéssel CAP_SYS_PTRACE.
process_vm_writev Korlátozza a folyamatvizsgálati képességeket, amelyeket már blokkolt az elvetéssel CAP_SYS_PTRACE.
ptrace Nyomkövetési/profilkészítési rendszerhívás. A 4.8 előtti Linux kernelverziókban blokkolva van a seccomp megkerülésének elkerülése érdekében. Tetszőleges folyamatok nyomon követése/profilozása már le van tiltva az CAP_SYS_PTRACE törlésével, mert információkat szivárogtathat a gazdagépen.
query_module Tiltsa le a kernelmodulok manipulációját és funkcióit. Elavult.
quotactl Kvóta syscall, amely lehetővé teheti, hogy a tárolók letiltsák saját erőforráskorlátaikat, vagy kikapcsolják a folyamatkövetést. Szintén korlátozott CAP_SYS_ADMIN által.
reboot Ne hagyja, hogy a tárolók újraindítsák a gazdagépet. Szintén korlátozott CAP_SYS_BOOT által.
request_key Megakadályozza, hogy a tárolók a nem névtérbe rendezett kernelkulcsot használják.
set_mempolicy Syscall, amely módosítja a kernel memóriáját és a NUMA beállításait. Már le van zárva CAP_SYS_NICE által.
setns Megtagadhatja a szál névtérrel való társítását. Szintén korlátozott CAP_SYS_ADMIN által.
settimeofday Az idő/dátum nincs névtérben. Szintén korlátozott CAP_SYS_TIME által.
stime Az idő/dátum nincs névtérben. Szintén korlátozott CAP_SYS_TIME által.
swapon Tiltsa le a fájlra/eszközre való felcserélés indítását/leállítását. Szintén korlátozott CAP_SYS_ADMIN által.
swapoff Tiltsa le a fájlra/eszközre való felcserélés indítását/leállítását. Szintén korlátozott CAP_SYS_ADMIN által.
sysfs Elavult rendszerhívás.
_sysctl Elavult, helyébe /proc/sys.
umount Kiemelt műveletnek kell lennie. Szintén korlátozott CAP_SYS_ADMIN által.
umount2 Kiemelt műveletnek kell lennie. Szintén korlátozott CAP_SYS_ADMIN által.
unshare A folyamatok új névtereinek klónozásának megtagadása. Szintén korlátozva van CAP_SYS_ADMIN által (kivéve unshare --user).
uselib Hosszú ideig nem használt régebbi syscall, amely megosztott kódtárakhoz kapcsolódik.
userfaultfd Felhasználói tér oldalhiba kezelése, amely nagyrészt a folyamatmigráláshoz szükséges.
ustat Elavult rendszerhívás.
vm86 Kernel x86-os valós módú virtuális gépen. Szintén korlátozott CAP_SYS_ADMIN által.
vm86old Kernel x86-os valós módú virtuális gépen. Szintén korlátozott CAP_SYS_ADMIN által.

Kapcsolódó tartalom

Az AKS-fürt biztonságának növelésével kapcsolatos további információkért tekintse meg az alábbi cikkeket:

  • Last updated on