5.5 schema, trustee_sid, pattern match

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

5.5 schema, trustee_sid, pattern match

KenSimone

Hi,

 

I was going through the 5.5 schema, and noticed this:

 

“The trustee_sid element is the unique sid that associated a user, group, system, or program (such as a Windows service).  If a pattern match operation is used attempts to identify all the trustees (for exampl a .* pattern) then the search should be limited to just the trustees on the DACL/SACL of the object in question.”

 

Would it be fair to reduce it to this?

 

“The trustee_sid element is the unique sid that associated a user, group, system, or program (such as a Windows service).  If a pattern match operation is used then the search should be limited to just the trustees on the DACL/SACL of the object in question.”

 

In other words, is there a need to special case a subset of patterns as the text implies? I *really* hope not. Also, would this apply to “not equals” as well?

 

Thanks,

Ken

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Andrew Buttner
Administrator
I think you bring up a great point.  I agree that the doc should be a
little more general.  Looking at this doc again, I would also suggest
that we replace the term "search" with the term "object set".

Yes, this applies to both equals and not equal.

I will put this in our tracker for a future release.

Thanks
Drew

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Wednesday, October 01, 2008 4:26 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>
>Hi,
>
>
>
>I was going through the 5.5 schema, and noticed this:
>
>
>
>"The trustee_sid element is the unique sid that associated a user,
>group, system, or program (such as a Windows service).  If a pattern
>match operation is used attempts to identify all the trustees (for
>exampl a .* pattern) then the search should be limited to just the
>trustees on the DACL/SACL of the object in question."
>
>
>
>Would it be fair to reduce it to this?
>
>
>
>"The trustee_sid element is the unique sid that associated a user,
>group, system, or program (such as a Windows service).  If a pattern
>match operation is used then the search should be limited to just the
>trustees on the DACL/SACL of the object in question."
>
>
>
>In other words, is there a need to special case a subset of patterns
as

>the text implies? I *really* hope not. Also, would this apply to "not
>equals" as well?
>
>
>
>Thanks,
>
>Ken
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

KenSimone
Thanks Drew. I have one more question... If sids in the ACL represent
groups, should the groups (and recursively, child groups) be expanded,
and their members included in the object set as well?

Thanks,
Ken

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, October 02, 2008 9:24 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

I think you bring up a great point.  I agree that the doc should be a
little more general.  Looking at this doc again, I would also suggest
that we replace the term "search" with the term "object set".

Yes, this applies to both equals and not equal.

I will put this in our tracker for a future release.

Thanks
Drew

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Wednesday, October 01, 2008 4:26 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>
>Hi,
>
>
>
>I was going through the 5.5 schema, and noticed this:
>
>
>
>"The trustee_sid element is the unique sid that associated a user,
>group, system, or program (such as a Windows service).  If a pattern
>match operation is used attempts to identify all the trustees (for
>exampl a .* pattern) then the search should be limited to just the
>trustees on the DACL/SACL of the object in question."
>
>
>
>Would it be fair to reduce it to this?
>
>
>
>"The trustee_sid element is the unique sid that associated a user,
>group, system, or program (such as a Windows service).  If a pattern
>match operation is used then the search should be limited to just the
>trustees on the DACL/SACL of the object in question."
>
>
>
>In other words, is there a need to special case a subset of patterns
as

>the text implies? I *really* hope not. Also, would this apply to "not
>equals" as well?
>
>
>
>Thanks,
>
>Ken
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Jon Baker
Administrator
Ken,

The behavior you are asking about here is detailed in the behaviors defined on the test. Look for the "resolve_group" and "include_group" behaviors.


