Re: RFC: New security model secmodel_securechroot(9)

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Jul 10, 2011 at 05:51:12PM +0300, Aleksey Cheusov wrote:
>  >>      ·   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.

Please make sure that it is clear that you mean the global scheduler
settings and not the pthread affinity flags.

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

That's problematic for programs dealing with cryptographic material,
which often (intentionally) disallow core dumps for obvious reasons.

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

Not necessary and again, there are valid reasons for the interface in
first place. Prohibiting raising the hard limits is fine -- e.g. dumb
the interface down to the normal non-root functionality. But don't break
it beyond that.

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

Alas it is one of the areas where you actually want to have as few
permissions as possible.

Joerg