Closed RoundofThree closed 2 months ago
Is there a reason not to just use elf_aux_info(AT_PS_STRINGS)
? The second sysctl is particularly problematic since it would let you get capabilities for a foreign address space and totally violate your own process's spatial safety. kern.ps_strings (or kern.proc.KERN_PROC_AUXV.pid for the current pid) perhaps less so, but if it's your own process I don't see why you shouldn't just use the in-userspace interface.
sysctl not exporting capabilities[0] is a feature of CheriABI to preserve least privilege and provenance. Things like kern.ps_strings and kern.usrstack would expose powerful capabilities to any code that can make a sysctl, effectively adding that code to the TCB of the application. Software should use elf_aux_info() or (if absolutely necessity) direct access to __elf_aux_vector which at least allows use to be audited and (with c18n) constrained.
[0] There is a SYSCTL_CAPABILITY, but both uses are to expose broad capabilities (for sealing and compartment IDs) to enable experimentation and they should be removed as experiments are completed.
Indeed I think that is a better approach. To provide a bit of context, ASan cannot invoke libc functions, hence I modified it to access __elf_aux_vector. Thanks!
While working on ASan, I found that sysctl
kern.ps_strings
doesn't return a valid capability. Here is a simple poc (compiled withcc
in CheriBSD Morello releng/24.05 without additional flags):Here is another program that uses sysctl
kern.proc.KERN_PROC_AUXV
to getAT_PS_STRINGS
(the outputpss
is also untagged):