Re: RFC: New security model secmodel_securechroot(9)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Jul 10, 2011 at 06:42:51PM +0300, Aleksey Cheusov wrote:

Aleksey,

Please keep some more citation information when quoting.  I can't tell
to whom you're responding here!

> > very roughly) sketch a proof that the details you've implemented
> > accomplish that goal?
> securechroot relies solely on kauth(9), so every authorization request
> supported by kauth(9) is either defered or denied by securechroot.

As someone who has written kauth security models myself, I don't think
you've really answered the question that was asked.

How does "every authorization request supported by kauth(9) is either
deferred or denied by securechroot" prove anything about whether the
specific set of defers/denies you've implemented actually provably
enforce some more abstractly stated security policy?  I think that is what
you're being asked, and I encourage you to think it over.

> > and can you show (at least informally) that every pathway in the
> > kernel to them is blocked by the operations you have prohibited, or at
> > least show under what hypotheses these pathways are blocked?
> In short, this is a zone of responsibility of kauth(9).

I don't really think this is an answer, for the same reasons stated
above.

> > That is, what an operator needs to do in order to use a
> > securechroot safely?
> modload securechroot

That's just plain false.  For example, because we still don't have any
protection against access to overlapping partitions of disk devices,
the operator must carefully build a /dev that will not allow the captive
program to tamper with filesystems using this mechanism.

The restriction against mknod(2) is clever, and *makes it possible to
carefully construct such a /dev inside the chroot* -- but that does not
mean the requirement for carefully building a /dev and making other
in-chroot adjustments is not necessary.  In fact, given the grab-bag
nature of the restrictions imposed here I think many such details of
the chroot's construction will be quite important, and they need to be
carefully documented.

You mention something along these lines later in your message when asked
for an example, but I am concerned that, in fact, a fully-worked example
is needed, with an explanation of why the example actually works together
with the security model to achieve the goal.  That there are several
different goals at the same time...worries me.

I have written three security models (one almost identical to this one)
using kauth, each intended to protect an embedded system runtime from, I
think, many of the same attacks you are worried about here.  Each time I
sat down to properly explain the operation of the security model and
document in detail an example, I found bugs.  And I am not a great
programmer nor a great security thinker but I am not such a bad one either.

Given that experience, I really think you should go through the exercise
of more formally and carefully writing up exactly what you're doing and
how at least one detailed example achieves that goal, from the system
configuration level all the way down through the source code of your
secmodel.

> > Do you have examples of safe use of securechroots to contain practical
> > applications?
> http://dictd.xdsl.by
> dict://dictd.xdsl.by       - RFC2229 service for slavic dictionaries
> dict://dictd.xdsl.by:26280 - pkgsrc pkg_online database 
> (pkgtools/pkg_online-client)

This is a list.  I do not think the person who asked you the question wanted
a list, I think he wanted a detailed example.  But I could be mistaken.

> The only problem is that I couldn't find an easy way to load modules at
> boot time like it is provided by Linux's /etc/modules.  I implemented
> home-made rc.d script.

Um.  The boot blocks can do this.

Thor