[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: New security model secmodel_securechroot(9)
On Sat, Jul 09, 2011 at 12:03:50PM +0300, Aleksey Cheusov wrote:
> 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
> · 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
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.
Main Index |
Thread Index |