Re: User Access Control Test

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

Re: User Access Control Test

Hansbury, Matt
Hi Miroslaw,

Before answering your specific question, I want to make you aware of a couple of things about this test.  First, there was a bit of conversation previously on this test that is important to be aware of:

http://making-security-measurable.1364806.n2.nabble.com/Is-the-win-def-uac-test-Necessary-tp3999228p4025634.html
http://making-security-measurable.1364806.n2.nabble.com/Re-Is-the-win-def-uac-test-Necessary-tp4094359p4094737.html

The second thing to know is that we currently have a tracker on record to deprecate this test, stemming from the above conversation.  We have not deprecated it yet, but given the conversation around it and the existing tracker, it would seem possible that this could be removed from the language in the future.  

That is all just to make sure you're aware of possible changes.  It doesn't help with your immediate question.  From the sounds of things, you are implementing this test and are wondering how to represent the various entities, since the OVAL Specification isn't clear on the text to use for each.  Of the possible solutions you mentioned, I think the best answer is using a format like:

ELEVATE_WITHOUT_PROMPTING

As that provides a lot more information that simply using 0x0000000 and is in line with how we typically represent enumeration values.  Does that make sense?

Thanks
Matt

-----Original Message-----
From: Miroslaw Zurek [mailto:[hidden email]]
Sent: Wednesday, December 05, 2012 10:34 AM
To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
Subject: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi all,

I am working with UAC Test. It's great test and have all information that I need but I have a little problem with two fields, elevation_prompt_admin and elevation_prompt_standard. The specification is saying that:


elevation_prompt_admin oval-def:EntityStateStringType <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType> 0 1
Behavior of the elevation prompt for administrators in Admin Approval Mode.
elevation_prompt_standard oval-def:EntityStateStringType <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType> 0 1
Behavior of the elevation prompt for standard users.

And these two fields should be a text message but what kind of information should be kept? When I took a look into MSDN I found that:

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode <http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior>  

and it contains

Prompt for credentials on the secure desktop
Elevate without prompting
Prompt for consent on the secure desktop
etc.

http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior

So the elevation_prompt_admin should have this format:

PROMPT_FOR_CREDENTIALS_ON_THE_SECURE_DESKTOP
ELEVATE_WITHOUT_PROMPTING
etc.

or
Prompt for credentials on the secure desktop

or it should be a number 1,2,3 ... etc. like here

http://msdn.microsoft.com/en-us/library/cc232761%28v=prot.20%29.aspx

And the same situation is for the elevation_prompt_standard:

http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_StandardUserPromptBehavior

http://msdn.microsoft.com/en-us/library/cc232762%28v=prot.20%29.aspx

So the question is what kind of format message should have these two fields?

Thanks,
Miroslaw Zurek
To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: User Access Control Test

Miroslaw Zurek
Hi Matt,

Thanks for your response about User Access Control. I agree with the format of text e.i. ELEVATE_WITHOUT_PROMPTING. It's good for me.

I would prefer this test should stay in the Oval Specification and I agree with Paul arguments about UAC. It's much easier to have all necessary data in one place.

Regards,
Miroslaw Zurek


2012/12/13 Hansbury, Matt <[hidden email]>
Hi Miroslaw,

Before answering your specific question, I want to make you aware of a couple of things about this test.  First, there was a bit of conversation previously on this test that is important to be aware of:

http://making-security-measurable.1364806.n2.nabble.com/Is-the-win-def-uac-test-Necessary-tp3999228p4025634.html
http://making-security-measurable.1364806.n2.nabble.com/Re-Is-the-win-def-uac-test-Necessary-tp4094359p4094737.html

The second thing to know is that we currently have a tracker on record to deprecate this test, stemming from the above conversation.  We have not deprecated it yet, but given the conversation around it and the existing tracker, it would seem possible that this could be removed from the language in the future.

That is all just to make sure you're aware of possible changes.  It doesn't help with your immediate question.  From the sounds of things, you are implementing this test and are wondering how to represent the various entities, since the OVAL Specification isn't clear on the text to use for each.  Of the possible solutions you mentioned, I think the best answer is using a format like:

ELEVATE_WITHOUT_PROMPTING

As that provides a lot more information that simply using 0x0000000 and is in line with how we typically represent enumeration values.  Does that make sense?

Thanks
Matt

