41–50 of 51 posts
Earlier quoted context omitted.
Do Docker images really have to contain an entire bloated Linux distro? Even for Xen, which, as a hypervisor, provides fewer services than Docker, it's possible to write applications which run directly under Xen.
They don't have to, one can run static binary without any problems. It's just that most people keep throwing in a whole distro...
Earlier quoted context omitted.
You have runtime information though. It's true that this method will not find all things (dlopened files in strange codepaths), but just like we have tools that can verify 100% code coverage in tests, you could fuzz inputs until you find that you've hit every single branch of the executable's instructions and record all dependencies as you go. You could argue that that can still be fooled by, e.g., making the softwar…
I don't think you can ever prove that you've found the required files for an arbitrary binary. (I especially have a hard time believing that such a proof would involve fuzzing, which is random.) However, it seems reasonable that you would be able to achieve a high enough level of confidence that this technique would be viable.
do something with foo.txt
You can, however, prove that you've found a superset of the required files for an arbitrary binary. Or prove that you've found the required files for some, but not all, arbitrary binaries.
Earlier quoted context omitted.
Variation on the halting problem? Given infinite running time and arbitrary input, can you prove that a program will never access file X.
There's no general algorithm, but you could probably prove it, if you tried really hard for your given example. :D
Earlier quoted context omitted.
I beg to differ, but we can probably compare data points until the cows come home. Anyhow, even a large-ish application such as Oracle or a control system doesn't actually use ping or dd or troff, or most parts of what a modern unix-OS is comprised of. Most things suid are usually unnecessary, which if nothing else does decrease the attack surface. Most web apps probably needs nothing unix-ish at all. A chrooted PHP…
I agree that it's common, but it's not common enough to make this into a helpful property if you're trying to define a 100% solution. The reason Docker exists at all, apart from just nsexec(1)ing static binaries, is that a lot of things do need an environment—not of other Unix binaries per se, but of library assets like locales, charmaps, keymaps, geoip mappings, etc.—and then these asset packages think they're there…
You mean like in this blog-post: https://blog.docker.com/2013/06/create-light-weight-docker-c...
Earlier quoted context omitted.
I don't think you can ever prove that you've found the required files for an arbitrary binary. (I especially have a hard time believing that such a proof would involve fuzzing, which is random.) However, it seems reasonable that you would be able to achieve a high enough level of confidence that this technique would be viable.
You cannot. It reduces to the halting problem, relatively trivially: do something with foo.txt This will use foo.txt iff said code halts. You can, however, prove that you've found a superset of the required files for an arbitrary binary. Or prove that you've found the required files for some, but not all, arbitrary binaries.
You cannot say you haven't found all the dependencies, but you can say you have found all the dependencies (given the constraints I placed above).
The halting problem only says that you cannot prove that a given program will halt.
However, you can prove a specific program halts if, in fact, that program halts.
The original question was not "can prove that I can find the dependencies for an arbitrary binary", but "can you prove that all the dependencies were found for a single specific binary".
For some program that has an infinite loop you can say "I don't know if I've found everything", but if you have shown that you have hit every code branch, as I said above, then clearly this program both halts and has had all dependencies found, excepting different behavior for user input within those already explored branches.
Earlier quoted context omitted.
I beg to differ, but we can probably compare data points until the cows come home. Anyhow, even a large-ish application such as Oracle or a control system doesn't actually use ping or dd or troff, or most parts of what a modern unix-OS is comprised of. Most things suid are usually unnecessary, which if nothing else does decrease the attack surface. Most web apps probably needs nothing unix-ish at all. A chrooted PHP…
I agree that it's common, but it's not common enough to make this into a helpful property if you're trying to define a 100% solution. The reason Docker exists at all, apart from just nsexec(1)ing static binaries, is that a lot of things do need an environment—not of other Unix binaries per se, but of library assets like locales, charmaps, keymaps, geoip mappings, etc.—and then these asset packages think they're there…
I regularly run it chrooted without problems. You do need to understand you use case however. Things like external database utilities and backup scripts differ in requirements. Some of them are run outside the chroot, some don't.
It's absolutely not complicated, and if you have the faintest idea what you're doing it's much easier to get right than the fanotify dance described above.
And a complete operating system in a chroot would sit mostly unused, and only increase the attack surface for no reason at all. So, why?