On Sat, Jul 09, 2011 at 12:03:50PM +0300, Aleksey Cheusov wrote: > DESCRIPTION > 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. I would also suggest to split the list into: (1) Things a process running as UID 0 is normally allowed to do. (2) Things a process not running as UID 0 is normally allowed to do. > · Module requests are not allowed. Does this include automatic loading of modules as side effect of actions or not? > · Processor-set manipulation is not allowed. Please cross reference what you mean here (cpuctl(8), I take?) > · Changing coredump settings for set-id processes is not allowed. Does this mean setrlimit(2) is prohibited for disabling core dumps? > · 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. > · Decreasing process nice is not allowed. > > · Setting the scheduler affinity, policy, and parameters is not > allowed. I think this is too restrictive. Prohibiting use of real time priorities is fine, but otherwise it is valid (and safe) to do thread pinning etc. > · Setting the process resource limits is not allowed. Lowering should still be possible. > · 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. > · Routing-related requests are not allowed. Obtaining the routing table is sometimes needed for proper operation. Joerg
