Re: RFC: New security model secmodel_securechroot(9)

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

> (Sorry, I forgot to add in my last message that I am not subscribed to
> this list, so please cc me in replies.)

>    Date: Sun, 10 Jul 2011 21:57:03 +0300
>    From: Alexey Cheusov <cheusov%tut.by@localhost>

>    As I said earlier my code is based solely on kauth(9) and I assume
>    it is correct. Also I assume my code is correct because I tested it
>    and I could not find any problems.

> That's not really what I was asking about.  Simply being based on
> kauth(9) is not sufficient to enforce a useful security policy.  What
> you have tested -- if I understand correctly from the rest of your
> message -- is that the front door is closed and locked, but someone
> clever could pick the lock, and someone very clever could walk in
> through the missing wall on the side.

Now I see your point. I can prove that there is at least one hidden door
in the wall. It is fchdir(2). In most UNIX systems fchdir provides a way
to escape from chroot. NetBSD seems the only OS where changing current
directory above the / using fchdir is not allowed.  This was implemented
long before kauth appeared, in NetBSD-1.4 AFAICS.  So, not all dangerous
requests are passed through kauth(9) and therefore not passed to
secmodel_securechroot. One of the first patch I sent to Elad moved
appropriate code to kauth but he asked me to not touch existing
functionality and provide only new one for a number of reasons.
Anyway this door is closed.

Maybe there are other paths not covered by kauth (I thought about shared
memory but I've not checked it yet, a lot of work last week). Actually
I'm new to kernel development (my primary area of interest is pkgsrc)
and didn't find all such paths. This is why I asked subscribers for a
help and review.

Another path to break the system by chrooted process is to use loopback
network interface that often listens to many ports unseen from the
outside.

> For instance, perhaps from within the chroot I can use fhopen to
> replace /bin/sh outside the chroot by a program that opens /dev/kmem
> and does horrible things.
I'll look at fh* functions.
Access to /dev/kmem is not allowed from chroots if securechroot is enabled.

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

> If not, what does an operator need to do to set up
> the chroot to get your kauth secmodel to block them?
At least don't create unnecessary device files. I said about
KAUTH_DEVICE_RAWIO_SPEC earlier.

-- 
Best regards, Aleksey Cheusov.