[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: New security model secmodel_securechroot(9)
> 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
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
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?
>> dict://dictd.xdsl.by - RFC2229 service for slavic dictionaries
>> dict://dictd.xdsl.by:26280 - pkgsrc pkg_online database
> 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.
Main Index |
Thread Index |