-----Original Message-----
From: Miroslaw Zurek [mailto:[hidden email]]
Sent: Wednesday, December 05, 2012 10:34 AM
To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
Subject: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi all,

I am working with UAC Test. It's great test and have all information that I need but I have a little problem with two fields, elevation_prompt_admin and elevation_prompt_standard. The specification is saying that:


elevation_prompt_admin   oval-def:EntityStateStringType <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType>          0       1
Behavior of the elevation prompt for administrators in Admin Approval Mode.
elevation_prompt_standard        oval-def:EntityStateStringType <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType>          0       1
Behavior of the elevation prompt for standard users.

And these two fields should be a text message but what kind of information should be kept? When I took a look into MSDN I found that:

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode <http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior>

and it contains

Prompt for credentials on the secure desktop
Elevate without prompting
Prompt for consent on the secure desktop
etc.

http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior

So the elevation_prompt_admin should have this format:

PROMPT_FOR_CREDENTIALS_ON_THE_SECURE_DESKTOP
ELEVATE_WITHOUT_PROMPTING
etc.

or
Prompt for credentials on the secure desktop

or it should be a number 1,2,3 ... etc. like here

http://msdn.microsoft.com/en-us/library/cc232761%28v=prot.20%29.aspx

And the same situation is for the elevation_prompt_standard:

http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_StandardUserPromptBehavior

http://msdn.microsoft.com/en-us/library/cc232762%28v=prot.20%29.aspx

So the question is what kind of format message should have these two fields?

Thanks,
Miroslaw Zurek
To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-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-DISCUSSION-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: User Access Control Test

Hansbury, Matt
Hi Miroslaw,

Good to hear that the text format works for you.

As for the deprecation aspect, we created a tracker for the possibility of deprecating the test some time ago.  However, it seems that there wasn't a clear consensus from the group on the topic, at least not from the responses we saw.  Thanks to you for providing your feedback on the test's value.

Are there any other folks with thoughts on this test?  

Thanks
Matt

-----Original Message-----
From: Miroslaw Zurek [mailto:[hidden email]]
Sent: Tuesday, December 18, 2012 3:51 PM
To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi Matt,


Thanks for your response about User Access Control. I agree with the format of text e.i. ELEVATE_WITHOUT_PROMPTING. It's good for me.


I would prefer this test should stay in the Oval Specification and I agree with Paul arguments about UAC. It's much easier to have all necessary data in one place.


Regards,

Miroslaw Zurek



2012/12/13 Hansbury, Matt <[hidden email]>


        Hi Miroslaw,
       
        Before answering your specific question, I want to make you aware of a couple of things about this test.  First, there was a bit of conversation previously on this test that is important to be aware of:
       
        http://making-security-measurable.1364806.n2.nabble.com/Is-the-win-def-uac-test-Necessary-tp3999228p4025634.html
        http://making-security-measurable.1364806.n2.nabble.com/Re-Is-the-win-def-uac-test-Necessary-tp4094359p4094737.html
       
        The second thing to know is that we currently have a tracker on record to deprecate this test, stemming from the above conversation.  We have not deprecated it yet, but given the conversation around it and the existing tracker, it would seem possible that this could be removed from the language in the future.
       
        That is all just to make sure you're aware of possible changes.  It doesn't help with your immediate question.  From the sounds of things, you are implementing this test and are wondering how to represent the various entities, since the OVAL Specification isn't clear on the text to use for each.  Of the possible solutions you mentioned, I think the best answer is using a format like:
       
        ELEVATE_WITHOUT_PROMPTING
       
        As that provides a lot more information that simply using 0x0000000 and is in line with how we typically represent enumeration values.  Does that make sense?
       
        Thanks
        Matt
       
        -----Original Message-----
        From: Miroslaw Zurek [mailto:[hidden email]]
        Sent: Wednesday, December 05, 2012 10:34 AM
        To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
        Subject: [OVAL-DISCUSSION-LIST] User Access Control Test
       
        Hi all,
       
        I am working with UAC Test. It's great test and have all information that I need but I have a little problem with two fields, elevation_prompt_admin and elevation_prompt_standard. The specification is saying that:
       
       
        elevation_prompt_admin   oval-def:EntityStateStringType <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType>          0       1
        Behavior of the elevation prompt for administrators in Admin Approval Mode.
        elevation_prompt_standard        oval-def:EntityStateStringType <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType>          0       1
        Behavior of the elevation prompt for standard users.
       
        And these two fields should be a text message but what kind of information should be kept? When I took a look into MSDN I found that:
       
        User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode <http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior>
       
        and it contains
       
        Prompt for credentials on the secure desktop
        Elevate without prompting
        Prompt for consent on the secure desktop
        etc.
       
        http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior
       
        So the elevation_prompt_admin should have this format:
       
        PROMPT_FOR_CREDENTIALS_ON_THE_SECURE_DESKTOP
        ELEVATE_WITHOUT_PROMPTING
        etc.
       
        or
        Prompt for credentials on the secure desktop
       
        or it should be a number 1,2,3 ... etc. like here
       
        http://msdn.microsoft.com/en-us/library/cc232761%28v=prot.20%29.aspx
       
        And the same situation is for the elevation_prompt_standard:
       
        http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_StandardUserPromptBehavior
       
        http://msdn.microsoft.com/en-us/library/cc232762%28v=prot.20%29.aspx
       
        So the question is what kind of format message should have these two fields?
       
        Thanks,
        Miroslaw Zurek
        To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: User Access Control Test

