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

>    - 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
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), 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 

Some recommended reading you might find useful:
* https://archive.fosdem.org/2015/schedule/event/openconnect_vpn/

>    - 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?)

>    - 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
help here?

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

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

> Thank you for your opinion!

Just my 2c. Hope they will be helpful.

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

Reply via email to