----- Original Message ----- > From: "Jan Cerny" <jce...@redhat.com> > To: "Jan Lieskovsky" <jlies...@redhat.com> > Cc: open-scap-list@redhat.com > Sent: Friday, April 15, 2016 2:15:10 PM > Subject: Re: [Open-scap] Offline scanning - SCE, probes > > Hi Iankko, > > ----- Original Message ----- > > From: "Jan Lieskovsky" <jlies...@redhat.com> > > To: "Zbynek Moravec" <zmora...@redhat.com> > > Cc: open-scap-list@redhat.com > > Sent: Friday, April 15, 2016 1:26:09 PM > > Subject: Re: [Open-scap] Offline scanning - SCE, probes > > > > > > Hello Zbynek, > > > > ----- Original Message ----- > > > From: "Zbynek Moravec" <zmora...@redhat.com> > > > To: open-scap-list@redhat.com > > > Sent: Wednesday, April 13, 2016 11:47:51 PM > > > Subject: [Open-scap] Offline scanning - SCE, probes > > > > > > Hi > > > > > > We plan to implement offline scan support for SCE scripts. I would like > > > to > > > ask > > > for our opinion. > > > > > > We have two? options how to deal with SCE offline scan support > > > - 1] pass new root path to script (env variable) > > > - Script will decide how to scan new root, it can use path prefix, > > > chroot.. > > > - 2] oscap will do chroot before execute script > > > - Script don't need to know that it is in different root > > > > > > > > > Pros/Cons: > > > 1] > > > + easy to implement in oscap > > > + script can use best way to perform offline_scan > > > - old SCE scripts are not compatible > > > - lot of work to deal with offline scan in every script > > > > IMHO the purpose of well-written software should be to hide all > > the underlying complexity from the user. This approach seems > > to contradict to that (be opposite to that). > > +1 Indeed. > > > > > > - not easy way to detect offline scan support of script > > > > > > 2] > > > + we can use old SCE scripts, easily write new one > > > - potentially execute evil code(grep/... called from script) with root > > > rights (but in chroot) > > > > If you are worried about possible security implications of such invocation, > > have a look at isolation / resource restriction possibilities. Besides > > I think that main woe is about possible "escaping from chroot jail" > > > chroot it's possible to use e.g. ptrace / (lib)seccomp to filter system > > calls, > > (lib)cgroup to limit resources used by the script, SELinux rules for proper > > labeling (least privilege) > > oscap and probes are now unconfined_t. > If I undestand it well, the child process inherits SELinux context from > parent process. > Lukáš said yesterday that changing the context from inside the application > code > is a nasty hack and that a special SELinux policy should be written for this. > > > > , separate namespaces for the SCE process. > > > > Shouldn't this all be sufficient, it's even possible to create new LXC > > container > > for each such a SCE script and run it there (but IMHO this would be pretty > > big overload). > > > Some recommended reading you might find useful: > > * https://archive.fosdem.org/2015/schedule/event/openconnect_vpn/ > > * > > http://openalt.cz/2015/data/Jan%20Lieskovsky%20-%20the_methods_of_sandboxing_and_isolation.pdf > > * > > https://www.berrange.com/posts/2012/01/17/building-application-sandboxes-with-libvirt-lxc-kvm/ > > > > > - offline scan of incompatible architecture will not work (but > > > majority > > > use x86_64) > > > > Can you be more specific? You mean "cross offline scan" (e.g. x86_64 vs > > s390[x] won't work?) yes. If we check existence of file using "ls" what was build for s390 on x86_64 host, it will not work. But we can perform it using host version of "ls" > > > > > - complicated way to execute script in new root if FS is read_only and > > > script cannot be copied > > > there > > > > Might the approach to create own minimal root FS e.g. with busybox > > (https://www.berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/ > > ) > > help here? > > Not really. Maybe I didn't understand what should I find in this link. My ideas how to solve the problem I've summarized in https://www.redhat.com/archives/open-scap-list/2016-April/msg00039.html. > > > > > > Which of these two methods is better? > > > > I like the second one more (since it doesn't bring additional complexity > > to the way users are accustomed to define SCE scripts today). > > > > > Or do you any have better idea? > > > > > > > A way to setup / establish a safe playground for execution of SCE scripts > > seems to be the way. But your second proposal is already proposing it. > > > > > > > > > > > Similar question I have about probes which support offline scan. > > > > > > Simplified phases of rpm probe life. > > > 1] begin > > > 2] chroot > > > 3] init - rpmReadConfigFiles > > > 4] collect > > > 5] end > > > > > > During phase 3, some of dynamic libraries are loaded from new root. > > > > Is the reason for this behaviour the fact the necessary *.so files > > aren't present in original root => thus linker can't load them sooner? > > Or doesn't need to load them yet because they weren't referenced yet? > > Or something else? Are we able to tell? Main reason is that they weren't referenced before chroot. I think, author of current implementation didn't think about it, because it "usually" works in both cases. Unfortunately no function like "load_all_possible_libraries()" doesn't exist. > > > > > Question is - when to load libraries? > > > - before chroot > > > - We can try to force libraries to load their dynamic parts before > > > chroot, > > > but it require some effort. > > > > Obviously (IMHO at least) we would want to load them as soon as possible > > (thus yet even before chroot). If that's not possible we should > > investigate, > > why that's the case. > > > > > > > > - after chroot > > > - again, we will run container code with root rights in chroot > > > > Maybe here we could again use seccomp to filter out dlopen() system call, > > so it wouldn't actually load anything (but this assumes all symbols are > > loaded before chroot() yet). > seccomp seems to be way. But I think dlopen() is not system call. I've found uselib(). But I will try to investigate system call used to loading of dynamic library. > I think we have to load all necessary libraries from the host > and then block loading any libraries after chroot() call. > > > > > > > > > > > > Thank you for your opinion! > > > > Just my 2c. Hope they will be helpful. > > Definitely, thank you! > > Have a nice weekend > > > Jan Černý > Security Technologies | Red Hat, Inc. > > > > > > > > > Thank you && Regards, Jan > > -- > > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > > > > > > Zbynek Moravec > > > OpenSCAP > > > > > > > > > > > > _______________________________________________ > > > Open-scap-list mailing list > > > Open-scap-list@redhat.com > > > https://www.redhat.com/mailman/listinfo/open-scap-list > > > > > > > _______________________________________________ > > Open-scap-list mailing list > > Open-scap-list@redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list@redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list
_______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
