> (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 <[email protected]> > 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.
