[Open-scap] XCCDF with Shell Script Engine

[Peter Vrabec]

Hi Chandra,


On Monday, December 19, 2011 01:44:18 PM Chandrashekhar B wrote:
> Yes, I agree, there's definitely a need for allowing script execution in
> OVAL. There are number of vulnerabilities that need to be checked remotely,
> sending packets, analyzing responses etc. There has been a discussion around
> this in the OVAL community as Danny identified in another response. I am
> sure community will agree upon such an ability.
I'm happy that community would agree on that. Frankly, I'm not the one who 
would scream "Don't do that!" :) I'm just not convinced that XCCDF->OVAL-
>Script is the best approach. 


> One comment on your approach: Instead of driving it through XCCDF (check
> system), we can define a new test in the OVAL for script execution. This
> will ensure that metadata schema is used, system-characteristics and results
> schema are used as well.
XCCDF->Script is quite easy thing to do. I mean it does not cost us too much  
because we already have XCCDF handling in OpenSCAP. SCE(Shell Script Engine) 
can be provided as encapsulated checking engine besides OVAL and OCIL.


Peter.



> Thanks,
> Chandra.
> 
> -----Original Message-----
> From: open-scap-list-bounces at redhat.com
> [mailto:open-scap-list-bounces at redhat.com] On Behalf Of Peter Vrabec
> Sent: Friday, December 16, 2011 7:10 PM
> To: open-scap-list at redhat.com; Jeffrey Blank
> Subject: [Open-scap] XCCDF with Shell Script Engine
> 
> Hi folks,
> 
> from time to time I see people talking about possibility to use/call system
> commands in OVAL content. There are various reasons for such a desire:
> 
> * missing OVAL object -> it's impossible to implement a check
> * OVAL content is too complex (one line in bash => 30 lines in OVAL)
> * lack of deeper OVAL knowledge
> * evaluation of OVAL content consume too much resources (poorly written
> content)
> 
> If my understanding of OVAL philosophy is correct, such functionality should
> never get into OVAL specs. It would basically break the whole philosophy
> and values. Right? :)
> 
> On the other side I can imagine valid use cases for using system commands,
> let's say shell scripts, to perform the check.
> 
> * shell script check can be a prototype before valid OVAL test is written
> * existing checking scripts can be used with XCCDF before their OVAL
> counterparts are written
> * shell script can handle cases where needed OVAL object does not exist
> * shell script approach could be used in environments where compliance check
> requirements do not insist on XCCDF + OVAL
> 
> 
> So what is the solution?
> 
> I think it's very valuable to use XCCDF to specify security checklists
> (profiles) and start using additional checking engine that enable users and
> content creators to call shell scripts when needed. In the end it's as
> simple as referencing a script instead of OVAL XML in your rules.
> 
> We put experimental support for shell script check engine with the latest
> commit:
> 
> commit 9044335936736e7a49e021020f46b161ea6c2109
> Author: Martin Preisler <mpreisle at redhat.com>
> 
>     Added script check engine (experimental)
> 
> 
> How to use it?
> 
> 1. Enable it first!
>       $ ./configure --enable-sce
> 
> 2. Call shell script from XCCDF.
> example:
>       <check system="http://open-scap.org/XMLSchema/SCE-definitions-1">
>         <check-content-ref href="unconfined_daemons.sh"/>
>       </check>
> 
> 3. Write a shell script (unconfined_daemons.sh in our case) and put it into
> same directory as XCCDF content.
> 
> 4. Run it
> & oscap xccdf eval --profile default --results result.xml sce_xccdf.xml
> 
> 5. See the results.
> Our example shell script examine whether you run any daemons in unconfined
> SELinux domain. The result will be available in XCCDF results file.
> 
> 
> That's it. Please note that this is work in progress.
> * we have bugs :)
> * we don't handle XCCDF variables and operators yet. (plan is to pass them
> via
> environment variables)
> * we don't produce shell script results file (TODO).
> * we want to use some kind of jail for shell script execution.
> 
> 
> 
> Peter.