[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: New security model secmodel_securechroot(9)
>> The securechroot security model is intended to protect the system
>> against destructive modifications by chroot-ed processes. If
>> enabled, secmodel_securechroot applies the following restrictions
>> to chroot-ed processes.
> Don't repeat "not allowed" over and over again.
>> · Processor-set manipulation is not allowed.
> Please cross reference what you mean here (cpuctl(8), I take?)
CPU manipulations using cpuctl(8) is also not allowed.
>> · Changing coredump settings for set-id processes is not allowed.
> Does this mean setrlimit(2) is prohibited for disabling core dumps?
Disabling core dump generation is not allowed in chroots due to
denying KAUTH_REQ_PROCESS_RLIMIT_SET requests.
But the sentence above is about changing kern.coredump.setid only.
>> · Access to a process using ptrace(2) and ktrace(2) is allowed
>> only if it belongs to the same chroot.
> It might be useful to clarify what "same chroot" means here and move
> them to a separate list under this definition.
Processes having the same root directory are run in the "same chroot".
Have a look how KAUTH_PROCESS_SIGNAL or KAUTH_PROCESS_CANSEE were
implemented. kauth_cred_getdata(cred, rootdir_key) != p->p_cwdi->cwdi_rdir
>> · Setting the process resource limits is not allowed.
> Lowering should still be possible.
Resource limits can be prepared before running chroot-ed daemon. In any
way we can allow lowering rlimits (excluding max core file size) later.
>> · Firewall-related operations such as modification of packet
>> filtering rules or modification of NAT rules are not allowed.
> Table manipulation is a valid use case of a chroot, especially a
> restricted chroot. Consider FTP proxies as example.
I agree with John Nemeth here.
>> · Routing-related requests are not allowed.
> Obtaining the routing table is sometimes needed for proper operation.
Read access to network routing tables is allwed. I've fixed the
Updated manual page is below. I hope now it is better. Thanks for your
secmodel_securechroot -- securechroot security model
The securechroot security model is intended to protect the system
against destructive modifications by chroot-ed processes. If
enabled, the fol- lowing actions are not allowed for chroot-ed
· chroot(2) and fchroot(2)
· Setting the CPU state using cpuctl(8)
· Debugging-related operations using ipkdb(4)
· Quota operations on file systems
· Using the file system reserved space
· Creating devices using mknod(2)
· Loading and unloading modules
· Processor-set manipulation
· Rebooting the system
· Changing coredump settings for set-id processes
· swapctl(2) modifying operations
· Mounting new file systems, unmounting, and changing existing
· Access to a process using ptrace(2) and ktrace(2) if it doesn't
belong to the same chroot
· Access to a process using procfs if it doesn't belong to the same
· Sending signals to a process if it doesn't belong to the same chroot
· Only processes belonging to the same chroot are visible by, for exam-
· Decreasing process nice
· Setting the scheduler affinity, policy, and parameters
· Setting the process corename
· Setting the process resource limits
· Firewall-related operations such as modification of packet filtering
rules or modification of NAT rules
· Network interface-related operations such as setting parameters on
the device or setting privileged parameters
· Adding and enabling network interfaces
· Modification of network routing tables
· Changing privileged settings of Bluetooth devices.
· Hardware passthru requests and user commands passed directly to the
· Changing the entropy pool and privileged settings of rnd(4)
· Modifying machine-dependent requests
· Access to kmem(4) files /dev/mem and /dev/kmem
chroot(2) kauth(9), secmodel(9)
Aleksey Cheusov <cheusov%NetBSD.org@localhost>
Elad Efrat <elad%NetBSD.org@localhost> provided guidance and answered
about the kauth(9) framework.
The idea of a hardened chroot comes from the grsecurity project.
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |