Re: RFC: New security model secmodel_securechroot(9)

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

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

Unfortunately your paraphrasing doesn't help to understand the question
better. I wrote the code having kauth(9) in hand and analysed *each*
authorization request provided by kauth and thought about should it be
allowed from inside chroot or not, and if yes, in which cases. After
that I implemented corresponding listeners and "switch/cases".  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. If you think it is buggy, please let me
know.

Note: while implementing securechroot I found that settimeofday(2), for
example, ignores KAUTH_RESULT_DENY returned for KAUTH_SYSTEM_TIME kauth
request. So, not *everything* is covered by kauth(9) and there are some
problems to be fixed. But this is not a part of my project, so I didn't
raise this question.

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

Ok. If you have some details about how to document
"careful chroot creation" could you please email me offlist?

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

For each listerner, each authorization request and if/else statement
I used at least one command from base or hand-written executable for
testing whether my code works as expected or not. For example, I used
'kill -TERM <pid>' for testing KAUTH_PROCESS_SIGNAL,
'cat /pric/1/maps' -- for KAUTH_PROCESS_PROCFS,
'ps' -- for KAUTH_PROCESS_CANSEE
'ipf' -- for KAUTH_NETWORK_FIREWALL and so on.

Do you want to see a full description of testing procedure I used while
development in order to make possible to doubletest
everything declared in the manual page?

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


- Setup 'modload securechroot' for running before chrooted daemons are run
- Run chrooted daemons

For testing I worked like the following
- modload securechroot
- chroot /var/chroot/lalala
- play/test inside chroot
- exit from chroot
- modunload securechroot

What kind of details do uou need?

-- 
Best regards, Aleksey Cheusov.