1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
// keyctl() syscall - Kernel Keyring Manipulation
//
// WHY KEYCTL IS DANGEROUS IN SANDBOXES:
// The Linux kernel keyring is a shared facility that stores authentication
// tokens, encryption keys, and other sensitive data. The keyring is NOT
// namespaced (in most kernel versions), meaning a sandboxed process could
// potentially access keys from the host or other containers.
//
// SECURITY ISSUES:
// 1. Keyrings are not fully isolated by namespaces (kernel < 5.2)
// 2. Process can read/write keys in session keyring
// 3. Potential to leak cryptographic secrets
// 4. Container escapes via keyring manipulation
//
// CVEs AND EXPLOITS:
// - CVE-2016-0728: Use-after-free in kernel keyring (privilege escalation)
// - CVE-2017-17449: netlink_dump kernel keyring info leak
// - Various container escapes using keyctl
//
// ATTACK VECTORS:
// 1. KEYCTL_GET_KEYRING_ID: Enumerate keyrings
// 2. KEYCTL_READ: Read key contents
// 3. KEYCTL_LINK: Link keys to accessible keyrings
// 4. KEYCTL_JOIN_SESSION_KEYRING: Join another session's keyring
//
// WHY BLOCK IT:
// 1. No legitimate use case for keyring access in sandboxed code
// 2. Keyrings not properly namespaced in older kernels
// 3. Defense in depth against kernel keyring exploits
// 4. Docker also blocks keyctl by default
//
// WHY THIS PAYLOAD:
// This payload attempts to access the kernel keyring. A secure sandbox
// must block keyctl() to prevent keyring-based attacks.
//
// EXPECTED RESULT:
// Sandbox should kill the process with SIGSYS (signal 31).
//
// REFERENCES:
// - https://man7.org/linux/man-pages/man2/keyctl.2.html
// - https://nvd.nist.gov/vuln/detail/CVE-2016-0728
// - Docker: "Prevent containers from using the kernel keyring"
//
// keyctl operations
// Special keyring IDs
int