[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: New security model secmodel_securechroot(9)
> (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
> 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
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |