Hi Zbyněk,

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

Thanks for sharing this with the community!

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

This approach sounds like delegating the problem to authors of SCE checks 
Each script will have to support offline scan in its own way.
But I suspect that somewhere in first line of those scripts chroot will be 
anyway called.

> - 2] oscap will do chroot before execute script
>   - Script don't need to know that it is in different root

I think that we want this second option, because then the SCE scipts
could be simple and universal and everybody will be able to use his old
content to scan his containers and VMs.

> 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
>    - not easy way to detect offline scan support of script

That seems like breaking the simplicity and purpose of SCE.
One of purposes of SCE is to allow easy transition from old script-based
solutions to SCAP -eg. user takes some big bundle of scripts that he developed
for many years and just references them from XCCDF, and continuously replaces
one by one by OVALs.

>  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)
>    - offline scan of incompatible architecture will not work (but majority
>    use x86_64)
>    - complicated way to execute script in new root if FS is read_only and
>    script cannot be copied
>       there

I would like to know if there is a way to avoid those security implications.

> Which of these two methods is better? Or do you any have better idea?

Does something like a ""fake chroot"" exist?
I mean that binaries will be loaded from outside == from host,
but other files will be accessed as in chroot.

> 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.
> 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.
>    - after chroot
>      - again, we will run container code with root rights in chroot

I think it should be done before chroot.
Does anyone have an experience / suggestion how to do that?
Is there any use case when this must be done after chroot?

> Thank you for your opinion!

Best Regards

Jan Černý
Security Technologies | Red Hat, Inc.

> 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

Reply via email to