Investigate and fix execution personality notification setup to ensure broadest coverage for seccomp.
Currently, notifications may only be set up for one execution mode (x86 or x64). Users could potentially change between modes without triggering all necessary notifications.
Current State
Seccomp Filter Implementation
File: executables/session_wrapper/src/seccomp.rs
Current filter policy:
- Default action: Allow
- Denied syscalls (EPERM): ptrace, process_vm_writev, process_vm_readv, pidfd_getfd, userfaultfd, unshare, setns, mount, umount2, mount_setattr, fsopen, fsmount, move_mount
- Notified syscalls: execve, execveat
Critical gap: The personality() syscall is NOT in the policy at all. It needs to be added.
The Security Issue
The personality(2) syscall changes process execution domains on Linux. On x86-64 systems this includes:
- PER_LINUX (0) = 64-bit mode
- PER_LINUX32 (8) = 32-bit (x86/i386) mode
- Legacy modes: PER_BSD, PER_SVR4, PER_OSF4, PER_HPUX, etc.
Attack vector:
- User is authorized to run a 64-bit binary: /usr/bin/foo
- User calls personality(PER_LINUX32) (currently not blocked)
- User calls execve("/usr/bin/foo") → a 32-bit version executes
- The 32-bit variant was never authorized by TACACS+
Work Required
1. Update Seccomp Policy
- Add personality to syscall_rules() with action RuleAction::Notify
- Allows supervisor to intercept and validate personality changes
2. Extend Supervisor to Handle Personality Notifications
File: executables/session_wrapper/src/supervisor.rs
- Extract personality argument from incoming notifications
- Validate personality changes against authorized commands
- Decide validation strategy:
- Deny all personality changes (strictest)
- Track per-command if only x86-64 binaries are authorized
- Compare personality mode with binary bitness
3. Investigation Tasks
- Platform coverage: Identify all valid personality modes on x86-64 Linux
- SONiC usage: What personality modes are actually deployed?
- Authorization model: Does TACACS+ need to return personality constraints?
- Broadest coverage: Ensure all mode combinations that could bypass authorization are covered
4. Testing
- Add seccomp policy tests verifying personality is in notify rules
- Add supervisor tests for personality notification handling
- Add integration tests for multi-personality scenarios
5. Documentation
- Update session-wrapper HLD/design to explain personality tracking
- Document supported personality modes and rationale
- Update SONiC TACACS+ kernel command authorization HLD
Platform Scope
Session-wrapper is Linux x86_64-specific (per main.rs)
Implementation should handle all x86-64 personality modes and modes that could cross binary architecture boundaries.
References
- Linux personality(2) man page
- libseccomp API documentation
- executables/session_wrapper/src/seccomp.rs (current policy)
- executables/session_wrapper/src/supervisor.rs (notification handling)
- executables/session_wrapper/src/process.rs (lifecycle)
- docs/sonic-tacacs-kernel-command-authorization-hld.md
Investigate and fix execution personality notification setup to ensure broadest coverage for seccomp.
Currently, notifications may only be set up for one execution mode (x86 or x64). Users could potentially change between modes without triggering all necessary notifications.
Current State
Seccomp Filter Implementation
File: executables/session_wrapper/src/seccomp.rs
Current filter policy:
Critical gap: The personality() syscall is NOT in the policy at all. It needs to be added.
The Security Issue
The personality(2) syscall changes process execution domains on Linux. On x86-64 systems this includes:
Attack vector:
Work Required
1. Update Seccomp Policy
2. Extend Supervisor to Handle Personality Notifications
File: executables/session_wrapper/src/supervisor.rs
3. Investigation Tasks
4. Testing
5. Documentation
Platform Scope
Session-wrapper is Linux x86_64-specific (per main.rs)
Implementation should handle all x86-64 personality modes and modes that could cross binary architecture boundaries.
References