Regards,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 11:26 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Thanks Drew. I have one more question... If sids in the ACL represent
>groups, should the groups (and recursively, child groups) be expanded,
>and their members included in the object set as well?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Thursday, October 02, 2008 9:24 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>I think you bring up a great point.  I agree that the doc should be a
>little more general.  Looking at this doc again, I would also suggest
>that we replace the term "search" with the term "object set".
>
>Yes, this applies to both equals and not equal.
>
>I will put this in our tracker for a future release.
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Wednesday, October 01, 2008 4:26 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>>
>>Hi,
>>
>>
>>
>>I was going through the 5.5 schema, and noticed this:
>>
>>
>>
>>"The trustee_sid element is the unique sid that associated a user,
>>group, system, or program (such as a Windows service).  If a pattern
>>match operation is used attempts to identify all the trustees (for
>>exampl a .* pattern) then the search should be limited to just the
>>trustees on the DACL/SACL of the object in question."
>>
>>
>>
>>Would it be fair to reduce it to this?
>>
>>
>>
>>"The trustee_sid element is the unique sid that associated a user,
>>group, system, or program (such as a Windows service).  If a pattern
>>match operation is used then the search should be limited to just the
>>trustees on the DACL/SACL of the object in question."
>>
>>
>>
>>In other words, is there a need to special case a subset of patterns
>as
>>the text implies? I *really* hope not. Also, would this apply to "not
>>equals" as well?
>>
>>
>>
>>Thanks,
>>
>>Ken
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>difficulties, write to [hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

KenSimone
Is the intent of resolve group to recursively resolve child groups in
addition to the current group?

Thanks,
Ken

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Monday, October 06, 2008 10:40 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

Ken,

The behavior you are asking about here is detailed in the behaviors
defined on the test. Look for the "resolve_group" and "include_group"
behaviors.


Regards,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 11:26 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Thanks Drew. I have one more question... If sids in the ACL represent
>groups, should the groups (and recursively, child groups) be expanded,
>and their members included in the object set as well?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Thursday, October 02, 2008 9:24 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>I think you bring up a great point.  I agree that the doc should be a
>little more general.  Looking at this doc again, I would also suggest
>that we replace the term "search" with the term "object set".
>
>Yes, this applies to both equals and not equal.
>
>I will put this in our tracker for a future release.
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Wednesday, October 01, 2008 4:26 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>>
>>Hi,
>>
>>
>>
>>I was going through the 5.5 schema, and noticed this:
>>
>>
>>
>>"The trustee_sid element is the unique sid that associated a user,
>>group, system, or program (such as a Windows service).  If a pattern
>>match operation is used attempts to identify all the trustees (for
>>exampl a .* pattern) then the search should be limited to just the
>>trustees on the DACL/SACL of the object in question."
>>
>>
>>
>>Would it be fair to reduce it to this?
>>
>>
>>
>>"The trustee_sid element is the unique sid that associated a user,
>>group, system, or program (such as a Windows service).  If a pattern
>>match operation is used then the search should be limited to just the
>>trustees on the DACL/SACL of the object in question."
>>
>>
>>
>>In other words, is there a need to special case a subset of patterns
>as
>>the text implies? I *really* hope not. Also, would this apply to "not
>>equals" as well?
>>
>>
>>
>>Thanks,
>>
>>Ken
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>difficulties, write to [hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Jon Baker
Administrator
In the OVAL Interpreter I am not recursively resolving groups when processing the "resolve_group" behavior. I believe that the intent of the schema was for the behavior to recursively resolve all subgroups. I will add a bug for the next release to clarify this documentation and I will add a bug to the interpreter to make sure groups are recursively resolved.

Thanks,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 11:47 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Is the intent of resolve group to recursively resolve child groups in
>addition to the current group?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 10:40 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Ken,
>
>The behavior you are asking about here is detailed in the behaviors
>defined on the test. Look for the "resolve_group" and "include_group"
>behaviors.
>
>
>Regards,
>
>Jon
>
>============================================
>Jonathan O. Baker
>The MITRE Corporation
>Email: [hidden email]
>
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 11:26 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Thanks Drew. I have one more question... If sids in the ACL represent
>>groups, should the groups (and recursively, child groups) be expanded,
>>and their members included in the object set as well?
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Thursday, October 02, 2008 9:24 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>I think you bring up a great point.  I agree that the doc should be a
>>little more general.  Looking at this doc again, I would also suggest
>>that we replace the term "search" with the term "object set".
>>
>>Yes, this applies to both equals and not equal.
>>
>>I will put this in our tracker for a future release.
>>
>>Thanks
>>Drew
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>>>
>>>Hi,
>>>
>>>
>>>
>>>I was going through the 5.5 schema, and noticed this:
>>>
>>>
>>>
>>>"The trustee_sid element is the unique sid that associated a user,
>>>group, system, or program (such as a Windows service).  If a pattern
>>>match operation is used attempts to identify all the trustees (for
>>>exampl a .* pattern) then the search should be limited to just the
>>>trustees on the DACL/SACL of the object in question."
>>>
>>>
>>>
>>>Would it be fair to reduce it to this?
>>>
>>>
>>>
>>>"The trustee_sid element is the unique sid that associated a user,
>>>group, system, or program (such as a Windows service).  If a pattern
>>>match operation is used then the search should be limited to just the
>>>trustees on the DACL/SACL of the object in question."
>>>
>>>
>>>
>>>In other words, is there a need to special case a subset of patterns
>>as
>>>the text implies? I *really* hope not. Also, would this apply to "not
>>>equals" as well?
>>>
>>>
>>>
>>>Thanks,
>>>
>>>Ken
>>>
>>>To unsubscribe, send an email message to [hidden email] with
>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>difficulties, write to [hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

KenSimone
Thanks Jon. I have one more question, and then I'll stop bugging you
about this :-)

Should the recursion be limited to the local machine? For example, if my
machine is in a domain called 'Engineering', then there's a good chance
that the 'Engineering\Domain Admins' group is in my Administrators
group. Expanding that group requires hitting the domain controller.
Should it do that?

Thanks,
Ken

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Monday, October 06, 2008 12:50 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

In the OVAL Interpreter I am not recursively resolving groups when
processing the "resolve_group" behavior. I believe that the intent of
the schema was for the behavior to recursively resolve all subgroups. I
will add a bug for the next release to clarify this documentation and I
will add a bug to the interpreter to make sure groups are recursively
resolved.

Thanks,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 11:47 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Is the intent of resolve group to recursively resolve child groups in
>addition to the current group?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 10:40 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Ken,
>
>The behavior you are asking about here is detailed in the behaviors
>defined on the test. Look for the "resolve_group" and "include_group"
>behaviors.
>
>
>Regards,
>
>Jon
>
>============================================
>Jonathan O. Baker
>The MITRE Corporation
>Email: [hidden email]
>
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 11:26 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Thanks Drew. I have one more question... If sids in the ACL represent
>>groups, should the groups (and recursively, child groups) be expanded,
>>and their members included in the object set as well?
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Thursday, October 02, 2008 9:24 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>I think you bring up a great point.  I agree that the doc should be a
>>little more general.  Looking at this doc again, I would also suggest
>>that we replace the term "search" with the term "object set".
>>
>>Yes, this applies to both equals and not equal.
>>
>>I will put this in our tracker for a future release.
>>
>>Thanks
>>Drew
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>>>
>>>Hi,
>>>
>>>
>>>
>>>I was going through the 5.5 schema, and noticed this:
>>>
>>>
>>>
>>>"The trustee_sid element is the unique sid that associated a user,
>>>group, system, or program (such as a Windows service).  If a pattern
>>>match operation is used attempts to identify all the trustees (for
>>>exampl a .* pattern) then the search should be limited to just the
>>>trustees on the DACL/SACL of the object in question."
>>>
>>>
>>>
>>>Would it be fair to reduce it to this?
>>>
>>>
>>>
>>>"The trustee_sid element is the unique sid that associated a user,
>>>group, system, or program (such as a Windows service).  If a pattern
>>>match operation is used then the search should be limited to just the
>>>trustees on the DACL/SACL of the object in question."
>>>
>>>
>>>
>>>In other words, is there a need to special case a subset of patterns
>>as
>>>the text implies? I *really* hope not. Also, would this apply to "not
>>>equals" as well?
>>>
>>>
>>>
>>>Thanks,
>>>
>>>Ken
>>>
>>>To unsubscribe, send an email message to [hidden email]
with

>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>difficulties, write to [hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

KenSimone
Does anyone have any opinions on this? I think my vote would be to not
explore beyond the machine for now, and add a behavior at the next OVAL
revision. I'm not a content guy, but my initial feeling is that group
details beyond the machine level are more noise than useful information.
I also think the likelihood of access related errors is fairly high.

Thanks,
Ken

-----Original Message-----
From: Simone, Ken
Sent: Tuesday, October 07, 2008 9:37 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

Thanks Jon. I have one more question, and then I'll stop bugging you
about this :-)

Should the recursion be limited to the local machine? For example, if my
machine is in a domain called 'Engineering', then there's a good chance
that the 'Engineering\Domain Admins' group is in my Administrators
group. Expanding that group requires hitting the domain controller.
Should it do that?

Thanks,
Ken

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Monday, October 06, 2008 12:50 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

In the OVAL Interpreter I am not recursively resolving groups when
processing the "resolve_group" behavior. I believe that the intent of
the schema was for the behavior to recursively resolve all subgroups. I
will add a bug for the next release to clarify this documentation and I
will add a bug to the interpreter to make sure groups are recursively
resolved.

Thanks,

Jon

============================================
Jonathan O. Baker
The MITRE Corporation
Email: [hidden email]



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 11:47 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Is the intent of resolve group to recursively resolve child groups in
>addition to the current group?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 10:40 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Ken,
>
>The behavior you are asking about here is detailed in the behaviors
>defined on the test. Look for the "resolve_group" and "include_group"
>behaviors.
>
>
>Regards,
>
>Jon
>
>============================================
>Jonathan O. Baker
>The MITRE Corporation
>Email: [hidden email]
>
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 11:26 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Thanks Drew. I have one more question... If sids in the ACL represent
>>groups, should the groups (and recursively, child groups) be expanded,
>>and their members included in the object set as well?
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Thursday, October 02, 2008 9:24 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>I think you bring up a great point.  I agree that the doc should be a
>>little more general.  Looking at this doc again, I would also suggest
>>that we replace the term "search" with the term "object set".
>>
>>Yes, this applies to both equals and not equal.
>>
>>I will put this in our tracker for a future release.
>>
>>Thanks
>>Drew
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match
>>>
>>>Hi,
>>>
>>>
>>>
>>>I was going through the 5.5 schema, and noticed this:
>>>
>>>
>>>
>>>"The trustee_sid element is the unique sid that associated a user,
>>>group, system, or program (such as a Windows service).  If a pattern
>>>match operation is used attempts to identify all the trustees (for
>>>exampl a .* pattern) then the search should be limited to just the
>>>trustees on the DACL/SACL of the object in question."
>>>
>>>
>>>
>>>Would it be fair to reduce it to this?
>>>
>>>
>>>
>>>"The trustee_sid element is the unique sid that associated a user,
>>>group, system, or program (such as a Windows service).  If a pattern
>>>match operation is used then the search should be limited to just the
>>>trustees on the DACL/SACL of the object in question."
>>>
>>>
>>>
>>>In other words, is there a need to special case a subset of patterns
>>as
>>>the text implies? I *really* hope not. Also, would this apply to "not
>>>equals" as well?
>>>
>>>
>>>
>>>Thanks,
>>>
>>>Ken
>>>
>>>To unsubscribe, send an email message to [hidden email]
with

>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>difficulties, write to [hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Andrew Buttner
Administrator
The original intent of the resolve group behavior was to list ALL
individual members of that group, both from the local machine and the
domain.  I can see how trying to resolve a group call USERS in a domain
environment might be tough.  But at the same time, the goal here was to
resolve something like ADMINISTRATORS that might include both some
local users and some domain users.  Thoughts?

I can see both valid points and would love to hear other opinions on
this matter.  If my above thinking holds, than how about the following
documentation for the resolve group behavior:

"The 'resolve_group' behavior defines whether an object set defined by
a group sid should be resolved to return a set that contains all the
user sids that are a member of that group.  Note that all child groups
should also be resolved any valid domain users that are members of the
group should also be included.  The intent of this behavior is to end
up with a list of all individual users from that system that make up
the group once everything has been resolved."

Thanks
Drew



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Thursday, October 16, 2008 3:06 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Does anyone have any opinions on this? I think my vote would be to not
>explore beyond the machine for now, and add a behavior at the next
OVAL
>revision. I'm not a content guy, but my initial feeling is that group
>details beyond the machine level are more noise than useful
information.

>I also think the likelihood of access related errors is fairly high.
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Simone, Ken
>Sent: Tuesday, October 07, 2008 9:37 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Thanks Jon. I have one more question, and then I'll stop bugging you
>about this :-)
>
>Should the recursion be limited to the local machine? For example, if
my
>machine is in a domain called 'Engineering', then there's a good
chance

>that the 'Engineering\Domain Admins' group is in my Administrators
>group. Expanding that group requires hitting the domain controller.
>Should it do that?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 12:50 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>In the OVAL Interpreter I am not recursively resolving groups when
>processing the "resolve_group" behavior. I believe that the intent of
>the schema was for the behavior to recursively resolve all subgroups.
I
>will add a bug for the next release to clarify this documentation and
I

>will add a bug to the interpreter to make sure groups are recursively
>resolved.
>
>Thanks,
>
>Jon
>
>============================================
>Jonathan O. Baker
>The MITRE Corporation
>Email: [hidden email]
>
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 11:47 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Is the intent of resolve group to recursively resolve child groups in
>>addition to the current group?
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Baker, Jon [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 10:40 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Ken,
>>
>>The behavior you are asking about here is detailed in the behaviors
>>defined on the test. Look for the "resolve_group" and "include_group"
>>behaviors.
>>
>>
>>Regards,
>>
>>Jon
>>
>>============================================
>>Jonathan O. Baker
>>The MITRE Corporation
>>Email: [hidden email]
>>
>>
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Monday, October 06, 2008 11:26 AM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Thanks Drew. I have one more question... If sids in the ACL
represent
>>>groups, should the groups (and recursively, child groups) be
expanded,

>>>and their members included in the object set as well?
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Buttner, Drew [mailto:[hidden email]]
>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>I think you bring up a great point.  I agree that the doc should be
a
>>>little more general.  Looking at this doc again, I would also
suggest

>>>that we replace the term "search" with the term "object set".
>>>
>>>Yes, this applies to both equals and not equal.
>>>
>>>I will put this in our tracker for a future release.
>>>
>>>Thanks
>>>Drew
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>To: oval-developer-list OVAL Developer List/Closed Public
Discussion
>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

>>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>I was going through the 5.5 schema, and noticed this:
>>>>
>>>>
>>>>
>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>group, system, or program (such as a Windows service).  If a
pattern

>>>>match operation is used attempts to identify all the trustees (for
>>>>exampl a .* pattern) then the search should be limited to just the
>>>>trustees on the DACL/SACL of the object in question."
>>>>
>>>>
>>>>
>>>>Would it be fair to reduce it to this?
>>>>
>>>>
>>>>
>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>group, system, or program (such as a Windows service).  If a
pattern
>>>>match operation is used then the search should be limited to just
the
>>>>trustees on the DACL/SACL of the object in question."
>>>>
>>>>
>>>>
>>>>In other words, is there a need to special case a subset of
patterns
>>>as
>>>>the text implies? I *really* hope not. Also, would this apply to
"not

>>>>equals" as well?
>>>>
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>Ken
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>>difficulties, write to [hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with

>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

KenSimone
So just to clarify, any child group should be resolved, even if it's a
domain group? For example:

Machine\Users
        MyDomain\Users

If we were to resolve Machine\Users, all users in MyDomain\Users should
be collected as well? If that's the intent, I suggest that a behavior
should be added to control this. I can see this crawling out of control.
I'm not an IT guy, but I know that a domain can have thousands of users,
and groups can contain groups from multiple domains.
   
Thanks,
Ken

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, October 22, 2008 1:57 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

The original intent of the resolve group behavior was to list ALL
individual members of that group, both from the local machine and the
domain.  I can see how trying to resolve a group call USERS in a domain
environment might be tough.  But at the same time, the goal here was to
resolve something like ADMINISTRATORS that might include both some
local users and some domain users.  Thoughts?

I can see both valid points and would love to hear other opinions on
this matter.  If my above thinking holds, than how about the following
documentation for the resolve group behavior:

"The 'resolve_group' behavior defines whether an object set defined by
a group sid should be resolved to return a set that contains all the
user sids that are a member of that group.  Note that all child groups
should also be resolved any valid domain users that are members of the
group should also be included.  The intent of this behavior is to end
up with a list of all individual users from that system that make up
the group once everything has been resolved."

Thanks
Drew



>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Thursday, October 16, 2008 3:06 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Does anyone have any opinions on this? I think my vote would be to not
>explore beyond the machine for now, and add a behavior at the next
OVAL
>revision. I'm not a content guy, but my initial feeling is that group
>details beyond the machine level are more noise than useful
information.

>I also think the likelihood of access related errors is fairly high.
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Simone, Ken
>Sent: Tuesday, October 07, 2008 9:37 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Thanks Jon. I have one more question, and then I'll stop bugging you
>about this :-)
>
>Should the recursion be limited to the local machine? For example, if
my
>machine is in a domain called 'Engineering', then there's a good
chance

>that the 'Engineering\Domain Admins' group is in my Administrators
>group. Expanding that group requires hitting the domain controller.
>Should it do that?
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Monday, October 06, 2008 12:50 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>In the OVAL Interpreter I am not recursively resolving groups when
>processing the "resolve_group" behavior. I believe that the intent of
>the schema was for the behavior to recursively resolve all subgroups.
I
>will add a bug for the next release to clarify this documentation and
I

>will add a bug to the interpreter to make sure groups are recursively
>resolved.
>
>Thanks,
>
>Jon
>
>============================================
>Jonathan O. Baker
>The MITRE Corporation
>Email: [hidden email]
>
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 11:47 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Is the intent of resolve group to recursively resolve child groups in
>>addition to the current group?
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Baker, Jon [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 10:40 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Ken,
>>
>>The behavior you are asking about here is detailed in the behaviors
>>defined on the test. Look for the "resolve_group" and "include_group"
>>behaviors.
>>
>>
>>Regards,
>>
>>Jon
>>
>>============================================
>>Jonathan O. Baker
>>The MITRE Corporation
>>Email: [hidden email]
>>
>>
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Monday, October 06, 2008 11:26 AM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Thanks Drew. I have one more question... If sids in the ACL
represent
>>>groups, should the groups (and recursively, child groups) be
expanded,

>>>and their members included in the object set as well?
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Buttner, Drew [mailto:[hidden email]]
>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>I think you bring up a great point.  I agree that the doc should be
a
>>>little more general.  Looking at this doc again, I would also
suggest

>>>that we replace the term "search" with the term "object set".
>>>
>>>Yes, this applies to both equals and not equal.
>>>
>>>I will put this in our tracker for a future release.
>>>
>>>Thanks
>>>Drew
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>To: oval-developer-list OVAL Developer List/Closed Public
Discussion
>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
match

>>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>I was going through the 5.5 schema, and noticed this:
>>>>
>>>>
>>>>
>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>group, system, or program (such as a Windows service).  If a
pattern

>>>>match operation is used attempts to identify all the trustees (for
>>>>exampl a .* pattern) then the search should be limited to just the
>>>>trustees on the DACL/SACL of the object in question."
>>>>
>>>>
>>>>
>>>>Would it be fair to reduce it to this?
>>>>
>>>>
>>>>
>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>group, system, or program (such as a Windows service).  If a
pattern
>>>>match operation is used then the search should be limited to just
the
>>>>trustees on the DACL/SACL of the object in question."
>>>>
>>>>
>>>>
>>>>In other words, is there a need to special case a subset of
patterns
>>>as
>>>>the text implies? I *really* hope not. Also, would this apply to
"not

>>>>equals" as well?
>>>>
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>Ken
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>>difficulties, write to [hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with

>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Andrew Buttner
Administrator
I do agree that a behavior to limit to local machine would be a good
idea here.  But as for how version 5.5 is intended, I think the answer
is that all users, including domain users are intended.

Note that we are only talking about the resolve group behavior.  It is
defined with regards to pattern matching that we are only matching
against the local system.  The reason for this is that resolving a .*
pattern is unrealistic when talking about big domain.

The difference here is in the context.  With the resolve group
behavior, we are making a pretty explicit statement that we want to
look at all users of a given group.  In the pattern match case, we
often are just making blanket statement and searching for objects that
might match.

I guess I would say the difference is due to the perceived usage.

Do we agree with this interpretation?  Are we correctly representing
the views of the community?

Thanks
Drew

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Wednesday, October 22, 2008 4:03 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>So just to clarify, any child group should be resolved, even if it's a
>domain group? For example:
>
>Machine\Users
> MyDomain\Users
>
>If we were to resolve Machine\Users, all users in MyDomain\Users
should
>be collected as well? If that's the intent, I suggest that a behavior
>should be added to control this. I can see this crawling out of
control.
>I'm not an IT guy, but I know that a domain can have thousands of
users,

>and groups can contain groups from multiple domains.
>
>Thanks,
>Ken
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, October 22, 2008 1:57 PM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>The original intent of the resolve group behavior was to list ALL
>individual members of that group, both from the local machine and the
>domain.  I can see how trying to resolve a group call USERS in a
domain
>environment might be tough.  But at the same time, the goal here was
to

>resolve something like ADMINISTRATORS that might include both some
>local users and some domain users.  Thoughts?
>
>I can see both valid points and would love to hear other opinions on
>this matter.  If my above thinking holds, than how about the following
>documentation for the resolve group behavior:
>
>"The 'resolve_group' behavior defines whether an object set defined by
>a group sid should be resolved to return a set that contains all the
>user sids that are a member of that group.  Note that all child groups
>should also be resolved any valid domain users that are members of the
>group should also be included.  The intent of this behavior is to end
>up with a list of all individual users from that system that make up
>the group once everything has been resolved."
>
>Thanks
>Drew
>
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Thursday, October 16, 2008 3:06 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Does anyone have any opinions on this? I think my vote would be to
not

>>explore beyond the machine for now, and add a behavior at the next
>OVAL
>>revision. I'm not a content guy, but my initial feeling is that group
>>details beyond the machine level are more noise than useful
>information.
>>I also think the likelihood of access related errors is fairly high.
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Simone, Ken
>>Sent: Tuesday, October 07, 2008 9:37 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>Thanks Jon. I have one more question, and then I'll stop bugging you
>>about this :-)
>>
>>Should the recursion be limited to the local machine? For example, if
>my
>>machine is in a domain called 'Engineering', then there's a good
>chance
>>that the 'Engineering\Domain Admins' group is in my Administrators
>>group. Expanding that group requires hitting the domain controller.
>>Should it do that?
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Baker, Jon [mailto:[hidden email]]
>>Sent: Monday, October 06, 2008 12:50 PM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>In the OVAL Interpreter I am not recursively resolving groups when
>>processing the "resolve_group" behavior. I believe that the intent of
>>the schema was for the behavior to recursively resolve all subgroups.
>I
>>will add a bug for the next release to clarify this documentation and
>I
>>will add a bug to the interpreter to make sure groups are recursively
>>resolved.
>>
>>Thanks,
>>
>>Jon
>>
>>============================================
>>Jonathan O. Baker
>>The MITRE Corporation
>>Email: [hidden email]
>>
>>
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Monday, October 06, 2008 11:47 AM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Is the intent of resolve group to recursively resolve child groups
in

>>>addition to the current group?
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Baker, Jon [mailto:[hidden email]]
>>>Sent: Monday, October 06, 2008 10:40 AM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Ken,
>>>
>>>The behavior you are asking about here is detailed in the behaviors
>>>defined on the test. Look for the "resolve_group" and
"include_group"

>>>behaviors.
>>>
>>>
>>>Regards,
>>>
>>>Jon
>>>
>>>============================================
>>>Jonathan O. Baker
>>>The MITRE Corporation
>>>Email: [hidden email]
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Monday, October 06, 2008 11:26 AM
>>>>To: oval-developer-list OVAL Developer List/Closed Public
Discussion

>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Thanks Drew. I have one more question... If sids in the ACL
>represent
>>>>groups, should the groups (and recursively, child groups) be
>expanded,
>>>>and their members included in the object set as well?
>>>>
>>>>Thanks,
>>>>Ken
>>>>
>>>>-----Original Message-----
>>>>From: Buttner, Drew [mailto:[hidden email]]
>>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>>To: [hidden email]
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>I think you bring up a great point.  I agree that the doc should be
>a
>>>>little more general.  Looking at this doc again, I would also
>suggest
>>>>that we replace the term "search" with the term "object set".
>>>>
>>>>Yes, this applies to both equals and not equal.
>>>>
>>>>I will put this in our tracker for a future release.
>>>>
>>>>Thanks
>>>>Drew
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>Discussion
>>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>>>>>
>>>>>Hi,
>>>>>
>>>>>
>>>>>
>>>>>I was going through the 5.5 schema, and noticed this:
>>>>>
>>>>>
>>>>>
>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>group, system, or program (such as a Windows service).  If a
>pattern
>>>>>match operation is used attempts to identify all the trustees (for
>>>>>exampl a .* pattern) then the search should be limited to just the
>>>>>trustees on the DACL/SACL of the object in question."
>>>>>
>>>>>
>>>>>
>>>>>Would it be fair to reduce it to this?
>>>>>
>>>>>
>>>>>
>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>group, system, or program (such as a Windows service).  If a
>pattern
>>>>>match operation is used then the search should be limited to just
>the
>>>>>trustees on the DACL/SACL of the object in question."
>>>>>
>>>>>
>>>>>
>>>>>In other words, is there a need to special case a subset of
>patterns
>>>>as
>>>>>the text implies? I *really* hope not. Also, would this apply to
>"not
>>>>>equals" as well?
>>>>>
>>>>>
>>>>>
>>>>>Thanks,
>>>>>
>>>>>Ken
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
have
>>>>>difficulties, write to
[hidden email].

>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>OVAL-
>>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email]
with

>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Jon Baker
Administrator
As we prepare for the next draft of version 5.6 I would like to consider addressing the resolve_group behavior. As it is currently defined in  several of the windows definition schema tests the behavior will result in recursively resolving all groups including groups that are not local to host that is being evaluated. In a domain environment this results in the collection of many, many trustees. Please review the email thread below for a more in depth discussion on this issue.

For version 5.6 I would like us to consider adding another behavior that would allow us to indicate whether non local groups should be resolved or not. Is this a change that we should in clued in version 5.6? Are others interested in this addition?

As an aside, the current oval interpreter source aligns with the documented resolve_group behavior. This results in the collection of a huge number of trustees when working a domain environment. Given the amount of data being collected I somewhat doubt that this capability is being properly supported in other products. I am curious to know how some of the implementers out there have handled this behavior. Perhaps your solutions/workarounds can help us develop a better construct in the language for version 5.6.

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]


>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, October 22, 2008 4:53 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>I do agree that a behavior to limit to local machine would be a good
>idea here.  But as for how version 5.5 is intended, I think the answer
>is that all users, including domain users are intended.
>
>Note that we are only talking about the resolve group behavior.  It is
>defined with regards to pattern matching that we are only matching
>against the local system.  The reason for this is that resolving a .*
>pattern is unrealistic when talking about big domain.
>
>The difference here is in the context.  With the resolve group
>behavior, we are making a pretty explicit statement that we want to
>look at all users of a given group.  In the pattern match case, we
>often are just making blanket statement and searching for objects that
>might match.
>
>I guess I would say the difference is due to the perceived usage.
>
>Do we agree with this interpretation?  Are we correctly representing
>the views of the community?
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Wednesday, October 22, 2008 4:03 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>So just to clarify, any child group should be resolved, even if it's a
>>domain group? For example:
>>
>>Machine\Users
>> MyDomain\Users
>>
>>If we were to resolve Machine\Users, all users in MyDomain\Users
>should
>>be collected as well? If that's the intent, I suggest that a behavior
>>should be added to control this. I can see this crawling out of
>control.
>>I'm not an IT guy, but I know that a domain can have thousands of
>users,
>>and groups can contain groups from multiple domains.
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Wednesday, October 22, 2008 1:57 PM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>The original intent of the resolve group behavior was to list ALL
>>individual members of that group, both from the local machine and the
>>domain.  I can see how trying to resolve a group call USERS in a
>domain
>>environment might be tough.  But at the same time, the goal here was
>to
>>resolve something like ADMINISTRATORS that might include both some
>>local users and some domain users.  Thoughts?
>>
>>I can see both valid points and would love to hear other opinions on
>>this matter.  If my above thinking holds, than how about the following
>>documentation for the resolve group behavior:
>>
>>"The 'resolve_group' behavior defines whether an object set defined by
>>a group sid should be resolved to return a set that contains all the
>>user sids that are a member of that group.  Note that all child groups
>>should also be resolved any valid domain users that are members of the
>>group should also be included.  The intent of this behavior is to end
>>up with a list of all individual users from that system that make up
>>the group once everything has been resolved."
>>
>>Thanks
>>Drew
>>
>>
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Thursday, October 16, 2008 3:06 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Does anyone have any opinions on this? I think my vote would be to
>not
>>>explore beyond the machine for now, and add a behavior at the next
>>OVAL
>>>revision. I'm not a content guy, but my initial feeling is that group
>>>details beyond the machine level are more noise than useful
>>information.
>>>I also think the likelihood of access related errors is fairly high.
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Simone, Ken
>>>Sent: Tuesday, October 07, 2008 9:37 AM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Thanks Jon. I have one more question, and then I'll stop bugging you
>>>about this :-)
>>>
>>>Should the recursion be limited to the local machine? For example, if
>>my
>>>machine is in a domain called 'Engineering', then there's a good
>>chance
>>>that the 'Engineering\Domain Admins' group is in my Administrators
>>>group. Expanding that group requires hitting the domain controller.
>>>Should it do that?
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Baker, Jon [mailto:[hidden email]]
>>>Sent: Monday, October 06, 2008 12:50 PM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>In the OVAL Interpreter I am not recursively resolving groups when
>>>processing the "resolve_group" behavior. I believe that the intent of
>>>the schema was for the behavior to recursively resolve all subgroups.
>>I
>>>will add a bug for the next release to clarify this documentation and
>>I
>>>will add a bug to the interpreter to make sure groups are recursively
>>>resolved.
>>>
>>>Thanks,
>>>
>>>Jon
>>>
>>>============================================
>>>Jonathan O. Baker
>>>The MITRE Corporation
>>>Email: [hidden email]
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Monday, October 06, 2008 11:47 AM
>>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Is the intent of resolve group to recursively resolve child groups
>in
>>>>addition to the current group?
>>>>
>>>>Thanks,
>>>>Ken
>>>>
>>>>-----Original Message-----
>>>>From: Baker, Jon [mailto:[hidden email]]
>>>>Sent: Monday, October 06, 2008 10:40 AM
>>>>To: [hidden email]
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Ken,
>>>>
>>>>The behavior you are asking about here is detailed in the behaviors
>>>>defined on the test. Look for the "resolve_group" and
>"include_group"
>>>>behaviors.
>>>>
>>>>
>>>>Regards,
>>>>
>>>>Jon
>>>>
>>>>============================================
>>>>Jonathan O. Baker
>>>>The MITRE Corporation
>>>>Email: [hidden email]
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>Sent: Monday, October 06, 2008 11:26 AM
>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>Discussion
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>Thanks Drew. I have one more question... If sids in the ACL
>>represent
>>>>>groups, should the groups (and recursively, child groups) be
>>expanded,
>>>>>and their members included in the object set as well?
>>>>>
>>>>>Thanks,
>>>>>Ken
>>>>>
>>>>>-----Original Message-----
>>>>>From: Buttner, Drew [mailto:[hidden email]]
>>>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>>>To: [hidden email]
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>I think you bring up a great point.  I agree that the doc should be
>>a
>>>>>little more general.  Looking at this doc again, I would also
>>suggest
>>>>>that we replace the term "search" with the term "object set".
>>>>>
>>>>>Yes, this applies to both equals and not equal.
>>>>>
>>>>>I will put this in our tracker for a future release.
>>>>>
>>>>>Thanks
>>>>>Drew
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>>Discussion
>>>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>>I was going through the 5.5 schema, and noticed this:
>>>>>>
>>>>>>
>>>>>>
>>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>>group, system, or program (such as a Windows service).  If a
>>pattern
>>>>>>match operation is used attempts to identify all the trustees (for
>>>>>>exampl a .* pattern) then the search should be limited to just the
>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>
>>>>>>
>>>>>>
>>>>>>Would it be fair to reduce it to this?
>>>>>>
>>>>>>
>>>>>>
>>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>>group, system, or program (such as a Windows service).  If a
>>pattern
>>>>>>match operation is used then the search should be limited to just
>>the
>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>
>>>>>>
>>>>>>
>>>>>>In other words, is there a need to special case a subset of
>>patterns
>>>>>as
>>>>>>the text implies? I *really* hope not. Also, would this apply to
>>"not
>>>>>>equals" as well?
>>>>>>
>>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Ken
>>>>>>
>>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>have
>>>>>>difficulties, write to
>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>OVAL-
>>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>OVAL-
>>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

KenSimone
We implement this as described in our processor. Our solution to the "large volume of data" problem is to avoid enabling the resolve_group behavior in our content.

Anyway... I'm voting against my proposed behavior. I don't think a resolved set of users that doesn't include everything is particularly useful. Instead, I would suggest deprecating this behavior from all of the probes, except for the ones that are explicitly designed to gather users and groups. This would force content authors to collect the users they're interested in w/ probes that can efficiently do it, and not from probes like "*effectiverights". I reworked some NIST content to do just what I described. It was getting effective rights for all domain users, when all it really needed was effective rights for a handful of users. To determine that handful of users, it had to collect all users. It was doing this by utilizing resolve_group in the effectiveright probe. This was taking an eternity at a site with 20k users in the domain. I modified it to use the sid_sid probe to gather the users, and that sped things up considerably. Attached is the original and reworked bit of content (in case it helps clarify what I'm describing).

Ken

-----Original Message-----
From: Baker, Jon [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 9:18 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern match

As we prepare for the next draft of version 5.6 I would like to consider addressing the resolve_group behavior. As it is currently defined in  several of the windows definition schema tests the behavior will result in recursively resolving all groups including groups that are not local to host that is being evaluated. In a domain environment this results in the collection of many, many trustees. Please review the email thread below for a more in depth discussion on this issue.

For version 5.6 I would like us to consider adding another behavior that would allow us to indicate whether non local groups should be resolved or not. Is this a change that we should in clued in version 5.6? Are others interested in this addition?

As an aside, the current oval interpreter source aligns with the documented resolve_group behavior. This results in the collection of a huge number of trustees when working a domain environment. Given the amount of data being collected I somewhat doubt that this capability is being properly supported in other products. I am curious to know how some of the implementers out there have handled this behavior. Perhaps your solutions/workarounds can help us develop a better construct in the language for version 5.6.

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]


>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, October 22, 2008 4:53 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>I do agree that a behavior to limit to local machine would be a good
>idea here.  But as for how version 5.5 is intended, I think the answer
>is that all users, including domain users are intended.
>
>Note that we are only talking about the resolve group behavior.  It is
>defined with regards to pattern matching that we are only matching
>against the local system.  The reason for this is that resolving a .*
>pattern is unrealistic when talking about big domain.
>
>The difference here is in the context.  With the resolve group
>behavior, we are making a pretty explicit statement that we want to
>look at all users of a given group.  In the pattern match case, we
>often are just making blanket statement and searching for objects that
>might match.
>
>I guess I would say the difference is due to the perceived usage.
>
>Do we agree with this interpretation?  Are we correctly representing
>the views of the community?
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Wednesday, October 22, 2008 4:03 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>So just to clarify, any child group should be resolved, even if it's a
>>domain group? For example:
>>
>>Machine\Users
>>      MyDomain\Users
>>
>>If we were to resolve Machine\Users, all users in MyDomain\Users
>should
>>be collected as well? If that's the intent, I suggest that a behavior
>>should be added to control this. I can see this crawling out of
>control.
>>I'm not an IT guy, but I know that a domain can have thousands of
>users,
>>and groups can contain groups from multiple domains.
>>
>>Thanks,
>>Ken
>>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Wednesday, October 22, 2008 1:57 PM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>The original intent of the resolve group behavior was to list ALL
>>individual members of that group, both from the local machine and the
>>domain.  I can see how trying to resolve a group call USERS in a
>domain
>>environment might be tough.  But at the same time, the goal here was
>to
>>resolve something like ADMINISTRATORS that might include both some
>>local users and some domain users.  Thoughts?
>>
>>I can see both valid points and would love to hear other opinions on
>>this matter.  If my above thinking holds, than how about the following
>>documentation for the resolve group behavior:
>>
>>"The 'resolve_group' behavior defines whether an object set defined by
>>a group sid should be resolved to return a set that contains all the
>>user sids that are a member of that group.  Note that all child groups
>>should also be resolved any valid domain users that are members of the
>>group should also be included.  The intent of this behavior is to end
>>up with a list of all individual users from that system that make up
>>the group once everything has been resolved."
>>
>>Thanks
>>Drew
>>
>>
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Thursday, October 16, 2008 3:06 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Does anyone have any opinions on this? I think my vote would be to
>not
>>>explore beyond the machine for now, and add a behavior at the next
>>OVAL
>>>revision. I'm not a content guy, but my initial feeling is that group
>>>details beyond the machine level are more noise than useful
>>information.
>>>I also think the likelihood of access related errors is fairly high.
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Simone, Ken
>>>Sent: Tuesday, October 07, 2008 9:37 AM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>Thanks Jon. I have one more question, and then I'll stop bugging you
>>>about this :-)
>>>
>>>Should the recursion be limited to the local machine? For example, if
>>my
>>>machine is in a domain called 'Engineering', then there's a good
>>chance
>>>that the 'Engineering\Domain Admins' group is in my Administrators
>>>group. Expanding that group requires hitting the domain controller.
>>>Should it do that?
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Baker, Jon [mailto:[hidden email]]
>>>Sent: Monday, October 06, 2008 12:50 PM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>In the OVAL Interpreter I am not recursively resolving groups when
>>>processing the "resolve_group" behavior. I believe that the intent of
>>>the schema was for the behavior to recursively resolve all subgroups.
>>I
>>>will add a bug for the next release to clarify this documentation and
>>I
>>>will add a bug to the interpreter to make sure groups are recursively
>>>resolved.
>>>
>>>Thanks,
>>>
>>>Jon
>>>
>>>============================================
>>>Jonathan O. Baker
>>>The MITRE Corporation
>>>Email: [hidden email]
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Monday, October 06, 2008 11:47 AM
>>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Is the intent of resolve group to recursively resolve child groups
>in
>>>>addition to the current group?
>>>>
>>>>Thanks,
>>>>Ken
>>>>
>>>>-----Original Message-----
>>>>From: Baker, Jon [mailto:[hidden email]]
>>>>Sent: Monday, October 06, 2008 10:40 AM
>>>>To: [hidden email]
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Ken,
>>>>
>>>>The behavior you are asking about here is detailed in the behaviors
>>>>defined on the test. Look for the "resolve_group" and
>"include_group"
>>>>behaviors.
>>>>
>>>>
>>>>Regards,
>>>>
>>>>Jon
>>>>
>>>>============================================
>>>>Jonathan O. Baker
>>>>The MITRE Corporation
>>>>Email: [hidden email]
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>Sent: Monday, October 06, 2008 11:26 AM
>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>Discussion
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>Thanks Drew. I have one more question... If sids in the ACL
>>represent
>>>>>groups, should the groups (and recursively, child groups) be
>>expanded,
>>>>>and their members included in the object set as well?
>>>>>
>>>>>Thanks,
>>>>>Ken
>>>>>
>>>>>-----Original Message-----
>>>>>From: Buttner, Drew [mailto:[hidden email]]
>>>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>>>To: [hidden email]
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>I think you bring up a great point.  I agree that the doc should be
>>a
>>>>>little more general.  Looking at this doc again, I would also
>>suggest
>>>>>that we replace the term "search" with the term "object set".
>>>>>
>>>>>Yes, this applies to both equals and not equal.
>>>>>
>>>>>I will put this in our tracker for a future release.
>>>>>
>>>>>Thanks
>>>>>Drew
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>>Discussion
>>>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>>I was going through the 5.5 schema, and noticed this:
>>>>>>
>>>>>>
>>>>>>
>>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>>group, system, or program (such as a Windows service).  If a
>>pattern
>>>>>>match operation is used attempts to identify all the trustees (for
>>>>>>exampl a .* pattern) then the search should be limited to just the
>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>
>>>>>>
>>>>>>
>>>>>>Would it be fair to reduce it to this?
>>>>>>
>>>>>>
>>>>>>
>>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>>group, system, or program (such as a Windows service).  If a
>>pattern
>>>>>>match operation is used then the search should be limited to just
>>the
>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>
>>>>>>
>>>>>>
>>>>>>In other words, is there a need to special case a subset of
>>patterns
>>>>>as
>>>>>>the text implies? I *really* hope not. Also, would this apply to
>>"not
>>>>>>equals" as well?
>>>>>>
>>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Ken
>>>>>>
>>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>have
>>>>>>difficulties, write to
>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>OVAL-
>>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>OVAL-
>>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email]
>with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].
To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

