RR
Rocio Romero
Wed, Jun 15, 2016 5:36 PM
Hi everyone,
Maybe some of you can help my with this.
I’m creating some news checks in a oval file, and I would like to know if there is anyway to check the output of a command line to test some patterns against the output.
Thank you so much!
...
Hi everyone,
Maybe some of you can help my with this.
I’m creating some news checks in a oval file, and I would like to know if there is anyway to check the output of a command line to test some patterns against the output.
Thank you so much!
...
DS
David Solin
Wed, Jun 15, 2016 9:29 PM
Hi Rocio,
There is not. Part of the “contract” of the OVAL language is that — being a compliance language — it is intended to have a “read-only” effect. If OVAL could run arbitrary commands, it would make the implementing security tools an excellent attack vector (although that could be mitigated with digitally signed content).
At the same time, some of us do recognize the need for a way to do what you’re talking about, in part as a “stop-gap” for implementing checks that perhaps cannot be implemented in OVAL without introducing a change in the OVAL language itself. For this purpose, RedHat came up with something called SCE (which stands for Script Check Engine), which makes it possible to write an arbitrary executable script and map it to a rule result in XCCDF (a related SCAP specification).
SCE is documented here:
https://www.open-scap.org/features/other-standards/sce/
I only know of two tools that implement SCE, one is OpenSCAP, and the other is Joval Continuous Monitoring. If there are any others, hopefully they’ll chime in.
Let me know if you want to discuss whether your use-case, and whether it might be addressable by an existing check in OVAL.
Best regards,
—David A. Solin
Hi Rocio,
There is not. Part of the “contract” of the OVAL language is that — being a compliance language — it is intended to have a “read-only” effect. If OVAL could run arbitrary commands, it would make the implementing security tools an excellent attack vector (although that could be mitigated with digitally signed content).
At the same time, some of us do recognize the need for a way to do what you’re talking about, in part as a “stop-gap” for implementing checks that perhaps cannot be implemented in OVAL without introducing a change in the OVAL language itself. For this purpose, RedHat came up with something called SCE (which stands for Script Check Engine), which makes it possible to write an arbitrary executable script and map it to a rule result in XCCDF (a related SCAP specification).
SCE is documented here:
https://www.open-scap.org/features/other-standards/sce/
I only know of two tools that implement SCE, one is OpenSCAP, and the other is Joval Continuous Monitoring. If there are any others, hopefully they’ll chime in.
Let me know if you want to discuss whether your use-case, and whether it might be addressable by an existing check in OVAL.
Best regards,
—David A. Solin
> On Jun 15, 2016, at 12:36 PM, Rocio Romero <rocio@wazuh.com> wrote:
>
> Hi everyone,
>
> Maybe some of you can help my with this.
>
> I’m creating some news checks in a oval file, and I would like to know if there is anyway to check the output of a command line to test some patterns against the output.
>
> Thank you so much!
>
>
> ...
>
> _______________________________________________
> OVAL_Developer mailing list
> OVAL_Developer@lists.cisecurity.org
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
...
DM
Darren Moffat
Wed, Jun 15, 2016 9:43 PM
On 15 Jun 2016, at 17:29, David Solin solin@jovalcm.com wrote:
recognize the need for a way to do what you’re talking about, in part as a “stop-gap” for implementing checks that perhaps cannot be implemented in OVAL without introducing a change in the OVAL language itself.
There are also cases where it isn't worth creating an OVAL schema for a single check. SCE is ideal for that.
As for the attack vector of arbitrary scripting that can be mitigated by using platform provided privilege bracketing and RBAC features to limit what those scripts can do. We can easily do this on Solaris with OpenSCAP by using the Solaris privilege model that can even limit what root can do.
Darren
...
> On 15 Jun 2016, at 17:29, David Solin <solin@jovalcm.com> wrote:
>
> recognize the need for a way to do what you’re talking about, in part as a “stop-gap” for implementing checks that perhaps cannot be implemented in OVAL without introducing a change in the OVAL language itself.
There are also cases where it isn't worth creating an OVAL schema for a single check. SCE is ideal for that.
As for the attack vector of arbitrary scripting that can be mitigated by using platform provided privilege bracketing and RBAC features to limit what those scripts can do. We can easily do this on Solaris with OpenSCAP by using the Solaris privilege model that can even limit what root can do.
Darren
...
GE
Gunnar Engelbach
Thu, Jun 16, 2016 12:57 AM
Rocio,
One of the conventions of OVAL is to stick with a definitive source for
the endpoints values you are writing OVAL for. Most likely the output
of the command you are referring to is pulled from some other source,
such as a configuration file, registry value, and so on. If you could
be more specific about which command you are looking at the output from,
maybe somebody on this list can help you track down the actual source of
that information -- even if it's just temporal information accessible
via the /proc file system.
It might be tempting to go the route that David/Darren suggested and use
SCE for this definition you are creating, but there's a good reason why
only two vendors have implemented that as a solution. Unless you are
specifically writing content that will only ever be used in one of those
two interpreters, it's best to stick with a solution that falls within
the standard.
--gun
On 6/15/2016 10:36 AM, Rocio Romero wrote:
Rocio,
One of the conventions of OVAL is to stick with a definitive source for
the endpoints values you are writing OVAL for. Most likely the output
of the command you are referring to is pulled from some other source,
such as a configuration file, registry value, and so on. If you could
be more specific about which command you are looking at the output from,
maybe somebody on this list can help you track down the actual source of
that information -- even if it's just temporal information accessible
via the /proc file system.
It might be tempting to go the route that David/Darren suggested and use
SCE for this definition you are creating, but there's a good reason why
only two vendors have implemented that as a solution. Unless you are
specifically writing content that will only ever be used in one of those
two interpreters, it's best to stick with a solution that falls within
the standard.
--gun
On 6/15/2016 10:36 AM, Rocio Romero wrote:
> Hi everyone,
>
> Maybe some of you can help my with this.
>
> I’m creating some news checks in a oval file, and I would like to know if there is anyway to check the output of a command line to test some patterns against the output.
>
> Thank you so much!
>
>
> ...
>
> _______________________________________________
> OVAL_Developer mailing list
> OVAL_Developer@lists.cisecurity.org
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
...
DJ
Darren J Moffat
Thu, Jun 16, 2016 5:58 PM
Rocio,
One of the conventions of OVAL is to stick with a definitive source for
the endpoints values you are writing OVAL for. Most likely the output
of the command you are referring to is pulled from some other source,
such as a configuration file, registry value, and so on. If you could
be more specific about which command you are looking at the output
from,
maybe somebody on this list can help you track down the actual source
of
that information -- even if it's just temporal information accessible
via the /proc file system.
That isn't a fair assumption, there are certainly cases in Solaris where the source of the information is binary or the backing store of it is not a documented interface - so third parties shouldn't be attempting to read the source file anyway.
There are also cases where the policy statement is too complex to implement in OVAL.
For example one of the rules we have in Solaris that I've just been fixing is this:
"All setuid binaries on the system must come from packages"
The implementation of this basically has to run a find over all the filesystems that are mounted setuid, and for each setuid file that is found check with the package system that the file was from a package.
Even with the IPS package schema for OVAL it is not possible to implement that rule, because OVAL just isn't expressive enough and can't deal with the iteration required to implement an example like the above.
We have quite a few checks in the Solaris policy that similar, but the majority of our checks are OVAL and some even use multiple OVAL schema in a single check (eg SMF and file schema).
It might be tempting to go the route that David/Darren suggested and
use
SCE for this definition you are creating, but there's a good reason why
only two vendors have implemented that as a solution. Unless you are
specifically writing content that will only ever be used in one of
those
two interpreters, it's best to stick with a solution that falls within
the standard.
--gun
On 6/15/2016 10:36 AM, Rocio Romero wrote:
Hi everyone,
Maybe some of you can help my with this.
I’m creating some news checks in a oval file, and I would like to
know if there is anyway to check the output of a command line to test
some patterns against the output.
On 16 June 2016 01:57:39 BST, Gunnar Engelbach <gunnar.engelbach@threatguard.com> wrote:
>
>Rocio,
>
>One of the conventions of OVAL is to stick with a definitive source for
>
>the endpoints values you are writing OVAL for. Most likely the output
>of the command you are referring to is pulled from some other source,
>such as a configuration file, registry value, and so on. If you could
>be more specific about which command you are looking at the output
>from,
>maybe somebody on this list can help you track down the actual source
>of
>that information -- even if it's just temporal information accessible
>via the /proc file system.
That isn't a fair assumption, there are certainly cases in Solaris where the source of the information is binary or the backing store of it is not a documented interface - so third parties shouldn't be attempting to read the source file anyway.
There are also cases where the policy statement is too complex to implement in OVAL.
For example one of the rules we have in Solaris that I've just been fixing is this:
"All setuid binaries on the system must come from packages"
The implementation of this basically has to run a find over all the filesystems that are mounted setuid, and for each setuid file that is found check with the package system that the file was from a package.
Even with the IPS package schema for OVAL it is not possible to implement that rule, because OVAL just isn't expressive enough and can't deal with the iteration required to implement an example like the above.
We have quite a few checks in the Solaris policy that similar, but the majority of our checks are OVAL and some even use multiple OVAL schema in a single check (eg SMF and file schema).
>It might be tempting to go the route that David/Darren suggested and
>use
>SCE for this definition you are creating, but there's a good reason why
>
>only two vendors have implemented that as a solution. Unless you are
>specifically writing content that will only ever be used in one of
>those
>two interpreters, it's best to stick with a solution that falls within
>the standard.
>
>
>--gun
>
>
>On 6/15/2016 10:36 AM, Rocio Romero wrote:
>> Hi everyone,
>>
>> Maybe some of you can help my with this.
>>
>> I’m creating some news checks in a oval file, and I would like to
>know if there is anyway to check the output of a command line to test
>some patterns against the output.
>>
>> Thank you so much!
>>
>>
>> ...
>>
>> _______________________________________________
>> OVAL_Developer mailing list
>> OVAL_Developer@lists.cisecurity.org
>>
>http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>
>
>...
>
>_______________________________________________
>OVAL_Developer mailing list
>OVAL_Developer@lists.cisecurity.org
>http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
--
Darren J Moffat
...
DS
David Solin
Thu, Jun 16, 2016 8:25 PM
Hi Darren,
I know this is tangential, but… I’d be interested in learning why you’re having trouble implementing that particular check in OVAL. (Feel free to email me off the list).
Best regards,
—David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com
Rocio,
One of the conventions of OVAL is to stick with a definitive source for
the endpoints values you are writing OVAL for. Most likely the output
of the command you are referring to is pulled from some other source,
such as a configuration file, registry value, and so on. If you could
be more specific about which command you are looking at the output
from,
maybe somebody on this list can help you track down the actual source
of
that information -- even if it's just temporal information accessible
via the /proc file system.
That isn't a fair assumption, there are certainly cases in Solaris where the source of the information is binary or the backing store of it is not a documented interface - so third parties shouldn't be attempting to read the source file anyway.
There are also cases where the policy statement is too complex to implement in OVAL.
For example one of the rules we have in Solaris that I've just been fixing is this:
"All setuid binaries on the system must come from packages"
The implementation of this basically has to run a find over all the filesystems that are mounted setuid, and for each setuid file that is found check with the package system that the file was from a package.
Even with the IPS package schema for OVAL it is not possible to implement that rule, because OVAL just isn't expressive enough and can't deal with the iteration required to implement an example like the above.
We have quite a few checks in the Solaris policy that similar, but the majority of our checks are OVAL and some even use multiple OVAL schema in a single check (eg SMF and file schema).
It might be tempting to go the route that David/Darren suggested and
use
SCE for this definition you are creating, but there's a good reason why
only two vendors have implemented that as a solution. Unless you are
specifically writing content that will only ever be used in one of
those
two interpreters, it's best to stick with a solution that falls within
the standard.
--gun
On 6/15/2016 10:36 AM, Rocio Romero wrote:
Hi everyone,
Maybe some of you can help my with this.
I’m creating some news checks in a oval file, and I would like to
know if there is anyway to check the output of a command line to test
some patterns against the output.
Hi Darren,
I know this is tangential, but… I’d be interested in learning why you’re having trouble implementing that particular check in OVAL. (Feel free to email me off the list).
Best regards,
—David A. Solin
Co-Founder, Research & Technology
solin@jovalcm.com
> On Jun 16, 2016, at 12:58 PM, Darren J Moffat <Darren.Moffat@ORACLE.COM> wrote:
>
>
>
> On 16 June 2016 01:57:39 BST, Gunnar Engelbach <gunnar.engelbach@threatguard.com> wrote:
>>
>> Rocio,
>>
>> One of the conventions of OVAL is to stick with a definitive source for
>>
>> the endpoints values you are writing OVAL for. Most likely the output
>> of the command you are referring to is pulled from some other source,
>> such as a configuration file, registry value, and so on. If you could
>> be more specific about which command you are looking at the output
>> from,
>> maybe somebody on this list can help you track down the actual source
>> of
>> that information -- even if it's just temporal information accessible
>> via the /proc file system.
>
> That isn't a fair assumption, there are certainly cases in Solaris where the source of the information is binary or the backing store of it is not a documented interface - so third parties shouldn't be attempting to read the source file anyway.
>
> There are also cases where the policy statement is too complex to implement in OVAL.
>
> For example one of the rules we have in Solaris that I've just been fixing is this:
>
> "All setuid binaries on the system must come from packages"
>
> The implementation of this basically has to run a find over all the filesystems that are mounted setuid, and for each setuid file that is found check with the package system that the file was from a package.
>
> Even with the IPS package schema for OVAL it is not possible to implement that rule, because OVAL just isn't expressive enough and can't deal with the iteration required to implement an example like the above.
>
> We have quite a few checks in the Solaris policy that similar, but the majority of our checks are OVAL and some even use multiple OVAL schema in a single check (eg SMF and file schema).
>
>> It might be tempting to go the route that David/Darren suggested and
>> use
>> SCE for this definition you are creating, but there's a good reason why
>>
>> only two vendors have implemented that as a solution. Unless you are
>> specifically writing content that will only ever be used in one of
>> those
>> two interpreters, it's best to stick with a solution that falls within
>> the standard.
>>
>>
>> --gun
>>
>>
>> On 6/15/2016 10:36 AM, Rocio Romero wrote:
>>> Hi everyone,
>>>
>>> Maybe some of you can help my with this.
>>>
>>> I’m creating some news checks in a oval file, and I would like to
>> know if there is anyway to check the output of a command line to test
>> some patterns against the output.
>>>
>>> Thank you so much!
>>>
>>>
>>> ...
>>>
>>> _______________________________________________
>>> OVAL_Developer mailing list
>>> OVAL_Developer@lists.cisecurity.org
>>>
>> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>>
>>
>> ...
>>
>> _______________________________________________
>> OVAL_Developer mailing list
>> OVAL_Developer@lists.cisecurity.org
>> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>
> --
> Darren J Moffat
>
> ...
>
> _______________________________________________
> OVAL_Developer mailing list
> OVAL_Developer@lists.cisecurity.org
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
...
RR
Rocio Romero
Thu, Jun 16, 2016 8:30 PM
Thank you so much to all of you for your answers.
What I wanted to check was some information about Selinux and iptables.
Actually Selinux is the example that we can find on the SCE webpage.
I have been taking a look to SCE, it seems that is going to work for me.
One question related with this: Can I use the package on Oracle Linux? If I
look with yum search, there is not any openscap-sce-engine... maybe install
it not by yum...
Thank you!
Rocio
*Rocio Romero *
IT Security Engineer
+1 415-481-5508
[image: http://www.wazuh.com/] http://www.wazuh.com/
On Thu, Jun 16, 2016 at 10:58 AM, Darren J Moffat darren.moffat@oracle.com
wrote:
Rocio,
One of the conventions of OVAL is to stick with a definitive source for
the endpoints values you are writing OVAL for. Most likely the output
of the command you are referring to is pulled from some other source,
such as a configuration file, registry value, and so on. If you could
be more specific about which command you are looking at the output
from,
maybe somebody on this list can help you track down the actual source
of
that information -- even if it's just temporal information accessible
via the /proc file system.
That isn't a fair assumption, there are certainly cases in Solaris where
the source of the information is binary or the backing store of it is not a
documented interface - so third parties shouldn't be attempting to read the
source file anyway.
There are also cases where the policy statement is too complex to
implement in OVAL.
For example one of the rules we have in Solaris that I've just been fixing
is this:
"All setuid binaries on the system must come from packages"
The implementation of this basically has to run a find over all the
filesystems that are mounted setuid, and for each setuid file that is found
check with the package system that the file was from a package.
Even with the IPS package schema for OVAL it is not possible to implement
that rule, because OVAL just isn't expressive enough and can't deal with
the iteration required to implement an example like the above.
We have quite a few checks in the Solaris policy that similar, but the
majority of our checks are OVAL and some even use multiple OVAL schema in a
single check (eg SMF and file schema).
It might be tempting to go the route that David/Darren suggested and
use
SCE for this definition you are creating, but there's a good reason why
only two vendors have implemented that as a solution. Unless you are
specifically writing content that will only ever be used in one of
those
two interpreters, it's best to stick with a solution that falls within
the standard.
--gun
On 6/15/2016 10:36 AM, Rocio Romero wrote:
Hi everyone,
Maybe some of you can help my with this.
I’m creating some news checks in a oval file, and I would like to
know if there is anyway to check the output of a command line to test
some patterns against the output.
Thank you so much to all of you for your answers.
What I wanted to check was some information about Selinux and iptables.
Actually Selinux is the example that we can find on the SCE webpage.
I have been taking a look to SCE, it seems that is going to work for me.
One question related with this: Can I use the package on Oracle Linux? If I
look with yum search, there is not any openscap-sce-engine... maybe install
it not by yum...
Thank you!
Rocio
*Rocio Romero *
*IT Security Engineer*
+1 415-481-5508
[image: http://www.wazuh.com/] <http://www.wazuh.com/>
On Thu, Jun 16, 2016 at 10:58 AM, Darren J Moffat <darren.moffat@oracle.com>
wrote:
>
>
> On 16 June 2016 01:57:39 BST, Gunnar Engelbach <
> gunnar.engelbach@threatguard.com> wrote:
> >
> >Rocio,
> >
> >One of the conventions of OVAL is to stick with a definitive source for
> >
> >the endpoints values you are writing OVAL for. Most likely the output
> >of the command you are referring to is pulled from some other source,
> >such as a configuration file, registry value, and so on. If you could
> >be more specific about which command you are looking at the output
> >from,
> >maybe somebody on this list can help you track down the actual source
> >of
> >that information -- even if it's just temporal information accessible
> >via the /proc file system.
>
> That isn't a fair assumption, there are certainly cases in Solaris where
> the source of the information is binary or the backing store of it is not a
> documented interface - so third parties shouldn't be attempting to read the
> source file anyway.
>
> There are also cases where the policy statement is too complex to
> implement in OVAL.
>
> For example one of the rules we have in Solaris that I've just been fixing
> is this:
>
> "All setuid binaries on the system must come from packages"
>
> The implementation of this basically has to run a find over all the
> filesystems that are mounted setuid, and for each setuid file that is found
> check with the package system that the file was from a package.
>
> Even with the IPS package schema for OVAL it is not possible to implement
> that rule, because OVAL just isn't expressive enough and can't deal with
> the iteration required to implement an example like the above.
>
> We have quite a few checks in the Solaris policy that similar, but the
> majority of our checks are OVAL and some even use multiple OVAL schema in a
> single check (eg SMF and file schema).
>
> >It might be tempting to go the route that David/Darren suggested and
> >use
> >SCE for this definition you are creating, but there's a good reason why
> >
> >only two vendors have implemented that as a solution. Unless you are
> >specifically writing content that will only ever be used in one of
> >those
> >two interpreters, it's best to stick with a solution that falls within
> >the standard.
> >
> >
> >--gun
> >
> >
> >On 6/15/2016 10:36 AM, Rocio Romero wrote:
> >> Hi everyone,
> >>
> >> Maybe some of you can help my with this.
> >>
> >> I’m creating some news checks in a oval file, and I would like to
> >know if there is anyway to check the output of a command line to test
> >some patterns against the output.
> >>
> >> Thank you so much!
> >>
> >>
> >> ...
> >>
> >> _______________________________________________
> >> OVAL_Developer mailing list
> >> OVAL_Developer@lists.cisecurity.org
> >>
> >
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
> >
> >
> >...
> >
> >_______________________________________________
> >OVAL_Developer mailing list
> >OVAL_Developer@lists.cisecurity.org
> >
> http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>
> --
> Darren J Moffat
>
...
GE
Gunnar Engelbach
Thu, Jun 16, 2016 10:56 PM
Rocio,
There are several tests in the Linux schema for working with SELinux.
If you would like to see some examples of this, as well as examples of
checking iptables details, have a look at the USGCB RHEL5 content from NIST.
--gun
On 6/16/2016 1:30 PM, Rocio Romero wrote:
Thank you so much to all of you for your answers.
What I wanted to check was some information about Selinux and
iptables. Actually Selinux is the example that we can find on the SCE
webpage.
I have been taking a look to SCE, it seems that is going to work for
me. One question related with this: Can I use the package on Oracle
Linux? If I look with yum search, there is not any
openscap-sce-engine... maybe install it not by yum...
Thank you!
Rocio
*Rocio Romero *
/IT Security Engineer
/
+1 415-481-5508
http://www.wazuh.com/ http://www.wazuh.com/
On Thu, Jun 16, 2016 at 10:58 AM, Darren J Moffat
<darren.moffat@oracle.com mailto:darren.moffat@oracle.com> wrote:
On 16 June 2016 01:57:39 BST, Gunnar Engelbach
<gunnar.engelbach@threatguard.com
<mailto:gunnar.engelbach@threatguard.com>> wrote:
Rocio,
One of the conventions of OVAL is to stick with a definitive
the endpoints values you are writing OVAL for. Most likely the
of the command you are referring to is pulled from some other source,
such as a configuration file, registry value, and so on. If you
be more specific about which command you are looking at the output
from,
maybe somebody on this list can help you track down the actual source
of
that information -- even if it's just temporal information accessible
via the /proc file system.
That isn't a fair assumption, there are certainly cases in Solaris
where the source of the information is binary or the backing store
of it is not a documented interface - so third parties shouldn't
be attempting to read the source file anyway.
There are also cases where the policy statement is too complex to
implement in OVAL.
For example one of the rules we have in Solaris that I've just
been fixing is this:
"All setuid binaries on the system must come from packages"
The implementation of this basically has to run a find over all
the filesystems that are mounted setuid, and for each setuid file
that is found check with the package system that the file was from
a package.
Even with the IPS package schema for OVAL it is not possible to
implement that rule, because OVAL just isn't expressive enough and
can't deal with the iteration required to implement an example
like the above.
We have quite a few checks in the Solaris policy that similar, but
the majority of our checks are OVAL and some even use multiple
OVAL schema in a single check (eg SMF and file schema).
It might be tempting to go the route that David/Darren suggested and
use
SCE for this definition you are creating, but there's a good
only two vendors have implemented that as a solution. Unless you are
specifically writing content that will only ever be used in one of
those
two interpreters, it's best to stick with a solution that falls
the standard.
--gun
On 6/15/2016 10:36 AM, Rocio Romero wrote:
Hi everyone,
Maybe some of you can help my with this.
I’m creating some news checks in a oval file, and I would like to
know if there is anyway to check the output of a command line to test
some patterns against the output.
<mailto:OVAL_Developer@lists.cisecurity.org>
<mailto:OVAL_Developer@lists.cisecurity.org>
Rocio,
There are several tests in the Linux schema for working with SELinux.
If you would like to see some examples of this, as well as examples of
checking iptables details, have a look at the USGCB RHEL5 content from NIST.
--gun
On 6/16/2016 1:30 PM, Rocio Romero wrote:
> Thank you so much to all of you for your answers.
>
> What I wanted to check was some information about Selinux and
> iptables. Actually Selinux is the example that we can find on the SCE
> webpage.
>
> I have been taking a look to SCE, it seems that is going to work for
> me. One question related with this: Can I use the package on Oracle
> Linux? If I look with yum search, there is not any
> openscap-sce-engine... maybe install it not by yum...
>
> Thank you!
>
> Rocio
>
> *Rocio Romero *
> /IT Security Engineer
> /
> +1 415-481-5508
> http://www.wazuh.com/ <http://www.wazuh.com/>
>
> On Thu, Jun 16, 2016 at 10:58 AM, Darren J Moffat
> <darren.moffat@oracle.com <mailto:darren.moffat@oracle.com>> wrote:
>
>
>
> On 16 June 2016 01:57:39 BST, Gunnar Engelbach
> <gunnar.engelbach@threatguard.com
> <mailto:gunnar.engelbach@threatguard.com>> wrote:
> >
> >Rocio,
> >
> >One of the conventions of OVAL is to stick with a definitive
> source for
> >
> >the endpoints values you are writing OVAL for. Most likely the
> output
> >of the command you are referring to is pulled from some other source,
> >such as a configuration file, registry value, and so on. If you
> could
> >be more specific about which command you are looking at the output
> >from,
> >maybe somebody on this list can help you track down the actual source
> >of
> >that information -- even if it's just temporal information accessible
> >via the /proc file system.
>
> That isn't a fair assumption, there are certainly cases in Solaris
> where the source of the information is binary or the backing store
> of it is not a documented interface - so third parties shouldn't
> be attempting to read the source file anyway.
>
> There are also cases where the policy statement is too complex to
> implement in OVAL.
>
> For example one of the rules we have in Solaris that I've just
> been fixing is this:
>
> "All setuid binaries on the system must come from packages"
>
> The implementation of this basically has to run a find over all
> the filesystems that are mounted setuid, and for each setuid file
> that is found check with the package system that the file was from
> a package.
>
> Even with the IPS package schema for OVAL it is not possible to
> implement that rule, because OVAL just isn't expressive enough and
> can't deal with the iteration required to implement an example
> like the above.
>
> We have quite a few checks in the Solaris policy that similar, but
> the majority of our checks are OVAL and some even use multiple
> OVAL schema in a single check (eg SMF and file schema).
>
> >It might be tempting to go the route that David/Darren suggested and
> >use
> >SCE for this definition you are creating, but there's a good
> reason why
> >
> >only two vendors have implemented that as a solution. Unless you are
> >specifically writing content that will only ever be used in one of
> >those
> >two interpreters, it's best to stick with a solution that falls
> within
> >the standard.
> >
> >
> >--gun
> >
> >
> >On 6/15/2016 10:36 AM, Rocio Romero wrote:
> >> Hi everyone,
> >>
> >> Maybe some of you can help my with this.
> >>
> >> I’m creating some news checks in a oval file, and I would like to
> >know if there is anyway to check the output of a command line to test
> >some patterns against the output.
> >>
> >> Thank you so much!
> >>
> >>
> >> ...
> >>
> >> _______________________________________________
> >> OVAL_Developer mailing list
> >> OVAL_Developer@lists.cisecurity.org
> <mailto:OVAL_Developer@lists.cisecurity.org>
> >>
> >http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
> >
> >
> >...
> >
> >_______________________________________________
> >OVAL_Developer mailing list
> >OVAL_Developer@lists.cisecurity.org
> <mailto:OVAL_Developer@lists.cisecurity.org>
> >http://lists.cisecurity.org/mailman/listinfo/oval_developer_lists.cisecurity.org
>
> --
> Darren J Moffat
>
>
...
DJ
Darren J Moffat
Mon, Jun 20, 2016 1:00 PM
On 06/16/16 21:25, David Solin wrote:
Hi Darren,
I know this is tangential, but… I’d be interested in learning why you’re having trouble implementing that particular check in OVAL. (Feel free to email me off the list).
Even if we had an OVAL schema for ZFS dataset properties (we probably
should have that and it is on my to do list to develop) I don't see how
we could iterate.
The particular test looks something like this:
zfs list -Ho setuid,zoned,mounted,mountpoint -t filesystem |
while read setuid zoned mounted mntpt; do
if [ $setuid == off -o $zoned == on -o $mounted == no ]; then
continue
fi
for set_id_file in
$(find $mntpt -xdev -type f (-perm -4000 -o -perm -2000 )) ; do
if ! pkg search -Ho path -l path:$set_id_file > /dev/null ; then
RESULT=$XCCDF_RESULT_FAIL
fi
done
done
Two levels of iteration, one of which loops over all the zfs
filesystems, the other loops over the contents of a find.
How do I do that in OVAL ?
--
Darren J Moffat
...
On 06/16/16 21:25, David Solin wrote:
> Hi Darren,
>
> I know this is tangential, but… I’d be interested in learning why you’re having trouble implementing that particular check in OVAL. (Feel free to email me off the list).
Even if we had an OVAL schema for ZFS dataset properties (we probably
should have that and it is on my to do list to develop) I don't see how
we could iterate.
The particular test looks something like this:
zfs list -Ho setuid,zoned,mounted,mountpoint -t filesystem |\
while read setuid zoned mounted mntpt; do
if [ $setuid == off -o $zoned == on -o $mounted == no ]; then
continue
fi
for set_id_file in \
$(find $mntpt -xdev -type f \(-perm -4000 -o -perm -2000 \)) ; do
if ! pkg search -Ho path -l path:$set_id_file > /dev/null ; then
RESULT=$XCCDF_RESULT_FAIL
fi
done
done
Two levels of iteration, one of which loops over all the zfs
filesystems, the other loops over the contents of a find.
How do I do that in OVAL ?
--
Darren J Moffat
...
DS
David Solin
Mon, Jun 20, 2016 1:42 PM
Hi Darren,
It’s funny you should ask, as I happen to be putting the finishing touches on a solution for that exact problem. I should be able to put out the fully-fledged proposal on this email list either this week or next.
Best regards,
—David Solin
Hi Darren,
I know this is tangential, but… I’d be interested in learning why you’re having trouble implementing that particular check in OVAL. (Feel free to email me off the list).
Even if we had an OVAL schema for ZFS dataset properties (we probably should have that and it is on my to do list to develop) I don't see how we could iterate.
The particular test looks something like this:
zfs list -Ho setuid,zoned,mounted,mountpoint -t filesystem |
while read setuid zoned mounted mntpt; do
if [ $setuid == off -o $zoned == on -o $mounted == no ]; then
continue
fi
for set_id_file in
$(find $mntpt -xdev -type f (-perm -4000 -o -perm -2000 )) ; do
if ! pkg search -Ho path -l path:$set_id_file > /dev/null ; then
RESULT=$XCCDF_RESULT_FAIL
fi
done
done
Two levels of iteration, one of which loops over all the zfs filesystems, the other loops over the contents of a find.
How do I do that in OVAL ?
--
Darren J Moffat
Hi Darren,
It’s funny you should ask, as I happen to be putting the finishing touches on a solution for that exact problem. I should be able to put out the fully-fledged proposal on this email list either this week or next.
Best regards,
—David Solin
> On Jun 20, 2016, at 8:00 AM, Darren J Moffat <Darren.Moffat@ORACLE.COM> wrote:
>
>
>
> On 06/16/16 21:25, David Solin wrote:
>> Hi Darren,
>>
>> I know this is tangential, but… I’d be interested in learning why you’re having trouble implementing that particular check in OVAL. (Feel free to email me off the list).
>
>
> Even if we had an OVAL schema for ZFS dataset properties (we probably should have that and it is on my to do list to develop) I don't see how we could iterate.
>
> The particular test looks something like this:
>
> zfs list -Ho setuid,zoned,mounted,mountpoint -t filesystem |\
> while read setuid zoned mounted mntpt; do
> if [ $setuid == off -o $zoned == on -o $mounted == no ]; then
> continue
> fi
> for set_id_file in \
> $(find $mntpt -xdev -type f \(-perm -4000 -o -perm -2000 \)) ; do
> if ! pkg search -Ho path -l path:$set_id_file > /dev/null ; then
> RESULT=$XCCDF_RESULT_FAIL
> fi
> done
> done
>
> Two levels of iteration, one of which loops over all the zfs filesystems, the other loops over the contents of a find.
>
> How do I do that in OVAL ?
>
> --
> Darren J Moffat
...