lutton
Hi all,

As a relative newbie here, I'm reticent to jump in here, but Matt *did* ask
so...

I find this probe to be poorly defined in that the underlying values for the
elevation_prompt_xxx elements are clearly enumerations, yet those elements
are defined to be essentially unconstrained string values.  As such, content
authors have (almost) no guidance on what to expect/check for in these
elements.  

That last is not entirely true, content authors do have, at least, OVALDI's
behavior to look at.  It looks like OVALDI chooses to return the underlying
integer value formatted as a string (with an OVAL data type of string -
probably to conform to the spec for the uac_item).  Should OVALDI's behavior
be considered in this discussion?

I confess I'm surprised that the conversation to this point has not
considered/examined what existing content looks for in this item.  Perhaps
there is no way to know what existing content looks for?

In general, do the conclusions reached in discussions like this have any
binding effect?  IOW, will the spec now be updated with the proposed
enumerated legal string values for these entities?  

Closer to home, should I change my (currently OVALDI compatible) my UAC
object implementation based on this discussion?

Somewhat more generally, does the SCAP Validation community abide by
discussions here when deciding whether an SCAP implementation is 'correct'
in its handling of its OVAL checks?

I seem to have gotten off track a bit, perhaps I should start a new thread
for some of these more general questions?

WRT the UAC elevation items, I guess I would suggest that we adopt the
position that we follow the behavior OVALDI where it exists and where it is
not obviously broken.  Thoughts?

Thanks in advance,
Bill L.



-----Original Message-----
From: Hansbury, Matt [mailto:[hidden email]]
Sent: Wednesday, December 19, 2012 7:07 AM
To: [hidden email]
Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi Miroslaw,

Good to hear that the text format works for you.

As for the deprecation aspect, we created a tracker for the possibility of
deprecating the test some time ago.  However, it seems that there wasn't a
clear consensus from the group on the topic, at least not from the responses
we saw.  Thanks to you for providing your feedback on the test's value.

Are there any other folks with thoughts on this test?  

Thanks
Matt

-----Original Message-----
From: Miroslaw Zurek [mailto:[hidden email]]
Sent: Tuesday, December 18, 2012 3:51 PM
To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi Matt,


Thanks for your response about User Access Control. I agree with the format
of text e.i. ELEVATE_WITHOUT_PROMPTING. It's good for me.


I would prefer this test should stay in the Oval Specification and I agree
with Paul arguments about UAC. It's much easier to have all necessary data
in one place.


Regards,

Miroslaw Zurek



2012/12/13 Hansbury, Matt <[hidden email]>


        Hi Miroslaw,
       
        Before answering your specific question, I want to make you aware of
a couple of things about this test.  First, there was a bit of conversation
previously on this test that is important to be aware of:
       
       
http://making-security-measurable.1364806.n2.nabble.com/Is-the-win-def-uac-t
est-Necessary-tp3999228p4025634.html
       
http://making-security-measurable.1364806.n2.nabble.com/Re-Is-the-win-def-ua
c-test-Necessary-tp4094359p4094737.html
       
        The second thing to know is that we currently have a tracker on
record to deprecate this test, stemming from the above conversation.  We
have not deprecated it yet, but given the conversation around it and the
existing tracker, it would seem possible that this could be removed from the
language in the future.
       
        That is all just to make sure you're aware of possible changes.  It
