.\" Generated by scdoc 1.11.5 .\" Complete documentation for this program is not available as a GNU info page .ie \n(.g .ds Aq \(aq .el .ds Aq ' .nh .ad l .\" Begin generated content: .TH "SYD" "7" "2026\-09\-01" .PP .SH NAME .PP Overview of sandboxing with Syd .PP .SH SANDBOXING .PP The list of available sandboxing categories is given below: .PP .TS allbox;lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx. T{ \fBwalk\fR T} T{ Confine path traversals.\& This sandboxing category is used during path canonicalization to confine path traversals.\& As such, its arguments are not necessarily fully canonicalized paths but they'\&re guaranteed to be absolute paths without any \fB.\&\fR (dot) or \fB.\&.\&\fR (dotdot) components.\& It has been split from the \fIstat\fR category as of version 3.\&39.\&0.\& Together with the \fIstat\fR category, path hiding provides a full implementation resilient against attempts to unhide otherwise hidden paths by passing through them during path canonicalization.\& For reference, OpenBSD'\&s \fIunveil\fR(2) pioneered similar capabilities and remains a mature reference implementation.\& T} T{ \fBlist\fR T} T{ Confine directory listings.\& This category is used during directory lists with \fIgetdents\fR(2) and \fIgetdents64\fR(2) system calls to filter out disallowed path patterns.\& It has been split from the \fIstat\fR category as of version 3.\&53.\&0.\& T} T{ \fBstat\fR T} T{ Confine file metadata accesses.\& List of filtered system calls are \fIaccess\fR(2), \fIfaccessat\fR(2), \fIfaccessat2\fR(2), \fIstat\fR(2), \fIfstat\fR(2), \fIlstat\fR(2), \fIstatx\fR(2), \fInewfstatat\fR(2), \fIstatfs\fR(2), \fIstatfs64\fR(2), \fIfstatfs\fR(2), and \fIfstatfs64\fR(2).\& In addition, paths may be masked using the \fImask\fR command.\& In this case, all filtered system calls on the path will be executed on the character device /dev/null instead.\& Refer to the description of the \fImask\fR command in \fIsyd\fR(2) manual page for more information.\& T} T{ \fBread\fR T} T{ Confine file reads and extended attribute reads.\& List of filtered system calls are \fIopen\fR(2), \fIopenat\fR(2) and \fIopenat2\fR(2) with the \fBO_RDONLY\fR or \fBO_RDWR\fR flags, \fIgetxattr\fR(2), \fIgetxattrat\fR(2), \fIlgetxattr\fR(2), \fIfgetxattr\fR(2), \fIlistxattr\fR(2), \fIlistxattrat\fR(2), \fIflistxattr\fR(2), and \fIllistxattr\fR(2).\& T} T{ \fBwrite\fR T} T{ Confine file writes.\& List of filtered system calls are \fIopen\fR(2), \fIopenat\fR(2) and \fIopenat2\fR(2) with the \fBO_WRONLY\fR or \fBO_RDWR\fR flags.\& T} T{ \fBexec\fR T} T{ Confine binary execution and dynamic library loading.\& The list of filtered system calls are \fIexecve\fR(2), \fIexecveat\fR(2), \fImmap\fR(2), \fImmap2\fR(2), and \fImemfd_create\fR(2).\& For scripts access check is done for both the script and the interpreter binary.\& As of version 3.\&16.\&3, Syd checks the paths of the dynamic libraries an executable is linked against for exec access as well.\& This only works for ELF binaries.\& As of version 3.\&21.\&2, Syd seals memory file descriptors as non\-executable by default, therefore memory file descriptors are not checked for exec access unless the option \fItrace/allow_unsafe_memfd:1\fR is set to lift this restriction.\& As of version 3.\&21.\&3, Syd hooks into \fImmap\fR(2) and \fImmap2\fR(2) system calls and checks the file descriptor for exec access when the memory protection mode includes \fBPROT_EXEC\fR and flags does not include \fBMAP_ANONYMOUS\fR which typically indicates a \fIdlopen\fR(3).\& Therefore, libraries dynamically loaded at runtime are checked for exec access as well.\& In addition, \fBSegvGuard\fR is used to deny execution if binary is crashing repeatedly which is similar to the implementation of Grsecurity & HardenedBSD.\& Refer to the \fBSegvGuard\fR section for more information.\& T} T{ \fBioctl\fR T} T{ Confine \fIioctl\fR(2) requests.\& Use \fBlock/ioctl\fR to confine \fIioctl\fR(2) system call for filesystem access.\& This feature may be used to effectively access GPU, PTY, DRM, and KVM etc.\& safely.\& \fIioctl\fR(2) requests may be allowed or denied by adding them to the respective list using the options \fIallow/ioctl+\fR and \fIdeny/ioctl+\fR.\& As of version 3.\&38.\&0, architecture\-agnostic \fIioctl\fR(2) decoding was introduced, allowing ioctls to be specified by name in addition to numeric values.\& Refer to the \fIsyd\fR(2) manual page for more information.\& T} T{ \fBcreate\fR T} T{ Confine creation of regular files, memory file descriptors, \fIepoll\fR(7), \fIeventfd\fR(2), \fIfanotify\fR(7), \fIinotify\fR(7), \fIpipe\fR(2), \fIsignalfd\fR(2), and \fItimerfd\fR(2) file descriptors.\& Filtered system calls are \fIcreat\fR(2), \fImknod\fR(2), \fImknodat\fR(2), \fImemfd_create\fR(2), \fImemfd_secret\fR(2), \fIepoll_create\fR(2), \fIepoll_create1\fR(2), \fIeventfd\fR(2), \fIeventfd2\fR(2), \fIfanotify_init\fR(2), \fIinotify_init\fR(2), \fIinotify_init1\fR(2), \fIpipe\fR(2), \fIpipe2\fR(2), \fIsignalfd\fR(2), \fIsignalfd4\fR(2), and \fItimerfd_create\fR(2).\& In addition, \fIopen\fR(2), \fIopenat\fR(2), and \fIopenat2\fR(2) are filtered when \fBO_CREAT\fR is set and \fBO_TMPFILE\fR is not.\& Non\-file descriptors are matched against a reserved keyword rather than a path: \fI!\&memfd:\fR, \fI!\&memfd\-hugetlb:\fR when flags include \fBMFD_HUGETLB\fR, \fI!\&secretmem\fR, \fI!\&eventpoll\fR, \fI!\&eventfd\fR, \fI!\&fanotify\fR, \fI!\&inotify\fR, \fI!\&signalfd\fR, \fI!\&timerfd\fR, and \fI!\&pipe\fR.\& \fIpipe2\fR(2) with \fBO_NOTIFICATION_PIPE\fR uses \fI!\¬ification_pipe\fR, refer to \fBDenying O_NOTIFICATION_PIPE Flag in pipe2\fR section.\& As an example, \fIdeny/create+!\&eventpoll\fR denies epoll(7) creation.\& T} T{ \fBdelete\fR T} T{ Confine file deletions.\& List of filtered system calls are \fIunlink\fR(2) and \fIunlinkat\fR(2).\& As of version 3.\&33.\&0, \fIunlinkat\fR(2) is confined by this category if and only if \fBAT_REMOVEDIR\fR is not set in flags, otherwise it'\&s confined by the \fIrmdir\fR category.\& T} T{ \fBrename\fR T} T{ Confine file renames and hard links.\& List of filtered system calls are \fIrename\fR(2), \fIrenameat\fR(2), \fIrenameat2\fR(2), \fIlink\fR(2), and \fIlinkat\fR(2).\& T} T{ \fBreadlink\fR T} T{ Confine symbolic link reads.\& List of filtered system calls are \fIreadlink\fR(2) and \fIreadlinkat\fR(2).\& This category has been split from the \fIstat\fR category as of version 3.\&53.\&0.\& T} T{ \fBsymlink\fR T} T{ Confine creation of symbolic links.\& List of filtered system calls are \fIsymlink\fR(2) and \fIsymlinkat\fR(2).\& T} T{ \fBtruncate\fR T} T{ Confine file truncations.\& List of filtered system calls are \fItruncate\fR(2), \fItruncate64\fR(2), \fIftruncate\fR(2), \fIftruncate64\fR(2), and \fIfallocate\fR(2).\& In addition, open system calls \fIopen\fR(2), \fIopenat\fR(2), and \fIopenat2\fR(2) are filtered if the flag \fBO_TRUNC\fR is set in arguments and the flags \fBO_TMPFILE\fR or \fBO_CREAT\fR are not set in arguments.\& T} T{ \fBchdir\fR T} T{ Confine directory changes.\& List of filtered system calls are \fIchdir\fR(2) and \fIfchdir\fR(2).\& Additional hardening may be achieved using the \fItrace/deny_dotdot:1\fR option to deny parent directory traversals.\& It is possible to set this option at runtime before sandbox is locked.\& This allows for incremental confinement.\& Refer to the \fBPath Resolution Restriction For Chdir and Open Calls\fR section for more information.\& T} T{ \fBreaddir\fR T} T{ Confine directory listings.\& List of filtered system calls are \fIopen\fR(2), \fIopenat\fR(2), and \fIopenat2\fR(2) when they'\&re called on an existing directory regardless of the \fBO_DIRECTORY\fR flag.\& T} T{ \fBmkdir\fR T} T{ Confine creation of directories.\& List of filtered system calls are \fImkdir\fR(2), \fImkdirat\fR(2), \fImknod\fR(2) and \fImknodat\fR(2).\& T} T{ \fBrmdir\fR T} T{ Confine deletion of directories.\& List of filtered system calls are \fIrmdir\fR(2) and \fIunlinkat\fR(2).\& Note \fIunlinkat\fR(2) is confined by this category if and only if \fBAT_REMOVEDIR\fR is set in flags, otherwise it'\&s confined by the \fIdelete\fR category.\& This category was split from the \fIdelete\fR category as of version 3.\&33.\&0.\& T} T{ \fBchown, chgrp\fR T} T{ Confine owner and group changes on files.\& List of filtered system calls are \fIchown\fR(2), \fIchown32\fR(2), \fIfchown\fR(2), \fIfchown32\fR(2), \fIlchown\fR(2), \fIlchown32\fR(2), and \fIfchownat\fR(2).\& By default, uid/gid arguments are confined to caller'\&s own effective credentials; set \fItrace/allow_unsafe_chown:1\fR to permit chown to arbitrary uid/gid.\& T} T{ \fBchmod\fR T} T{ Confine mode changes on files.\& List of filtered system calls are \fIchmod\fR(2), \fIfchmod\fR(2), \fIfchmodat\fR(2), and \fIfchmodat2\fR(2).\& In addition, a \fIumask\fR(2) value may be set using the \fItrace/force_umask\fR option which is enforced at \fIchmod\fR(2) boundary as well as during regular file creation, e.\&g.\& setting \fItrace/force_umask:7177\fR effectively disallows setting s{u,g}id bits, all group+other bits and execute bit for the current user.\& This feature is useful in setting up W\(haX (Write XOR Execute) configuration for the sandbox.\& T} T{ \fBchattr\fR T} T{ Confine extended attribute changes on files.\& List of filtered system calls are \fIsetxattr\fR(2), \fIsetxattrat\fR(2), \fIfsetxattr\fR(2), \fIlsetxattr\fR(2), \fIremovexattr\fR(2), \fIremovexattrat\fR(2), \fIfremovexattr\fR(2), and \fIlremovexattr\fR(2).\& In addition, Syd ensures extended attributes whose name start with the one of the prefixes \fIsecurity.\&\fR, \fIsystem.\&\fR, and \fItrusted.\&\fR can not be listed or tampered by the sandbox process unless the sandbox lock is \fIoff\fR for the respective process.\& This access can be permitted to the initial sandbox process with \fIlock:exec\fR or to all sandbox processes with \fIlock:off\fR.\& As of version 3.\&37.\&0, this restriction may be lifted with \fItrace/allow_unsafe_xattr:1\fR.\& T} T{ \fBchroot\fR T} T{ Confine change of the root directory using the \fIchroot\fR(2) system call.\& This sandboxing category can be disabled with \fItrace/allow_unsafe_chroot:1\fR at startup, when the \fIchroot\fR(2) system call becomes a no\-op.\& Similarly the \fIpivot_root\fR(2) system call is denied with the \fIerrno\fR(3) \fBEPERM\fR by default unless \fItrace/allow_unsafe_pivot_root:1\fR is set at startup in which case it becomes a no\-op like \fIchroot\fR(2).\& No actual change of root directory takes place either way.\& \fBSyd must share the root directory with the sandbox process to work correctly.\&\fR Instead, Syd will prevent all filesystem access after the first allowed \fIchroot\fR(2) attempt regardless of the root directory argument.\& The only exception to the prevention of filesystem access is the \fIchdir\fR(2) system call with the specific argument \fB/\fR, aka the root directory, is allowed.\& This ensures a TOCTOU\-free way to support the common use\-case of cutting all filesystem access by means of a \fIchroot\fR(2) call to /var/empty which is common case among unix daemons.\& This sandboxing category does not depend on the Linux capability \fBCAP_SYS_CHROOT\fR, therefore can be used in unprivileged context.\& Syd drops the \fBCAP_SYS_CHROOT\fR Linux capability by default unless \fItrace/allow_unsafe_caps:1\fR is passed at startup.\& T} T{ \fBnotify\fR T} T{ Confine file notification access.\& List of filtered system calls are \fIfanotify_mark\fR(2) and \fIinotify_add_watch\fR(2).\& This category was split from the \fIstat\fR category as of version 3.\&50.\&0.\& Access and modify events for block and character devices are stripped by default like Grsecurity'\&s \fBGRKERNSEC_DEVICE_SIDECHANNEL\fR to prevent device sidechannels.\& Refer to the \fBDevice Sidechannel Mitigations\fR section for more information.\& T} T{ \fButime\fR T} T{ Confine last access and modification time changes on files.\& List of filtered system calls are \fIutime\fR(2), \fIutimes\fR(2), \fIfutimesat\fR(2), \fIutimensat\fR(2), and \fIutimensat_time64\fR(2).\& T} T{ \fBmkbdev\fR T} T{ Confine block device creation.\& List of filtered system calls are \fImknod\fR(2) and \fImknodat\fR(2).\& Block device creation is disabled by default to adhere to the principle of secure defaults with a kernel level seccomp\-bpf filter which terminates the process on violation.\& This filter includes the Syd process, so a compromised Syd process will not be able to create block devices either.\& Therefore, the user must opt\-in at startup using the \fItrace/allow_unsafe_mkbdev:1\fR option to use this category for path\-based access checks on block devices.\& T} T{ \fBmkcdev\fR T} T{ Confine character device creation.\& List of filtered system calls are \fImknod\fR(2), \fImknodat\fR(2), and \fIrenameat2\fR(2) with the \fBRENAME_WHITEOUT\fR flag.\& Character device creation is disabled by default to adhere to the principle of secure defaults with a kernel level seccomp\-bpf filter which terminates the process on violation.\& This filter includes the Syd process, so a compromised Syd process will not be able to create character devices either.\& Therefore, the user must opt\-in at startup using the \fItrace/allow_unsafe_mkcdev:1\fR option to use this category for path\-based access checks on character devices.\& T} T{ \fBmkfifo\fR T} T{ Confine named pipe (FIFO) creation.\& List of filtered system calls are \fImknod\fR(2) and \fImknodat\fR(2).\& T} T{ \fBmktemp\fR T} T{ Confine temporary file creation.\& List of filtered system calls are \fIopen\fR(2), \fIopenat\fR(2), and \fIopenat2\fR(2) with the \fBO_TMPFILE\fR flag.\& A rule such as \fIallow/mktemp+/tmp\fR permits the sandbox process to create \fIanonymous\fR temporary files under the directory /tmp.\& The creation of regular files of temporary nature are confined by the \fBcreate\fR category instead.\& T} T{ \fBnet\fR T} T{ Confine network access.\& Socket types UNIX, IPv4, IPv6, NetLink and KCAPI are supported, use the option \fItrace/allow_unsupp_socket:1\fR to pass\-through sockets of unsupported types.\& UNIX domain sockets are always matched on absolute path, therefore always start with the character \fB/\fR.\& UNIX abstract sockets are prefixed with the \fB@\fR character before access check.\& Similarly unnamed UNIX sockets use the dummy path \fI!\&unnamed\fR for access check.\& Finally, network sandboxing concentrates on confining the initial connection action and leaves out the system call \fIrecvfrom\fR(2) as out of scope for sandbox confinement for performance reasons and due to a lack of security implications noting the fact that recv* system calls cannot specify target addresses.\& The system calls \fIrecvmsg\fR(2) and \fIrecvmmsg\fR(2) are confined by the \fBrecvfd\fR category which checks \fBSCM_RIGHTS\fR file descriptor reception.\& T} T{ \fBnet/bind\fR T} T{ Confine binding network access.\& This category confines the \fIbind\fR(2) system call, UNIX domain socket file creation using the \fImknod\fR(2) and \fImknodat\fR(2) system calls, and UNIX socket\-pair creation using the \fIsocketpair\fR(2) system call.\& \fIsocketpair\fR(2) system call uses the dummy path \fI!\&unnamed\fR for access check.\& Unnamed UNIX sockets use the same dummy path.\& T} T{ \fBnet/connect\fR T} T{ Confine connecting network access.\& List of filtered system calls are \fIconnect\fR(2), \fIsendto\fR(2), \fIsendmsg\fR(2), and \fIsendmmsg\fR(2).\& For IPv4 and IPv6 sockets, the target address of these system calls are also checked against the IP blocklist, refer to the description of the \fIblock\fR command in \fIsyd\fR(2) manual page for more information.\& T} T{ \fBsendfd\fR T} T{ Confine sending of file descriptors.\& Filtered system calls are \fIsendmsg\fR(2) and \fIsendmmsg\fR(2).\& The file descriptor being sent is matched, not the peer it is sent to.\& The name of a file descriptor begins with the character \fI!\&\fR, e.\&g.\& \fI!\&file\fR, \fI!\&pipe\fR, or \fI!\&memfd:NAME\fR.\& Refer to the \fIsyd\fR(2) manual page for the list of file descriptor names.\& T} T{ \fBrecvfd\fR T} T{ Confine reception of file descriptors.\& Filtered system calls are \fIrecvmsg\fR(2) and \fIrecvmmsg\fR(2).\& The file descriptor being received is matched, not the peer it is received from.\& The name of a file descriptor begins with the character \fI!\&\fR, e.\&g.\& \fI!\&file\fR, \fI!\&pipe\fR, or \fI!\&memfd:NAME\fR.\& Refer to the \fIsyd\fR(2) manual page for the list of file descriptor names.\& T} T{ \fBnet/link\fR T} T{ Confine \fInetlink\fR(7) sockets used in communication between kernel and user space.\& This sandboxing category may be used to specify a list of \fInetlink\fR(7) families to allow for the sandbox process.\& Use e.\&g.\& \fIallow/net/link+route\fR to allow the \fBNETLINK_ROUTE\fR family.\& Refer to the \fIsyd\fR(2) manual page for more information.\& T} T{ \fBlock/read\fR T} T{ Use \fIlandlock\fR(7) to confine file read access.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_READ_FILE\fR and only applies to the content of the directory not the directory itself.\& As of version 3.\&33.\&0, \fIlock/exec\fR and \fIlock/readdir\fR access rights are confined in their respective categories.\& Previously, this category included the access rights \fBLANDLOCK_ACCESS_FS_EXECUTE\fR and \fBLANDLOCK_ACCESS_FS_READ_DIR\fR as well.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/write\fR T} T{ Use \fIlandlock\fR(7) to confine file write access.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_WRITE_FILE\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/exec\fR T} T{ Use \fIlandlock\fR(7) to confine file execution.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_EXECUTE\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/ioctl\fR T} T{ Use \fIlandlock\fR(7) to confine \fIioctl\fR(2) operations.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_IOCTL_DEV\fR and only applies to the content of the directory not the directory itself.\& This access right is supported as of Landlock ABI version 5 which was introduced with Linux\-6.\&10.\& This command has no effect when running on older Linux kernels.\& Use \fIsyd\-lock\fR(1) to check the latest Landlock ABI supported by the running Linux kernel.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/create\fR T} T{ Use \fIlandlock\fR(7) to confine file creation, renames and links.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_MAKE_REG\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/delete\fR T} T{ Use \fIlandlock\fR(7) to confine file unlinking, renames and links.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_REMOVE_FILE\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/rename\fR T} T{ Use \fIlandlock\fR(7) to confine link or rename a file from or to a different directory (i.\&e.\& reparent a file hierarchy).\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_REFER\fR and only applies to the content of the directory not the directory itself.\& This access right is supported as of Landlock ABI version 2 which was introduced with Linux\-5.\&19.\& This command has no effect when running on older Linux kernels.\& Use \fIsyd\-lock\fR(1) to check the latest Landlock ABI supported by the running Linux kernel.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/symlink\fR T} T{ Use \fIlandlock\fR(7) to confine symbolic link creation, renames and links.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_MAKE_SYM\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/truncate\fR T} T{ Use \fIlandlock\fR(7) to confine file truncation with \fItruncate\fR(2), \fIftruncate\fR(2), \fIcreat\fR(2), or \fIopen(2)\fR with \fBO_TRUNC\fR.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_TRUNCATE\fR and only applies to the content of the directory not the directory itself.\& This access right is supported as of Landlock ABI version 3 which was introduced with Linux\-6.\&2.\& This command has no effect when running on older Linux kernels.\& Use \fIsyd\-lock\fR(1) to check the latest Landlock ABI supported by the running Linux kernel.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/readdir\fR T} T{ Use \fIlandlock\fR(7) to confine directory listings.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_READ_DIR\fR and applies to the given directory and the directories beneath it.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/mkdir\fR T} T{ Use \fIlandlock\fR(7) to confine directory creation and renames.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_MAKE_DIR\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/rmdir\fR T} T{ Use \fIlandlock\fR(7) to confine directory deletion and renames.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_REMOVE_DIR\fR and only applies to the content of the directory not the directory itself.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/mkbdev\fR T} T{ Use \fIlandlock\fR(7) to confine block device creation, renames and links.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_MAKE_BLOCK\fR.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/mkcdev\fR T} T{ Use \fIlandlock\fR(7) to confine character device creation, renames and links.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_MAKE_CHAR\fR.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/mkfifo\fR T} T{ Use \fIlandlock\fR(7) to confine named pipe (FIFO) creation, renames and links.\& This category corresponds to the \fIlandlock\fR(7) access right \fBLANDLOCK_ACCESS_FS_MAKE_FIFO\fR.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/bind\fR T} T{ Use \fIlandlock\fR(7) to confine network ports for \fIbind\fR(2) and UNIX domain socket creation, renames and links.\& This category corresponds to the Landlock access rights \fBLANDLOCK_ACCESS_NET_BIND_TCP\fR and \fBLANDLOCK_ACCESS_NET_BIND_UDP\fR for network ports, and \fBLANDLOCK_ACCESS_FS_MAKE_SOCK\fR for UNIX domain sockets, the last of which only applies to the content of the directory not the directory itself.\& \fBLANDLOCK_ACCESS_NET_BIND_TCP\fR is supported as of Landlock ABI version 4 which was introduced with Linux\-6.\&7.\& \fBLANDLOCK_ACCESS_NET_BIND_UDP\fR is supported as of Landlock ABI version 10 which was introduced with Linux\-7.\&2.\& This command has no effect when running on older Linux kernels.\& Use \fIsyd\-lock\fR(1) to check the latest Landlock ABI supported by the running Linux kernel.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBlock/connect\fR T} T{ Use \fIlandlock\fR(7) to confine network ports for \fIconnect\fR(2) and UNIX domain socket resolution.\& This category corresponds to the Landlock access rights \fBLANDLOCK_ACCESS_NET_CONNECT_TCP\fR and \fBLANDLOCK_ACCESS_NET_CONNECT_SEND_UDP\fR for network ports, and \fBLANDLOCK_ACCESS_FS_RESOLVE_UNIX\fR for UNIX domain sockets, the last of which restricts both \fIconnect\fR(2) and \fIsendmsg\fR(2) with an explicit recipient address to UNIX domain sockets created outside the \fIlandlock\fR(7) domain.\& \fBLANDLOCK_ACCESS_NET_CONNECT_TCP\fR is supported as of Landlock ABI version 4 which was introduced with Linux\-6.\&7.\& \fBLANDLOCK_ACCESS_FS_RESOLVE_UNIX\fR is supported as of Landlock ABI version 9 which was introduced with Linux\-7.\&1.\& \fBLANDLOCK_ACCESS_NET_CONNECT_SEND_UDP\fR is supported as of Landlock ABI version 10 which was introduced with Linux\-7.\&2.\& This command has no effect when running on older Linux kernels.\& Use \fIsyd\-lock\fR(1) to check the latest Landlock ABI supported by the running Linux kernel.\& This category is enforced completely in kernel\-space so it can be used to construct a multi\-layered sandbox.\& Refer to the \fBLock Sandboxing\fR section for more information.\& T} T{ \fBblock\fR T} T{ Application firewall with capability to include \fIipset\fR and \fInetset\fR files.\& List of filtered system calls are \fIaccept\fR(2), \fIaccept4\fR(2), \fIconnect\fR(2), \fIsendto\fR(2), \fIsendmsg\fR(2), \fIsendmmsg\fR(2).\& IPv4 and IPv6 family sockets are supported.\& Source and target addresses are checked against the IP blocklist.\& Refer to the description of the \fBblock\fR command in \fIsyd\fR(2) manual page for more information.\& T} T{ \fBfs\fR T} T{ Confine file opens based on filesystem type.\& By default, no filesystem types are allowed.\& To make this sandboxing practical, the \fIfs\fR profile included by the \fIlinux\fR profile allows all filesystem types except aafs, bpf_fs, securityfs, selinux, smack, debugfs, pstorefs, tracefs, cgroup, cgroup2, nsfs, pid_fd, rdtgroup, devmem, efivarfs, hostfs, mtd_inode_fs, openprom, daxfs, secretmem, bdevfs, binderfs, usbdevice, xenfs, and zonefs.\& Use \fIallow/fs+\fR to allow a filesystem type.\& T} T{ \fBforce\fR T} T{ Verified Execution: Verify binary/library integrity at \fIexec\fR(3)/\fImmap\fR(2) time which is similar to \fBVeriexec\fR (NetBSD) & \fBIntegriForce\fR (HardenedBSD).\& Refer to the \fBForce Sandboxing\fR section for more information.\& T} T{ \fBtpe\fR T} T{ Trusted Path Execution: Execution only allowed from \fBTrusted directories\fR for \fBTrusted files\fR which are not writable by group or others and are optionally owned by root or current user.\& This feature is similar to the implementation of Grsecurity & HardenedBSD.\& Refer to the \fBTPE Sandboxing\fR section for more information.\& T} T{ \fBproxy\fR T} T{ SOCKS5 proxy forwarding with network namespace isolation.\& Defaults to TOR.\& Refer to the \fBProxy Sandboxing\fR section for more information.\& T} T{ \fBpty\fR T} T{ Run sandbox process inside a new pseudoterminal.\& Refer to the \fBPTY Sandboxing\fR section for more information.\& T} T{ \fBmem, pid\fR T} T{ Memory and PID sandboxing: Simple, unprivileged alternatives to Control Groups.\& Refer to the \fBMemory Sandboxing\fR and \fBPID Sandboxing\fR sections for more information.\& T} T{ \fBuring\fR T} T{ Confine \fIio_uring\fR(7) with task\-level restrictions new in Linux\-7.\&0.\& Allow submission queue operations with \fIallow/uring/op\fR, registrations with \fIallow/uring/reg\fR and submission flags with \fIallow/uring/flag\fR.\& Use e.\&g.\& \fIallow/uring/op+openat\fR to also permit \fBIORING_OP_OPENAT\fR.\& Refer to the \fBUring Sandboxing\fR section for more information.\& T} T{ \fBSafeSetID\fR T} T{ Safe user/group switching with predefined UID/GID transitions like \fBSafeSetID\fR of the \fBLinux\fR kernel.\& Refer to the \fBSafeSetID\fR section for more information.\& T} T{ \fBGhost mode\fR T} T{ Detach Syd from the sandbox process, similar to \fIseccomp\fR(2) Level 1, aka "Strict Mode".\& Refer to the \fBGhost mode\fR section for more information.\& T} .TE .sp 1 Sandboxing for a category may be \fIon\fR or \fIoff\fR: If sandboxing is off, none of the relevant system calls are checked and all access is granted.\& If, however, sandboxing is on, the action defaults to \fIdeny\fR and allowlists and denylists can be used to refine access rights, e.\&g.\& \fIallow/read+/etc/passwd\fR.\& The default action for a sandboxing category may be changed with the respective option, e.\&g.\& default/force:kill.\& Refer to the \fIsyd\fR(2) manual page for more information on how to configure Syd sandbox policies.\& If the sandbox process invokes a system call that violates access, this attempt is reported in system log and the system call is denied from execution.\& There are two ways to customise this behaviour.\& Syd may be configured to \fIallow\fR some \fIglob\fR(3p) patterns.\& If the path argument of the system call which is subject to be modified matches a pattern in the list of allowed \fIglob\fR(3p) patterns, this attempt is not denied.\& If, however it matches a pattern in the list of \fIdeny\fR \fIglob\fR(3p) patterns the attempt is denied.\& \fBIf many rules match the same path or address, the last matching pattern wins\fR.\& It is also possible to use the actions \fIexit\fR, \fIkill\fR, \fIabort\fR, \fIstop\fR, \fIpanic\fR, and \fIwarn\fR instead of the \fIallow\fR and \fIdeny\fR actions.\& The list of available sandboxing actions is given below: .PP .TS allbox;lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx. T{ \fBallow\fR T} T{ Allow system call.\& T} T{ \fBwarn\fR T} T{ Allow system call and warn.\& T} T{ \fBfilter\fR T} T{ Deny system call silently.\& T} T{ \fBdeny\fR T} T{ Deny system call and warn.\& This is the default.\& T} T{ \fBpanic\fR T} T{ Deny system call, warn and panic the current Syd thread.\& T} T{ \fBstop\fR T} T{ Deny system call, warn and stop offending process.\& T} T{ \fBabort\fR T} T{ Deny system call, warn and abort offending process.\& T} T{ \fBkill\fR T} T{ Deny system call, warn and kill offending process.\& T} T{ \fBexit\fR T} T{ Warn, and exit Syd immediately with deny \fIerrno\fR(3) as exit value.\& T} .TE .sp 1 \fIdeny\fR is default unless another default action is set using one of the \fIdefault/:\fR options.\& Refer to \fIsyd\fR(2) manual page for more information.\& \fIexit\fR causes Syd to exit immediately with all the sandbox processes running under it.\& \fIkill\fR makes Syd send the offending process a \fBSIGKILL\fR signal and deny the system call.\& \fIstop\fR makes Syd send the offending process a \fBSIGSTOP\fR signal and deny the system call.\& \fIabort\fR makes Syd send the offending process a \fBSIGABRT\fR signal and deny the system call.\& Unlike \fIkill\fR and \fIstop\fR actions sandbox processes are able to catch the \fBSIGABRT\fR signal, therefore \fIabort\fR action should only be used for debugging in trusted environments where a \fIcore\fR(5) dump file may provide useful information.\& \fIpanic\fR causes the respective Syd emulator thread to panic in which case the system call is denied by an RAII guard.\& This behaviour of \fIpanic\fR action is currently functionally equivalent to the \fIdeny\fR action, however it may be further extended in the future where Syd emulator processes are fork+exec'\&ed and address space is rerandomized by ASLR on each access violation.\& \fIwarn\fR makes Syd allow the system call and print a warning about it which is used by \fIpandora\fR(1) for learning mode.\& Additionally, Syd may be configured to \fIfilter\fR some \fIglob\fR(3p) patterns.\& In this case a match will prevent Syd from reporting a warning about the access violation, the system call is still denied though.\& For \fIlock/*\fR categories the only available action is \fIallow\fR, and these categories accept path names rather than \fIglob\fR(3p) patterns as arguments.\& Relative paths are permitted for all \fIlock/*\fR categories except \fIlock/bind\fR and \fIlock/connect\fR which require either an absolute UNIX domain socket path or a port specification as argument.\& The port specification can be a single port, a closed range such as \fIport1\-port2\fR, or a comma\-separated list such as \fI80,443,8000\-9000\fR.\& .PP .SS SANDBOX CATEGORY SETS .PP As of v3.\&38.\&0, multiple categories may be specified split by commas and the following sets are defined to simplify sandbox profile composition.\& Names are intentionally chosen to be consistent with OpenBSD'\&s \fIpledge\fR(2) and FreeBSD'\&s capsicum \fIrights\fR(4freebsd): .PP .TS allbox;lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx lx. T{ \fBall\fR T} T{ All categories T} T{ \fBall\-l\fR T} T{ All categories except \fBlpath\fR T} T{ \fBall\-n\fR T} T{ All categories except \fBnpath\fR T} T{ \fBall\-x\fR T} T{ All categories except \fBexec\fR T} T{ \fBall\-ln\fR T} T{ All categories except \fBlpath\fR and \fBnpath\fR T} T{ \fBall\-lx\fR T} T{ All categories except \fBlpath\fR and \fBexec\fR T} T{ \fBall\-nx\fR T} T{ All categories except \fBnpath\fR and \fBexec\fR T} T{ \fBall\-lnx\fR T} T{ All categories except \fBlpath\fR, \fBnpath\fR, and \fBexec\fR T} T{ \fBlock/all\fR T} T{ All \fIlandlock\fR(7) access rights T} T{ \fBlock/all\-x\fR T} T{ All \fIlandlock\fR(7) access rights except \fBexec\fR T} T{ \fBlpath\fR T} T{ walk, list, chdir, readlink T} T{ \fBnpath\fR T} T{ notify, stat T} T{ \fBrpath\fR T} T{ read, readdir T} T{ \fBlock/rpath\fR T} T{ lock/read, lock/readdir T} T{ \fBwpath\fR T} T{ write, truncate T} T{ \fBlock/wpath\fR T} T{ lock/write, lock/truncate T} T{ \fBcpath\fR T} T{ create, delete, rename T} T{ \fBlock/cpath\fR T} T{ lock/create, lock/delete, lock/rename T} T{ \fBdpath\fR T} T{ mkbdev, mkcdev T} T{ \fBlock/dpath\fR T} T{ lock/mkbdev, lock/mkcdev T} T{ \fBspath\fR T} T{ mkfifo, symlink T} T{ \fBlock/spath\fR T} T{ lock/mkfifo, lock/symlink T} T{ \fBtpath\fR T} T{ mkdir, rmdir T} T{ \fBlock/tpath\fR T} T{ lock/mkdir, lock/rmdir T} T{ \fBfown\fR T} T{ chown, chgrp T} T{ \fBfattr\fR T} T{ chmod, chattr, utime T} T{ \fBnet\fR T} T{ net/bind, net/connect T} T{ \fBlock/net\fR T} T{ lock/bind, lock/connect T} T{ \fBinet\fR T} T{ net/bind, net/connect T} T{ \fBlock/inet\fR T} T{ lock/bind, lock/connect T} T{ \fBbnet\fR T} T{ net/bind T} T{ \fBlock/bnet\fR T} T{ lock/bind T} T{ \fBcnet\fR T} T{ net/connect T} T{ \fBlock/cnet\fR T} T{ lock/connect T} T{ \fBpassfd\fR T} T{ sendfd, recvfd T} .TE .sp 1 Some examples are given below: .PP .nf .RS 4 default/all:kill sandbox/inet:off deny/cpath,rpath,wpath+${HOME}/\&.ssh/*** kill/spath+/tmp/*** allow/inet+loopback!1024\-65535 allow/cnet+tcp!10\&.0\&.0\&.7!5432 kill/unix+/dev/log .fi .RE .PP .SS SANDBOX RULE SHORTCUTS .PP Sandbox capabilities may be passed to sandbox actions either as a single unit or as a comma\-delimited list, e.\&g: .PP .nf .RS 4 allow/read,write,stat,exec+/*** allow/read,write,stat\-/*** deny/read,write,stat+/*** deny/read,write\-/*** filter/read,write,stat+/dev/mem filter/read,write\-/dev/mem .fi .RE .PP As of version 3.\&18.\&14, sandboxing modes may be specified as a single unit or as a comma\-delimited list, e.\&g: .PP .nf .RS 4 sandbox/read,write,stat,exec:on sandbox/net,lock:off .fi .RE .PP As of version 3.\&19.\&0, namespace types may be specified as a single unit or as a comma\-delimited list, e.\&g.\&: .PP .nf .RS 4 unshare/user,pid,mount:on unshare/net,cgroup:off .fi .RE .PP As of version 3.\&35.\&0, default modes may be specified as a single unit or as a comma\-delimited list, e.\&g: .PP .nf .RS 4 default/write,truncate:kill default/read,stat:allow .fi .RE .PP .SS SegvGuard .PP As of version 3.\&16.\&3, Syd has a simple implementation of SegvGuard.\& The implementation is inspired by that of HardenedBSD with identical defaults: If a sandbox process receives a signal that may produce a \fIcore\fR(5) dump file for \fIsegvguard/maxcrashes\fR times (defaults to 5), in a period of \fIsegvguard/expiry\fR seconds (defaults to 2 minutes), subsequent attempts to execute the same executable is denied for \fIsegvguard/suspension\fR seconds (defaults to 10 minutes).\& SegvGuard can be disabled by setting \fIsegvguard/expiry:0\fR.\& SegvGuard support depends on \fIptrace\fR(2), therefore it may also be disabled by setting \fItrace/allow_unsafe_ptrace:1\fR at startup.\& The trigger signals for SegvGuard are \fBSIGABRT\fR, \fBSIGBUS\fR, \fBSIGFPE\fR, \fBSIGILL\fR, \fBSIGIOT\fR, \fBSIGKILL\fR, \fBSIGQUIT\fR, \fBSIGSEGV\fR, \fBSIGSYS\fR, \fBSIGTRAP\fR, \fBSIGXCPU\fR, and \fBSIGXFSZ\fR.\& The signal \fBSIGKILL\fR is intentionally included into the list even though it is not a \fIcore\fR(5) dump file generating signal to make \fIkill\fR rules trigger SegvGuard, a design later mirrored in HardenedBSD'\&s work on PaX SEGVGUARD and Capsicum integration.\& .PP Check out the following links for further information on SegvGuard: .PP .PD 0 .IP \(bu 4 http://en.\&wikibooks.\&org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deter_exploit_bruteforcing .IP \(bu 4 http://en.\&wikibooks.\&org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Active_kernel_exploit_response .IP \(bu 4 http://phrack.\&org/archives/issues/59/9.\&txt .IP \(bu 4 http://phrack.\&org/archives/issues/58/4.\&txt .IP \(bu 4 https://github.\&com/HardenedBSD/hardenedBSD/wiki/segvguard2\-ideas\-\-\-brainstorm .IP \(bu 4 https://hardenedbsd.\&org/article/shawn\-webb/2025\-03\-01/hardenedbsd\-february\-2025\-status\-report .PD .PP .SS Force Sandboxing .PP Force Sandboxing enhances system security by scrutinizing the path provided to \fIexecve\fR(2) and \fIexecveat\fR(2) system calls, comparing them against a predefined Integrity Force map \-\- a registry of path\-to\-checksum correlations.\& Upon invocation of these calls, the sandbox computes the checksum of the target binary and cross\-references it with the map.\& Discrepancies trigger rule\-defined actions: execution might proceed with a logged warning, or culminate in the termination of the process in violation.\& This mechanism allows for enforcement of binary integrity, echoing the preventative ethos of HardenedBSD'\&s Integriforce and NetBSD'\&s Veriexec by preventing unauthorised code execution.\& .PP The response to checksum mismatches is configurable: \fIkill\fR, \fIdeny\fR, or \fIwarn\fR.\& Use \fIsyd\-sum\fR(1) for checksum calculation and \fIsyd\-path\fR(1) for rule creation.\& See \fIforce\fR command in \fIsyd\fR(2) manual page on how to add/remove entries to/from the Integrity Force map.\& .PP As of version 3.\&16.\&3, Syd checks the paths of the dynamic libraries an executable is linked against for force access as well.\& This only works for ELF files.\& .PP As of version 3.\&21.\&3, Syd hooks into \fImmap\fR(2), and \fImmap2\fR(2) system calls and checks the file descriptor for Force access when the memory protection mode includes \fBPROT_EXEC\fR and flags does not include \fBMAP_ANONYMOUS\fR which typically indicates a \fIdlopen\fR(3).\& Therefore libraries dynamically loaded at runtime are checked for Force access as well.\& .PP .SS TPE sandboxing .PP As of version 3.\&21.\&0, Syd introduces Trusted Path Execution (TPE) sandboxing, which restricts the execution of binaries to ensure they come from \fItrusted directories\fR.\& As of version 3.\&37.\&2, the binary file must be \fItrusted\fR as well as its parent directory.\& The intention is to make privilege escalation harder when an account restricted by TPE is compromised as the attacker won'\&t be able to execute custom binaries which are not in the trusted path.\& A binary is \fItrusted\fR if the file and its parent directory meet the following criteria: .PP .PD 0 .IP \(bu 4 Not writable by group or others.\& .IP \(bu 4 Optionally owned by root, controlled by the \fItpe/root_owned\fR option.\& .IP \(bu 4 Optionally owned by the current user or root, controlled by the \fItpe/user_owned\fR option.\& .IP \(bu 4 Optionally part of the root filesystem, controlled by the \fItpe/root_mount\fR option.\& .PD .PP If these criteria are not met, the execution is denied with an \fBEACCES\fR \fIerrno\fR(3), and optionally, the offending process can be terminated with the \fBSIGKILL\fR signal using the \fIdefault/tpe:kill\fR option.\& This mechanism ensures that only binaries from secure, trusted paths can be executed, enhancing security by preventing unauthorized code execution.\& TPE sandboxing operates by checking the the executables at three stages: .PP .PD 0 .IP \(bu 4 During the system call entry of \fIexecve\fR(2) and \fIexecveat\fR(2) to check scripts.\& .IP \(bu 4 On \fIptrace\fR(2) exec event to check the ELF executable and dynamic loader.\& .IP \(bu 4 On \fImmap\fR(2) when dynamic libraries are mapped to memory, typically with \fIdlopen\fR(3).\& .PD .PP TPE can be configured to apply to a specific user group.\& By default, TPE applies to all users.\& However, administrators can specify an untrusted GID with the \fItpe/gid\fR setting, restricting TPE only to users in that group.\& Additionally, TPE can negate GID logic with the \fItpe/negate\fR setting, making the specified group trusted and exempt from TPE.\& .PP Syd'\&s TPE implementation is based on HardenedBSD'\&s which is inspired by GrSecurity'\&s TPE.\& Check out the following links for more information: .PP .PD 0 .IP \(bu 4 http://phrack.\&org/issues/52/6.\&html#article .IP \(bu 4 http://phrack.\&org/issues/53/8.\&html#article .IP \(bu 4 https://wiki.\&gentoo.\&org/wiki/Hardened/Grsecurity_Trusted_Path_Execution .PD .PP .SS Lock Sandboxing .PP Lock sandboxing utilises the \fBLandlock Linux Security Module\fR for simple unprivileged access control.\& It is enforced completely in kernel\-space and the policy is also applied to the Syd process, such that a compromised Syd process is still stuck inside the \fIlandlock\fR(7) sandbox, therefore Lock sandboxing can be used to construct a multi\-layered sandbox for added security.\& Lock sandboxing may be turned on with the \fIsandbox/lock:on\fR sandbox command at startup.\& Paths to files and file hierarchies should be populated using the \fIlock/*\fR categories either specifying them one at a time, e.\&g.\& \fIallow/lock/read+/usr\fR, \fIallow/lock/write+/dev/null\fR or by specifying them as a comma delimited list, e.\&g.\& allow/lock/read,write,ioctl+/dev/null.\& The shorthand \fIlock/all\fR is provided to ease configuration and it stands for the union of categories \fIlock/read\fR, \fIlock/write\fR, \fIlock/exec\fR, \fIlock/ioctl\fR, \fIlock/create\fR, \fIlock/delete\fR, \fIlock/rename\fR, \fIlock/symlink\fR, \fIlock/truncate\fR, \fIlock/readdir\fR, \fIlock/mkdir\fR, \fIlock/rmdir\fR, \fIlock/mkdev\fR, \fIlock/mkfifo\fR, and \fIlock/bind\fR.\& The shorthand \fIlock/all\-x\fR stands for all \fIlock/all\fR categories except \fIlock/exec\fR.\& As of version 3.\&29.\&0, network confinement is supported and allowlisted \fIbind\fR(2) and \fIconnect\fR(2) ports can be specified using the commands \fIallow/lock/bind+port\fR and \fIallow/lock/connect+port\fR.\& A closed range in format \fIport1\-port2\fR or a comma\-separated list of ports and/or ranges such as \fI80,443,8000\-9000\fR may also be specified instead of a single port number.\& Use the \fIlock/bind\fR category with an absolute path to confine UNIX domain socket creation, renames and links, e.\&g \fIallow/lock/bind+/run/user/${SYD_UID}\fR.\& As of version 3.\&35.\&0, the default compatibility level has been changed to \fIHard Requirement\fR.\& Compared to the old default \fIBest Effort\fR, this level enforces the sandbox fully.\& \fBENOENT\fR ("No such file or directory"), errors are made fatal in this level.\& The compatibility level may be changed at startup using the command \fIdefault/lock\fR.\& See the \fIsyd\fR(2) manual page for more information.\& .PP .SS Uring Sandboxing .PP As of version 3.\&58.\&0, Syd confines \fIio_uring\fR(7) with task\-level restrictions which are new in Linux\-7.\&0.\& Without this restriction, \fIio_uring\fR(7) can bypass path and network sandboxing.\& Enforcement is entirely in kernel\-space and applies to Syd itself.\& Uring sandboxing is on by default.\& It may be turned off with \fIsandbox/uring:off\fR at startup, which lets \fIio_uring\fR(7) pass through to Linux unconfined.\& Allowed submission queue operations are configured with \fIallow/uring/op\fR.\& Allowed registrations are configured with \fIallow/uring/reg\fR.\& Allowed submission flags are configured with \fIallow/uring/flag\fR.\& Operations default to \fIepoll_ctl\fR, \fIread\fR, \fIreadv\fR, \fIwrite\fR, and \fIwritev\fR.\& Registrations default to \fIregister_probe\fR.\& Flags default to \fIasync\fR.\& An empty operation list denies \fIio_uring\fR(7) altogether.\& A registration configures a ring rather than submits work.\& The kernel enforces register restrictions only when at least one registration is allowlisted.\& The default allows only the read\-only \fIregister_probe\fR query.\& This denies the remaining registrations.\& Syd denies \fIio_uring\fR(7) interface altogether using \fIseccomp\fR(2) on Linux kernels older than 7.\&0.\& Syd similarly denies \fIio_uring\fR(7) altogether if the task\-level restriction cannot be installed.\& \fIsyd\-ring\fR(1) utility may be used to install these restrictions alone without \fIsyd\fR(1).\& Refer to documentation of \fIallow/uring/op\fR, \fIallow/uring/reg\fR and \fIallow/uring/flag\fR commands in the \fIsyd\fR(2) manual page for more information.\& .PP .SS Domain Transitions .PP As of version 3.\&55.\&0, Syd supports sandbox \fIdomains\fR: named, self\-contained policies among which the sandbox switches at run time.\& Sandbox always has exactly one \fIactive domain\fR, whose policy applies to every process, and Syd keeps no per\-process domain table.\& The domain \fIdefault\fR always exists.\& Further new domains are created, seeded, removed, and cleared with the \fBdomain\fR command.\& A per\-domain command is addressed to a domain with the prefix \fI@/\fR.\& An unprefixed command applies to the \fIdefault\fR domain.\& Startup\-only settings, those reported as \fIstatic\fR in the \fIsyd\fR(2) manual page, are global and cannot be addressed to a domain, which fails with the \fIerrno\fR(3) \fBEINVAL\fR ("Invalid argument").\& At most 64 domains may be defined, including \fIdefault\fR.\& A domain name is 1 to 16 bytes, letter\-first ASCII alphanumeric with underscore (\fI[A\-Za\-z][A\-Za\-z0\-9_]*\fR).\& Every domain'\&s policy is sealed together with the global policy when the sandbox is locked.\& This model follows the domain\-and\-transition mechanism of the \fBTOMOYO\fR and \fBCaitSith\fR Linux Security Modules, in which policy is keyed on an audited label.\& .PP Syd'\&s design shares its lineage with CaitSith but differs in domain scope and in how policy evolves at run time.\& CaitSith binds a domain to each task and maintains a per\-process domain table.\& Syd keeps a single active domain and no such table, a simpler design that holds one policy in force across the sandbox rather than tracking one per process.\& CaitSith keeps policy editable at run time through a designated manager program.\& Syd governs editability through a lock whose state decides who, if anyone, may change policy, ranging from all sandbox processes, to only the initial trusted process, to an irreversible sealed state in which every domain'\&s policy is fixed for the remainder of the sandbox'\&s lifetime.\& Both systems support a learning workflow in which violations are logged rather than enforced and a profile is derived from the record, in Syd through the \fBwarn\fR action and \fIpandora\fR(1).\& CaitSith additionally expresses per\-rule conditions, quotas, and audit facilities that Syd'\&s model leaves out.\& .PP A move changes the active domain and is always declared by the administrator with the \fBmove\fR command.\& A move is atomic.\& The active domain is switched in a single step, so every mediated operation sees exactly one domain, never a mix of two.\& An automatic move is taken when a mediated operation of one kind (\fBexit\fR, \fBexec\fR, \fBchdir\fR, \fBmmap\fR, \fBbind\fR, \fBconnect\fR, or \fBaccept\fR) is allowed on a matching pattern.\& A lock\-state move switches to a domain named \fIlock\fR, \fIread\fR, or \fIdrop\fR, when it exists, as \fIlock:on\fR, \fIlock:read\fR, or \fIlock:drop\fR is instantiated.\& A manual move is requested at run time by a process with the \fBcmd/move\fR command.\& See the \fBdomain\fR, \fBmove\fR, and \fBcmd/move\fR commands in the \fIsyd\fR(2) manual page.\& .PP An \fBexec\fR move matches the new program image, as reported by \fIproc_self_exe\fR(5), not the \fIexecve\fR(2) argument.\& For a \fI#!\&\fR script the image is the interpreter.\& .PP .nf .RS 4 # exec: confine a CGI interpreter\&. Executing it enters @cgi, which may not # itself execute any further program\&. domain+@cgi @cgi/sandbox/exec:on move/@cgi/exec+/usr/bin/php\-cgi # bind: confine a server to its serving phase\&. Once it has bound its # listening port it can no longer bind or execute\&. domain+@serve @serve/sandbox/exec,net/bind:on move/@serve/bind+0\&.0\&.0\&.0/0!443 # connect: after the application reaches its database it may open no further # outbound connection, bounding exfiltration if it is later compromised\&. domain+@db @db/sandbox/net/connect:on move/@db/connect+0\&.0\&.0\&.0/0!5432 # accept: once a worker has accepted a client it may neither execute # programs nor open new connections of its own\&. domain+@worker @worker/sandbox/exec,net/connect:on move/@worker/accept+0\&.0\&.0\&.0/0!1\-65535 # mmap: the moment a plugin object is mapped, forbid loading further code # and using the network\&. domain+@plugin @plugin/sandbox/exec,net:on move/@plugin/mmap+/usr/lib/myapp/plugins/**\&.so # chdir: on entering the upload directory, restrict the sandbox to that tree\&. domain+@upload @upload/sandbox/read,write:on @upload/allow/read,write+/srv/upload/** move/@upload/chdir+/srv/upload # exit: open the network only while curl runs\&. Executing curl enters @net, # and curl\&'s exit returns the sandbox to the base policy\&. sandbox/net:on domain+@net @net/allow/net/connect+0\&.0\&.0\&.0/0!443 move/@net/exec+/usr/bin/curl @net/move/@default/exit+/usr/bin/curl # lock state: a domain named drop is entered on lock:drop; lock and read # behave the same way for lock:on and lock:read\&. domain+@drop @drop/sandbox/all:on @drop/allow/write+/var/log/myapp/** # manual: a program switches to a prepared domain itself, issuing # cmd/move!untrusted before it parses untrusted input\&. domain+@untrusted @untrusted/sandbox/all:on # remove one move with \&'\-\&', or every move of a kind with \&'^\&': move/@net/exec\-/usr/bin/curl move/@net/exec^ .fi .RE .PP .SS Proxy Sandboxing .PP As of version 3.\&22.\&0, Proxy sandboxing in Syd confines network communication exclusively through a designated SOCKS proxy, enforced by the helper utility \fIsyd\-tor\fR(1).\& Configured at startup with \fIsandbox/proxy:on\fR, this type implies the use of \fIunshare/net:1\fR, isolating network namespaces to prevent direct network access.\& Traffic is forwarded from a specified local port (proxy/port:9050) to an external address and port (proxy/ext/host:127.\&0.\&0.\&1, proxy/ext/port:9050).\& As of version 3.\&34.\&1, you may also specify an external UNIX domain socket using e.\&g.\& proxy/ext/unix:/path/socks5.\&sock.\& All network traffic routes through the proxy using zero\-copy data transfers and edge\-triggered \fIepoll\fR(7) for event handling.\& The implementation uses seccomp and Landlock for additional confinement, preventing unauthorized network access outside the defined proxy path.\& .PP .SS PTY Sandboxing .PP As of version 3.\&36.\&0, PTY Sandboxing runs the target process inside a dedicated pseudoterminal managed by the \fIsyd\-pty\fR(1) helper, isolating all terminal I/O from the host TTY and preventing direct \fIioctl\fR(2) or control\-sequence escapes.\& The PTY main is proxied via an edge\-triggered \fIepoll\fR(7) loop with non\-blocking zero\-copy \fIsplice\fR(2), so no data traverses user space in the clear.\& A minimal \fIseccomp\fR(2) filter allows only the required PTY ioctls (e.\&g.\& \fBTIOCGWINSZ\fR, \fBTIOCSWINSZ\fR) and denies all others \-\- including injection via \fBTIOCSTI\fR \-\- while Landlock locks down access to the PTY device, filesystem, and network.\& No\-exec memory seals and namespace isolation further harden against terminal\-based attacks.\& .PP .SS Memory Sandboxing .PP This sandboxing category handles the system calls \fIbrk\fR(2), \fImmap\fR(2), \fImmap2\fR(2), and \fImremap\fR(2) and checks the per\-process memory usage on each memory allocation request.\& If the memory usage reaches the maximum value defined by \fImem/max\fR, the system call is denied with \fBENOMEM\fR.\& The virtual memory size can also be limited using \fImem/vm_max\fR.\& If the limit is reached on the entry of any of the respective system calls, the system call is denied with \fBENOMEM\fR and the signal \fBSIGKILL\fR is delivered to the offending process.\& Subsequent to the delivery of the signal, the \fIprocess_mrelease\fR(2) system call is called on the process to immediately release memory.\& The default action may be changed using the \fIdefault/mem\fR option.\& The per\-process memory usage is a fair estimate calculated using the file \fIproc_pid_smaps\fR(5) summing the following fields together: .PP .PD 0 .IP \(bu 4 \fIPss (Proportional Set Size)\fR is similar to \fIRss\fR, but accounts for shared memory more accurately by dividing it among the processes that share it.\& \fIRss (Resident Set Size)\fR is the portion of memory occupied by a process that is held in RAM.\& .IP \(bu 4 \fIPrivate_Dirty\fR represents the private memory that has been modified (dirty).\& .IP \(bu 4 \fIShared_Dirty\fR represents the shared memory that has been modified.\& .PD .PP As of version 3.\&43.\&1, the memory sandboxing system has been updated to improve memory usage tracking.\& Syd now enforces a strict memory limit based on allocation granularity, meaning that programs cannot exceed the defined memory limits, even by the amount they allocate at once.\& This change aligns the limit with the allocation size rather than allowing any overflow beyond the limit.\& Additionally, memory tracking has been optimized by switching from iterating over \fIproc_pid_smaps\fR(5) to using the more efficient \fI/proc/pid/smaps_rollup\fR, which consolidates memory usage information for better performance and more accurate enforcement of memory constraints.\& .PP \fIMemory sandboxing is not an alternative to cgroups(7)!\&\fR You should use \fIcgroups\fR(7) when you can instead.\& This sandboxing category is meant for more constrained environments where \fIcgroups\fR(7) is not supported or not available due to missing permissions or other similar restrictions.\& .PP .SS PID sandboxing .PP This sandboxing category handles the system calls \fIfork\fR(2), \fIvfork\fR(2), \fIclone\fR(2), and \fIclone3\fR(2) and checks the total number of tasks running on the system on each process creation request.\& If the count reaches the maximum value defined by \fIpid/max\fR, the system call is denied with \fBEAGAIN\fR.\& If \fIpid/kill\fR is set to true, the signal \fBSIGKILL\fR is delivered to the offending process.\& This sandboxing category is best coupled with a pid namespace using \fIunshare/pid\fR.\& In this mode, Syd will check the number of running tasks in the current namespace only.\& .PP As of version 3.\&40.\&0, with \fIunshare/pid:1\fR the limit and accounting apply per PID namespace; on Linux 6.\&14 and newer the namespaced \fIkernel.\&pid_max\fR \fIsysctl\fR(8) is set to \fImax(pid/max, 301)\fR so the kernel'\&s 300 reserved PIDs do not reduce the configured headroom, and on older kernels \fIkernel.\&pid_max\fR \fIsysctl\fR(8) is not modified.\& .PP \fIPID sandboxing is not an alternative to cgroups(7)!\&\fR You should use \fIcgroups\fR(7) when you can instead.\& This is meant for more constrained environments where \fIcgroups\fR(7) is not supported or not available due to missing permissions or other similar restrictions.\& .PP .SS SafeSetID .PP \fBSafeSetID\fR, introduced in version 3.\&16.\&8, enhancing the management of UID/GID transitions.\& This feature enables finer\-grained control by allowing administrators to explicitly specify permissible transitions for UID and GID changes, thus tightening security constraints around process privilege management.\& It works by allowing predefined UID and GID transitions that are explicitly configured using the \fIsetuid+:\fR and \fIsetgid+:\fR commands in the Syd configuration.\& This ensures that transitions can only occur between specified user and group IDs, and unauthorised privilege escalations are blocked.\& For instance, a transition might be allowed from a higher\-privileged user to a less\-privileged user but not vice versa, preventing any escalation of privileges through these system calls.\& .PP As of version 3.\&24.\&5, Syd applies a kernel\-level \fIseccomp\fR(2) filter by default to terminate all set*uid system calls with UID less than or equal to 11 which is typically the operator user, and all set*gid system calls with GID less than or equal to 14 which is typically the uucp group.\& This means even a compromised Syd process cannot change privileges using these system calls.\& As of version 3.\&54.\&0, the option \fItrace/allow_unsafe_setid\fR may be used to deny these system calls with \fBEPERM\fR ("Operation not permitted") rather than terminate the offending process.\& Refer to the output of the command \fIsyd\-ls setid\fR to see the full list of system calls in this group.\& .PP When a UID or GID transition is defined Syd will keep the \fBCAP_SETUID\fR and \fBCAP_SETGID\fR capabilities respectively and sandbox process will inherit these capabilities from Syd.\& Since version 3.\&24.\&6, Syd drops the \fBCAP_SETUID\fR capability after the first successful UID transition and similarly the \fBCAP_SETGID\fR capability after the first successful GID transition.\& This means Syd can only ever change its UID and GID once in its lifetime.\& However, this does not completely lock the setid system calls in the sandbox process: Transitions to Syd'\&s current UID and GID are continued in the sandbox process which means the first successful UID and GID transition will continue to function as long as the sandbox process keeps the respective \fBCAP_SETUID\fR, and \fBCAP_SETGID\fR capabilities.\& This allows containing daemons, such as \fInginx\fR(1), which spawn multiple unprivileged worker processes out of a single main privileged process.\& .PP .SS Ghost mode .PP Ghost Mode, introduced in Syd version 3.\&20.\&0, is a one\-way sandboxing mode, closely resembling \fIseccomp\fR(2) Level 1, also known as \fBStrict Mode\fR.\& This mode enhances security by allowing a process to transition to a highly restrictive state after completing its initial setup.\& When a sandboxed process is ready for this higher level of confinement, it invokes Ghost Mode by executing the \fIstat\fR(2) system call with the virtual path \fI/dev/syd/ghost\fR.\& Upon receiving this command, Syd closes the \fIseccomp_unotify\fR(2) file descriptor.\& This action elevates all previously hooked system calls to a kernel\-level deny with the \fBENOSYS\fR ("Function not implemented") \fIerrno\fR(3), making them unavailable.\& The transition to Ghost Mode is irreversible; once the file descriptor is closed, the process is locked into this restricted state.\& Only a minimal set of system calls remain available.\& .PP The name reflects that, upon closing the \fIseccomp_unotify\fR(2) file descriptor, the sandboxed process effectively detaches from Syd and becomes independent, much like a ghost.\& Entering ghost mode subsequently causes the \fIsyd_mon\fR monitor thread and all \fIsyd_emu\fR emulator threads to exit, and the remaining \fIsyd_main\fR thread merely waits for the sandbox process to exit without any further intervention.\& .PP A process cannot enter Ghost mode once the sandbox lock is set.\& Alternatively, though, a process can set its process dumpable attribute to zero using the \fBPR_SET_DUMPABLE\fR \fIprctl\fR(2).\& Under Syd, this achieves almost the same effect as Syd will not be able to emulate system calls with the per\-process directory inaccessible.\& This provides an unprivileged way to enter Ghost mode.\& .PP .SH SECURITY .PP Syd stands out for its ability to operate without requiring elevated privileges, eliminating the need for root access.\& This feature significantly simplifies setup and usage.\& Users benefit from the capability to dynamically configure the sandbox from within, with options to secure it further as needed.\& Tip: To take a quick peek at the seccomp filters applied by Syd under various different configurations, use \fIsyd \-Epfc\fR where PFC stands for Pseudo Filter Code which yields a human\-readable textual dump of Syd'\&s \fIseccomp\fR(2) filters.\& Syd further enrichens the output of this textual dump with \fB#\fR comments.\& .PP .SS Threat Model .PP \fISyd strictly adheres to the current threat model of seccomp(2)\fR.\& The goal is to restrict how untrusted userspace applications interact with the shared OS kernel through system calls to protect the kernel from userspace exploits (e.\&g.\&, shellcode or ROP payload).\& The kernel is trusted.\& Syd'\&s threat model delineates the sandbox as the trusted interceptor of system calls, while all user applications running within the sandbox are considered untrusted.\& These untrusted applications can manipulate their execution environment through syscalls, and attackers are assumed to have the capability to execute arbitrary code within these applications.\& Syd uses several mechanisms, including \fIseccomp\fR(2) and \fIptrace\fR(2) for syscall filtering, \fIlandlock\fR(7) for filesystem access restrictions, and \fInamespaces\fR(7) for process and device isolation, to limit the impact of these potential attacks.\& The threat model assumes that attackers have control over the untrusted user space and may attempt reads, writes, or arbitrary code execution that could influence the behavior of the trusted sandbox or exploit syscall handling.\& The security of Syd relies on the correctness of its implementation and the underlying Linux kernel features it utilises.\& It is assumed that there are no vulnerabilities in Syd'\&s interception and handling of syscalls, nor in the enforcement mechanisms provided by \fIlandlock\fR(7) and \fInamespaces\fR(7).\& External attacks via network vectors or physical access to hardware are considered out of scope for this threat model.\& .PP "The sandbox lock" is an integral component of Syd'\&s security architecture, which governs the configurability and integrity of the sandbox environment.\& By default, the sandbox lock is set to \fIon\fR, preventing any further sandbox commands after the initial setup.\& Once the sandbox is configured and the primary process is executed, the security policies remain unaltered by any untrusted processes within the sandbox.\& When the lock is set to \fIexec\fR, only the initial sandbox process retains the authority to access and modify the sandbox configuration, enabling a trusted process to securely establish the sandbox parameters while maintaining a \fIpidfd\fR (process ID file descriptor) to the initial process to safeguard against PID recycling attacks.\& Conversely, if the lock is set to \fIoff\fR, all sandbox processes are permitted to access and modify the sandbox configuration, allowing for broader configurability during the setup phase.\& However, this state persists only until the sandbox is explicitly locked, after which the lock becomes immutable and the sandbox policies are fixed, preventing any subsequent processes from altering the configuration.\& This layered locking mechanism, reinforced by the use of \fIpidfd\fR in \fIexec\fR mode, effectively safeguards against untrusted processes attempting to modify sandbox settings to escalate privileges or circumvent restrictions, maintaining a secure execution environment within Syd'\&s framework.\& In \fIipc\fR mode, the sandbox configuration is accessible through a UNIX socket which may or may not be accessible from within the sandbox depending on sandbox ACL rules.\& In \fIread\fR mode, the sandbox configuration is accessible only to reads, but NOT edits.\& Transition from lock modes \fIoff\fR, \fIexec\fR, and \fIipc\fR into one of \fIread\fR and \fIon\fR is one\-way and idempotent: It results in the sandbox policy getting sealed in memory using the \fImseal\fR(2) system call either immediately or simultaneously with sandbox process startup.\& Transitions between lock modes \fIread\fR and \fIon\fR are not permitted.\& .PP .SS Accessing remote process memory .PP Syd denies various system calls which can access remote process memory such as \fIptrace\fR(2) and \fIprocess_vm_writev\fR(2) and common sandboxing profiles such as \fIpaludis\fR and \fIuser\fR disallow write access to the \fI/proc/pid/mem\fR file.\& This makes TOCTOU attack vectors harder to realise.\& Refer to the the output of the command \fIsyd\-ls deny\fR to see the full list of denied system calls.\& .PP .SS Enhanced Handling of PTRACE_TRACEME .PP As of version 3.\&16.\&3, Syd introduced a new feature for managing the \fBPTRACE_TRACEME\fR operation, aimed at improving stealth against detection.\& Traditionally, \fBPTRACE_TRACEME\fR is the only \fIptrace\fR(2) operation allowed by a tracee, which makes it a common target for detection of ptracers.\& By converting \fBPTRACE_TRACEME\fR into a no\-operation (no\-op) that always succeeds, Syd aims to subtly prevent simple detection methods that rely on this operation.\& Additionally, other \fIptrace\fR(2) operations are modified to return an \fBEPERM\fR ("Operation not permitted") \fIerrno\fR(3) instead of \fBENOSYS\fR ("Function not implemented"), which helps reduce the likelihood of the sandbox being detected through these errors.\& This approach enhances the discreetness of Syd'\&s operation by mitigating straightforward detection tactics used by monitored processes.\& .PP As of version 3.\&19.\&0, Syd extends this mitigation and turns the system call \fIptrace\fR(2) into a no\-op.\& Again, this provides a best\-effort mitigation against using requests such as \fBPTRACE_ATTACH\fR or \fBPTRACE_SEIZE\fR to detect a ptracer.\& .PP As of version 3.\&47.\&0, Syd improves this mitigation and turns the \fIprctl\fR(2) calls with \fBPR_SET_PTRACER\fR argument into a no\-op.\& .PP As of version 3.\&47.\&0, Syd improves this mitigation to defend against intelligent \fIptrace\fR(2) detectors which use multiple \fIptrace\fR(2) requests to detect ptracer.\& Refer to the following links for more information on intelligent \fIptrace\fR(2) detection: .PP .PD 0 .IP \(bu 4 https://arxiv.\&org/pdf/2109.\&06127 .IP \(bu 4 https://seblau.\&github.\&io/posts/linux\-anti\-debugging .IP \(bu 4 https://docs.\&rs/debugoff .PD .PP .SS Hardened procfs and devfs .PP Syd enforces restrictions on \fIprocfs\fR(5) and devfs file systems by implementing several key measures: denying both the listing and opening of block devices and files of unknown types by omitting entries corresponding to these file types (identified by \fBDT_BLK\fR and \fBDT_UNKNOWN\fR) from directory listings and rejecting \fIopen\fR(2) operations on them.\& This prevents unauthorized enumeration and access to system storage devices, mitigating information disclosure and potential tampering.\& .PP Syd also restricts visibility within the \fI/proc\fR directory so that processes can only see their own process IDs, preventing discovery and potential interaction with other running processes, which reduces risks of information leakage, privilege escalation, and process manipulation.\& Access to the \fI/proc\fR entries of the Syd process itself is explicitly denied, safeguarding the sandbox manager from inspection or interference and preventing access to sensitive information about the sandboxing mechanism that could be exploited to bypass security controls or escape the sandbox.\& .PP Additionally, Syd addresses risks associated with magic symbolic links in \fI/proc\fR \-\- such as \fI/proc/[pid]/exe\fR and \fI/proc/[pid]/fd/*\fR \-\- by denying access to these links when they refer to processes other than the calling process, thus preventing exposure of sensitive file descriptors or executable paths of other processes and mitigating unauthorized access or container escape scenarios; this mitigation can be disabled with the \fItrace/allow_unsafe_magiclinks:1\fR option if necessary, though doing so is not recommended.\& .PP Together, these restrictions confine sandboxed processes to the minimum required visibility.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://forums.\&whonix.\&org/t/proc\-pid\-sched\-spy\-on\-keystrokes\-proof\-of\-concept\-spy\-gksu/8225 .IP \(bu 4 https://homes.\&luddy.\&indiana.\&edu/xw7/papers/zhou2013identity.\&pdf .IP \(bu 4 https://petsymposium.\&org/2016/files/papers/Don%E2%80%99t_Interrupt_Me_While_I_Type__Inferring_Text_Entered_Through_Gesture_Typing_on_Android_Keyboards.\&pdf .IP \(bu 4 https://staff.\&ie.\&cuhk.\&edu.\&hk/\(tikhzhang/my\-papers/2016\-oakland\-interrupt.\&pdf .IP \(bu 4 https://www.\&cs.\&ucr.\&edu/\(tizhiyunq/pub/sec14_android_activity_inference.\&pdf .IP \(bu 4 https://www.\&gruss.\&cc/files/procharvester.\&pdf .IP \(bu 4 https://www.\&kicksecure.\&com/wiki/Dev/Strong_Linux_User_Account_Isolation#/proc/pid/sched_spy_on_keystrokes .IP \(bu 4 https://www.\&openwall.\&com/lists/oss\-security/2011/11/05/3 .IP \(bu 4 https://www.\&usenix.\&org/legacy/event/sec09/tech/full_papers/zhang.\&pdf .IP \(bu 4 https://www.\&openwall.\&com/lists/oss\-security/2025/11/05/3 .PD .PP .SS Hardened proc_pid_status(5) .PP As of version 3.\&38.\&0, Syd filters \fIproc_pid_status\fR(5) at \fIopen\fR(2) boundary to defeat common sandbox\-fingerprinting heuristics while preserving compatibility with ordinary tooling.\& When a process (or its threads) reads /proc//status or /proc//task//status, Syd normalizes only the security\-critical fields \-\- zeroing \fITracerPid\fR, \fINoNewPrivs\fR, \fISeccomp\fR, and \fISeccomp_filters\fR, and rewriting the sandbox\-revealing phrases in \fISpeculation_Store_Bypass\fR and \fISpeculationIndirectBranch\fR.\& This targeted normalization breaks trivial anti\-analysis checks (ptracer presence, seccomp/no_new_privs probes, speculative mitigation fingerprints) without altering process state.\& .PP The security impact is twofold: untrusted code loses a low\-cost oracle for environment discovery, reducing the likelihood of logic bombs or capability gating based on sandbox detection, and defenders retain observability because the kernel'\&s real enforcement still applies \-\- only the user\-space view of these select fields is masked.\& For forensic and debugging workflows that explicitly need the unfiltered view, this mitigation can be temporarily relaxed per trace with \fItrace/allow_unsafe_proc_pid_status:1\fR, after which toggling back to \fI:0\fR restores the hardened, stealth\-preserving default.\& .PP .SS Hardened uname(2) .PP As of version 3.\&15.\&1, Syd mediates \fIuname\fR(2) and returns a policy governed \fIutsname\fR that suppresses host identification and constrains kernel disclosure.\& The release string is synthesized to expose only the Linux major and minor as observed on the host or, as of 3.\&36.\&1, as supplied via \fBSYD_ASSUME_KERNEL\fR for controlled feature detection, while the micro component is randomized per Syd run to limit patch level fingerprinting; reads of \fI/proc/version\fR and \fI/proc/sys/kernel/osrelease\fR are hardened to present the same masked view.\& As of 3.\&40.\&0, the nodename, domainname, and version fields are sourced from the options \fIuts/host\fR, \fIuts/domain\fR, and \fIuts/version\fR with defaults \fIlocalhost\fR, \fI(none)\fR, and a startup random value.\& As of 3.\&44.\&2, this restriction may be relaxed at startup with the option \fItrace/allow_unsafe_uname:1\fR.\& Practical effects include disrupting exploit and loader selection that depend on exact release matching, reducing cross host correlation via stable node and domain labels, neutralizing sandbox and VM fingerprinting heuristics that key off \fIuname\fR(2) and the corresponding \fIproc\fR(5) paths, and keeping build and compatibility probes functional by retaining \fImajor.\&minor\fR semantics while allowing explicit control through \fBSYD_ASSUME_KERNEL\fR.\& Workloads that tie licensing, clustering, telemetry, or feature gates to the precise host release or to the original nodename should use the \fIuts\fR options to supply the required identity or opt out with the relaxation flag.\& .PP .SS Restricting fcntl operations and trace/allow_unsafe_fcntl .PP As of version 3.\&54.\&0, Syd restricts potentially unsafe \fIfcntl\fR(2) operations that could be used to bypass \fIlandlock\fR(7) signal scoping protections.\& By default, Syd denies the \fBF_SETOWN\fR, \fBF_SETOWN_EX\fR, and \fBF_SETSIG\fR operations which, when combined with \fBO_ASYNC\fR signal\-driven I/O, can be exploited to deliver arbitrary signals, including \fBSIGKILL\fR, to processes outside the \fIlandlock\fR(7) domain that share the same process group.\& This restriction closes a signal scoping bypass vulnerability in the \fBSIGIO\fR delivery path where a \fIlandlock\fR(7) restricted process could use \fIfcntl\fR(2) with a process group ID to fan signals out to all members of the group, including non\-sandboxed processes.\& The option \fItrace/allow_unsafe_fcntl:1\fR may be set at startup to lift this restriction when such signal\-driven I/O functionality is required.\& .PP .SS Restricting prctl option space and trace/allow_unsafe_prctl .PP Syd confines the scope of permissible \fIprctl\fR(2) operations to enhance security within its sandbox environment.\& By limiting available \fIprctl\fR(2) options to a specific set, including but not limited to \fBPR_SET_PDEATHSIG\fR, \fBPR_GET_DUMPABLE\fR, \fBPR_SET_NO_NEW_PRIVS\fR, and \fBPR_SET_SECCOMP\fR, only the process control operations required for correct sandbox behaviour remain available, reducing exposure to under\-scrutinised \fIprctl\fR(2) calls.\& This restriction is important for preventing security vulnerabilities associated with broader \fIprctl\fR(2) access, such as unauthorised privilege escalations or manipulations of process execution states.\& However, recognizing the need for flexibility in certain scenarios, Syd offers the option to lift these restrictions through the \fItrace/allow_unsafe_prctl:1\fR setting.\& This allows a more permissive \fIprctl\fR(2) environment when required.\& .PP .SS Restricting creation of device special files .PP Since version 3.\&1.\&12, Syd has enhanced its security model by disallowing the creation of device special files through the \fImknod\fR(2) and \fImknodat\fR(2) system calls.\& This decision is rooted in mitigating potential security vulnerabilities, as device special files could be exploited to circumvent established path\-based access controls within the sandbox environment.\& These files, which include character and block devices, can provide direct access to hardware components or enable interactions with kernel modules that could lead to unauthorised actions or data exposure.\& By restricting their creation, Syd significantly reduces the risk of such exploit paths, and only predefined types of files \-\- such as FIFOs, regular files, and sockets \-\- are permissible, aligning with the principle of least privilege by limiting file system operations to those deemed safe within the sandbox'\&s context.\& .PP .SS Sharing Pid namespace with signal protections .PP Since version 3.\&6.\&7, Syd prevents sandboxed processes from sending signals to the Syd process or any of its threads.\& This protection is implemented by hooking and monitoring system calls related to signal operations, including \fIkill\fR(2), \fItkill\fR(2), \fItgkill\fR(2), and \fIpidfd_open\fR(2).\& When a sandboxed process attempts to send a signal to Syd or its threads, these system calls are intercepted, and the operation is denied at the seccomp level with an \fBEACCES\fR ("Permission denied") \fIerrno\fR(3).\& This ensures Syd maintains control over the execution and management of sandboxed processes, safeguarding against interruptions or unauthorised interactions that could compromise the security or stability of the sandbox environment.\& This mechanism is part of Syd'\&s broader strategy to share the same root, private proc, and mount namespaces with the sandboxed process for simple system call emulation.\& By making Syd and its threads immune to signals from sandboxed processes, the integrity and isolation of the sandboxed environment are enhanced, preventing sandboxed processes from disrupting Syd.\& .PP As of version 3.\&35.\&2, a scope\-only \fIlandlock\fR(7) sandbox is installed unconditionally to further isolate the sandbox process from the Syd process.\& Terminal\-generated signals and I/O remain confined to the sandbox'\&s process group and cannot affect Syd or any other processes, further strengthening the sandbox'\&s isolation guarantees alongside the existing \fIseccomp\fR(2) based \fIpid_namespaces\fR(7) protections.\& .PP .SS Process Priority and Resource Management .PP Since version 3.\&8.\&1, Syd has been implementing strategies for smooth host system operation while managing security through its sandboxing mechanism.\& It sets the \fInice\fR(2) value of its system call handler threads to \fI19\fR, which places them at \fIthe lowest priority\fR to minimise CPU starvation for other processes.\& This approach prioritises system stability and fair CPU resource distribution, enabling Syd to handle numerous system calls without degrading host performance.\& .PP Enhancing this strategy, Syd introduced further adjustments in versions 3.\&8.\&6 and 3.\&9.\&7 to address I/O and CPU resource management more comprehensively.\& From version 3.\&8.\&6, it sets the I/O priority of the system call handler threads to \fIidle\fR, preventing I/O operations from monopolising resources and starving other processes.\& Similarly, from version 3.\&9.\&7, it adjusts the CPU scheduling priority of these threads to \fIidle\fR, further guarding against CPU starvation.\& These measures collectively keep Syd'\&s overhead low while sandboxing applications.\& .PP As of version 3.\&30.\&0, changes in process and I/O priorities are inherited by sandbox processes as well and sandbox processes are prevented from making any further changes.\& The option \fItrace/allow_unsafe_nice\fR may be set at startup to prevent Syd from making any changes and allow sandbox processes access to the system calls that are used to make process and I/O priority changes.\& .PP .SS Restricting Resource Limits, Core Dumps, and trace/allow_unsafe_prlimit .PP Since version 3.\&9.\&6, Syd has implemented restrictions on setting process resource limits and generating core dumps for the sandboxed process.\& This prevents the sandboxed process from altering resource limits or producing core dumps.\& Use \fItrace/allow_unsafe_prlimit:1\fR to disable this restriction.\& .PP .SS Enhancing Sandbox Security with Landlock .PP Since version 3.\&0.\&1, Syd uses \fIlandlock\fR(7) to enforce advanced filesystem sandboxing, for sandboxed processes.\& By integrating Landlock, Syd allows even unprivileged processes to create sandboxes with fine\-grained access control over filesystem operations without requiring elevated permissions.\& This mitigates the risk of security breaches stemming from bugs or malicious behaviors in applications by restricting ambient rights, such as global filesystem or network access.\& Landlock operates by allowing processes to self\-impose restrictions on their access to system resources, effectively creating a secure environment that limits their operation to a specified set of files and directories.\& This mechanism is particularly useful for running legacy daemons or applications that require specific environmental setups, as it allows for the precise tailoring of access rights, limiting processes to designated parts of the filesystem.\& For instance, by setting Landlock rules, Syd can confine a process'\&s filesystem interactions to read\-only or read\-write operations on explicitly allowed paths, thus preventing unauthorised access to sensitive areas of the system.\& .PP Furthermore, the inclusion of the Syd process itself within the Landlock\-enforced sandbox adds an additional layer of security.\& This design choice means that even if the Syd process were compromised, the attacker'\&s ability to manipulate the sandboxed environment or access unauthorised resources would be significantly constrained.\& .PP .SS Namespace Isolation in Syd .PP Syd enhances sandbox isolation through namespace use, starting from version 3.\&0.\&2.\& Version 3.\&9.\&10 added a key enhancement by restricting user subnamespace creation, addressing a path sandboxing bypass vulnerability.\& This strategic limitation thwarts sandboxed processes from altering their namespace environment to access restricted filesystem areas.\& Furthermore, since version 3.\&11.\&2, Syd maintains process capabilities within user namespaces, mirroring the \fIunshare\fR(1) command'\&s \-\-keep\-caps behavior, allowing sandboxed processes to retain necessary operational capabilities.\& Additionally, Syd utilises the powerful \fIbind\fR command within the mount namespace to create secure, isolated environments by allowing specific filesystem locations to be remounted with custom attributes, such as \fIro\fR, \fInoexec\fR, \fInosuid\fR, \fInodev\fR, or \fInosymfollow\fR, to further restricting sandboxed processes'\& access to the filesystem.\& .PP Syd also introduces enhanced isolation within the mount namespace by offering options to bind mount temporary directories over /dev/shm and /tmp, giving sandboxed processes private instances of these directories.\& This prevents inter\-process communication through shared memory and mitigates the risk of temporary file\-based attacks, further solidifying the sandbox'\&s defence mechanisms.\& As of version 3.\&35.\&2, an empty mount namespace may be built from scratch starting with the \fIroot:tmpfs\fR command.\& As of version 3.\&11.\&2, Syd mounts the \fIprocfs\fR(5) filesystem privately with the \fIhidepid=2\fR option, enhancing privacy by concealing process information from unauthorised users.\& As of version 3.\&37.\&2, this option is changed to \fIhidepid=4\fR which is new in Linux>=5.\&8 for added hardening.\& As of version 3.\&39.\&0 the option \fIsubset=pid\fR is also supplied to private \fIprocfs\fR(5) mount for added hardening.\& This option is also new in Linux>=5.\&8.\& .PP Syd'\&s \fIcontainer\fR and \fIimmutable\fR profiles exemplify its adaptability, offering from isolated to highly restrictive environments.\& The container profile provides a general\-purpose sandbox, while the immutable profile enforces stricter controls, such as making key system directories read\-only, to prevent tampering.\& This approach illustrates Syd'\&s use of kernel features for sandbox security.\& See \fIsyd\-cat \-pcontainer\fR, and \fIsyd\-cat \-pimmutable\fR to list the rules in these sandboxing profiles.\& .PP As of version 3.\&23.\&0, Syd has further strengthened its security with the introduction of a time namespace, represented by the \fIunshare/time:1\fR option, allows Syd to reset the boot\-time clock so that the \fIuptime\fR(1) command reports container uptime instead of host uptime.\& The creation of namespaces, including mount, UTS, IPC, user, PID, net, cgroup, and time is denied by default to prevent unauthorized namespace manipulation that could undermine path sandboxing security.\& To allow specific namespace types, administrators must explicitly enable them via the \fItrace/allow_unsafe_namespace\fR setting.\& Another restriction to note is that the system calls \fImount\fR(2), \fImount_setattr\fR(2), \fIumount\fR(2), and \fIumount2\fR(2) are denied by default unless \fImount\fR namespace is allowed.\& This change tightens control over process capabilities and isolation, reinforcing the defense mechanisms against potential security breaches.\& .PP .SS Restricting environment and trace/allow_unsafe_env .PP As of version 3.\&11.\&1, Syd has implemented measures to clear unsafe environment variables, such as \fBLD_PRELOAD\fR, enhancing security by preventing the manipulation of dynamic linker behavior by sandboxed processes.\& This action mitigates risks associated with dynamic linker hijacking, where adversaries may load malicious shared libraries to execute unauthorised code, potentially leading to privilege escalation, persistence, or defence evasion.\& Variables like \fBLD_PRELOAD\fR allow specifying additional shared objects to be loaded before any others, which could be exploited to override legitimate functions with malicious ones, thus hijacking the execution flow of a program.\& To accommodate scenarios where developers might need to use these variables for legitimate purposes, Syd allows this security feature to be disabled at startup with \fItrace/allow_unsafe_env:1\fR.\& Refer to the output of the command \fIsyd\-ls env\fR to see the full list of environment variables that Syd clears from the environment of the sandbox process.\& As of version 3.\&39.\&0, Syd additionally clears \fBLANG\fR and the full set of \fBLC_*\fR locale variables (e.\&g.\& \fBLC_CTYPE\fR, \fBLC_TIME\fR, \fBLC_ALL\fR, etc.\&) to avoid leaking locale settings into the sandboxed process \-\- preventing subtle behavior differences or information disclosure that could be abused.\& Similarly, the \fBTZ\fR variable is cleared to prevent leaking timezone settings to the sandbox process.\& The builtin \fIlinux\fR profile masks the file \fI/etc/localtime\fR and the \fIglob\fR(3p) pattern \fI/usr/share/zoneinfo/**\fR with the file \fI/usr/share/zoneinfo/UTC\fR preventing another vector of timezone settings leaking into the environment of the sandbox process.\& For controlled exceptions, the CLI \-e flag provides per\-variable control: \fI\-e var=val\fR injects var=val into the child environment, \fI\-e var\fR removes var from the child environment, and \fI\-e var=\fR explicitly passes through an otherwise unsafe variable; any of these forms may be repeated as needed.\& .PP .SS Managing Linux Capabilities for Enhanced Security .PP Since its 3.\&0.\&17 release, Syd strategically curtails specific Linux \fIcapabilities\fR(7) for sandboxed processes to strengthen security.\& By revoking privileges such as \fBCAP_SYS_ADMIN\fR among others, Syd reduces the risk of privilege escalation and system compromise.\& Even if a sandboxed process is compromised, its ability to perform sensitive operations is severely limited.\& The full list of dropped capabilities, including but not limited to \fBCAP_NET_ADMIN\fR, \fBCAP_SYS_MODULE\fR, and \fBCAP_SYS_RAWIO\fR, limits what a compromised process can do.\& Refer to the output of the command \fIsyd\-ls drop\fR to see the full list of \fIcapabilities\fR(7) that Syd drops at startup.\& .PP Exceptions, introduced in version 3.\&11.\&1, such as retaining \fBCAP_NET_BIND_SERVICE\fR with \fItrace/allow_unsafe_bind:1\fR, \fBCAP_NET_RAW\fR with \fItrace/allow_unsafe_socket:1\fR, \fBCAP_SYSLOG\fR with \fItrace/allow_unsafe_syslog:1\fR and \fBCAP_SYS_TIME\fR with \fItrace/allow_unsafe_time:1\fR, offer a more granular security model.\& These exceptions allow for necessary network, syslog and time adjustments within the sandbox, providing flexibility without significantly compromising security.\& .PP Since version 3.\&12.\&5, Syd allows the user to prevent dropping capabilities at startup using the command \fItrace/allow_unsafe_caps:1\fR.\& This command may be used to construct privileged containers with Syd.\& .PP .SS Path Resolution Restriction For Chdir and Open Calls .PP In Syd version 3.\&15.\&1, a configurable security feature is available to address the risk of directory traversal attacks by restricting the use of \fI.\&.\&\fR components in path arguments for \fIchdir\fR(2), \fIopen\fR(2), \fIopenat\fR(2), \fIopenat2\fR(2), and \fIcreat\fR(2) system calls.\& This feature is off by default, providing broad compatibility and operational flexibility for a range of applications.\& When enabled with the \fItrace/deny_dotdot:1\fR command, Syd strengthens its defence mechanisms against unauthorised directory access, echoing the flexibility seen in FreeBSD'\&s \fIvfs.\&lookup_cap_dotdot\fR sysctl.\& This allows for a targeted approach to filesystem security, where administrators can tailor the sandbox'\&s behavior to match specific security requirements or operational contexts.\& By drawing on the security insights of FreeBSD and HardenedBSD, Syd provides a versatile toolset for managing path traversal security, adaptable to the unique demands of various application environments.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://man.\&freebsd.\&org/cgi/man.\&cgi?\&open(2) .IP \(bu 4 https://cgit.\&freebsd.\&org/src/tree/sys/kern/vfs_lookup.\&c#n351 .PD .PP .SS Enhanced Symbolic Link Validation .PP As of version 3.\&13.\&0, Syd enhances security by enforcing stricter validation on symbolic links within \fI/proc/pid/fd\fR, \fI/proc/pid/cwd\fR, \fI/proc/pid/exe\fR, and \fI/proc/pid/root\fR, addressing potential misuse in container escape scenarios.\& Specifically, Syd returns an \fBEACCES\fR ("Permission denied") \fIerrno\fR(3) for attempts to resolve these symbolic links if they do not pertain to the \fIcurrent process\fR, akin to implementing \fBRESOLVE_NO_MAGICLINKS\fR behavior of the \fIopenat2\fR(2) system call.\& This measure effectively hardens the sandbox against attacks exploiting these links to access resources outside the intended confinement, strengthening the isolation provided by Syd and mitigating common vectors for privilege escalation and sandbox escape.\& As of version 3.\&14.\&5, Syd keeps intercepting path system calls even if sandboxing is off making this protection unconditional.\& .PP .SS Trusted Symbolic Links .PP As of version 3.\&37.\&2, Syd implements a strict symbolic\-link hardening mechanism that intercepts every \fIsymlink\fR(7) resolution within untrusted directories \-\- those marked world\-writable, group\-writable, or carrying the sticky bit \-\- and denies any follow operation, returning \fBEACCES\fR ("Permission denied"); this behavior mirrors GrSecurity'\&s \fBCONFIG_GRKERNSEC_LINK\fR and guarantees that symlink chains in shared or temporary locations cannot be weaponized for TOCTOU or link\-trick exploits.\& Under the default policy, neither direct nor nested symlinks in untrusted paths will be traversed, and the check is applied at the \fIseccomp\fR(2) interception layer prior to any mutable state changes \-\- for an early, fail\-close enforcement.\& Administrators may relax this restriction at startup or runtime by enabling the \fItrace/allow_unsafe_symlinks:1\fR option, which restores legacy symlink behavior for compatibility at the cost of re\-exposing potential link\-based race vulnerabilities.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://wiki.\&gentoo.\&org/wiki/Hardened/Grsecurity2_Quickstart .IP \(bu 4 https://en.\&wikibooks.\&org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Linking_restrictions .IP \(bu 4 https://xorl.\&wordpress.\&com/2010/11/11/grkernsec_link\-linking\-restrictions/ .IP \(bu 4 https://man7.\&org/linux/man\-pages/man5/proc_sys_fs.\&5.\&html .PD .PP .SS Trusted Hardlinks .PP As of version 3.\&37.\&4, Syd introduces a \fITrusted Hardlinks\fR policy to mitigate a class of vulnerabilities stemming from unsafe hardlink creation, particularly those enabling time\-of\-check\-to\-time\-of\-use (TOCTOU) exploitation and privilege escalation in shared filesystem environments.\& This mitigation enforces strict constraints on which files may be linked, based on their visibility, mutability, and privilege\-related attributes.\& A file is permitted as a hardlink target only if it is accessible for both reading and writing by the caller; immutable or opaque targets cannot be used in multi\-stage attack chains.\& Furthermore, the file must be a regular file and must not possess privilege\-escalation enablers such as the set\-user\-ID bit or a combination of set\-group\-ID and group\-executable permissions.\& These checks are performed preemptively and unconditionally during syscall handling to eliminate reliance on ambient filesystem state and to maintain integrity under adversarial conditions.\& Administrators may relax this policy for compatibility purposes using the \fItrace/allow_unsafe_hardlinks:1\fR option, though doing so reintroduces well\-documented link\-based race conditions and undermines the guarantees provided by Syd'\&s secure execution model.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://wiki.\&gentoo.\&org/wiki/Hardened/Grsecurity2_Quickstart .IP \(bu 4 https://en.\&wikibooks.\&org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Linking_restrictions .IP \(bu 4 https://xorl.\&wordpress.\&com/2010/11/11/grkernsec_link\-linking\-restrictions/ .IP \(bu 4 https://man7.\&org/linux/man\-pages/man5/proc_sys_fs.\&5.\&html .PD .PP .SS Trusted File Creation .PP As of version 3.\&37.\&4, Syd enforces a strict \fITrusted File Creation\fR policy designed to mitigate longstanding race\-condition vulnerabilities associated with unprivileged use of \fBO_CREAT\fR in shared or adversarial environments.\& Building upon the Linux kernel'\&s \fIprotected_fifos\fR and \fIprotected_regular\fR sysctls \-\- as well as the stricter semantics of grsecurity'\&s \fBCONFIG_GRKERNSEC_FIFO\fR \-\- this mitigation blocks all \fBO_CREAT\fR operations targeting pre\-existing FIFOs or regular files unless the calling process is the file'\&s owner and the file is neither group\-writable nor world\-writable, irrespective of the parent directory'\&s ownership or permissions.\& Unlike upstream Linux, which allows certain accesses if the file resides in a directory owned by the caller, Syd eliminates this dependency to close subtle privilege boundary gaps and ensure consistent, capability\-centric enforcement even in nested namespace or idmapped mount scenarios.\& This policy guarantees that users cannot preempt or hijack file\-based IPC or partial writes via shared directories, while maintaining usability through precise capability trimming.\& For compatibility with legacy workloads or permissive setups, this restriction may be selectively disabled by setting the \fItrace/allow_unsafe_create:1\fR option, though doing so reintroduces exposure to well\-documented filesystem race attacks.\& .PP As of version 3.\&45.\&0, Syd extends this policy to deny file creation through dangling symbolic links as part of its filesystem race hardening.\& At the \fIopen\fR(2) boundary, the presence of \fBO_CREAT\fR implicitly adds \fBO_NOFOLLOW\fR unless \fBO_EXCL\fR is also specified, so attempts to create or truncate a path whose final component is a symlink will fail rather than resolving the link target.\& This behaviour directly addresses classes of vulnerabilities where privileged components are tricked into creating or modifying files behind attacker\-controlled symlinks, such as CVE\-2021\-28153 in GLib (file creation via dangling symlink replacement) and repeated symlink\- or mount\-race attacks in container runtimes: CVE\-2018\-15664 (docker cp path traversal via symlink and mount races), CVE\-2019\-16884 (runc bind\-mount escape through user\-controlled symlinked host paths), CVE\-2021\-30465 (runc container escape via crafted /proc and mount races), CVE\-2025\-31133 (runc maskedPath abuse to obtain writable procfs bindings), CVE\-2025\-52565 (runc /dev/console bind\-mount symlink races leading to writable procfs targets), and CVE\-2025\-52881 (runc redirected writes bypassing LSM enforcement to arbitrary procfs files).\& By enforcing fail\-closed semantics for all \fBO_CREAT\fR operations that encounter symlinks, Syd blocks these patterns even when higher\-level code assumes symbolic links cannot influence file creation.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://wiki.\&gentoo.\&org/wiki/Hardened/Grsecurity2_Quickstart .IP \(bu 4 https://en.\&wikibooks.\&org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#FIFO_restrictions .IP \(bu 4 https://xorl.\&wordpress.\&com/2010/11/24/grkernsec_fifo\-named\-pipe\-restrictions/ .IP \(bu 4 https://man7.\&org/linux/man\-pages/man5/proc_sys_fs.\&5.\&html .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2021\-28153 .IP \(bu 4 https://github.\&com/advisories/GHSA\-9hh6\-p5c5\-mmmf .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2018\-15664 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2019\-16884 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2021\-30465 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2025\-31133 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2025\-52565 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2025\-52881 .IP \(bu 4 https://www.\&openwall.\&com/lists/oss\-security/2025/11/05/3 .IP \(bu 4 https://github.\&com/opencontainers/runc/security .IP \(bu 4 https://www.\&starlab.\&io/blog/linux\-symbolic\-links\-convenient\-useful\-and\-a\-whole\-lot\-of\-trouble .PD .PP .SS Memory\-Deny\-Write\-Execute Protections .PP Syd version 3.\&14.\&1 implements Memory\-Deny\-Write\-Execute (MDWE) protections, aligning with the \fBPR_SET_MDWE\fR and \fBPR_MDWE_REFUSE_EXEC_GAIN\fR functionality introduced in Linux kernel 6.\&3.\& This prevents creating memory mappings that are \fIsimultaneously writable and executable\fR, closely adhering to the executable space protection mechanisms inspired by PaX project.\& In addition, Syd fortifies these MDWE protections by employing kernel\-level seccomp filters on critical system calls, including \fImmap\fR(2), \fImmap2\fR(2), \fImprotect\fR(2), \fIpkey_mprotect\fR(2), and \fIshmat\fR(2).\& These filters are designed to intercept and restrict operations that could potentially contravene MDWE policies, such as attempts to make non\-executable memory mappings executable or to map shared memory segments with executable permissions.\& By integrating \fBPR_SET_MDWE\fR for preemptive kernel enforcement and utilizing seccomp filters for granular, kernel\-level control over system call execution, Syd provides a defence against memory exploitation.\& This restriction may be relaxed using the \fItrace/allow_unsafe_exec_memory:1\fR sandbox command at startup.\& Even with this restriction relaxed, Syd is going to call \fBPR_SET_MDWE\fR, but it will use the \fBPR_MDWE_NO_INHERIT\fR flag to prevent propagation of the MDWE protection to child processes on \fIfork\fR(2).\& .PP As of version 3.\&25.\&0, Syd kills the process on memory errors rather than denying these system calls with \fBEACCES\fR ("Permission denied").\& This ensures the system administrator gets a notification via \fIdmesg\fR(1), and has a higher chance to react soon to investigate potentially malicious activity.\& In addition, repeated failures are going to trigger SegvGuard.\& .PP As of version 3.\&37.\&0, Syd addresses a fundamental architectural vulnerability in the Linux kernel'\&s Memory\-Deny\-Write\-Execute (MDWE) implementation through proactive file descriptor writability assessment during memory mapping operations.\& This enhancement directly mitigates Linux kernel bug 219227, which exposes a critical W\(haX enforcement bypass wherein adversaries can circumvent memory protection mechanisms by exploiting the semantic disconnect between file\-backed memory mappings and their underlying file descriptors.\& The vulnerability manifests when executable memory regions are mapped with \fBPROT_READ|PROT_EXEC\fR permissions from file descriptors that retain \fIwrite access\fR, enabling post\-mapping modification of executable memory content through standard file I/O operations \-\- effectively transforming read\-only executable mappings into mutable code regions that violate fundamental W\(haX invariants.\& By implementing mandatory writability validation prior to permitting any file\-backed executable memory mapping, Syd enforces strict temporal isolation between memory mapping permissions and underlying file descriptor capabilities, preventing the exploitation of this kernel\-level abstraction leakage that would otherwise enable arbitrary code injection through seemingly benign file operations.\& This defense mechanism operates at the syscall interception layer, preventing code injection through writable file descriptors backing executable mappings.\& This restriction may be relaxed using the \fItrace/allow_unsafe_exec_memory:1\fR sandbox command at startup.\& .PP .SS Advanced Memory Protection Mechanisms .PP Syd version 3.\&15.\&1 adds a seccomp BPF hook to block \fIexecutable+shared\fR memory mappings, targeting a critical vulnerability exploitation pathway.\& As of version 3.\&21.\&3, Syd also blocks \fIexecutable+anonymous\fR memory.\& These updates refine the sandbox'\&s defence against unauthorised memory access and arbitrary code execution by inspecting and filtering system calls, in particular \fImmap\fR(2), and \fImmap2\fR(2), to prevent dangerous memory mapping combinations.\& While this bolstered security measure reduces exposure to buffer overflows and code injections, it acknowledges potential legitimate use cases, such as Just\-In\-Time (JIT) compilation and plugin architectures, that may require exceptions.\& To accommodate necessary exceptions, Syd allows these restrictions to be relaxed with explicit configuration through the \fItrace/allow_unsafe_exec_memory:1\fR command.\& .PP .SS Null Address Mapping Prevention .PP As of version 3.\&15.\&1, Syd introduced an important update inspired by the practices of HardenedBSD, specifically aimed at bolstering our sandbox'\&s defences against null pointer dereference vulnerabilities.\& Following the model set by HardenedBSD, Syd now includes a new security measure that completely prohibits mapping memory at the NULL address via the \fImmap\fR(2) and \fImmap2\fR(2) system calls with the \fBMAP_FIXED\fR and \fBMAP_FIXED_NOREPLACE\fR flags.\& Seccomp filter rules deny these mapping requests when the first argument (addr) is zero, returning \fBEACCES\fR ("Permission denied").\& By preventing allocation at address zero, Syd renders null pointer dereference exploits non\-viable, reducing the null pointer dereference exploits.\& .PP Linux has \fIvm/mmap_min_addr\fR which guards against this already.\& Hence, this acts as a second layer of defense.\& Unlike Syd, Linux allows processes with the \fBCAP_SYS_RAWIO\fR capability to edit/override this value.\& As of version 3.\&37.\&0, Syd caps this value at page size like OpenBSD does for added hardening against such edits.\& .PP As of version 3.\&25.\&0, all addresses lower than the value of \fIvm/mmap_min_addr\fR at Syd startup are included into the seccomp filter the action of the filter is set to kill process rather than deny with EACCES.\& This ensures the system administrator gets a notification via \fIdmesg\fR(1), and has a higher chance to react soon to investigate potentially malicious activity.\& In addition, repeated failures are going to trigger SegvGuard.\& .PP .SS Default Memory Allocator Security Enhancement .PP As of version 3.\&46.\&0, Syd has transitioned to using the GrapheneOS allocator as its default memory allocator.\& This new allocator leverages modern hardware capabilities to provide substantial defenses against common vulnerabilities like heap memory corruption, while reducing the lifetime of sensitive data in memory.\& While the previously used mimalloc with the secure option offered notable security improvements, the GrapheneOS allocator goes further with features like out\-of\-line metadata protection, fine\-grained randomization, and aggressive consistency checks.\& It incorporates advanced techniques such as hardware memory tagging for probabilistic detection of use\-after\-free errors, zero\-on\-free with write\-after\-free detection, and randomized quarantines to mitigate use\-after\-free vulnerabilities.\& The allocator is designed to prevent traditional exploitation methods by introducing high entropy, random base allocations across multiple memory regions, and offers a portable solution being adopted by other security\-focused operating systems like Secureblue.\& It also heavily influenced the next\-generation musl malloc implementation, improving security with minimal memory usage.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://grapheneos.\&org/features#exploit\-mitigations .IP \(bu 4 https://github.\&com/GrapheneOS/hardened_malloc .PD .PP .SS Enhanced Security for Memory File Descriptors .PP In version 3.\&21.\&1, Syd enhanced security by introducing restrictions on memory file descriptors (memfds).\& The \fImemfd_create\fR(2) system call is now sandboxed under Create sandboxing, with the name argument prepended with \fI!\&memfd:\fR before access checks.\& This allows administrators to globally deny access to memfds using rules like \fIdeny/create+!\&memfd:*\fR.\& Additionally, the \fImemfd_secret\fR(2) system call, which requires the \fIsecretmem.\&enable=1\fR boot option and is seldom used, was denied to prevent potential exploits.\& Despite file I/O being restricted on secret memfds, they could be abused by attackers to write payloads and map them as executable, thus bypassing denylisted code execution controls.\& .PP Building on these changes, version 3.\&21.\&2 further fortifies security by making memfds non\-executable by default.\& This is achieved by removing the \fBMFD_EXEC\fR flag and adding the \fBMFD_NOEXEC_SEAL\fR flag to \fImemfd_create\fR(2), preventing memfds from being made executable.\& The \fBMFD_NOEXEC_SEAL\fR flag requires Linux\-6.\&3 or newer to function.\& These measures collectively mitigate the risk of memfd abuse, which can involve executing malicious code within a sandbox, circumventing security mechanisms like Exec, Force, and TPE sandboxing.\& For scenarios where executable or secret memfds are genuinely required, the \fItrace/allow_unsafe_memfd:1\fR option allows for relaxing these restrictions, though it introduces increased security risks.\& By default, these restrictions prevent attackers from using memfds as a vector for unauthorized code execution.\& .PP .SS Path Masking .PP Introduced in version 3.\&16.\&7, the \fIPath Masking\fR feature in Syd enhances security by enabling the obfuscation of file contents without denying access to the file itself.\& This functionality is critical in scenarios where compatibility requires file presence, but not file readability.\& Path Masking works by redirecting any attempt to \fIopen\fR(2) a specified file to the character device \fI/dev/null\fR, effectively presenting an empty file to the sandboxed process.\& The original file metadata remains unchanged, which is necessary for applications that perform operations based on this data.\& Masked files retain their execute permission, so a binary subject to the mask runs normally while its content appears empty to read operations.\& .PP Files subject to masking are selected with \fIglob\fR(3p) patterns.\& By default, Syd masks sensitive paths such as \fI/proc/cmdline\fR to prevent the leakage of potentially sensitive boot parameters, aligning with Syd'\&s security\-first design philosophy.\& Path Masking is a strict security enhancement that minimises the risk of sensitive data exposure while maintaining necessary system functionality and compliance with expected application behaviors.\& .PP .SS Refined Socket System Call Enforcement .PP In Syd version 3.\&16.\&12, we have strengthened the enforcement of socket system call restrictions within the sandbox using kernel\-level BPF filters.\& This enhancement builds upon existing features by embedding these controls directly into the Syd process; even if Syd is compromised, it cannot utilise or manipulate denied socket domains.\& This proactive measure restricts socket creation strictly to permitted domains such as UNIX (\fBAF_UNIX\fR), IPv4 (\fBAF_INET\fR), and IPv6 (\fBAF_INET6\fR), restricting socket creation to permitted domains.\& The \fItrace/allow_unsupp_socket:1\fR option allows for the extension of permissible socket domains, catering to specific needs but potentially increasing exposure risks.\& Additionally, \fItrace/allow_safe_kcapi:1\fR enables access to the Kernel Crypto API, facilitating necessary cryptographic operations directly at the kernel level.\& These enhancements provide a more secure and configurable environment, allowing administrators precise control over network interactions.\& .PP .SS Enhanced Execution Control (EEC) .PP The Enhanced Execution Control (EEC) feature, introduced in Syd version 3.\&17.\&0, hardens the sandbox.\& This feature strategically disables the \fIexecve\fR(2) and \fIexecveat\fR(2) system calls for the Syd process after they are no longer required for executing the sandbox process, thus safeguarding against their potential abuse by a compromised Syd process.\& The prohibition of these critical system calls adds a strong layer to the existing Memory\-Deny\-Write\-Execute (MDWE) protections, intensifying the system'\&s defences against exploit techniques such as code injection or return\-oriented programming (ROP).\& Concurrently, EEC ensures that the \fIptrace\fR(2) syscall is limited following the initial use of the \fBPTRACE_SEIZE\fR call for execution\-related mitigations.\& This action effectively prevents subsequent system trace operations, barring unauthorised process attachments and further securing the system against manipulation.\& Together, these measures enhance Syd'\&s security architecture.\& .PP As of version 3.\&17.\&1, the Enhanced Execution Control (EEC) has been further strengthened by integrating \fImprotect\fR(2) hardening mechanisms specifically targeting the prevention of the \fIret2mprotect\fR exploitation technique.\& This enhancement blocks attempts to alter memory protections to executable (using the \fBPROT_EXEC\fR flag) via the \fImprotect\fR(2) and \fIpkey_mprotect\fR(2) system calls.\& By adding these checks, EEC mitigates the risk associated with compromised Syd processes by enforcing strict memory policies that prevent unauthorised memory from becoming executable, blocking ROP and code injection attacks.\& .PP As of version 3.\&23.\&9, the Enhanced Execution Control (EEC) feature has been expanded to mitigate Sigreturn Oriented Programming (SROP) attacks by denying access to the system calls \fIsigreturn\fR(2) and \fIrt_sigreturn\fR(2) for \fIsyd\fR(1), \fIsyd\-oci\fR(1), and \fIsyd\-tor\fR(1).\& Given the lack of signal handlers, these system calls have no legitimate use.\& By preventing these calls, the system is better protected against SROP attacks, which involve manipulating signal handler frames to control program state.\& For further reading, refer to section 2.\&4.\&4 Sigreturn\-oriented programming in the Low\-Level Software Security book (URL: https://llsoftsec.\&github.\&io/llsoftsecbook/#sigreturn\-oriented\-programming).\& SROP (Bosman and Bos 2014) is a special case of ROP where the attacker creates a fake signal handler frame and calls \fIsigreturn\fR(2), a system call on many UNIX\-type systems normally called upon return from a signal handler, which restores the state of the process based on the state saved on the signal handler'\&s stack by the kernel previously.\& The ability to fake a signal handler frame and call sigreturn gives an attacker a simple way to control the state of the program.\& .PP .SS Enhanced execve and execveat Syscall Validation .PP As of version 3.\&24.\&2, security enhancements to \fIexecve\fR(2) and \fIexecveat\fR(2) syscalls have been introduced to thwart simple Return\-Oriented Programming (ROP) attacks.\& Per the Linux \fIexecve\fR(2) manpage: "On Linux, argv and envp can be specified as NULL.\& In both cases, this has the same effect as specifying the argument as a pointer to a list containing a single null pointer.\& \fIDo not take advantage of this nonstandard and nonportable misfeature!\&\fR On many other UNIX systems, specifying argv as NULL will result in an error (\fBEFAULT\fR: "Bad address").\& Some other UNIX systems treat the envp==NULL case the same as Linux.\&" Based on this guidance, Syd now rejects \fIexecve\fR(2) and \fIexecveat\fR(2) with \fBEFAULT\fR when one of the pathname, argv and envp arguments is NULL.\& This mitigation targets basic ROP chains where NULL pointers are used as placeholders to bypass argument validation checks, a common tactic in exploiting buffer overflow vulnerabilities.\& For example, a typical ROP chain trying to execute \fIexecve\fR(2) with argv and envp set to NULL would be intercepted and denied under these rules: .PP .nf .RS 4 0x0000: 0x40ee2b pop rdx; ret 0x0008: 0x0 [arg2] rdx = 0 0x0010: 0x402885 pop rsi; ret 0x0018: 0x0 [arg1] rsi = 0 0x0020: 0x4013cc pop rdi; ret 0x0028: 0x460000 [arg0] rdi = 4587520 0x0030: 0x438780 execve .fi .RE .PP An attacker might circumvent this mitigation by arranging that none of the critical syscall arguments are NULL.\& This requires a more complex ROP chain, potentially increasing the complexity of the exploit and reducing the number of vulnerable targets.\& This focused security measure enhances system resilience against simple ROP exploits while maintaining compliance with POSIX standards, promoting robustness and cross\-platform security.\& .PP As of version 3.\&25.\&0, Syd terminates the process upon entering these system calls with NULL arguments rather than denying them with \fBEFAULT\fR.\& This ensures the system administrator gets a notification via kernel audit log, ie.\& \fIdmesg\fR(1), about potentially malicious activity.\& In addition, repeated failures are going to trigger SegvGuard.\& .PP We have verified the same issue is also present on HardenedBSD and notified upstream: .PD 0 .IP \(bu 4 Issue: https://git.\&hardenedbsd.\&org/hardenedbsd/HardenedBSD/\-/issues/106 .IP \(bu 4 Fix: https://git.\&hardenedbsd.\&org/hardenedbsd/HardenedBSD/\-/commit/cd93be7afbcfd134b45b52961fc9c6907984c85f .PD .PP .SS Securebits and Kernel\-Assisted Executability .PP As of version 3.\&41.\&0, Syd initializes the per\-thread securebits in a kernel\-cooperative manner: on Linux 6.\&14 and newer, which provide the executability\-check interface (\fIexecveat\fR(2) with \fBAT_EXECVE_CHECK\fR) and the corresponding interpreter self\-restriction securebits, Syd first attempts to install a strict securebits configuration (with locks) that hardens capability semantics and execution constraints; if the kernel refuses changes due to privilege (e.\&g.\&, \fBCAP_SETPCAP\fR not present) and returns \fBEPERM\fR ("Operation not permitted"), Syd deterministically degrades to the unprivileged, interpreter\-facing policy only, thereby enabling and locking a file\-descriptor\-based executability check and prohibiting interactive snippet execution unless the same kernel probe passes, while on older kernels the secure\-exec policy setup is treated as a no\-op and startup proceeds without altering executability behavior; this initialization is inherited across forks and execs (with the kernel rule that the \fIkeep capabilities\fR base flag is cleared on exec), is orthogonal to the \fIno_new_privs\fR attribute, and is designed to be monotonic and predictable under mixed\-privilege and mixed\-kernel deployments: unsupported features are ignored, permission failures do not abort startup, and the resulting state is the strongest policy the kernel will accept; Users may opt out of these defaults per deployment by setting \fItrace/allow_unsafe_exec_script:1\fR to skip the script/file vetting policy, \fItrace/allow_unsafe_exec_interactive:1\fR to allow interactive interpreter inputs again, \fItrace/allow_unsafe_exec_null:1\fR to permit legacy exec with NULL argv/envp as described in the previous subsection, or \fItrace/allow_unsafe_cap_fixup:1\fR to preserve traditional UID/capability\-fixup semantics.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://docs.\&kernel.\&org/userspace\-api/check_exec.\&html .IP \(bu 4 https://man7.\&org/linux/man\-pages/man2/execveat.\&2.\&html .IP \(bu 4 https://man7.\&org/linux/man\-pages/man7/capabilities.\&7.\&html .IP \(bu 4 https://man7.\&org/linux/man\-pages/man2/prctl.\&2.\&html .IP \(bu 4 https://man7.\&org/linux/man\-pages/man2/pr_set_securebits.\&2const.\&html .IP \(bu 4 https://www.\&man7.\&org/linux/man\-pages/man2/PR_SET_KEEPCAPS.\&2const.\&html .PD .PP .SS Enhanced Path Integrity Measures .PP As of version 3.\&17.\&4, Syd rejects file system paths containing control characters at the sandbox access\-check boundary.\& Any such path that reaches the logging subsystem is sanitized before output, preventing terminal escape\-sequence injection and log\-poisoning attacks.\& Together, these checks close a class of input\-handling vulnerabilities at the path\-processing layer.\& .PP As of version 3.\&18.\&6, this restriction can be relaxed by using the setting \fItrace/allow_unsafe_filename:1\fR.\& This setting may be toggled from within the sandbox during runtime prior to locking the sandbox.\& .PP As of version 3.\&28.\&0, Syd has enhanced its path integrity measures by incorporating an implementation based on David A.\& Wheeler'\&s Safename Linux Security Module (LSM) patches.\& This update not only prevents the creation of filenames containing potentially harmful characters but also hides existing files with such names.\& Invalid filenames are now denied with an \fBEILSEQ\fR ("Illegal byte sequence") \fIerrno\fR(3) when necessary.\& In alignment with Wheeler'\&s recommendations on restricting dangerous filenames, the validation now enforces stricter rules: .PP .PD 0 .IP \(bu 4 \fBControl Characters\fR: Filenames containing control characters (bytes 0x00–0x1F and 0x7F) are denied.\& .IP \(bu 4 \fBUTF\-8 Encoding\fR: Filenames must be valid UTF\-8 sequences.\& .IP \(bu 4 \fBForbidden Characters\fR: The following characters are disallowed in filenames as they may interfere with shell operations or be misinterpreted by programs: *, ?\&, [, ], ", <, >, |, (, ), &, '\&, !\&, \e, ;, $, and `.\& .IP \(bu 4 \fBLeading Characters\fR: Filenames cannot start with a space ( ), dash (\-), or tilde (\(ti).\& .IP \(bu 4 \fBTrailing Characters\fR: Filenames cannot end with a space ( ).\& .PD .PP As of version 3.\&37.\&9, space checks have been extended to cover UTF\-8 whitespace, thanks to an idea by Jacob Bachmeyer, see https://seclists.\&org/oss\-sec/2025/q3/123 for more information.\& .PP As of version 3.\&38.\&0, the characters :, {, and } have been removed from the forbidden set to improve usability and reduce false positives.\& : is used commonly across /dev and /proc.\& {} are used by \fIfirefox\fR(1) for filenames under the profile directory.\& .PP As of version 3.\&48.\&0, deny \fIerrno\fR(3) has been changed from \fBEINVAL\fR ("Invalid argument") to \fBEILSEQ\fR ("Illegal byte sequence") to match ZFS behaviour.\& .PP As of version 3.\&49.\&0, the values of \fIuts/host\fR and \fIuts/domain\fR must be safe filenames for added hardening.\& .PP Both new and existing filenames are validated against these rules.\& For more information, refer to the following links: .PP .PD 0 .IP \(bu 4 https://dwheeler.\&com/essays/fixing\-unix\-linux\-filenames.\&html .IP \(bu 4 https://lwn.\&net/Articles/686021/ .IP \(bu 4 https://lwn.\&net/Articles/686789/ .IP \(bu 4 https://lwn.\&net/Articles/686792/ .PD .PP .SS Device Sidechannel Mitigations .PP As of Syd version 3.\&21.\&0, Syd'\&s device sidechannel mitigations align closely with \fBGRKERNSEC_DEVICE_SIDECHANNEL\fR in Grsecurity, aiming to prevent timing analyses on block or character devices via \fIstat\fR(2) or \fIinotify\fR(7)/\fIfanotify\fR(7).\& For stat\-family system calls, Syd, like Grsecurity, matches the last access and modification times to the creation time for devices, thwarting unprivileged user timing attacks.\& Instead of dropping events, Syd strips access and modify \fIfanotify\fR(7)/\fIinotify\fR(7) flags at syscall entry, preventing unsafe \fIfanotify\fR(7)/\fIinotify\fR(7) event generation.\& This ensures unauthorized users cannot determine sensitive information, such as the length of the administrator password.\& Syd dynamically strips these flags to block sidechannel attacks without breaking functionality.\& As of version 3.\&40.\&0, these mitigations can be disabled using the options \fItrace/allow_unsafe_stat_bdev\fR, \fItrace/allow_unsafe_stat_cdev\fR, \fItrace/allow_unsafe_notify_bdev\fR, \fItrace/allow_unsafe_notify_cdev\fR respectively.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://web.\&archive.\&org/web/20130111093624/http://vladz.\&devzero.\&fr/013_ptmx\-timing.\&php .IP \(bu 4 https://en.\&wikibooks.\&org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Eliminate_stat/notify\-based_device_sidechannels .PD .PP .SS Restricting CPU Emulation System Calls .PP As of version 3.\&22.\&1, Syd denies the \fImodify_ldt\fR(2), \fIsubpage_prot\fR(2), \fIswitch_endian\fR(2), \fIvm86\fR(2), and \fIvm86old\fR(2) system calls by default, which are associated with CPU emulation functionalities.\& These calls can only be allowed if the \fItrace/allow_unsafe_cpu\fR option is explicitly set.\& This restriction helps mitigate potential vulnerabilities and unauthorized access that can arise from modifying CPU state or memory protections.\& .PP .SS Kernel Keyring Access Restriction .PP To enhance system security, access to the kernel'\&s key management facility via the \fIadd_key\fR(2), \fIkeyctl\fR(2), and \fIrequest_key\fR(2) system calls is restricted by default as of version 3.\&22.\&1.\& These calls are important for managing keys within the kernel, enabling operations such as adding keys, manipulating keyrings, and requesting keys.\& The restriction aims to prevent unauthorized or potentially harmful modifications to keyrings, permitting only safe, controlled access.\& However, administrators can relax this restriction by enabling the "trace/allow_unsafe_keyring" option, allowing these system calls to be executed when necessary for legitimate purposes.\& .PP Because of this restriction, Syd is not affected by CVE\-2024\-42318 although we use Landlock.\& See here for more information: https://www.\&openwall.\&com/lists/oss\-security/2024/08/17/2 .PP .SS Restricting Memory Protection Keys System Calls .PP As of version 3.\&22.\&1, Syd denies the \fIpkey_alloc\fR(2), \fIpkey_free\fR(2), and \fIpkey_mprotect\fR(2) system calls by default, preventing sandboxed processes from changing memory access permissions via memory protection keys.\& Use \fItrace/allow_unsafe_pkey\fR to allow these calls.\& .PP .SS Restricting vmsplice System Call .PP As of version 3.\&23.\&5, Syd disables the \fIvmsplice\fR(2) system call by default to enhance security.\& This syscall, identified as a potential vector for memory corruption and privilege escalation, poses significant risks in sandboxed environments.\& By default, disabling \fIvmsplice\fR(2) removes this risk.\& Podman applies the same restriction.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://lore.\&kernel.\&org/linux\-mm/X+PoXCizo392PBX7@redhat.\&com/ .IP \(bu 4 https://lwn.\&net/Articles/268783/ .PD .PP As of version 3.\&41.\&3, \fIvmsplice\fR(2) call may be permitted at startup using the \fItrace/allow_unsafe_vmsplice:1\fR option.\& .PP .SS Enforcing Position\-Independent Executables (PIE) .PP As of version 3.\&23.\&9, Syd mandates that all executables must be Position\-Independent Executables (PIE) to use Address Space Layout Randomization (ASLR).\& PIE allows executables to be loaded at random memory addresses, making it harder for attackers to predict the location of executable code.\& This randomization thwarts various types of exploits, such as buffer overflow attacks, which rely on predictable memory addresses to execute malicious code.\& To accommodate scenarios where PIE is not feasible, users can relax this restriction using the \fItrace/allow_unsafe_exec_nopie:1\fR option.\& This maintains compatibility while enforcing a secure default.\& .PP .SS Enforcing Non\-Executable Stack .PP As of version 3.\&23.\&16, Syd mandates that all executables must have a non\-executable stack to enhance security.\& A non\-executable stack helps to prevent various types of exploits, such as stack\-based buffer overflow attacks, by making it more difficult for attackers to execute malicious code from the stack.\& This complements PIE enforcement.\& To accommodate scenarios where a non\-executable stack is not feasible, administrators can relax this restriction using the \fItrace/allow_unsafe_exec_stack:1\fR option.\& This maintains compatibility while enforcing a secure default.\& .PP As of version 3.\&23.\&19, Syd enforces this restriction at \fImmap\fR(2) boundary as well so it is no longer possible to \fIdlopen\fR(3) a library with executable stack to change the stack permissions of the process to executable.\& This is useful in mitigating attacks such as CVE\-2023\-38408.\& Refer to the URL https://www.\&qualys.\&com/2023/07/19/cve\-2023\-38408/rce\-openssh\-forwarded\-ssh\-agent.\&txt for more information.\& As of version 3.\&25.\&0, Syd kills the process in this case rather than denying the system call to be consistent with other memory related seccomp filters.\& This ensures the system administrator gets a notification via the audit log, and has a higher chance to react soon to investigate potentially malicious activity.\& In addition, repeated failures are going to trigger SegvGuard.\& .PP .SS Mitigation against Page Cache Attacks .PP As of version 3.\&25.\&0, Syd denies the \fImincore\fR(2) system call by default, which is typically not needed during normal run and has been successfully (ab)used for page cache attacks: https://arxiv.\&org/pdf/1901.\&01161 .PP To quote the \fBCountermeasures\fR section of the article: .PP Our side\-channel attack targets the operating system page cache via operating system interfaces and behavior.\& Hence, it clearly can be mitigated by modifying the operating system implementation.\& \fBPrivileged Access.\&\fR The \fIQueryWorkingSetEx\fR and \fImincore\fR system calls are the core of our side\-channel attack.\& Requiring a higher privilege level for these system calls stops our attack.\& The downside of restricting access to these system calls is that existing programs which currently make use of these system calls might break.\& Hence, we analyzed how frequently \fImincore\fR is called by any of the software running on a typical Linux installation.\& We used the Linux \fIperf\fR tools to measure over a 5 hour period whenever the \fIsys_enter_mincore\fR system call is called by any application.\& During these 5 hours a user performed regular operations on the system, i.\&e.\&, running various work\-related tools like Libre Office, gcc, Clion, Thunderbird, Firefox, Nautilus, and Evince, but also non\-work\-related tools like Spotify.\& The system was also running regular background tasks during this time frame.\& Surprisingly, the \fIsys_enter_mincore\fR system call was not called a single time.\& This indicates that making the \fImincore\fR system call privileged is feasible and would mitigate our attack at a very low implementation cost.\& .PP As of version 3.\&35.\&2, the new system call \fIcachestat\fR(2) is also denied for the same reason as it is a scalable version of the \fImincore\fR(2) system call.\& Again, as of version 3.\&35.\&2, the option \fItrace/allow_unsafe_page_cache\fR has been added to relax this restriction at startup.\& This may be needed to make direct rendering work with Firefox family browsers.\& .PP .SS Enforcing AT_SECURE and UID/GID Verification .PP As of version 3.\&27.\&0, Syd enhances security by enforcing the \fBAT_SECURE\fR flag in the auxiliary vector of executables at \fIptrace\fR(2) boundary upon receiving the \fBPTRACE_EVENT_EXEC\fR event to enforce secure\-execution mode.\& This event happens after the executable binary is loaded into memory but before it starts executing.\& This enforcement ensures that the C library operates in a secure mode, disabling unsafe behaviors like loading untrusted dynamic libraries or accessing insecure environment variables.\& Additionally, Syd performs strict UID and GID verification to confirm that the process'\&s user and group IDs match the expected values, preventing unauthorized privilege escalation.\& If the verification fails or the \fBAT_SECURE\fR flag cannot be set, Syd terminates the process to prevent potential security breaches.\& This mitigation can be relaxed at startup with the option \fItrace/allow_unsafe_exec_libc:1\fR, though doing so is not recommended as it reduces the effectiveness of the sandbox.\& Secure\-execution mode is also enforced by \fIapparmor\fR(7) and it may also be enforced by other LSMs and eBPF.\& You may find some implications of the secure\-execution mode below.\& Refer to the \fIld.\&so\fR(8) and \fIgetauxval\fR(3) manual pages for implications of secure\-execution mode on your system.\& .PP glibc dynamic linker strips/ignores dangerous LD_* variables in secure\-execution mode, including \fBLD_LIBRARY_PATH\fR, \fBLD_PRELOAD\fR (only standard dirs; paths with slashes ignored), \fBLD_AUDIT\fR, \fBLD_DEBUG\fR, \fBLD_DEBUG_OUTPUT\fR, \fBLD_DYNAMIC_WEAK\fR, \fBLD_HWCAP_MASK\fR, \fBLD_ORIGIN_PATH\fR, \fBLD_PROFILE\fR, \fBLD_SHOW_AUXV\fR, \fBLD_USE_LOAD_BIAS\fR, etc.\& glibc also treats some non\-LD_* variables as unsafe in secure\-execution mode: \fBGCONV_PATH\fR, \fBGETCONF_DIR\fR, \fBHOSTALIASES\fR, \fBLOCALDOMAIN\fR, \fBLOCPATH\fR, \fBMALLOC_TRACE\fR, \fBNIS_PATH\fR, \fBNLSPATH\fR, \fBRESOLV_HOST_CONF\fR, \fBRES_OPTIONS\fR, \fBTMPDIR\fR, \fBTZDIR\fR (stripped/ignored).\& Refer to the \fIld.\&so\fR(8) manual page for more information.\& As of version 3.\&11.\&1, Syd also strips unsafe environment variables before executing the sandbox process by default and this can be disabled altogether with \fItrace/allow_unsafe_env:1\fR or unsafe environment variables can be selectively allowed using the \fI\-e var=\fR format, e.\&g.\& \fI\-eLD_PRELOAD=\fR Refer to the \fBRestricting environment and trace/allow_unsafe_env\fR section for more information.\& .PP glibc'\&s \fBLD_PREFER_MAP_32BIT_EXEC\fR is always disabled in secure\-execution mode (mitigates ASLR\-weakening).\& Historical bugs (e.\&g.\&, CVE\-2019\-19126) fixed cases where this wasn'\&t ignored after a security transition.\& Refer to the \fIld.\&so\fR(8) manual page and the following links for more information: .PP .PD 0 .IP \(bu 4 https://lists.\&gnu.\&org/archive/html/info\-gnu/2020\-02/msg00001.\&html .IP \(bu 4 https://alas.\&aws.\&amazon.\&com/ALAS\-2021\-1511.\&html .PD .PP glibc \fBGLIBC_TUNABLES\fR environment variable handling under \fBAT_SECURE\fR: tunables carry security levels (\fBSXID_ERASE\fR, \fBSXID_IGNORE\fR) so they'\&re ignored/erased for secure\-execution mode; post\-CVE\-2023\-4911 hardening ensures secure\-execution mode invocations with hostile GLIBC_TUNABLES are blocked/terminated.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://lwn.\&net/Articles/947736/ .IP \(bu 4 https://access.\&redhat.\&com/security/cve/cve\-2023\-4911 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2023\-4911 .PD .PP glibc \fIsecure_getenv\fR(3) returns NULL when \fBAT_SECURE\fR is set; any glibc subsystem that uses \fIsecure_getenv\fR(3) (e.\&g.\&, timezone, locale, iconv, resolver paths) will ignore environment overrides in secure\-execution mode.\& Similarly calling \fIgetauxval\fR(3) with the flag \fBAT_SECURE\fR returns true in secure\-execution mode.\& .PP musl libc honors \fBAT_SECURE\fR and likewise ignores preload/library/locale environment knobs in secure\-execution mode; examples include \fBLD_PRELOAD\fR, \fBLD_LIBRARY_PATH\fR, and \fBMUSL_LOCPATH\fR.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://musl.\&libc.\&org/manual.\&html .IP \(bu 4 https://wiki.\&musl\-libc.\&org/environment\-variables .PD .PP Because the Linux host kernel is not aware of Syd setting the \fBAT_SECURE\fR bit, the \fIproc_pid_auxv\fR(5) file will report the bit as unset.\& On the contrary, when verbose logging is turned on using the \fIlog/verbose:1\fR option, Syd will correctly log this bit as set after parsing the \fIproc_pid_auxv\fR(5) file of the sandbox process.\& .PP .SS Process Name Modification Restriction .PP As of version 3.\&28.\&0, Syd introduces a critical security enhancement that logs and denies attempts to set a process'\&s name using the \fBPR_SET_NAME\fR \fIprctl\fR(2) request.\& This mitigation is necessary as it prevents malicious software from disguising itself under legitimate process names such as \fIapache\fR or other system daemons, thereby thwarting attempts to evade detection and maintain stealth within the system.\& By default, any invocation of \fBPR_SET_NAME\fR within the sandboxed environment is intercepted; the action is logged for audit purposes if verbose logging is on, and the system call is denied with success return, essentially turning it into a no\-op.\& If there is a legitimate need to permit process name changes within the sandbox, this restriction can be overridden by enabling the \fItrace/allow_unsafe_prctl:1\fR option, which allows \fBPR_SET_NAME\fR requests to succeed without logging.\& .PP .SS Speculative Execution Mitigation .PP As of version 3.\&30.\&0, Syd integrates a mitigation mechanism using the \fIprctl\fR(2) system call to enforce speculative execution controls to mitigate advanced speculative execution vulnerabilities, such as \fBSpectre\fR and related side\-channel attacks.\& Upon initialization, Syd attempts to apply the \fBPR_SPEC_FORCE_DISABLE\fR setting for critical speculative execution features \-\- namely \fBPR_SPEC_STORE_BYPASS\fR, \fBPR_SPEC_INDIRECT_BRANCH\fR, and \fBPR_SPEC_L1D_FLUSH\fR \-\- thereby irrevocably disabling these CPU\-level misfeatures when permissible.\& This ensures that, where supported by the underlying kernel and hardware, speculative execution is constrained to eliminate potential avenues for data leakage and privilege escalation across privilege domains.\& The mitigation is conditionally enforced based on the availability of per\-task control via \fIprctl\fR(2), and any inability to apply these settings due to architectural constraints or insufficient permissions results in logged informational messages without disrupting sandbox operations.\& Furthermore, administrators retain the capability to override this security policy through the \fItrace/allow_unsafe_exec_speculative:1\fR configuration option, permitting flexibility in environments where speculative execution controls may need to be relaxed for compatibility or performance reasons.\& Refer to the links below for more information: .PP .PD 0 .IP \(bu 4 https://docs.\&kernel.\&org/admin\-guide/hw\-vuln/spectre.\&html .IP \(bu 4 https://docs.\&kernel.\&org/userspace\-api/spec_ctrl.\&html .PD .PP .SS Cryptographically Randomized Sysinfo .PP Since Syd 3.\&28.\&0, the \fIsysinfo\fR(2) system call has been cryptographically obfuscated by applying high\-entropy offsets to memory fields (e.\&g.\&, total RAM, free RAM) and constraining them to plausible power\-of\-two boundaries, frustrating trivial attempts at system fingerprinting.\& Specifically, uptime and idle counters each incorporate a distinct offset up to 0xFF_FFFF (\(ti194 days) unless \fIunshare/time:1\fR when time starts from zero, while load averages are randomized in fixed\-point format and clamped to realistic upper limits.\& Administrators seeking genuine system metrics may disable these transformations via \fItrace/allow_unsafe_sysinfo:1\fR, albeit at the cost of enabling straightforward correlation and potential data leakage.\& .PP As of Syd 3.\&58.\&1, when Memory Sandboxing is enabled with a non\-zero \fImem/max\fR limit, memory fields are no longer randomized.\& \fItotalram\fR reports configured limit, and \fIfreeram\fR reports remaining size based on current memory usage of the calling process.\& \fIbufferram\fR and \fIsharedram\fR are reported as zero in this case.\& .PP .SS Memory Sealing of Sandbox Policy Regions on Lock .PP Beginning with version 3.\&33.\&1, Syd applies Linux'\&s \fImseal\fR(2) syscall to enforce immutability of policy\-critical memory regions at the moment the sandbox is locked with \fIlock:on\fR.\& At this point, all mutable structures influencing access control \-\- such as ACLs, action filters, and syscall mediation rules \-\- are sealed at the virtual memory level.\& Unlike traditional permission schemes (e.\&g.\&, W\(haX or \fImprotect\fR(2)), \fImseal\fR(2) protects against structural manipulation of memory mappings themselves, preventing \fImmap\fR(2), \fImremap\fR(2), \fImprotect\fR(2), \fImunmap\fR(2), and destructive \fImadvise\fR(2) operations from altering sealed VMAs.\& This eliminates attacker primitives that rely on reclaiming, remapping, or changing permissions on enforcement data, thereby closing off advanced data\-oriented exploitation paths such as policy subversion through remapped ACLs or revocation of constraints via memory permission resets.\& Syd permits legitimate late\-stage policy configuration during startup and defers sealing until \fIlock:on\fR is called, after which mutation of enforcement state is structurally frozen.\& The process is one\-way and idempotent; sealed memory cannot be unsealed, providing strong guarantees once lockdown is complete.\& For diagnostic or non\-hardened environments, this mechanism may be disabled explicitly via the startup toggle \fItrace/allow_unsafe_nomseal:1\fR, which should only be used with full awareness of the resulting relaxation in protection.\& When enabled, sealing substantially raises the integrity threshold of the sandbox; post\-lock policy enforcement is immune to both direct and indirect memory\-level tampering.\& .PP .SS Force Close\-on\-Exec File Descriptors .PP The \fItrace/force_cloexec\fR option, introduced in Syd version 3.\&35.\&2, ensures that all \fIcreat\fR(2), \fIopen\fR(2), \fIopenat\fR(2), \fIopenat2\fR(2), \fImemfd_create\fR(2), \fIsocket\fR(2), \fIaccept\fR(2), and \fIaccept4\fR(2) system calls made by the sandbox process include the \fBO_CLOEXEC\fR flag.\& This feature can be toggled at runtime via Syd'\&s virtual stat API, enabling dynamic adjustment of confinement levels as needed.\& The \fBO_CLOEXEC\fR flag, when set on file descriptors, ensures they are automatically closed when executing a new program via \fIexecve\fR(2) or similar system calls.\& This automatic closure of file descriptors is critical for enhancing security and safety, as it prevents file descriptors from being unintentionally inherited by newly executed programs, which could otherwise lead to unauthorized access to sensitive files or resources.\& By enforcing the \fBO_CLOEXEC\fR flag across all \fIopen\fR(2) calls, Syd mitigates the risk of file descriptor leakage, effectively isolating the sandboxed environment and providing a clean execution context for newly spawned processes.\& .PP .SS Force Randomized File Descriptors .PP The \fItrace/force_rand_fd\fR option, introduced in Syd version 3.\&35.\&2, ensures that all \fIcreat\fR(2), \fIopen\fR(2), \fIopenat\fR(2), \fIopenat2\fR(2), \fImemfd_create\fR(2), \fIsocket\fR(2), \fIaccept\fR(2), and \fIaccept4\fR(2) system calls made by the sandbox process allocate file descriptors at random available slots rather than the lowest\-numbered one.\& When this feature is enabled, Syd specifies a random available slot (rather than the lowest\-numbered one) to the \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR operation which is used to install a file descriptor to the sandbox process.\& Randomizing file descriptor numbers makes it significantly harder for an attacker to predict or deliberately reuse critical descriptors, thereby raising the bar against file\-descriptor reuse and collision attacks.\& Note that enabling this may break programs which rely on the POSIX guarantee that \fIopen\fR(2) returns the lowest available descriptor.\& This behavior can be toggled at runtime via Syd'\&s virtual stat API, allowing operators to enable or disable descriptor randomization without restarting or recompiling the sandboxed process.\& We'\&re also cooperating with the HardenedBSD project to implement a similar feature in the BSD kernel.\& Refer to the following link for more information: https://git.\&hardenedbsd.\&org/hardenedbsd/HardenedBSD/\-/issues/117 .PP .SS Syscall Argument Cookies .PP To further harden the \fIseccomp\fR(2) boundary, as of version 3.\&35.\&2 Syd embeds cryptographically\-strong, per\-instance "cookies" into unused architecture\-defined syscall argument slots (e.\&g.\&, the 5th and 6th arguments of \fIopenat2\fR(2)).\& These cookies are generated at startup via the OS random number generator using \fIgetrandom\fR(2), and are checked in the BPF filter so that only calls bearing the correct 32\- or 64\-bit values will be allowed.\& By requiring this unpredictable token, Syd raises the bar against arbitrary or forged syscalls: Attackers must first discover or leak the randomized cookies despite Address Space Layout Randomization (ASLR) before mounting a successful path or network operation.\& This approach effectively transforms unused syscall parameters into an application\-level authorization mechanism, preventing trivial reuse of legitimate code paths and mitigating time\-of\-check\-to\-time\-of\-use (TOCTTOU) and ROP payloads that rely on guessing or omitting optional arguments.\& In combination with absolute path enforcement and the denial of relative descriptors (e.\&g.\& AT_FDCWD), syscall argument cookies form a lightweight, zero\-cost integrity check that elevates syscall hardening without kernel modifications or performance penalties.\& As an example, here is how the filters look in pseudo filter code for the system calls \fIopenat2\fR(2) and \fIsocket\fR(2) on x86\-64.\& \fIopenat2\fR(2) uses two unused arguments as cookies and \fIsocket\fR(2) uses three.\& In addition, \fIopenat2\fR(2) denies negative file descriptor arguments such as \fBAT_FDCWD\fR: .PP .nf .RS 4 # filter for syscall "openat2" (437) [priority: 65528] if ($syscall == 437) if ($a0\&.hi32 > 0) else if ($a0\&.hi32 == 0) if ($a0\&.lo32 > 2147483647) else if ($a4\&.hi32 == 2047080271) if ($a4\&.lo32 == 419766579) if ($a5\&.hi32 == 2863373132) if ($a5\&.lo32 == 396738706) action ALLOW; else if ($a4\&.hi32 == 2047080271) if ($a4\&.lo32 == 419766579) if ($a5\&.hi32 == 2863373132) if ($a5\&.lo32 == 396738706) action ALLOW; # filter for syscall "socket" (41) [priority: 65529] if ($syscall == 41) if ($a3\&.hi32 == 3378530982) if ($a3\&.lo32 == 4160747949) if ($a4\&.hi32 == 2899982880) if ($a4\&.lo32 == 990920938) if ($a5\&.hi32 == 3611760485) if ($a5\&.lo32 == 1163305215) action ALLOW; .fi .RE .PP Another example is how the critical \fIseccomp\fR(2) notify \fIioctl\fR(2) requests \fBSECCOMP_IOCTL_NOTIF_SEND\fR and \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR are confined for the Syd emulator threads.\& \fBSECCOMP_IOCTL_NOTIF_SEND\fR is critical because it allows pass\-through of system calls to the host Linux kernel with the \fBSECCOMP_USER_NOTIF_FLAG_CONTINUE\fR flag in the \fIseccomp\fR(2) response data structure.\& This flag must be used with utmost care and in the hands of an attacker it can be a tool for further exploitation.\& \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR is critical because it allows file descriptor transfer between the Syd process and the sandbox process and in the hands of an attacker it can be a tool for file descriptor stealing.\& As part of this mitigation three syscall cookies are enforced for \fIioctl\fR(2) system calls with the \fBSECCOMP_IOCTL_NOTIF_SEND\fR and \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR requests.\& Coupled with the startup randomization of the \fIseccomp\fR(2) notify file descriptor, this mitigation raises the bar for an attacker trying to call arbitrary or forged syscalls within a compromised Syd emulator thread.\& Excerpt from the seccomp filter in pseudo filter code is given below: .PP .nf .RS 4 # Syd monitor rules with seccomp fd 626 # # pseudo filter code start # # filter for arch x86_64 (3221225534) \&.\&.\&. # filter for syscall "ioctl" (16) [priority: 65497] if ($syscall == 16) if ($a0\&.hi32 == 0) if ($a0\&.lo32 == 626) if ($a1\&.hi32 == 4294967295) if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_RECV) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_SEND) if ($a3\&.hi32 == 4195042482) if ($a3\&.lo32 == 329284685) if ($a4\&.hi32 == 3163914537) if ($a4\&.lo32 == 2000745976) if ($a5\&.hi32 == 3932715328) if ($a5\&.lo32 == 2409429749) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_ADDFD) if ($a3\&.hi32 == 2387882717) if ($a3\&.lo32 == 529632567) if ($a4\&.hi32 == 2017338540) if ($a4\&.lo32 == 3732042218) if ($a5\&.hi32 == 4202049614) if ($a5\&.lo32 == 546113052) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_SET_FLAGS) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_ID_VALID) action ALLOW; if ($a1\&.hi32 == 0) if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_RECV) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_SEND) if ($a3\&.hi32 == 4195042482) if ($a3\&.lo32 == 329284685) if ($a4\&.hi32 == 3163914537) if ($a4\&.lo32 == 2000745976) if ($a5\&.hi32 == 3932715328) if ($a5\&.lo32 == 2409429749) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_ADDFD) if ($a3\&.hi32 == 2387882717) if ($a3\&.lo32 == 529632567) if ($a4\&.hi32 == 2017338540) if ($a4\&.lo32 == 3732042218) if ($a5\&.hi32 == 4202049614) if ($a5\&.lo32 == 546113052) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_SET_FLAGS) action ALLOW; if ($a1\&.lo32 == SECCOMP_IOCTL_NOTIF_ID_VALID) action ALLOW; \&.\&.\&. # default action action KILL_PROCESS; # invalid architecture action action KILL_PROCESS; .fi .RE .PP List of system calls protected by cookies is given below.\& The list may be further extended in the future to cover more system calls used by Syd: .PP .PD 0 .IP \(bu 4 \fIexecveat\fR(2) with \fBAT_EXECVE_CHECK\fR .IP \(bu 4 \fIexit_group\fR(2) .IP \(bu 4 \fIkill\fR(2), \fIpidfd_open\fR(2), \fIpidfd_getfd\fR(2), \fIpidfd_send_signal\fR(2), \fIptrace\fR(2) .IP \(bu 4 \fIioctl\fR(2) \- \fBPROCMAP_QUERY\fR \- \fBSECCOMP_IOCTL_NOTIF_RECV\fR \- \fBSECCOMP_IOCTL_NOTIF_SEND\fR \- \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR .IP \(bu 4 \fIseccomp\fR(2) .IP \(bu 4 \fIfaccessat2\fR(2), \fIfchdir\fR(2), \fIfchmod\fR(2), \fIfchmodat\fR(2), \fIfchmodat2\fR(2), \fIfchown\fR(2), \fIfchownat\fR(2) .IP \(bu 4 \fIgetdents64\fR(2), \fIreadlinkat\fR(2), \fIstatx\fR(2), \fIinotify_add_watch\fR(2), \fIsysinfo\fR(2) .IP \(bu 4 \fImkdirat\fR(2), \fImknodat\fR(2) .IP \(bu 4 \fIlinkat\fR(2), \fIrenameat2\fR(2), \fIsymlinkat\fR(2), \fIunlinkat\fR(2) .IP \(bu 4 \fImemfd_create\fR(2), \fImemfd_secret\fR(2) .IP \(bu 4 \fIopenat2\fR(2) .IP \(bu 4 \fIread\fR(2), \fIwrite\fR(2) .IP \(bu 4 \fIclose\fR(2), \fIclose_range\fR(2), \fIdup3\fR(2) .IP \(bu 4 \fIpipe2\fR(2) .IP \(bu 4 \fIkcmp\fR(2), \fIwaitid\fR(2) .IP \(bu 4 \fIsocket\fR(2), \fIbind\fR(2), \fIconnect\fR(2), \fIaccept4\fR(2) (\fB64\-bit only\fR) .IP \(bu 4 \fIrecvmsg\fR(2), \fIsendmsg\fR(2) (\fB64\-bit only\fR) .IP \(bu 4 \fIgetpeername\fR(2), \fIgetsockname\fR(2), \fIgetsockopt\fR(2) (\fB64\-bit only\fR) .IP \(bu 4 \fIfallocate\fR(2) (\fB64\-bit only\fR) .IP \(bu 4 \fItruncate\fR(2), \fItruncate64\fR(2), \fIftruncate\fR(2) .IP \(bu 4 \fIuname\fR(2), \fIumask\fR(2), \fIutimensat\fR(2), \fIutimensat_time64\fR(2) .IP \(bu 4 \fIfsetxattr\fR(2), \fIlsetxattr\fR(2) .IP \(bu 4 \fIfgetxattr\fR(2), \fIflistxattr\fR(2) .IP \(bu 4 \fIfremovexattr\fR(2), \fIlremovexattr\fR(2) .IP \(bu 4 \fIepoll_create1\fR(2), \fIeventfd2\fR(2) .PD .PP As of version 3.\&36.\&0, this mitigation may be disabled at startup using the \fItrace/allow_unsafe_nocookie:1\fR option.\& .PP As of version 3.\&48.\&2, all cookies reside in a single contiguous memory region hardened with guard pages, read\-only protection, and \fImseal\fR(2) where available.\& This consolidation reduces entropy consumption to one \fIgetrandom\fR(2) call and eliminates per\-cookie allocation overhead while preserving the cryptographic unpredictability of each token.\& .PP As of version 3.\&54.\&0, the cookie pool employs a randomized indirection table to decouple logical cookie identifiers from their physical memory offsets.\& At startup, a Fisher\-Yates permutation σ of size N (where N is the number of cookie slots) is generated using \fIgetrandom\fR(2) with rejection sampling to eliminate modular reduction bias.\& The permutation is constructed in place in the data region, then immediately sealed.\& The permutation resides in a separate guard\-page protected memory region that is \fImadvise\fR(2) \fBMADV_DONTDUMP\fR, read\-only protected with \fImprotect\fR(2), and sealed with \fImseal\fR(2).\& Cookie lookups index through σ, so that leaking the pool'\&s base address no longer reveals which physical offset corresponds to which system call without independently compromising the indirection table.\& .PP .SS Shared Memory Hardening .PP As of version 3.\&48.\&0, Syd denies access to \fIsysvipc\fR(7) and \fImq_overview\fR(7) system calls by default to enforce a strict shared\-nothing architecture.\& This hardening eliminates an entire class of inter\-process communication (IPC) vulnerabilities, including "memory squatting" attacks where malicious actors preemptively allocate shared memory keys to hijack or disrupt legitimate applications, as detailed in the research by Portcullis.\& By blocking the creation and usage of System V shared memory, semaphores, message queues, and POSIX message queues, Syd closes kernel code paths that have historically harbored privilege escalation and information leakage bugs.\& This strict isolation aligns with modern container security best practices, preventing sandboxed processes from interfering with the host or other containers via shared global namespaces.\& If legacy application compatibility is required, these subsystems can be selectively re\-enabled using the \fItrace/allow_unsafe_shm:1\fR and \fItrace/allow_unsafe_msgqueue:1\fR options, partially exposing the sandbox to the aforementioned risks.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://man7.\&org/linux/man\-pages/man7/sysvipc.\&7.\&html .IP \(bu 4 https://man7.\&org/linux/man\-pages/man7/mq_overview.\&7.\&html .IP \(bu 4 https://labs.\&portcullis.\&co.\&uk/whitepapers/memory\-squatting\-attacks\-on\-system\-v\-shared\-memory/ .IP \(bu 4 https://labs.\&portcullis.\&co.\&uk/presentations/i\-miss\-lsd/ .IP \(bu 4 https://www.\&cve.\&org/CVERecord?\&id=CVE\-2013\-0254 .PD .PP .SS Shared Memory Permissions Hardening .PP As of version 3.\&37.\&0, Syd introduces a kernel\-enforced mitigation against System V shared memory squatting by conditioning allow rules on strict permission masks.\& By inspecting the mode bits passed to \fIshmget\fR(2), \fImsgget\fR(2), \fIsemget\fR(2) and \fImq_open\fR(2) system calls, the sandbox admits creates only when user\-, group\-, and other\-permission fields exclude unsafe write or execute flags (i.\&e.\&, no bits set in mask 0o177).\& This measure prevents untrusted processes from elevating permissions after creation or exploiting legacy IPC segments with permissive ACLs, which could lead to disclosure or corruption of shared pages.\& Based on the attack taxonomy described in \fBMemory Squatting: Attacks on System V Shared Memory\fR (Portcullis, 2013), mode checks take place within the \fIseccomp\fR(2) BPF filter before any mapping.\& The \fBIPC_SET\fR operations of the \fIshmctl\fR(2), \fImsgctl\fR(2), and \fIsemctl\fR(2) system calls are also denied, preventing permission changes after creation.\& Additionally, any attempt to attach a shared memory segment with the \fBSHM_EXEC\fR flag via \fIshmat\fR(2) is denied to enforce W\(haX policies, blocking executable mappings through shared memory.\& The \fIseccomp\fR(2) filter also blocks the \fBMSG_STAT_ANY\fR, \fBSEM_STAT_ANY\fR, and \fBSHM_STAT_ANY\fR operations (Linux 4.\&17+), which would otherwise return segment metadata without verifying its mode, mitigating unintended information leaks.\& This mitigation is applied in the parent \fIseccomp\fR(2) filter, binding the Syd process itself to these restrictions.\& Administrators may relax this policy at startup using the \fItrace/allow_unsafe_perm_msgqueue:1\fR and \fItrace/allow_unsafe_perm_shm:1\fR options, but doing so reintroduces the classic squatting vulnerabilities documented in CVE\-2013\-0254 and related research.\& For more information refer to the following links: .PP .PD 0 .IP \(bu 4 https://labs.\&portcullis.\&co.\&uk/whitepapers/memory\-squatting\-attacks\-on\-system\-v\-shared\-memory/ .IP \(bu 4 https://labs.\&portcullis.\&co.\&uk/presentations/i\-miss\-lsd/ .IP \(bu 4 https://www.\&cve.\&org/CVERecord?\&id=CVE\-2013\-0254 .PD .PP .SS Mitigation Against Heap Spraying .PP As of version 3.\&23.\&18, Syd disables the \fImsgsnd\fR(2) system call by default to mitigate kernel heap\-spraying attacks.\& System V message queues allocate large, contiguous kernel\-heap buffers under caller control, making \fImsgsnd\fR(2) a practical primitive for heap layout manipulation.\& CVE\-2016\-6187, CVE\-2021\-22555, and CVE\-2021\-26708 each exploited this property to achieve predictable heap placement and subsequent privilege escalation or kernel code execution.\& Blocking \fImsgsnd\fR(2) at the seccomp layer removes this allocation primitive from the attacker'\&s reach.\& Administrators who need System V message queues for legitimate IPC can re\-enable the call with \fItrace/allow_unsafe_shm:1\fR.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://en.\&wikipedia.\&org/wiki/Heap_spraying .IP \(bu 4 https://grsecurity.\&net/how_autoslab_changes_the_memory_unsafety_game .IP \(bu 4 https://duasynt.\&com/blog/cve\-2016\-6187\-heap\-off\-by\-one\-exploit .IP \(bu 4 https://google.\&github.\&io/security\-research/pocs/linux/cve\-2021\-22555/writeup.\&html .IP \(bu 4 https://a13xp0p0v.\&github.\&io/2021/02/09/CVE\-2021\-26708.\&html .PD .PP .SS Denying Restartable Sequences .PP As of version 3.\&37.\&0, Syd denies access to the restartable sequences with the \fIrseq\fR(2) system call by default, substantially elevating the security baseline of the sandbox.\& The restartable sequences interface enables user space to register per\-thread critical regions with kernel\-enforced atomicity guarantees, but critically, also exposes a user\-controlled abort handler address.\& In adversarial scenarios, this facility can be abused: attackers with the ability to manipulate process memory or \fIrseq\fR(2) registration can redirect execution to arbitrary, attacker\-chosen code locations on preemption or CPU migration, bypassing intra\-process isolation boundaries and subverting mechanisms such as memory protection keys or control\-flow integrity.\& By prohibiting \fIrseq\fR(2), Syd eliminates this kernel\-facilitated control\-flow transfer primitive, foreclosing a class of attacks that exploit restartable sequence state for privilege escalation, sandbox escape, or bypass of compartmentalization.\& This mitigation exemplifies a least\-privilege syscall surface and strong adherence to modern threat models, allowing only strictly necessary system calls and neutralizing emergent attack vectors rooted in kernel\-user collaboration.\& Administrators may explicitly re\-enable this system call if required for compatibility using the \fItrace/allow_unsafe_rseq:1\fR startup option, with the understanding that doing so weakens this critical security boundary.\& For more information, refer to the following links: .PP .PD 0 .IP \(bu 4 https://arxiv.\&org/abs/2108.\&03705 .IP \(bu 4 https://arxiv.\&org/abs/2406.\&07429 .IP \(bu 4 https://www.\&usenix.\&org/system/files/usenixsecurity24\-yang\-fangfei.\&pdf .PD .PP .SS Personality Syscall Restrictions .PP As of version 3.\&37.\&0, Syd implements strict restrictions on the \fIpersonality\fR(2) system call to mitigate security vulnerabilities associated with unsafe \fIpersonality\fR(2) flags, particularly the \fBADDR_NO_RANDOMIZE\fR flag which can disable Address Space Layout Randomization (ASLR) \-\- a fundamental memory protection mechanism that prevents reliable exploitation of memory corruption vulnerabilities by randomizing memory layout or the \fBREAD_IMPLIES_EXEC\fR flag which can bypass memory protections provided by Memory\-Deny\-Write\-Execute, aka W\(haX.\& This security enhancement aligns Syd with industry\-standard container runtimes including Docker and Podman, which employ identical restrictions to balance security with application compatibility by maintaining an allowlist of safe personality values: \fBPER_LINUX\fR for standard Linux execution domain, \fBPER_LINUX32\fR for 32\-bit compatibility, \fBUNAME26\fR for legacy kernel version reporting, \fBPER_LINUX32|UNAME26\fR for combined 32\-bit and legacy compatibility, and \fBGET_PERSONALITY\fR for querying current \fIpersonality\fR(2) without modification.\& The implementation follows the principle of least privilege by denying all potentially dangerous \fIpersonality\fR(2) modifications while permitting only required compatibility requirements, preventing malicious actors from using \fIpersonality\fR(2) flags to make exploits more predictable and reliable \-\- a behavior specifically monitored by security detection systems.\& Administrators requiring unrestricted personality system call access can disable these restrictions using \fItrace/allow_unsafe_personality:1\fR, though this should be undertaken with careful consideration of the security implications as it potentially exposes the sandbox to personality\-based security bypasses that could compromise the isolation guarantees provided by Syd'\&s broader security hardening strategy encompassing strict system call filtering, capability restrictions, and resource access controls.\& .PP As of version 3.\&47.\&0, Syd extends these protections by adding \fBADDR_COMPAT_LAYOUT\fR \-\- which forces a legacy, more predictable memory layout \-\- and \fBMMAP_PAGE_ZERO\fR \-\- which allows mapping page 0 and can turn NULL\-pointer dereferences into code execution \-\- to the \fIpersonality\fR(2) "kill list", so that any attempt within the sandbox to enable \fBREAD_IMPLIES_EXEC\fR, \fBADDR_NO_RANDOMIZE\fR, \fBADDR_COMPAT_LAYOUT\fR, or \fBMMAP_PAGE_ZERO\fR results in immediate termination of the offending process.\& During sandbox setup, Syd also clears all four of these flags from the inherited \fIpersonality\fR(2) so that untrusted workloads always start with ASLR\-friendly layouts and without the ability to rely on legacy low\-entropy address layouts or exploit NULL\-pointer mappings.\& .PP .SS Thread\-Level Filesystem and File\-Descriptor Namespace Isolation .PP As of version 3.\&37.\&2, Syd'\&s interrupt, IPC and emulator worker threads are each placed into their own filesystem and file\-descriptor namespace by \fIunshare\fR(2)'\&ing both \fBCLONE_FS\fR and \fBCLONE_FILES\fR.\& This per\-thread isolation ensures that working directory, \fIumask\fR(2) and open\-file table changes in one thread cannot leak into \-\- or be influenced by \-\- any other, closing subtle attack vectors such as TOCTOU races on shared \fIprocfs\fR(5) or fd entries, descriptor reuse across threads, and cwd\-based side channels.\& By scoping thread\-local filesystem state and descriptor tables, this enhancement hardens Syd'\&s sandbox manager against advanced multithreading exploits and preserves strict separation between the monitoring and emulation components.\& .PP .SS Denying MSG_OOB Flag in send/recv System Calls .PP As of version 3.\&37.\&5, Syd unconditionally denies the use of the \fBMSG_OOB\fR flag in all \fIsend\fR(2), \fIsendto\fR(2), \fIsendmsg\fR(2), and \fIsendmmsg\fR(2) calls \-\- regardless of socket family \-\- by returning the \fBEOPNOTSUPP\fR ("Operation not supported on transport endpoint") \fIerrno\fR(3).\& As of version 3.\&41.\&1, the restriction includes the system calls \fIrecv\fR(2), \fIrecvfrom\fR(2), \fIrecvmsg\fR(2), and \fIrecvmmsg\fR(2).\& This measure addresses long\-standing security concerns with out\-of\-band messaging semantics in stream sockets, where urgent data bypasses normal in\-order delivery rules and is handled via separate kernel paths.\& Such semantics are rarely required by modern software but introduce complexity and subtle state transitions inside the kernel'\&s networking stack, which have historically led to memory safety bugs and race conditions exploitable from unprivileged code.\& By default, removing \fBMSG_OOB\fR support removes reachable kernel OOB code paths for sandboxed processes without impacting typical application behavior.\& For controlled environments where \fBMSG_OOB\fR is explicitly required, Syd provides the opt\-in \fItrace/allow_unsafe_oob:1\fR flag to restore legacy behavior, though enabling it reintroduces the inherent risks associated with out\-of\-band data handling.\& This mitigation is enabled by default on all architectures without the \fIsocketcall\fR(2) multiplexer which are aarch64, arm, loongarch64, mips64, mipsel64, parisc, parisc64, riscv64, x32, and x86_64.\& On architectures with the \fIsocketcall\fR(2) multiplexer \-\- x86, m68k, mips, mipsel, ppc, ppc64, ppc64le, s390, s390x, sheb, and sh \-\- this mitigation historically did not apply.\& However, as of version 3.\&57.\&0 \fIsocketcall\fR(2) is denied by default, forcing libcs onto the direct system calls, so this mitigation is effective on those architectures too unless \fItrace/allow_unsafe_socketcall:1\fR is set at startup.\& For more information refer to the following links: .PP .PD 0 .IP \(bu 4 https://googleprojectzero.\&blogspot.\&com/2025/08/from\-chrome\-renderer\-code\-exec\-to\-kernel.\&html .IP \(bu 4 https://chromium\-review.\&googlesource.\&com/c/chromium/src/+/6711812 .IP \(bu 4 https://u1f383.\&github.\&io/linux/2025/10/03/analyze\-linux\-kernel\-1\-day\-0aeb54ac.\&html .PD .PP .SS Denying O_NOTIFICATION_PIPE Flag in pipe2 .PP Notification pipes require \fItrace/allow_unsafe_pipe:1\fR.\& Without this option \fIpipe2\fR(2) with \fBO_NOTIFICATION_PIPE\fR fails with \fIENOPKG\fR as on a Linux kernel built without \fBCONFIG_WATCH_QUEUE\fR.\& When the option is set, Syd checks each \fBO_NOTIFICATION_PIPE\fR pipe against the dummy path \fB!\¬ification_pipe\fR under the \fBcreate\fR category.\& A rule such as \fIdeny/create+!\¬ification_pipe\fR then fails with \fIENOPKG\fR.\& This restriction addresses the security risks associated with notification pipes, a specialized and seldom\-used mechanism designed for delivering kernel event notifications (currently only from the keys subsystem) to userspace when the kernel is built with \fBCONFIG_WATCH_QUEUE\fR.\& Unlike normal pipes, notification pipes operate with distinct semantics and are tightly integrated with kernel internals, creating a more complex and less widely audited code path.\& Historically, vulnerabilities in notification pipe handling have demonstrated that exposing this functionality to unprivileged, sandboxed code can create exploitable kernel entry points.\& Because typical sandboxed applications, including high\-risk workloads such as browser renderers, have no legitimate need for notification pipes, denying \fB!\¬ification_pipe\fR eliminates an entire class of low\-value yet high\-risk kernel interfaces.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://chromium\-review.\&googlesource.\&com/c/chromium/src/+/4128252 .IP \(bu 4 https://git.\&kernel.\&org/pub/scm/linux/kernel/git/torvalds/linux.\&git/log/?\&qt=grep&q=watch_queue .PD .PP .SS madvise(2) Hardening .PP As of version 3.\&41.\&3, Syd tightens its \fIseccomp\fR(2) BPF policy by argument\-filtering madvise(2) to an allow\-list that is safe for untrusted workloads and has well\-understood locality: \fBMADV_SEQUENTIAL\fR, \fBMADV_DONTNEED\fR, \fBMADV_REMOVE\fR, \fBMADV_HUGEPAGE\fR, \fBMADV_NOHUGEPAGE\fR, \fBMADV_DONTDUMP\fR, \fBMADV_COLLAPSE\fR, \fBMADV_POPULATE_READ\fR, \fBMADV_POPULATE_WRITE\fR, and (since Linux 6.\&13) the lightweight guard operations \fBMADV_GUARD_INSTALL\fR/\fBMADV_GUARD_REMOVE\fR (page\-table\-level red zones that fault on access without VMA churn).\& The advice \fBMADV_HWPOISON\fR is denied and all other advice are treated as no\-op because they enable cross\-domain information leaks or system\-wide pressure channels with no isolation benefit, e.\&g.\&, \fBMADV_MERGEABLE\fR drives KSM deduplication which has been repeatedly shown to enable cross\-VM/process side channels and targeted bit\-flip exploitation (Flip Feng Shui) as well as newer remote and timing channels.\& \fBMADV_WILLNEED\fR/\fBMADV_RANDOM\fR manipulate page\-cache residency and prefetch behavior that underpin page\-cache side\-channel attacks; and reclaim steering like \fBMADV_FREE\fR/\fBMADV_COLD\fR/\fBMADV_PAGEOUT\fR introduces externally observable memory\-pressure/timing signals and accounting ambiguity that sandboxes should not expose; privileged page state changes \fBMADV_SOFT_OFFLINE\fR/\fBMADV_HWPOISON\fR are unnecessary in least\-authority contexts and remain outside the sandbox contract even if capability checks would reject them.\& This design follows the strict syscall\-and\-argument allow\-listing discipline also employed by Google'\&s Sandbox2/Sandboxed\-API while remaining specific to Syd'\&s threat model.\& To temporarily relax this mitigation for tracing/compatibility, set \fItrace/allow_unsafe_madvise:1\fR at startup, otherwise unsafe advice remain blocked by default.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://www.\&usenix.\&org/system/files/conference/usenixsecurity16/sec16_paper_razavi.\&pdf .IP \(bu 4 https://www.\&ndss\-symposium.\&org/wp\-content/uploads/2022\-81\-paper.\&pdf .IP \(bu 4 https://svs.\&informatik.\&uni\-hamburg.\&de/publications/2024/Lindemann_ACSAC2024_FakeDD.\&pdf .IP \(bu 4 https://arxiv.\&org/pdf/1901.\&01161 .IP \(bu 4 https://lwn.\&net/Articles/790123/ .IP \(bu 4 https://lwn.\&net/Articles/1011366/ .IP \(bu 4 https://developers.\&google.\&com/code\-sandboxing/sandbox2/explained .IP \(bu 4 https://developers.\&google.\&com/code\-sandboxing/sandboxed\-api/explained .PD .PP .SS setsockopt(2) Hardening .PP As of version 3.\&46.\&1, Syd introduces a fine\-grained \fIsetsockopt\fR(2) hardening layer that denies a curated set of historically fragile or highly privileged \fIsocket\fR(2) options by matching on the (level, optname) pair in a dedicated \fIseccomp\fR(2) filter, covering netfilter rule programming (iptables, ip6tables, arptables, ebtables), multicast routing control, IPv4/IPv6 multicast group management, IPv6 header manipulation, TCP repair and upper\-layer protocol hooks, congestion control selection, UDP corking, AF_PACKET ring/fanout configuration, BPF\-based socket filters, and VSOCK buffer sizing.\& Syd converts these dangerous combinations into success\-returning no\-ops emulating a successful \fIsetsockopt\fR(2) while silently discarding the request, which preserves compatibility with applications that merely probe for these features but never rely on their semantics, and at the same time removes substantial kernel code reachable from unprivileged processes.\& This mitigation is enabled by default on all architectures without the \fIsocketcall\fR(2) multiplexer which are aarch64, arm, loongarch64, mips64, mipsel64, parisc, parisc64, riscv64, x32, and x86_64.\& On architectures with the \fIsocketcall\fR(2) multiplexer \-\- x86, m68k, mips, mipsel, ppc, ppc64, ppc64le, s390, s390x, sheb, and sh \-\- this mitigation historically did not apply.\& However, as of version 3.\&57.\&0 \fIsocketcall\fR(2) is denied by default, forcing libcs onto the direct system calls, so this mitigation is effective on those architectures too unless \fItrace/allow_unsafe_socketcall:1\fR is set at startup.\& The mitigation may be relaxed at startup using the option \fItrace/allow_unsafe_setsockopt:1\fR.\& .PP As of version 3.\&57.\&0, Syd denies each unsupported option level with one \fIseccomp\fR(2) rule matched on the level alone, instead of one rule per option name.\& SOL_ALG is allowed with \fItrace/allow_unsafe_kcapi:1\fR, the raw families CAN_RAW, AF_PACKET and AF_XDP with \fItrace/allow_unsafe_socket:1\fR, and the rest, such as SCTP, DCCP, TLS, TIPC, Bluetooth and VSOCK, with \fItrace/allow_unsupp_socket:1\fR.\& The supported levels are still denied per option.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2016\-9793 .IP \(bu 4 https://www.\&cve.\&org/CVERecord?\&id=CVE\-2016\-9793 .IP \(bu 4 https://security\-tracker.\&debian.\&org/tracker/CVE\-2016\-9793 .IP \(bu 4 https://ubuntu.\&com/security/CVE\-2016\-9793 .IP \(bu 4 https://www.\&exploit\-db.\&com/exploits/41995 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2017\-6346 .IP \(bu 4 https://www.\&cve.\&org/CVERecord?\&id=CVE\-2017\-6346 .IP \(bu 4 https://security\-tracker.\&debian.\&org/tracker/CVE\-2017\-6346 .IP \(bu 4 https://ubuntu.\&com/security/CVE\-2017\-6346 .IP \(bu 4 https://www.\&cvedetails.\&com/cve/CVE\-2017\-6346/ .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2018\-18559 .IP \(bu 4 https://www.\&cve.\&org/CVERecord?\&id=CVE\-2018\-18559 .IP \(bu 4 https://security\-tracker.\&debian.\&org/tracker/CVE\-2018\-18559 .IP \(bu 4 https://ubuntu.\&com/security/CVE\-2018\-18559 .IP \(bu 4 https://www.\&cvedetails.\&com/cve/CVE\-2018\-18559/ .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2020\-14386 .IP \(bu 4 https://www.\&openwall.\&com/lists/oss\-security/2020/09/03/3 .IP \(bu 4 https://unit42.\&paloaltonetworks.\&com/cve\-2020\-14386/ .IP \(bu 4 https://sysdig.\&com/blog/cve\-2020\-14386\-falco .IP \(bu 4 https://gvisor.\&dev/blog/2020/09/18/containing\-a\-real\-vulnerability/ .IP \(bu 4 https://www.\&cve.\&org/CVERecord?\&id=CVE\-2007\-1353 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2007\-1353 .IP \(bu 4 https://security\-tracker.\&debian.\&org/tracker/CVE\-2007\-1353 .IP \(bu 4 https://ubuntu.\&com/security/CVE\-2007\-1353 .IP \(bu 4 https://bugzilla.\&redhat.\&com/show_bug.\&cgi?\&id=CVE\-2007\-1353 .IP \(bu 4 https://ssd\-disclosure.\&com/ssd\-advisory\-linux\-kernel\-af_packet\-use\-after\-free\-2/ .IP \(bu 4 https://github.\&com/V4bel/dirtyfrag .PD .PP .SS Hardening against kernel pointer misuse .PP As of version 3.\&48.\&0, Syd hardens against kernel pointer misuse by default.\& This mitigation deploys a \fIseccomp\fR(2) BPF filter to inspect system call arguments known to accept pointers.\& If a user\-supplied argument is detected to point into kernel memory, the \fIseccomp\fR(2) filter returns \fBEFAULT\fR ("Bad address") without passing it on to the host kernel.\& This defense\-in\-depth measure effectively neutralizes a class of critical vulnerabilities where the kernel fails to validate that a user\-supplied pointer resides in user\-space memory (e.\&g.\& missing \fIaccess_ok()\fR checks), typically leading to arbitrary kernel memory corruption.\& A seminal example of such a vulnerability is CVE\-2017\-5123, where the \fIwaitid\fR(2) system call failed to validate the \fIinfop\fR argument, allowing unprivileged users to trigger arbitrary kernel writes.\& To disable this mitigation, set the configuration option \fItrace/allow_unsafe_kptr:1\fR at startup.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://lwn.\&net/Articles/736348/ .IP \(bu 4 https://www.\&cvedetails.\&com/cve/CVE\-2017\-5123/ .IP \(bu 4 https://salls.\&github.\&io/Linux\-Kernel\-CVE\-2017\-5123/ .IP \(bu 4 https://github.\&com/salls/kernel\-exploits/blob/master/CVE\-2017\-5123/exploit_smap_bypass.\&c .IP \(bu 4 https://www.\&cvedetails.\&com/cve/CVE\-2018\-1000199 .IP \(bu 4 https://git.\&kernel.\&org/pub/scm/linux/kernel/git/torvalds/linux.\&git/commit/?\&id=f67b15037a7a .IP \(bu 4 https://git.\&kernel.\&org/pub/scm/linux/kernel/git/torvalds/linux.\&git/commit/?\&id=27747f8bc355 .PD .PP .SS Hardening executable mappings .PP As of version 3.\&48.\&0, Syd performs self\-hardening by enforcing immutability and Execute\-Only Memory (XOM) protections on its own executable mappings during initialization.\& This mitigation, inspired by the OpenBSD \fImimmutable\fR(2) system call introduced by Theo de Raadt, aims to protect the sandbox monitor itself from compromise and code\-reuse attacks like Return\-Oriented Programming (ROP) by iterating over its executable Virtual Memory Areas (VMAs) and applying \fImprotect\fR(2) to limit permissions to \fBPROT_EXEC\fR (blocking \fBPROT_READ\fR) and \fImseal\fR(2) to render them immutable.\& These operations prevent attackers from scanning the text segment for gadgets or remapping memory to bypass W\(haX (Write XOR Execute) policies.\& Note that this hardening is applied on a best\-effort basis; specifically, \fImseal\fR(2) is only available on 64\-bit Linux kernels (version 6.\&10+), and \fImprotect\fR(2) XOM support depends on the underlying architecture and kernel configuration.\& The hardening may be disabled at startup using the option \fItrace/allow_unsafe_noxom:1\fR.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://lwn.\&net/Articles/779478/ .IP \(bu 4 https://lwn.\&net/Articles/948129/ .IP \(bu 4 https://lwn.\&net/Articles/958438/ .IP \(bu 4 https://lwn.\&net/Articles/978010/ .IP \(bu 4 https://lwn.\&net/Articles/1006375/ .IP \(bu 4 https://man.\&openbsd.\&org/mimmutable.\&2 .IP \(bu 4 https://www.\&openbsd.\&org/papers/csw2023.\&pdf .PD .PP .SS Restricting File Descriptor Passing via SCM_RIGHTS .PP Since version 3.\&31.\&0, Syd denies file descriptors referring to block devices, directories and symbolic links from being transmitted via \fIsendmsg\fR(2) and \fIsendmmsg\fR(2) with \fBSCM_RIGHTS\fR on UNIX domain sockets, in alignment with OpenBSD \fIpledge\fR(2) which disallows file descriptors referring to directories from being sent.\& Passing such descriptors allows a receiving process to perform I/O on files it has no path\-based access to: a directory descriptor enables \fIfchdir\fR(2) into denied subtrees while a block device descriptor affords raw sector access that bypasses filesystem access controls entirely.\& As of version 3.\&50.\&0, the restriction was extended to character devices, FIFOs, sockets, anonymous memory file descriptors from \fImemfd_create\fR(2), secret memory file descriptors from \fImemfd_secret\fR(2), magic symbolic links, and miscellaneous kernel objects such as \fIepoll\fR(7) file descriptors; character device transfers expose device\-specific \fIioctl\fR(2) interfaces outside the path\-based sandbox model, socket transfers hand over an established network endpoint circumventing network sandboxing, and memory file descriptor transfers carry anonymous executable\-capable pages that bypass Exec and TPE sandboxing.\& Each of these has a name that a \fBsendfd\fR or \fBrecvfd\fR rule may match.\& .PP .SS Immutable Sticky Bit .PP As of version 3.\&50.\&0, Syd enforces the immutability of the sticky bit (\fBS_ISVTX\fR) on directories at the \fIchmod\fR(2) boundary by intercepting \fIchmod\fR(2), \fIfchmod\fR(2), \fIfchmodat\fR(2), and \fIfchmodat2\fR(2) system calls and, for any directory that already carries the sticky bit, re\-inserting \fBS_ISVTX\fR into the requested mode before forwarding the operation to the kernel with a warning; the check is performed atomically on the file descriptor obtained during path resolution, eliminating any TOCTOU window between the mode query and the mode modification.\& The sticky bit on directories such as \fB/tmp\fR is a critical security primitive that restricts file deletion and renaming to the file owner, the directory owner, or the superuser, and its removal \-\- whether by accident, misconfiguration, or a compromised process \-\- re\-exposes the directory to symlink and hardlink race attacks including file clobbering.\& .PP As of version 3.\&54.\&0, this enforcement also covers the setgid bit (\fBS_ISGID\fR) on directories.\& When setgid bit is set on a directory, files created within it inherit directory'\&s group ownership rather than creating process'\&s effective group, which is essential for shared\-directory security models (e.\&g.\& group\-writable project directories).\& Removing setgid bit \-\- whether by accident, misconfiguration, or a compromised process \-\- breaks group inheritance and may re\-expose the directory to permission escalation.\& If a directory already carries \fBS_ISGID\fR and a \fIchmod\fR(2) call would remove it, Syd re\-inserts the bit and emits a warning, mirroring the sticky bit behaviour.\& .PP Both enforcements may be disabled using the \fItrace/allow_unsafe_sticky:1\fR option, which restores standard \fIchmod\fR(2) semantics at the cost of re\-exposing the described vulnerabilities.\& .PP .SS Deleted File Access Mediation .PP As of version 3.\&54.\&0, Syd mediates access to deleted files through open file descriptors and \fIproc_pid_fd\fR(5) magic links, denying such access with \fBENOENT\fR ("No such file or directory") by default.\& On Linux, when a file is unlinked while a process still holds an open file descriptor to it, kernel preserves file'\&s \fIinode\fR(7) and data until all referencing descriptors are closed.\& This behaviour creates a sandbox bypass vector.\& A process can open a file, have it removed from directory tree, and continue to \fIread\fR(2), \fIwrite\fR(2), or \fImmap\fR(2) its contents unchecked by path\-based access controls, since file no longer exists at any policy\-governed path.\& Syd enforces deleted file restriction at two points: in \fIproc_pid_fd\fR(5) magic link resolution during path canonicalization, and in file descriptor based path lookup.\& Both enforcement points operate on file descriptor obtained during resolution, eliminating any TOCTOU window between deleted\-state query and access decision.\& This mitigation is inspired by AppArmor'\&s \fBPATH_MEDIATE_DELETED\fR flag.\& When AppArmor encounters an unlinked dentry during path name resolution, it checks whether \fBPATH_MEDIATE_DELETED\fR is set in profile flags.\& If flag is not set, access to deleted file is denied with \fBENOENT\fR ("No such file or directory").\& Syd adopts the same default\-deny semantics.\& Administrators may relax this restriction using \fItrace/allow_unsafe_deleted:1\fR option for workloads that legitimately require continued access to deleted files, though doing so reintroduces described bypass vector.\& Refer to following links for more information: .PP .PD 0 .IP \(bu 4 https://gitlab.\&com/apparmor/apparmor/\-/wikis/FAQ#failed\-name\-lookup\-\-\-deleted\-entry .IP \(bu 4 https://git.\&kernel.\&org/pub/scm/linux/kernel/git/torvalds/linux.\&git/tree/security/apparmor/include/path.\&h .IP \(bu 4 https://git.\&kernel.\&org/pub/scm/linux/kernel/git/torvalds/linux.\&git/tree/security/apparmor/path.\&c .IP \(bu 4 https://manpages.\&ubuntu.\&com/manpages/noble/en/man5/apparmor.\&d.\&5.\&html .IP \(bu 4 https://man7.\&org/linux/man\-pages/man5/proc_pid_fd.\&5.\&html .PD .PP .SS Inheriting File Descriptors .PP As of version 3.\&57.\&0, Syd controls which file descriptors the sandbox process inherits across \fIexecve\fR(2).\& By default it closes every file descriptor except \fIstdio\fR(3) (0, 1, 2), so file descriptors opened or inherited by the supervisor do not leak into untrusted code.\& A leaked file descriptor is reachable as a \fIproc_pid_fd\fR(5) magic symbolic link that Linux resolves to the underlying \fIinode\fR(7) regardless of path or \fImount_namespaces\fR(7) confinement, so a single file descriptor to a host directory can defeat the sandbox, as in the \fIrunc\fR(1) breakouts CVE\-2016\-9962 and CVE\-2024\-21626.\& The \fIpassfd\fR command selects file descriptors to keep as numbers, inclusive ranges, or the keywords \fIstdio\fR, \fIstdin\fR, \fIstdout\fR, \fIstderr\fR, and \fIall\fR.\& Remaining file descriptors are closed with \fIclose_range\fR(2) just before \fIexecve\fR(2).\& The \fInullfd\fR command instead redirects file descriptors to \fI/dev/null\fR.\& This guards against a program, in particular a set\-user\-ID one, that starts with a standard file descriptor closed and binds the next descriptor it opens to slot 0, 1, or 2, mixing file data with standard input, output, or error as in CVE\-2002\-0820.\& Syd opens \fI/dev/null\fR with \fIopenat2\fR(2) under \fBRESOLVE_NO_SYMLINKS\fR and \fBRESOLVE_NO_MAGICLINKS\fR resolve flags, confirms it is the expected character device with major 1, minor 3 device numbers before \fIdup2\fR(2).\& A file descriptor redirected with \fInullfd\fR is implicitly inherited, so it need not also be listed in \fIpassfd\fR.\& The \fI/dev/null\fR redirection takes precedence over \fIpassfd\fR and the redirected descriptor is preserved across \fIexecve\fR(2).\& By default \fIstdio\fR(3) is passed and no file descriptor is redirected.\& Refer to the following links for more information: .PP .PD 0 .IP \(bu 4 https://access.\&redhat.\&com/security/vulnerabilities/cve\-2016\-9962 .IP \(bu 4 https://github.\&com/opencontainers/runc/discussions/4213 .IP \(bu 4 https://github.\&com/opencontainers/runc/security/advisories/GHSA\-xr7r\-f8xq\-vfvv .IP \(bu 4 https://github.\&com/strikoder/cve\-2024\-21626\-runc\-1.\&1.\&11\-escape .IP \(bu 4 https://labs.\&snyk.\&io/resources/cve\-2024\-21626\-runc\-process\-cwd\-container\-breakout/ .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2002\-0820 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2016\-9962 .IP \(bu 4 https://nvd.\&nist.\&gov/vuln/detail/CVE\-2024\-21626 .IP \(bu 4 https://www.\&kb.\&cert.\&org/vuls/id/314963 .IP \(bu 4 https://www.\&wiz.\&io/blog/leaky\-vessels\-container\-escape\-vulnerabilities .PD .PP .SH BUGS .PP .SS Pointer Modification TOCTOU .PP When Syd checks a system call argument then returns \fBSECCOMP_USER_NOTIF_FLAG_CONTINUE\fR, the kernel executes the call with the original pointer.\& A memory\-sharing attacker such as threads, \fIptrace\fR(2), or \fIprocess_vm_writev\fR(2) can overwrite the pointer target between check and use.\& \fIptrace\fR(2) and \fIprocess_vm_writev\fR(2) are by default denied inside the sandbox so attacks using these vectors must come from outside the sandbox.\& Affected system calls and mitigations are the following: .PP .PD 0 .IP \(bu 4 \fIexecve\fR(2)/\fIexecveat\fR(2): Syd hooks \fBPTRACE_EVENT_EXEC\fR and validates \fIproc_pid_exe\fR(5) at \fIptrace\fR(2) exec\-stop.\& If the executed path is denylisted, the process is terminated.\& .IP \(bu 4 \fIchdir\fR(2)/\fIfchdir\fR(2): Syd hooks \fIptrace\fR(2) syscall\-exit and validates \fIproc_pid_cwd\fR(5).\& If the directory is denylisted, the process is terminated.\& .IP \(bu 4 \fIopen\fR(2) with \fBO_PATH\fR: Syd converts \fBO_PATH\fR to \fBO_RDONLY\fR and emulates the call via \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR, eliminating the TOCTOU vector at the cost of a semantic downgrade.\& See \fIO_PATH to O_RDONLY Downgrade\fR below.\& .PD .PP Other file\-related calls are emulated with \fIopenat2\fR(2) and \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR, making them TOCTOU\-free.\& Refer to the Linux kernel bug 218501 for more information: https://bugzilla.\&kernel.\&org/show_bug.\&cgi?\&id=218501 .PP Restricting file execution with \fIlandlock\fR(7) using the \fBlock/exec\fR category isn'\&t affected by this issue.\& .PP .SS O_PATH to O_RDONLY Downgrade .PP When a sandboxed process opens a file with \fBO_PATH\fR, the resulting file descriptor is a lightweight handle that permits only a restricted set of operations \-\- \fIfstat\fR(2), \fIfchdir\fR(2), descriptor duplication, passing via \fIsendmsg\fR(2) with \fBSCM_RIGHTS\fR, and use as a \fIdirfd\fR argument in \fB*at\fR system calls \-\- but does not convey read, write, or execute permissions on the file content itself.\& Syd cannot faithfully emulate \fBO_PATH\fR because the kernel'\&s \fBSECCOMP_IOCTL_NOTIF_ADDFD\fR interface, used to install a supervisor\-opened file descriptor into the supervised process, does not support \fBO_PATH\fR descriptors.\& .PP As a consequence, Syd downgrades \fBO_PATH\fR to \fBO_RDONLY\fR before opening the file and transferring the descriptor.\& This emulation eliminates the pointer\-modification TOCTOU race that would arise from using \fBSECCOMP_USER_NOTIF_FLAG_CONTINUE\fR, but introduces a semantic discrepancy: the installed descriptor carries read permission rather than the minimal, permission\-less \fBO_PATH\fR semantics.\& In practice the difference is observable in the following ways: .PP .PD 0 .IP \(bu 4 \fIread\fR(2) and related data\-access system calls that would return \fBEBADF\fR on a genuine \fBO_PATH\fR descriptor will succeed on the downgraded descriptor.\& .IP \(bu 4 \fIfcntl\fR(2) \fBF_GETFL\fR reports \fBO_RDONLY\fR instead of \fBO_PATH\fR, and \fIproc_pid_fdinfo\fR(5) reports \fBflags:\fR without the \fBO_PATH\fR (\fB010000000\fR) bit.\& .IP \(bu 4 Programs that intentionally use \fBO_PATH\fR to avoid triggering side effects (e.\&g.\&, device \fIopen\fR(2) handlers, automount, or audit events) may see those side effects with the emulated descriptor.\& .PD .PP This limitation is tracked in the upstream kernel bugzilla: https://bugzilla.\&kernel.\&org/show_bug.\&cgi?\&id=218501 .PP As of version 3.\&50.\&1, Syd additionally inserts \fBO_NONBLOCK\fR into the downgraded flags to prevent indefinite blocking on FIFOs and spurious device\-open side effects that a genuine \fBO_PATH\fR descriptor would never cause.\& .PP .SS File Descriptor TOCTOU on mmap .PP When \fImmap\fR(2) maps a file with \fBPROT_EXEC\fR, both the file descriptor and file'\&s contents can change between Syd'\&s check and the kernel'\&s mapping.\& This permits loading modified code.\& .PP Mitigation: By default, Syd uses \fIptrace\fR(2) to intercept \fImmap\fR(2) at entry, then re\-checks \fIproc_pid_maps\fR(5) at syscall exit.\& If a denylisted path appears, the process is terminated, preventing execution of files from denylisted locations.\& Note this does not prevent content modification of allowlisted files.\& .PP .SS Hashbang Script Execution .PP Hashbang (#!\&) script execution is a two\-phase operation: Syd checks the script path, then the kernel re\-parses the hashbang and executes the interpreter.\& The interpreter can be replaced between phases.\& .PP Mitigation: On Linux 6.\&14+, Syd sets \fBSECBIT_EXEC_RESTRICT_FILE\fR and its lock.\& Interpreters supporting this check executability via \fIexecveat\fR(2) with \fBAT_EXECVE_CHECK\fR on the open file descriptor before loading, which is TOCTOU\-free.\& .PP .SS Interactive Code Bypass .PP Interpreters accepting code via \-e, \-c, environment variables, or REPL bypass file\-based execution checks.\& .PP Mitigation: On Linux 6.\&14+, Syd sets \fBSECBIT_EXEC_DENY_INTERACTIVE\fR and its lock.\& Cooperating interpreters refuse non\-FD\-sourced code.\& .PP .SH HISTORY & DESIGN .PP .PD 0 .IP \(bu 4 \fBsydbox\-0\fR https://git.\&sr.\&ht/\(tialip/syd/tree/sydbox\-0 is a \fIptrace\fR(2) based sandbox.\& .IP \(bu 4 \fBsydbox\-1\fR https://git.\&sr.\&ht/\(tialip/syd/tree/sydbox\-1 is a \fIptrace\fR(2) and \fIseccomp\fR(2) based sandbox.\& .IP \(bu 4 \fBsydbox\-2\fR https://git.\&sr.\&ht/\(tialip/syd/tree/sydbox\-1 is a \fIseccomp\fR(2) and \fIseccomp\-notify\fR based sandbox.\& .IP \(bu 4 \fBsydbox\-3\fR is a rewrite of \fBsydbox\-2\fR in Rust and it'\&s what you are looking at.\& .PD .PP This codebase has a history of a bit over 15 years and up to this point we have used C11 as our implementation language for various reasons.\& With \fBsydbox\-3\fR we took the next step and rewrote the sandbox from scratch using the Rust programming language with the only non\-Rust dependency being libseccomp.\& Although we inherit many ideas and design decisions from the old codebase, we also don'\&t shy away from radically changing the internal implementation making it much simpler, idiomatic, and less prone to bugs.\& We have \fIproper multiarch support\fR since release 3.\&0.\&11, e.\&g on x86\-64, you can run your x32 or x86 binaries just fine under Syd.\& .PP This version takes advantage of multithreading and handles system calls using a thread pool whose size is equal to the number of CPUs on the running machine and utilises globsets to match a list of patterns at once, thus continues to perform reasonably well even with very long rulesets.\& This version also comes with four new sandboxing categories called \fBLock Sandboxing\fR, \fBMemory Sandboxing\fR, \fBPID sandboxing\fR, \fBStat Sandboxing\fR, \fBForce Sandboxing\fR: \fBLock Sandboxing\fR utilises the Landlock Linux Security Module (LSM), \fBMemory Sandboxing\fR allows the user to define a per\-process memory limit, \fBPID sandboxing\fR allows the user to define a limit on the maximum number of running tasks under the sandbox, \fBStat Sandboxing\fR can be used to effectively \fIhide files and directories\fR from the sandboxed process whereas \fBForce Sandboxing\fR can be used to verify file checksums prior to exec, similar to HardenedBSD'\&s Integriforce and NetBSD'\&s Veriexec.\& .PP Finally, the new Syd has support for namespaces.\& Use e.\&g.\& \fIsyd \-munshare/user:1\fR to create a user namespace.\& You may use \fImount\fR, \fIuts\fR, \fIipc\fR, \fIpid\fR, \fInet\fR, and \fIcgroup\fR instead of \fIuser\fR to create various namespaces.\& You may use the \fIcontainer\fR profile as a shorthand to create namespaces with \fIsyd \-pcontainer\fR.\& .PP You may use Syd as your login shell because it is very practical to have a restricted user.\& To do this simply add \fI/path/to/syd\fR to the file \fI/etc/shells\fR and do \fIchsh \-s /path/to/syd username\fR as root.\& In this mode the sandbox may be configured using the files \fI/etc/user.\&syd\-3\fR and \fI\(ti/.\&user.\&syd\-3\fR.\& If you want to restrict user configuration of the sandbox, lock the sandbox using \fIlock:on\fR at the end of the site\-wide configuration file.\& .PP .SH EXHERBO .PP Syd is the default sandbox of \fBExherbo Linux\fR.\& We use it to provide a restricted environment under which package builds run with controlled access to file system and network resources.\& \fIexheres\-0\fR has a function called \fIesandbox\fR to interact with Syd.\& .PP .SH SEE ALSO .PP \fIsyd\fR(1), \fIsyd\fR(2), \fIsyd\fR(5), \fIseccomp\fR(2), \fIpidfd_getfd\fR(2), \fIpidfd_send_signal\fR(2), \fIioctl\fR(2), \fIioctl_tty\fR(2), \fIprctl\fR(2), \fInamespaces\fR(7), \fIcgroup_namespaces\fR(7), \fIipc_namespaces\fR(7), \fImount_namespaces\fR(7), \fInetwork_namespaces\fR(7), \fIpid_namespaces\fR(7), \fIuser_namespaces\fR(7), \fIuts_namespaces\fR(7), \fIsydtutorial\fR(7) .PP https://exherbo.\&org/docs/eapi/exheres\-for\-smarties.\&html#sandboxing .PP .SH AUTHORS .PP Maintained by Ali Polatel.\& Up\-to\-date sources can be found at https://gitlab.\&exherbo.\&org/sydbox/sydbox.\&git and on Radicle at rad:z38HCnbmcDegA2BMxuPaPRPMdp6wF.\& Bugs/patches can be submitted to https://gitlab.\&exherbo.\&org/groups/sydbox/\-/issues.\& Discuss in #sydbox on Libera Chat or in #sydbox:mailstation.\&de on Matrix.\&