Re: RFC: New security model secmodel_securechroot(9)

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

 >> > So what is the security policy you mean to enforce by blocking paths
 >> > into the kernel with kauth?  For every `destructive modification' that
 >> > can be done to the system, what is every path into the kernel that
 >> > leads to that modification?
 >> >  Have you blocked all such paths in your kauth secmodel?
 >>
 >> I'm open for concrete ideas and references.

> I haven't followed the discussion that closely, but the following list appears
> in the chroot(2) restrictions of the PaX/Grsecurity (Linux) project:

>     * No mknod
>     * No sysctl writes
>     * No raising of scheduler priority
>     * No kill outside of chroot
>     * No ptrace outside of chroot (architecture independent)
>     * No viewing of any process outside of chroot, even if /proc is mounted
>     * No mounting or remounting
>     * No double chroot
All of the above is already implemented

>     * No fchdir out of chroot
>     * Enforced chdir("/") upon chroot
This is done not in securechroot but other parts of the kernel (fchdir
since 1.4).

>     * No (f)chmod +s
I'm not sure this makes any sense.

>     * No pivot_root
>     * No capget outside of chroot
>     * Removal of harmful privileges via capabilities
Linux-sisms

>     * Exec logging within chroot
What's this?

>     * No connecting to abstract unix domain sockets outside of chroot
>     * No attaching shared memory outside of chroot
>     * No getsid outside of chroot
>     * No setpgid outside of chroot
>     * No getpgid outside of chroot
>     * No sending of signals by fcntl outside of chroot
This needs additional checks and probably fixes.
I'd like to commit my initial version of securechroot and then
fix the rest problems one-by-one.

-- 
Best regards, Aleksey Cheusov.