Re: RFC: New security model secmodel_securechroot(9)

[Aleksey Cheusov <cheusov%tut.by@localhost>]

 >> 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.
Fixed

 >>      ·   Processor-set manipulation is not allowed.

> Please cross reference what you mean here (cpuctl(8), I take?)
No. schedctl(8).
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
documentation.

Updated manual page is below. I hope now it is better. Thanks for your
comments.

======================================================================

NAME
     secmodel_securechroot -- securechroot security model

DESCRIPTION
     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
     processes.

     ·   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
         mounts

     ·   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
         chroot

     ·   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-
         ple, ps(1)

     ·   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
         hardware

     ·   Changing the entropy pool and privileged settings of rnd(4)

     ·   Modifying machine-dependent requests

     ·   Access to kmem(4) files /dev/mem and /dev/kmem

SEE ALSO
     chroot(2) kauth(9), secmodel(9)

AUTHORS
     Aleksey Cheusov <cheusov%NetBSD.org@localhost>

     Elad Efrat <elad%NetBSD.org@localhost> provided guidance and answered 
questions
     about the kauth(9) framework.

     The idea of a hardened chroot comes from the grsecurity project.
     http://grsecurity.org/

-- 
Best regards, Aleksey Cheusov.