resolve_group_rework.zip (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Jon Baker
Administrator
Ken,

Your sample content helps. I think your proposal to deprecate the "resolve_group" behavior on from all of the test, except for the ones that are explicitly designed to gather users and groups makes a lot of sense. At the same time I will try to clarify the schema documentation on all related tests to ensure that the handling of operations other than 'equals' is consistently defined to be relative to the trustees on the Security Descriptor or Policy Database or appropriate databases for each test.

Here my suggested revision to the documentation on the fileeffectiverights53_object trustee_sid entity:


"The trustee_sid entity identifies a unique sid associated with a user, group, system, or program (such as a Windows service).  If an operation other than equals is used to identify trustees (for example a .* pattern match) then the search shall be limited to only the trustees referenced in the file's Security Descriptor.  The scope is limited here to ensure that it is possible to examine the contents of a file's Security Descriptor and also leverage large sets of trustees through the use of variables."


If this revised text captures the needed clarification I will make similar updates and deprecate the "resolve_group" behavior on the following other tests:

- accesstoken_test
- fileauditedpermissions53_test
- fileauditedpermissions_test
- fileeffectiverights53_test
- fileeffectiverights_test
- printereffectiverights_test
- regkeyauditedpermissions53_test
- regkeyauditedpermissions_test
- regkeyeffectiverights53_test
- regkeyeffectiverights_test

In the end I think this will simplify many implementations that support OVAL, help developers understand the affected tests more easily, and should not significantly impact content writers.


Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]