doesn't help with your immediate question.  From the sounds of things, you
are implementing this test and are wondering how to represent the various
entities, since the OVAL Specification isn't clear on the text to use for
each.  Of the possible solutions you mentioned, I think the best answer is
using a format like:
       
        ELEVATE_WITHOUT_PROMPTING
       
        As that provides a lot more information that simply using 0x0000000
and is in line with how we typically represent enumeration values.  Does
that make sense?
       
        Thanks
        Matt
       
        -----Original Message-----
        From: Miroslaw Zurek [mailto:[hidden email]]
        Sent: Wednesday, December 05, 2012 10:34 AM
        To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
        Subject: [OVAL-DISCUSSION-LIST] User Access Control Test
       
        Hi all,
       
        I am working with UAC Test. It's great test and have all information
that I need but I have a little problem with two fields,
elevation_prompt_admin and elevation_prompt_standard. The specification is
saying that:
       
       
        elevation_prompt_admin   oval-def:EntityStateStringType
<https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/
oval-definitions-schema.html#EntityStateStringType>          0       1
        Behavior of the elevation prompt for administrators in Admin
Approval Mode.
        elevation_prompt_standard        oval-def:EntityStateStringType
<https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/
oval-definitions-schema.html#EntityStateStringType>          0       1
        Behavior of the elevation prompt for standard users.
       
        And these two fields should be a text message but what kind of
information should be kept? When I took a look into MSDN I found that:
       
        User Account Control: Behavior of the elevation prompt for
administrators in Admin Approval Mode
<http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_
AdminPromptBehavior>
       
        and it contains
       
        Prompt for credentials on the secure desktop
        Elevate without prompting
        Prompt for consent on the secure desktop
        etc.
       
       
http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_A
dminPromptBehavior
       
        So the elevation_prompt_admin should have this format:
       
        PROMPT_FOR_CREDENTIALS_ON_THE_SECURE_DESKTOP
        ELEVATE_WITHOUT_PROMPTING
        etc.
       
        or
        Prompt for credentials on the secure desktop
       
        or it should be a number 1,2,3 ... etc. like here
       
        http://msdn.microsoft.com/en-us/library/cc232761%28v=prot.20%29.aspx
       
        And the same situation is for the elevation_prompt_standard:
       
       
http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_S
tandardUserPromptBehavior
       
        http://msdn.microsoft.com/en-us/library/cc232762%28v=prot.20%29.aspx
       
        So the question is what kind of format message should have these two
fields?
       
        Thanks,
        Miroslaw Zurek
        To unsubscribe, send an email message to [hidden email]
with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: User Access Control Test

joval
There is no SCAP validation content for the UAC test.  There is a piece of MITRE test content, but it's not instructive.

Nothing said on this list is binding, but it can be instructive, and a lot of what's discussed will seem to find its way into the next version of OVAL.  Given the state of the UAC test however, I'd guess that anyone writing content to validate a UAC setting is probably using a registry test.

On 12/20/2012 3:05 PM, Bill Lutton wrote:
Hi all,

As a relative newbie here, I'm reticent to jump in here, but Matt *did* ask
so...

I find this probe to be poorly defined in that the underlying values for the
elevation_prompt_xxx elements are clearly enumerations, yet those elements
are defined to be essentially unconstrained string values.  As such, content
authors have (almost) no guidance on what to expect/check for in these
elements.  

That last is not entirely true, content authors do have, at least, OVALDI's
behavior to look at.  It looks like OVALDI chooses to return the underlying
integer value formatted as a string (with an OVAL data type of string -
probably to conform to the spec for the uac_item).  Should OVALDI's behavior
be considered in this discussion?

I confess I'm surprised that the conversation to this point has not
considered/examined what existing content looks for in this item.  Perhaps
there is no way to know what existing content looks for?

In general, do the conclusions reached in discussions like this have any
binding effect?  IOW, will the spec now be updated with the proposed
enumerated legal string values for these entities?  

Closer to home, should I change my (currently OVALDI compatible) my UAC
object implementation based on this discussion?

Somewhat more generally, does the SCAP Validation community abide by
discussions here when deciding whether an SCAP implementation is 'correct'
in its handling of its OVAL checks?

I seem to have gotten off track a bit, perhaps I should start a new thread
for some of these more general questions?

WRT the UAC elevation items, I guess I would suggest that we adopt the
position that we follow the behavior OVALDI where it exists and where it is
not obviously broken.  Thoughts?

