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