>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Thursday, June 18, 2009 11:17 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>We implement this as described in our processor. Our solution to the
>"large volume of data" problem is to avoid enabling the resolve_group
>behavior in our content.
>
>Anyway... I'm voting against my proposed behavior. I don't think a
>resolved set of users that doesn't include everything is particularly
>useful. Instead, I would suggest deprecating this behavior from all of
>the probes, except for the ones that are explicitly designed to gather
>users and groups. This would force content authors to collect the users
>they're interested in w/ probes that can efficiently do it, and not from
>probes like "*effectiverights". I reworked some NIST content to do just
>what I described. It was getting effective rights for all domain users,
>when all it really needed was effective rights for a handful of users.
>To determine that handful of users, it had to collect all users. It was
>doing this by utilizing resolve_group in the effectiveright probe. This
>was taking an eternity at a site with 20k users in the domain. I
>modified it to use the sid_sid probe to gather the users, and that sped
>things up considerably. Attached is the original and reworked bit of
>content (in case it helps clarify what I'm describing).
>
>Ken
>
>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Thursday, June 18, 2009 9:18 AM
>To: [hidden email]
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>As we prepare for the next draft of version 5.6 I would like to consider
>addressing the resolve_group behavior. As it is currently defined in
>several of the windows definition schema tests the behavior will result
>in recursively resolving all groups including groups that are not local
>to host that is being evaluated. In a domain environment this results in
>the collection of many, many trustees. Please review the email thread
>below for a more in depth discussion on this issue.
>
>For version 5.6 I would like us to consider adding another behavior that
>would allow us to indicate whether non local groups should be resolved
>or not. Is this a change that we should in clued in version 5.6? Are
>others interested in this addition?
>
>As an aside, the current oval interpreter source aligns with the
>documented resolve_group behavior. This results in the collection of a
>huge number of trustees when working a domain environment. Given the
>amount of data being collected I somewhat doubt that this capability is
>being properly supported in other products. I am curious to know how
>some of the implementers out there have handled this behavior. Perhaps
>your solutions/workarounds can help us develop a better construct in the
>language for version 5.6.
>
>Thanks,
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Wednesday, October 22, 2008 4:53 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>I do agree that a behavior to limit to local machine would be a good
>>idea here.  But as for how version 5.5 is intended, I think the answer
>>is that all users, including domain users are intended.
>>
>>Note that we are only talking about the resolve group behavior.  It is
>>defined with regards to pattern matching that we are only matching
>>against the local system.  The reason for this is that resolving a .*
>>pattern is unrealistic when talking about big domain.
>>
>>The difference here is in the context.  With the resolve group
>>behavior, we are making a pretty explicit statement that we want to
>>look at all users of a given group.  In the pattern match case, we
>>often are just making blanket statement and searching for objects that
>>might match.
>>
>>I guess I would say the difference is due to the perceived usage.
>>
>>Do we agree with this interpretation?  Are we correctly representing
>>the views of the community?
>>
>>Thanks
>>Drew
>>
>>>-----Original Message-----
>>>From: [hidden email] [mailto:[hidden email]]
>>>Sent: Wednesday, October 22, 2008 4:03 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>So just to clarify, any child group should be resolved, even if it's a
>>>domain group? For example:
>>>
>>>Machine\Users
>>>      MyDomain\Users
>>>
>>>If we were to resolve Machine\Users, all users in MyDomain\Users
>>should
>>>be collected as well? If that's the intent, I suggest that a behavior
>>>should be added to control this. I can see this crawling out of
>>control.
>>>I'm not an IT guy, but I know that a domain can have thousands of
>>users,
>>>and groups can contain groups from multiple domains.
>>>
>>>Thanks,
>>>Ken
>>>
>>>-----Original Message-----
>>>From: Buttner, Drew [mailto:[hidden email]]
>>>Sent: Wednesday, October 22, 2008 1:57 PM
>>>To: [hidden email]
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>The original intent of the resolve group behavior was to list ALL
>>>individual members of that group, both from the local machine and the
>>>domain.  I can see how trying to resolve a group call USERS in a
>>domain
>>>environment might be tough.  But at the same time, the goal here was
>>to
>>>resolve something like ADMINISTRATORS that might include both some
>>>local users and some domain users.  Thoughts?
>>>
>>>I can see both valid points and would love to hear other opinions on
>>>this matter.  If my above thinking holds, than how about the following
>>>documentation for the resolve group behavior:
>>>
>>>"The 'resolve_group' behavior defines whether an object set defined by
>>>a group sid should be resolved to return a set that contains all the
>>>user sids that are a member of that group.  Note that all child groups
>>>should also be resolved any valid domain users that are members of the
>>>group should also be included.  The intent of this behavior is to end
>>>up with a list of all individual users from that system that make up
>>>the group once everything has been resolved."
>>>
>>>Thanks
>>>Drew
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Thursday, October 16, 2008 3:06 PM
>>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Does anyone have any opinions on this? I think my vote would be to
>>not
>>>>explore beyond the machine for now, and add a behavior at the next
>>>OVAL
>>>>revision. I'm not a content guy, but my initial feeling is that group
>>>>details beyond the machine level are more noise than useful
>>>information.
>>>>I also think the likelihood of access related errors is fairly high.
>>>>
>>>>Thanks,
>>>>Ken
>>>>
>>>>-----Original Message-----
>>>>From: Simone, Ken
>>>>Sent: Tuesday, October 07, 2008 9:37 AM
>>>>To: [hidden email]
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>Thanks Jon. I have one more question, and then I'll stop bugging you
>>>>about this :-)
>>>>
>>>>Should the recursion be limited to the local machine? For example, if
>>>my
>>>>machine is in a domain called 'Engineering', then there's a good
>>>chance
>>>>that the 'Engineering\Domain Admins' group is in my Administrators
>>>>group. Expanding that group requires hitting the domain controller.
>>>>Should it do that?
>>>>
>>>>Thanks,
>>>>Ken
>>>>
>>>>-----Original Message-----
>>>>From: Baker, Jon [mailto:[hidden email]]
>>>>Sent: Monday, October 06, 2008 12:50 PM
>>>>To: [hidden email]
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>In the OVAL Interpreter I am not recursively resolving groups when
>>>>processing the "resolve_group" behavior. I believe that the intent of
>>>>the schema was for the behavior to recursively resolve all subgroups.
>>>I
>>>>will add a bug for the next release to clarify this documentation and
>>>I
>>>>will add a bug to the interpreter to make sure groups are recursively
>>>>resolved.
>>>>
>>>>Thanks,
>>>>
>>>>Jon
>>>>
>>>>============================================
>>>>Jonathan O. Baker
>>>>The MITRE Corporation
>>>>Email: [hidden email]
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>Sent: Monday, October 06, 2008 11:47 AM
>>>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>Is the intent of resolve group to recursively resolve child groups
>>in
>>>>>addition to the current group?
>>>>>
>>>>>Thanks,
>>>>>Ken
>>>>>
>>>>>-----Original Message-----
>>>>>From: Baker, Jon [mailto:[hidden email]]
>>>>>Sent: Monday, October 06, 2008 10:40 AM
>>>>>To: [hidden email]
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>Ken,
>>>>>
>>>>>The behavior you are asking about here is detailed in the behaviors
>>>>>defined on the test. Look for the "resolve_group" and
>>"include_group"
>>>>>behaviors.
>>>>>
>>>>>
>>>>>Regards,
>>>>>
>>>>>Jon
>>>>>
>>>>>============================================
>>>>>Jonathan O. Baker
>>>>>The MITRE Corporation
>>>>>Email: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>Sent: Monday, October 06, 2008 11:26 AM
>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>>Discussion
>>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>>match
>>>>>>
>>>>>>Thanks Drew. I have one more question... If sids in the ACL
>>>represent
>>>>>>groups, should the groups (and recursively, child groups) be
>>>expanded,
>>>>>>and their members included in the object set as well?
>>>>>>
>>>>>>Thanks,
>>>>>>Ken
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Buttner, Drew [mailto:[hidden email]]
>>>>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>>>>To: [hidden email]
>>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>>match
>>>>>>
>>>>>>I think you bring up a great point.  I agree that the doc should be
>>>a
>>>>>>little more general.  Looking at this doc again, I would also
>>>suggest
>>>>>>that we replace the term "search" with the term "object set".
>>>>>>
>>>>>>Yes, this applies to both equals and not equal.
>>>>>>
>>>>>>I will put this in our tracker for a future release.
>>>>>>
>>>>>>Thanks
>>>>>>Drew
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>>>Discussion
>>>>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>I was going through the 5.5 schema, and noticed this:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>>>group, system, or program (such as a Windows service).  If a
>>>pattern
>>>>>>>match operation is used attempts to identify all the trustees (for
>>>>>>>exampl a .* pattern) then the search should be limited to just the
>>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Would it be fair to reduce it to this?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>"The trustee_sid element is the unique sid that associated a user,
>>>>>>>group, system, or program (such as a Windows service).  If a
>>>pattern
>>>>>>>match operation is used then the search should be limited to just
>>>the
>>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>In other words, is there a need to special case a subset of
>>>patterns
>>>>>>as
>>>>>>>the text implies? I *really* hope not. Also, would this apply to
>>>"not
>>>>>>>equals" as well?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Thanks,
>>>>>>>
>>>>>>>Ken
>>>>>>>
>>>>>>>To unsubscribe, send an email message to [hidden email]
>>>>with
>>>>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>have
>>>>>>>difficulties, write to
>>[hidden email].
>>>>>>
>>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>>[hidden email].
>>>>>>
>>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>>in the BODY of the message.  If you have difficulties, write to
>>>OVAL-
>>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>OVAL-
>>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email] with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to
>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email] with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: 5.5 schema, trustee_sid, pattern match

