Draft: seccomp syscall and ioctls #1458
Conversation
| operation: super::types::SeccompOperation, | ||
| flags: Option<SetSecureComputingFilterFlags>, | ||
| args: *mut c::c_void, | ||
| ) -> io::Result<c::c_int> { |
There was a problem hiding this comment.
This function should be unsafe because it effectively dereferences args.
| operation: SeccompOperation, | ||
| flags: Option<SetSecureComputingModeFilterFlags>, | ||
| args: *mut c::c_void, | ||
| ) -> io::Result<()> { |
There was a problem hiding this comment.
This function should also be unsafe.
| Self( | ||
| c::sock_fprog { | ||
| // usize as u16 is lossy. However filter programs with more than BPF_MAXINSNS (4096) | ||
| // will be rejected by the kernel with EINVAL. |
There was a problem hiding this comment.
If the user passes a filter list that's too long, it seems like it's be better to fail than to silently truncate the list. The user may be assuming that if the call succeeds, the entire filter list is installed.
There was a problem hiding this comment.
The kernel will return EINVAL for len > 4096 (~32kB filter code). u16::MAX is 65535 (~500kb filter code). So this is more a theoretical than a practical issue - the filter will get rejected by the kernel. On the other hand edit: This would mean we can not use u16::try_from(length).map_err(|_| EINVAL)? isn't complicated.From. So under the assumption to keep using From we can:
u16::try_from(length).unwrap_or(u16::MAX)u16::try_from(length).unwrap_or(0)(Kernel:if (fprog->len == 0 || fprog->len > BPF_MAXINSNS) return ERR_PTR(-EINVAL);)assert!(filter_lines.len() < u16::MAX as usize)as it should not happen in practice.
This is an early draft seeking for feedback on the API. The
SecureComputingFilteris based on my own seccomp abstractions https://codeberg.org/crabjail/crablock/src/commit/c6cadc33b0e605bf16b8dc2fc0ba8156c7693567/seccomp/src/bpf.rs#L416 .Closes #1451