tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: New security model secmodel_securechroot(9)

On Tue, 12 Jul 2011 04:49:48 +0000, Taylor R Campbell wrote:
Perhaps there's a similar hole in your kauth secmodel that lets
chrooted processes rewrite arbitrary kernel memory (even without, say,
a buffer overflow bug in the kernel); perhaps you need another tiny
tweak to close the hole. 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.

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?  If not, what does an operator need to do to set up
the chroot to get your kauth secmodel to block them?

Well, normally (except for bugs or conception errors), kauth is supposed to sit at every point in kernel where authorization has to be enforced.

It's quite some feat to have a fine-grained framework where each of his rule has no impact on another one, especially when you have millions lines of code involved; it may even lead to contradictions when you start adding negations, e.g.:
- foo is allowed to load modules
- foo is /not/ allowed to access /root/

Which is evidently flawed.

The purpose of his patch is to make system's information gathering more difficult from a chroot, and raise process containment a bit further. I doubt that the ultimate goal is to completely protect system from exploitation, especially when the chroot is improperly built and run.

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index