Thanks in advance,
Bill L.



-----Original Message-----
From: Hansbury, Matt [[hidden email]] 
Sent: Wednesday, December 19, 2012 7:07 AM
To: [hidden email]
Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi Miroslaw,

Good to hear that the text format works for you.

As for the deprecation aspect, we created a tracker for the possibility of
deprecating the test some time ago.  However, it seems that there wasn't a
clear consensus from the group on the topic, at least not from the responses
we saw.  Thanks to you for providing your feedback on the test's value. 

Are there any other folks with thoughts on this test?  

Thanks
Matt

-----Original Message-----
From: Miroslaw Zurek [[hidden email]]
Sent: Tuesday, December 18, 2012 3:51 PM
To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test

Hi Matt,


Thanks for your response about User Access Control. I agree with the format
of text e.i. ELEVATE_WITHOUT_PROMPTING. It's good for me.


I would prefer this test should stay in the Oval Specification and I agree
with Paul arguments about UAC. It's much easier to have all necessary data
in one place.


Regards,

Miroslaw Zurek



2012/12/13 Hansbury, Matt [hidden email]


	Hi Miroslaw,
	
	Before answering your specific question, I want to make you aware of
a couple of things about this test.  First, there was a bit of conversation
previously on this test that is important to be aware of:
	
	
http://making-security-measurable.1364806.n2.nabble.com/Is-the-win-def-uac-t
est-Necessary-tp3999228p4025634.html
	
http://making-security-measurable.1364806.n2.nabble.com/Re-Is-the-win-def-ua
c-test-Necessary-tp4094359p4094737.html
	
	The second thing to know is that we currently have a tracker on
record to deprecate this test, stemming from the above conversation.  We
have not deprecated it yet, but given the conversation around it and the
existing tracker, it would seem possible that this could be removed from the
language in the future.
	
	That is all just to make sure you're aware of possible changes.  It
doesn't help with your immediate question.  From the sounds of things, you
are implementing this test and are wondering how to represent the various
entities, since the OVAL Specification isn't clear on the text to use for
each.  Of the possible solutions you mentioned, I think the best answer is
using a format like:
	
	ELEVATE_WITHOUT_PROMPTING
	
	As that provides a lot more information that simply using 0x0000000
and is in line with how we typically represent enumeration values.  Does
that make sense?
	
	Thanks
	Matt
	
	-----Original Message-----
	From: Miroslaw Zurek [[hidden email]]
	Sent: Wednesday, December 05, 2012 10:34 AM
	To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
	Subject: [OVAL-DISCUSSION-LIST] User Access Control Test
	
	Hi all,
	
	I am working with UAC Test. It's great test and have all information
that I need but I have a little problem with two fields,
elevation_prompt_admin and elevation_prompt_standard. The specification is
saying that:
	
	
	elevation_prompt_admin   oval-def:EntityStateStringType
<https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/
oval-definitions-schema.html#EntityStateStringType>          0       1
	Behavior of the elevation prompt for administrators in Admin
Approval Mode.
	elevation_prompt_standard        oval-def:EntityStateStringType
<https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/
oval-definitions-schema.html#EntityStateStringType>          0       1
	Behavior of the elevation prompt for standard users.
	
	And these two fields should be a text message but what kind of
information should be kept? When I took a look into MSDN I found that:
	
	User Account Control: Behavior of the elevation prompt for
administrators in Admin Approval Mode
<http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_
AdminPromptBehavior>
	
	and it contains
	
	Prompt for credentials on the secure desktop
	Elevate without prompting
	Prompt for consent on the secure desktop
	etc.
	
	
http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_A
dminPromptBehavior
	
	So the elevation_prompt_admin should have this format:
	
	PROMPT_FOR_CREDENTIALS_ON_THE_SECURE_DESKTOP
	ELEVATE_WITHOUT_PROMPTING
	etc.
	
	or
	Prompt for credentials on the secure desktop
	
	or it should be a number 1,2,3 ... etc. like here
	
	http://msdn.microsoft.com/en-us/library/cc232761%28v=prot.20%29.aspx
	
	And the same situation is for the elevation_prompt_standard:
	
	
http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_S
tandardUserPromptBehavior
	
	http://msdn.microsoft.com/en-us/library/cc232762%28v=prot.20%29.aspx
	
	So the question is what kind of format message should have these two