Andrew Buttner
Administrator
I'm liking this direction.  I would tweak the documentation to read:


> "The trustee_sid entity identifies a unique sid
> associated with a user, group, system, or program
> (such as a Windows service).  If an operation other
> than equals is used to identify trustees (for
> example

does not equal, or

> a .* pattern match) then the

object set

> shall be limited to only the trustees referenced
> in the file's Security Descriptor.  The scope is
> limited here

due to the extreme resource intensiveness of operations targeting a large organization's entire domain.  Larger scope is still obtainable however

> through the use of variables."


Agree?  Thanks
Drew



>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Monday, June 29, 2009 3:54 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>match
>
>Ken,
>
>Your sample content helps. I think your proposal to deprecate the
>"resolve_group" behavior on from all of the test, except for the ones
>that are explicitly designed to gather users and groups makes a lot of
>sense. At the same time I will try to clarify the schema documentation
>on all related tests to ensure that the handling of operations other
>than 'equals' is consistently defined to be relative to the trustees on
>the Security Descriptor or Policy Database or appropriate databases for
>each test.
>
>Here my suggested revision to the documentation on the
>fileeffectiverights53_object trustee_sid entity:
>
>
>"The trustee_sid entity identifies a unique sid associated with a user,
>group, system, or program (such as a Windows service).  If an operation
>other than equals is used to identify trustees (for example a .* pattern
>match) then the search shall be limited to only the trustees referenced
>in the file's Security Descriptor.  The scope is limited here to ensure
>that it is possible to examine the contents of a file's Security
>Descriptor and also leverage large sets of trustees through the use of
>variables."
>
>
>If this revised text captures the needed clarification I will make
>similar updates and deprecate the "resolve_group" behavior on the
>following other tests:
>
>- accesstoken_test
>- fileauditedpermissions53_test
>- fileauditedpermissions_test
>- fileeffectiverights53_test
>- fileeffectiverights_test
>- printereffectiverights_test
>- regkeyauditedpermissions53_test
>- regkeyauditedpermissions_test
>- regkeyeffectiverights53_test
>- regkeyeffectiverights_test
>
>In the end I think this will simplify many implementations that support
>OVAL, help developers understand the affected tests more easily, and
>should not significantly impact content writers.
>
>
>Thanks,
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:[hidden email]]
>>Sent: Thursday, June 18, 2009 11:17 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>We implement this as described in our processor. Our solution to the
>>"large volume of data" problem is to avoid enabling the resolve_group
>>behavior in our content.
>>
>>Anyway... I'm voting against my proposed behavior. I don't think a
>>resolved set of users that doesn't include everything is particularly
>>useful. Instead, I would suggest deprecating this behavior from all of
>>the probes, except for the ones that are explicitly designed to gather
>>users and groups. This would force content authors to collect the users
>>they're interested in w/ probes that can efficiently do it, and not
>from
>>probes like "*effectiverights". I reworked some NIST content to do just
>>what I described. It was getting effective rights for all domain users,
>>when all it really needed was effective rights for a handful of users.
>>To determine that handful of users, it had to collect all users. It was
>>doing this by utilizing resolve_group in the effectiveright probe. This
>>was taking an eternity at a site with 20k users in the domain. I
>>modified it to use the sid_sid probe to gather the users, and that sped
>>things up considerably. Attached is the original and reworked bit of
>>content (in case it helps clarify what I'm describing).
>>
>>Ken
>>
>>-----Original Message-----
>>From: Baker, Jon [mailto:[hidden email]]
>>Sent: Thursday, June 18, 2009 9:18 AM
>>To: [hidden email]
>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>match
>>
>>As we prepare for the next draft of version 5.6 I would like to
>consider
>>addressing the resolve_group behavior. As it is currently defined in
>>several of the windows definition schema tests the behavior will result
>>in recursively resolving all groups including groups that are not local
>>to host that is being evaluated. In a domain environment this results
>in
>>the collection of many, many trustees. Please review the email thread
>>below for a more in depth discussion on this issue.
>>
>>For version 5.6 I would like us to consider adding another behavior
>that
>>would allow us to indicate whether non local groups should be resolved
>>or not. Is this a change that we should in clued in version 5.6? Are
>>others interested in this addition?
>>
>>As an aside, the current oval interpreter source aligns with the
>>documented resolve_group behavior. This results in the collection of a
>>huge number of trustees when working a domain environment. Given the
>>amount of data being collected I somewhat doubt that this capability is
>>being properly supported in other products. I am curious to know how
>>some of the implementers out there have handled this behavior. Perhaps
>>your solutions/workarounds can help us develop a better construct in
>the
>>language for version 5.6.
>>
>>Thanks,
>>
>>Jon
>>
>>============================================
>>Jonathan O. Baker
>>G022 - IA Industry Collaboration
>>The MITRE Corporation
>>Email: [hidden email]
>>
>>
>>>-----Original Message-----
>>>From: Buttner, Drew [mailto:[hidden email]]
>>>Sent: Wednesday, October 22, 2008 4:53 PM
>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>match
>>>
>>>I do agree that a behavior to limit to local machine would be a good
>>>idea here.  But as for how version 5.5 is intended, I think the answer
>>>is that all users, including domain users are intended.
>>>
>>>Note that we are only talking about the resolve group behavior.  It is
>>>defined with regards to pattern matching that we are only matching
>>>against the local system.  The reason for this is that resolving a .*
>>>pattern is unrealistic when talking about big domain.
>>>
>>>The difference here is in the context.  With the resolve group
>>>behavior, we are making a pretty explicit statement that we want to
>>>look at all users of a given group.  In the pattern match case, we
>>>often are just making blanket statement and searching for objects that
>>>might match.
>>>
>>>I guess I would say the difference is due to the perceived usage.
>>>
>>>Do we agree with this interpretation?  Are we correctly representing
>>>the views of the community?
>>>
>>>Thanks
>>>Drew
>>>
>>>>-----Original Message-----
>>>>From: [hidden email] [mailto:[hidden email]]
>>>>Sent: Wednesday, October 22, 2008 4:03 PM
>>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>So just to clarify, any child group should be resolved, even if it's
>a
>>>>domain group? For example:
>>>>
>>>>Machine\Users
>>>>      MyDomain\Users
>>>>
>>>>If we were to resolve Machine\Users, all users in MyDomain\Users
>>>should
>>>>be collected as well? If that's the intent, I suggest that a behavior
>>>>should be added to control this. I can see this crawling out of
>>>control.
>>>>I'm not an IT guy, but I know that a domain can have thousands of
>>>users,
>>>>and groups can contain groups from multiple domains.
>>>>
>>>>Thanks,
>>>>Ken
>>>>
>>>>-----Original Message-----
>>>>From: Buttner, Drew [mailto:[hidden email]]
>>>>Sent: Wednesday, October 22, 2008 1:57 PM
>>>>To: [hidden email]
>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>
>>>>The original intent of the resolve group behavior was to list ALL
>>>>individual members of that group, both from the local machine and the
>>>>domain.  I can see how trying to resolve a group call USERS in a
>>>domain
>>>>environment might be tough.  But at the same time, the goal here was
>>>to
>>>>resolve something like ADMINISTRATORS that might include both some
>>>>local users and some domain users.  Thoughts?
>>>>
>>>>I can see both valid points and would love to hear other opinions on
>>>>this matter.  If my above thinking holds, than how about the
>following
>>>>documentation for the resolve group behavior:
>>>>
>>>>"The 'resolve_group' behavior defines whether an object set defined
>by
>>>>a group sid should be resolved to return a set that contains all the
>>>>user sids that are a member of that group.  Note that all child
>groups
>>>>should also be resolved any valid domain users that are members of
>the
>>>>group should also be included.  The intent of this behavior is to end
>>>>up with a list of all individual users from that system that make up
>>>>the group once everything has been resolved."
>>>>
>>>>Thanks
>>>>Drew
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>Sent: Thursday, October 16, 2008 3:06 PM
>>>>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>Does anyone have any opinions on this? I think my vote would be to
>>>not
>>>>>explore beyond the machine for now, and add a behavior at the next
>>>>OVAL
>>>>>revision. I'm not a content guy, but my initial feeling is that
>group
>>>>>details beyond the machine level are more noise than useful
>>>>information.
>>>>>I also think the likelihood of access related errors is fairly high.
>>>>>
>>>>>Thanks,
>>>>>Ken
>>>>>
>>>>>-----Original Message-----
>>>>>From: Simone, Ken
>>>>>Sent: Tuesday, October 07, 2008 9:37 AM
>>>>>To: [hidden email]
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>Thanks Jon. I have one more question, and then I'll stop bugging you
>>>>>about this :-)
>>>>>
>>>>>Should the recursion be limited to the local machine? For example,
>if
>>>>my
>>>>>machine is in a domain called 'Engineering', then there's a good
>>>>chance
>>>>>that the 'Engineering\Domain Admins' group is in my Administrators
>>>>>group. Expanding that group requires hitting the domain controller.
>>>>>Should it do that?
>>>>>
>>>>>Thanks,
>>>>>Ken
>>>>>
>>>>>-----Original Message-----
>>>>>From: Baker, Jon [mailto:[hidden email]]
>>>>>Sent: Monday, October 06, 2008 12:50 PM
>>>>>To: [hidden email]
>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>match
>>>>>
>>>>>In the OVAL Interpreter I am not recursively resolving groups when
>>>>>processing the "resolve_group" behavior. I believe that the intent
>of
>>>>>the schema was for the behavior to recursively resolve all
>subgroups.
>>>>I
>>>>>will add a bug for the next release to clarify this documentation
>and
>>>>I
>>>>>will add a bug to the interpreter to make sure groups are
>recursively
>>>>>resolved.
>>>>>
>>>>>Thanks,
>>>>>
>>>>>Jon
>>>>>
>>>>>============================================
>>>>>Jonathan O. Baker
>>>>>The MITRE Corporation
>>>>>Email: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>Sent: Monday, October 06, 2008 11:47 AM
>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>Discussion
>>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>>match
>>>>>>
>>>>>>Is the intent of resolve group to recursively resolve child groups
>>>in
>>>>>>addition to the current group?
>>>>>>
>>>>>>Thanks,
>>>>>>Ken
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Baker, Jon [mailto:[hidden email]]
>>>>>>Sent: Monday, October 06, 2008 10:40 AM
>>>>>>To: [hidden email]
>>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>>>match
>>>>>>
>>>>>>Ken,
>>>>>>
>>>>>>The behavior you are asking about here is detailed in the behaviors
>>>>>>defined on the test. Look for the "resolve_group" and
>>>"include_group"
>>>>>>behaviors.
>>>>>>
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Jon
>>>>>>
>>>>>>============================================
>>>>>>Jonathan O. Baker
>>>>>>The MITRE Corporation
>>>>>>Email: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>>Sent: Monday, October 06, 2008 11:26 AM
>>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>>>Discussion
>>>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid,
>pattern
>>>>>>>match
>>>>>>>
>>>>>>>Thanks Drew. I have one more question... If sids in the ACL
>>>>represent
>>>>>>>groups, should the groups (and recursively, child groups) be
>>>>expanded,
>>>>>>>and their members included in the object set as well?
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Ken
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Buttner, Drew [mailto:[hidden email]]
>>>>>>>Sent: Thursday, October 02, 2008 9:24 AM
>>>>>>>To: [hidden email]
>>>>>>>Subject: Re: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid,
>pattern
>>>>>>>match
>>>>>>>
>>>>>>>I think you bring up a great point.  I agree that the doc should
>be
>>>>a
>>>>>>>little more general.  Looking at this doc again, I would also
>>>>suggest
>>>>>>>that we replace the term "search" with the term "object set".
>>>>>>>
>>>>>>>Yes, this applies to both equals and not equal.
>>>>>>>
>>>>>>>I will put this in our tracker for a future release.
>>>>>>>
>>>>>>>Thanks
>>>>>>>Drew
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [hidden email] [mailto:[hidden email]]
>>>>>>>>Sent: Wednesday, October 01, 2008 4:26 PM
>>>>>>>>To: oval-developer-list OVAL Developer List/Closed Public
>>>>Discussion
>>>>>>>>Subject: [OVAL-DEVELOPER-LIST] 5.5 schema, trustee_sid, pattern
>>>>match
>>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>I was going through the 5.5 schema, and noticed this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>"The trustee_sid element is the unique sid that associated a
>user,
>>>>>>>>group, system, or program (such as a Windows service).  If a
>>>>pattern
>>>>>>>>match operation is used attempts to identify all the trustees
>(for
>>>>>>>>exampl a .* pattern) then the search should be limited to just
>the
>>>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Would it be fair to reduce it to this?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>"The trustee_sid element is the unique sid that associated a
>user,
>>>>>>>>group, system, or program (such as a Windows service).  If a
>>>>pattern
>>>>>>>>match operation is used then the search should be limited to just
>>>>the
>>>>>>>>trustees on the DACL/SACL of the object in question."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>In other words, is there a need to special case a subset of
>>>>patterns
>>>>>>>as
>>>>>>>>the text implies? I *really* hope not. Also, would this apply to
>>>>"not
>>>>>>>>equals" as well?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>
>>>>>>>>Ken
>>>>>>>>
>>>>>>>>To unsubscribe, send an email message to [hidden email]
>>>>>with
>>>>>>>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>have
>>>>>>>>difficulties, write to
>>>[hidden email].
>>>>>>>
>>>>>>>To unsubscribe, send an email message to [hidden email]
>>>>with
>>>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>>>[hidden email].
>>>>>>>
>>>>>>>To unsubscribe, send an email message to [hidden email]
>>>>with
>>>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>OVAL-
>>>>>>>[hidden email].
>>>>>>
>>>>>>To unsubscribe, send an email message to [hidden email]
>>>>with
>>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>>[hidden email].
>>>>>>
>>>>>>To unsubscribe, send an email message to [hidden email]
>>>>with
>>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>>in the BODY of the message.  If you have difficulties, write to
>>>OVAL-
>>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>>>>>[hidden email].
>>>>>
>>>>>To unsubscribe, send an email message to [hidden email]
>>>with
>>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>>in the BODY of the message.  If you have difficulties, write to
>OVAL-
>>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to
>>>>[hidden email].
>>>>
>>>>To unsubscribe, send an email message to [hidden email]
>with
>>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>>>[hidden email].
>>>
>>>To unsubscribe, send an email message to [hidden email] with
>>>SIGNOFF OVAL-DEVELOPER-LIST
>>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message.  If you have difficulties, write to OVAL-
>>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].