fields?
	
	Thanks,
	Miroslaw Zurek
	To unsubscribe, send an email message to [hidden email]
with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].


--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download

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

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: User Access Control Test

Hansbury, Matt
David is correct here, the team here at MITRE uses this list (and the developer list) as ways to reach out to the community to gather as much information and thoughts as possible on a given subject.  We work with the community (and the OVAL Board) to determine the best path forward.  

For something like this I think we have two possible directions:

1. Deprecate the test
Or
2. Update the specification such that the ambiguity identified during this thread is removed.  

Given the discussion so far, I'm inclined to move this conversation to the developer list, since that is the most appropriate place for it.  I didn't want to abruptly cut it off here, but since it seems that there are some thoughts on the topic, I'll start a fresh thread (with some context from this current one) over to the developer list.  

Thanks for the input provide so far.  

Oh, and one more thing...in general, the best tool for implementing the OVAL Language is the Specification.  It would certainly be appropriate to update implementations based on a shared understanding over the list, but two thoughts with doing that:

1. If it is something that is directly stated in the Specification, and the decision is to reverse or change something, I wouldn't do that type of change until after a new release of the Language.
2. For something that is vague or simply underspecified, then I would think it might make more sense to update it ahead of any official Language update.  

Thanks
Matt

-----Original Message-----
From: David Solin [mailto:[hidden email]]
Sent: Thursday, December 20, 2012 4:36 PM
To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test

There is no SCAP validation content for the UAC test.  There is a piece of MITRE test content, but it's not instructive.

Nothing said on this list is binding, but it can be instructive, and a lot of what's discussed will seem to find its way into the next version of OVAL.  Given the state of the UAC test however, I'd guess that anyone writing content to validate a UAC setting is probably using a registry test.


On 12/20/2012 3:05 PM, Bill Lutton wrote:


        Hi all,
       
        As a relative newbie here, I'm reticent to jump in here, but Matt *did* ask
        so...
       
        I find this probe to be poorly defined in that the underlying values for the
        elevation_prompt_xxx elements are clearly enumerations, yet those elements
        are defined to be essentially unconstrained string values.  As such, content
        authors have (almost) no guidance on what to expect/check for in these
        elements.  
       
        That last is not entirely true, content authors do have, at least, OVALDI's
        behavior to look at.  It looks like OVALDI chooses to return the underlying
        integer value formatted as a string (with an OVAL data type of string -
        probably to conform to the spec for the uac_item).  Should OVALDI's behavior
        be considered in this discussion?
       
        I confess I'm surprised that the conversation to this point has not
        considered/examined what existing content looks for in this item.  Perhaps
        there is no way to know what existing content looks for?
       
        In general, do the conclusions reached in discussions like this have any
        binding effect?  IOW, will the spec now be updated with the proposed
        enumerated legal string values for these entities?  
       
        Closer to home, should I change my (currently OVALDI compatible) my UAC
        object implementation based on this discussion?
       
        Somewhat more generally, does the SCAP Validation community abide by
        discussions here when deciding whether an SCAP implementation is 'correct'
        in its handling of its OVAL checks?
       
        I seem to have gotten off track a bit, perhaps I should start a new thread
        for some of these more general questions?
       
        WRT the UAC elevation items, I guess I would suggest that we adopt the
        position that we follow the behavior OVALDI where it exists and where it is
        not obviously broken.  Thoughts?
       
        Thanks in advance,
        Bill L.
       
       
       
        -----Original Message-----
        From: Hansbury, Matt [mailto:[hidden email]]
        Sent: Wednesday, December 19, 2012 7:07 AM
        To: [hidden email]
        Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test
       
        Hi Miroslaw,
       
        Good to hear that the text format works for you.
       
        As for the deprecation aspect, we created a tracker for the possibility of
        deprecating the test some time ago.  However, it seems that there wasn't a
        clear consensus from the group on the topic, at least not from the responses
        we saw.  Thanks to you for providing your feedback on the test's value.
       
        Are there any other folks with thoughts on this test?  
       
        Thanks
        Matt
       
        -----Original Message-----
        From: Miroslaw Zurek [mailto:[hidden email]]
        Sent: Tuesday, December 18, 2012 3:51 PM
        To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
        Subject: Re: [OVAL-DISCUSSION-LIST] User Access Control Test
       
        Hi Matt,
       
       
        Thanks for your response about User Access Control. I agree with the format
        of text e.i. ELEVATE_WITHOUT_PROMPTING. It's good for me.
       
       
        I would prefer this test should stay in the Oval Specification and I agree
        with Paul arguments about UAC. It's much easier to have all necessary data
        in one place.
       
       
        Regards,
       
        Miroslaw Zurek
       
       
       
        2012/12/13 Hansbury, Matt <[hidden email]> <mailto:[hidden email]>
       
       
                Hi Miroslaw,
               
                Before answering your specific question, I want to make you aware of
        a couple of things about this test.  First, there was a bit of conversation
        previously on this test that is important to be aware of:
               
               
        http://making-security-measurable.1364806.n2.nabble.com/Is-the-win-def-uac-t
        est-Necessary-tp3999228p4025634.html
               
        http://making-security-measurable.1364806.n2.nabble.com/Re-Is-the-win-def-ua
        c-test-Necessary-tp4094359p4094737.html
               
                The second thing to know is that we currently have a tracker on
        record to deprecate this test, stemming from the above conversation.  We
        have not deprecated it yet, but given the conversation around it and the
        existing tracker, it would seem possible that this could be removed from the
        language in the future.
               
                That is all just to make sure you're aware of possible changes.  It
        doesn't help with your immediate question.  From the sounds of things, you
        are implementing this test and are wondering how to represent the various
        entities, since the OVAL Specification isn't clear on the text to use for
        each.  Of the possible solutions you mentioned, I think the best answer is
        using a format like:
               
                ELEVATE_WITHOUT_PROMPTING
               
                As that provides a lot more information that simply using 0x0000000
        and is in line with how we typically represent enumeration values.  Does
        that make sense?
               
                Thanks
                Matt
               
                -----Original Message-----
                From: Miroslaw Zurek [mailto:[hidden email]]
                Sent: Wednesday, December 05, 2012 10:34 AM
                To: oval-discussion-list OVAL Discussion List/Closed Public Discussi
                Subject: [OVAL-DISCUSSION-LIST] User Access Control Test
               
                Hi all,
               
                I am working with UAC Test. It's great test and have all information
        that I need but I have a little problem with two fields,
        elevation_prompt_admin and elevation_prompt_standard. The specification is
        saying that:
               
               
                elevation_prompt_admin   oval-def:EntityStateStringType
        <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/
        oval-definitions-schema.html#EntityStateStringType> <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType>           0       1
                Behavior of the elevation prompt for administrators in Admin
        Approval Mode.
                elevation_prompt_standard        oval-def:EntityStateStringType
        <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/
        oval-definitions-schema.html#EntityStateStringType> <https://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation/oval-definitions-schema.html#EntityStateStringType>           0       1
                Behavior of the elevation prompt for standard users.
               
                And these two fields should be a text message but what kind of
        information should be kept? When I took a look into MSDN I found that:
               
                User Account Control: Behavior of the elevation prompt for
        administrators in Admin Approval Mode
        <http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_
        AdminPromptBehavior> <http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_AdminPromptBehavior>
               
                and it contains
               
                Prompt for credentials on the secure desktop
                Elevate without prompting
                Prompt for consent on the secure desktop
                etc.
               
               
        http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_A
        dminPromptBehavior
               
                So the elevation_prompt_admin should have this format:
               
                PROMPT_FOR_CREDENTIALS_ON_THE_SECURE_DESKTOP
                ELEVATE_WITHOUT_PROMPTING
                etc.
               
                or
                Prompt for credentials on the secure desktop
               
                or it should be a number 1,2,3 ... etc. like here
               
                http://msdn.microsoft.com/en-us/library/cc232761%28v=prot.20%29.aspx
               
                And the same situation is for the elevation_prompt_standard:
               
               
        http://technet.microsoft.com/en-us/library/dd835564%28v=ws.10%29.aspx#BKMK_S
        tandardUserPromptBehavior
               
                http://msdn.microsoft.com/en-us/library/cc232762%28v=prot.20%29.aspx
               
                So the question is what kind of format message should have these two
        fields?
               
                Thanks,
                Miroslaw Zurek
                To unsubscribe, send an email message to [hidden email]
        with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-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-DISCUSSION-LIST
        in the BODY of the message.  If you have difficulties, write to [hidden email].



--


jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org>  | Features <http://www.joval.org/features/>  | Download <http://www.joval.org/download/>  

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DISCUSSION-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-DISCUSSION-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].