unix_def:file_object and symbolic links.

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

unix_def:file_object and symbolic links.

dpeddicord
All,
The current definition of file object behavior appears to have too much ambiguity.
As you well know in unix and unix-like systems symbolic links permissions are meaningless as the actual file permissions are the permissions of the symlink target.
I believe the ambiguity lies in the issue that a symbolic link (like most unix things) is a file and therefore should be treated as such. Although there are means of implementing such file_object with
current OVAL specs. It does tend to obscure the meaning/intent of the content at times.
I propose that the committee reduce the ambiguity by selecting one of two options:
        1. Define permissions of symbolic links as the permissions of the  target (de-referenced file.) If the target does not exist, then "does not exist" status would make sense.
Or
        2. Create a Boolean attribute for file_object ... such are dereference_sym_links=x   which would create the behavior outlined in  #1 to take place.

I would like to hear other thoughts on this

Don Peddicord

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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

David Solin-3
Hi Don,

I agree with you that the ambiguity needs to be addressed.  Whatever proposal emerges from this discussion should apply to both unix:file_object and unix_fileextendedattribute_object.

There is a way to build an OVAL test so that it applies generically to either a file or its symlink target.  OVAL 5.11 introduced a symlink_test/object.  This object can be used to obtain the ultimate destination file path for a symlink (even if the target file itself does not exist).

It is therefore possible to use a symlink_object whose filepath entity references a variable based on the original file_object’s filepath field, to construct another variable based on that symlink_object’s canonical_path field, and use that variable’s value to determine the filepath entity of yet another file_object, which will either produce an error (if the original file is not a symlink), or will represent the actual file that is the link target.

An error is produced whenever a variable value is based on an object that doesn’t exist (due to a note to that effect in the OVAL specification).  But that can be worked-around by ORing the result of the error-producing test, with a test for non-existence of the symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE, FALSE OR FALSE => FALSE produces the necessary range of results for testing whether the target satisfies a comparison with a state, provided that the target exists).

If we were to go with your proposal #1, we would be attesting in OVAL that symlink files that point to invalid paths do not themselves exist, and I think we don’t really want that.

Your proposal #2 requires a new attribute to unix:FileBehaviors.  There was actually a MITRE proposal about modifying Unix FileBehaviors to solve this class of problems.  I think Michael (Andy) Chisolm made the proposal?  It died, IIRC because there was insufficient time to consider whether it had any unforeseen side-effects before the 5.11 deadline.

I cannot seem to find that proposal on the Making Security Measurable list archive.  Can anyone dredge it up so we can take another look?

Best regards,
— David A. Solin
Co-Founder, Research & Technology
[hidden email]

 

   



> On Jul 29, 2015, at 9:58 AM, Peddicord, Don <[hidden email]> wrote:
>
> All,
> The current definition of file object behavior appears to have too much ambiguity.
> As you well know in unix and unix-like systems symbolic links permissions are meaningless as the actual file permissions are the permissions of the symlink target.
> I believe the ambiguity lies in the issue that a symbolic link (like most unix things) is a file and therefore should be treated as such. Although there are means of implementing such file_object with
> current OVAL specs. It does tend to obscure the meaning/intent of the content at times.
> I propose that the committee reduce the ambiguity by selecting one of two options:
> 1. Define permissions of symbolic links as the permissions of the  target (de-referenced file.) If the target does not exist, then "does not exist" status would make sense.
> Or
> 2. Create a Boolean attribute for file_object ... such are dereference_sym_links=x   which would create the behavior outlined in  #1 to take place.
>
> I would like to hear other thoughts on this
>
> Don Peddicord
>
> 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

Steve Grubb
On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:

> Hi Don,
>
> I agree with you that the ambiguity needs to be addressed.  Whatever
> proposal emerges from this discussion should apply to both unix:file_object
> and unix_fileextendedattribute_object.
>
> There is a way to build an OVAL test so that it applies generically to
> either a file or its symlink target.  OVAL 5.11 introduced a
> symlink_test/object.  This object can be used to obtain the ultimate
> destination file path for a symlink (even if the target file itself does
> not exist).
>
> It is therefore possible to use a symlink_object whose filepath entity
> references a variable based on the original file_object’s filepath field,
> to construct another variable based on that symlink_object’s canonical_path
> field, and use that variable’s value to determine the filepath entity of
> yet another file_object, which will either produce an error (if the
> original file is not a symlink), or will represent the actual file that is
> the link target.
>
> An error is produced whenever a variable value is based on an object that
> doesn’t exist (due to a note to that effect in the OVAL specification).
> But that can be worked-around by ORing the result of the error-producing
> test, with a test for non-existence of the symlink_object (because TRUE OR
> ERROR => TRUE, FALSE OR TRUE => TRUE, FALSE OR FALSE => FALSE produces the
> necessary range of results for testing whether the target satisfies a
> comparison with a state, provided that the target exists).
>
> If we were to go with your proposal #1, we would be attesting in OVAL that
> symlink files that point to invalid paths do not themselves exist, and I
> think we don’t really want that.
>
> Your proposal #2 requires a new attribute to unix:FileBehaviors.  There was
> actually a MITRE proposal about modifying Unix FileBehaviors to solve this
> class of problems.  I think Michael (Andy) Chisolm made the proposal?  It
> died, IIRC because there was insufficient time to consider whether it had
> any unforeseen side-effects before the 5.11 deadline.
>
> I cannot seem to find that proposal on the Making Security Measurable list
> archive.  Can anyone dredge it up so we can take another look?

This has been asked before:
http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html

My position on the subject is in this thread:

http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-test-td7581356.html

-Steve



> > On Jul 29, 2015, at 9:58 AM, Peddicord, Don <[hidden email]>
> > All,
> > The current definition of file object behavior appears to have too much
> > ambiguity. As you well know in unix and unix-like systems symbolic links
> > permissions are meaningless as the actual file permissions are the
> > permissions of the symlink target. I believe the ambiguity lies in the
> > issue that a symbolic link (like most unix things) is a file and
> > therefore should be treated as such. Although there are means of
> > implementing such file_object with current OVAL specs. It does tend to
> > obscure the meaning/intent of the content at times.>
> > I propose that the committee reduce the ambiguity by selecting one of two options:
> > 1. Define permissions of symbolic links as the permissions of the  target
> > (de-referenced file.) If the target does not exist, then "does not
> > exist" status would make sense.>
> > Or
> >
> > 2. Create a Boolean attribute for file_object ... such are
> > dereference_sym_links=x   which would create the behavior outlined in
> > #1 to take place.>
> > I would like to hear other thoughts on this
> >
> > Don Peddicord
> >
> > 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

drothenberg
Steve's links and additional related discussions on this topic are all located in the comments on the open OVAL Language issue tracker [1] for this topic.

Thanks,
David Rothenberg

[1] https://github.com/OVALProject/Language/issues/107

-----Original Message-----
From: Steve Grubb [mailto:[hidden email]]
Sent: Wednesday, July 29, 2015 12:25 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion <[hidden email]>
Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.

On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:

> Hi Don,
>
> I agree with you that the ambiguity needs to be addressed.  Whatever
> proposal emerges from this discussion should apply to both
> unix:file_object and unix_fileextendedattribute_object.
>
> There is a way to build an OVAL test so that it applies generically to
> either a file or its symlink target.  OVAL 5.11 introduced a
> symlink_test/object.  This object can be used to obtain the ultimate
> destination file path for a symlink (even if the target file itself
> does not exist).
>
> It is therefore possible to use a symlink_object whose filepath entity
> references a variable based on the original file_object’s filepath
> field, to construct another variable based on that symlink_object’s
> canonical_path field, and use that variable’s value to determine the
> filepath entity of yet another file_object, which will either produce
> an error (if the original file is not a symlink), or will represent
> the actual file that is the link target.
>
> An error is produced whenever a variable value is based on an object
> that doesn’t exist (due to a note to that effect in the OVAL specification).
> But that can be worked-around by ORing the result of the
> error-producing test, with a test for non-existence of the
> symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE,
> FALSE OR FALSE => FALSE produces the necessary range of results for
> testing whether the target satisfies a comparison with a state, provided that the target exists).
>
> If we were to go with your proposal #1, we would be attesting in OVAL
> that symlink files that point to invalid paths do not themselves
> exist, and I think we don’t really want that.
>
> Your proposal #2 requires a new attribute to unix:FileBehaviors.  
> There was actually a MITRE proposal about modifying Unix FileBehaviors
> to solve this class of problems.  I think Michael (Andy) Chisolm made
> the proposal?  It died, IIRC because there was insufficient time to
> consider whether it had any unforeseen side-effects before the 5.11 deadline.
>
> I cannot seem to find that proposal on the Making Security Measurable
> list archive.  Can anyone dredge it up so we can take another look?

This has been asked before:
http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html

My position on the subject is in this thread:

http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-test-td7581356.html

-Steve



> > On Jul 29, 2015, at 9:58 AM, Peddicord, Don
> > <[hidden email]> All, The current definition of file
> > object behavior appears to have too much ambiguity. As you well know
> > in unix and unix-like systems symbolic links permissions are
> > meaningless as the actual file permissions are the permissions of
> > the symlink target. I believe the ambiguity lies in the issue that a
> > symbolic link (like most unix things) is a file and therefore should
> > be treated as such. Although there are means of implementing such
> > file_object with current OVAL specs. It does tend to obscure the
> > meaning/intent of the content at times.> I propose that the
> > committee reduce the ambiguity by selecting one of two options:
> > 1. Define permissions of symbolic links as the permissions of the  target
> > (de-referenced file.) If the target does not exist, then "does not
> > exist" status would make sense.>
> > Or
> >
> > 2. Create a Boolean attribute for file_object ... such are
> > dereference_sym_links=x   which would create the behavior outlined in
> > #1 to take place.>
> > I would like to hear other thoughts on this
> >
> > Don Peddicord
> >
> > 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

dpeddicord
In reply to this post by Steve Grubb
Steve, David...
I could not find the discussion / proposal for adding an  attribute, though I  am sure I seen it proposed before.

A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.

If the target does not exist then there are no permissions / attributes to gather (hence my "does not exist" idea.)

Don


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Steve Grubb
Sent: Wednesday, July 29, 2015 12:25 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.

On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:

> Hi Don,
>
> I agree with you that the ambiguity needs to be addressed.  Whatever
> proposal emerges from this discussion should apply to both
> unix:file_object and unix_fileextendedattribute_object.
>
> There is a way to build an OVAL test so that it applies generically to
> either a file or its symlink target.  OVAL 5.11 introduced a
> symlink_test/object.  This object can be used to obtain the ultimate
> destination file path for a symlink (even if the target file itself
> does not exist).
>
> It is therefore possible to use a symlink_object whose filepath entity
> references a variable based on the original file_object’s filepath
> field, to construct another variable based on that symlink_object’s
> canonical_path field, and use that variable’s value to determine the
> filepath entity of yet another file_object, which will either produce
> an error (if the original file is not a symlink), or will represent
> the actual file that is the link target.
>
> An error is produced whenever a variable value is based on an object
> that doesn’t exist (due to a note to that effect in the OVAL specification).
> But that can be worked-around by ORing the result of the
> error-producing test, with a test for non-existence of the
> symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE,
> FALSE OR FALSE => FALSE produces the necessary range of results for
> testing whether the target satisfies a comparison with a state, provided that the target exists).
>
> If we were to go with your proposal #1, we would be attesting in OVAL
> that symlink files that point to invalid paths do not themselves
> exist, and I think we don’t really want that.
>
> Your proposal #2 requires a new attribute to unix:FileBehaviors.  
> There was actually a MITRE proposal about modifying Unix FileBehaviors
> to solve this class of problems.  I think Michael (Andy) Chisolm made
> the proposal?  It died, IIRC because there was insufficient time to
> consider whether it had any unforeseen side-effects before the 5.11 deadline.
>
> I cannot seem to find that proposal on the Making Security Measurable
> list archive.  Can anyone dredge it up so we can take another look?

This has been asked before:
http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html

My position on the subject is in this thread:

http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-test-td7581356.html

-Steve



> > On Jul 29, 2015, at 9:58 AM, Peddicord, Don
> > <[hidden email]> All, The current definition of file
> > object behavior appears to have too much ambiguity. As you well know
> > in unix and unix-like systems symbolic links permissions are
> > meaningless as the actual file permissions are the permissions of
> > the symlink target. I believe the ambiguity lies in the issue that a
> > symbolic link (like most unix things) is a file and therefore should
> > be treated as such. Although there are means of implementing such
> > file_object with current OVAL specs. It does tend to obscure the
> > meaning/intent of the content at times.> I propose that the
> > committee reduce the ambiguity by selecting one of two options:
> > 1. Define permissions of symbolic links as the permissions of the  target
> > (de-referenced file.) If the target does not exist, then "does not
> > exist" status would make sense.>
> > Or
> >
> > 2. Create a Boolean attribute for file_object ... such are
> > dereference_sym_links=x   which would create the behavior outlined in
> > #1 to take place.>
> > I would like to hear other thoughts on this
> >
> > Don Peddicord
> >
> > 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

David Solin-3
Hi Don,

Any variable that points to an object that doesn’t exist generates an error, it has nothing to do with whether or not there is a file at the path to which the link points.

From the OVAL definitions-schema documentation (emphasis added):

< variable >

The variable element is an abstract element that is meant to be extended (via substitution groups) by the different types of variables. An actual variable element is not valid. The different variable types describe different sources for obtaining a value(s) for the variable. There are currently three types of variables; local, external, and constant. Please refer to the description of each one for more specific information. The value(s) of a variable is treated as if it were inserted where referenced. One of the main benefits of variables is that they allow tests to evaluate user-defined policy. For example, an OVAL Test might check to see if a password is at least a certain number of characters long, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element that defines the length.

If a variable defines a collection of values, any entity that references the variable will evaluate to true depending on the value of the var_check attribute. For example, if an entity 'size' with an operation of 'less than' references a variable that returns five different integers, and the var_check attribute has a value of 'all', then the 'size' entity returns true only if the actual size is less than each of the five integers defined by the variable. If a variable does not return any value, then an error should be reported during OVAL analysis.


Nevertheless, as I sketched out below, it is still possible to write any definition to account and correct for the possibility of this particular error.

Best regards,
—David Solin

On Jul 29, 2015, at 11:32 AM, Peddicord, Don <[hidden email]> wrote:

Steve, David...
I could not find the discussion / proposal for adding an  attribute, though I  am sure I seen it proposed before.

A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.

If the target does not exist then there are no permissions / attributes to gather (hence my "does not exist" idea.)

Don


-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Steve Grubb
Sent: Wednesday, July 29, 2015 12:25 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.

On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:
Hi Don,

I agree with you that the ambiguity needs to be addressed.  Whatever 
proposal emerges from this discussion should apply to both 
unix:file_object and unix_fileextendedattribute_object.

There is a way to build an OVAL test so that it applies generically to 
either a file or its symlink target.  OVAL 5.11 introduced a 
symlink_test/object.  This object can be used to obtain the ultimate 
destination file path for a symlink (even if the target file itself 
does not exist).

It is therefore possible to use a symlink_object whose filepath entity 
references a variable based on the original file_object’s filepath 
field, to construct another variable based on that symlink_object’s 
canonical_path field, and use that variable’s value to determine the 
filepath entity of yet another file_object, which will either produce 
an error (if the original file is not a symlink), or will represent 
the actual file that is the link target.

An error is produced whenever a variable value is based on an object 
that doesn’t exist (due to a note to that effect in the OVAL specification).
But that can be worked-around by ORing the result of the 
error-producing test, with a test for non-existence of the 
symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE, 
FALSE OR FALSE => FALSE produces the necessary range of results for 
testing whether the target satisfies a comparison with a state, provided that the target exists).

If we were to go with your proposal #1, we would be attesting in OVAL 
that symlink files that point to invalid paths do not themselves 
exist, and I think we don’t really want that.

Your proposal #2 requires a new attribute to unix:FileBehaviors.  
There was actually a MITRE proposal about modifying Unix FileBehaviors 
to solve this class of problems.  I think Michael (Andy) Chisolm made 
the proposal?  It died, IIRC because there was insufficient time to 
consider whether it had any unforeseen side-effects before the 5.11 deadline.

I cannot seem to find that proposal on the Making Security Measurable 
list archive.  Can anyone dredge it up so we can take another look?

This has been asked before:
http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html

My position on the subject is in this thread:

http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-test-td7581356.html

-Steve



On Jul 29, 2015, at 9:58 AM, Peddicord, Don 
<[hidden email]> All, The current definition of file 
object behavior appears to have too much ambiguity. As you well know 
in unix and unix-like systems symbolic links permissions are 
meaningless as the actual file permissions are the permissions of 
the symlink target. I believe the ambiguity lies in the issue that a 
symbolic link (like most unix things) is a file and therefore should 
be treated as such. Although there are means of implementing such 
file_object with current OVAL specs. It does tend to obscure the 
meaning/intent of the content at times.> I propose that the 
committee reduce the ambiguity by selecting one of two options:
1. Define permissions of symbolic links as the permissions of the  target
(de-referenced file.) If the target does not exist, then "does not
exist" status would make sense.>
Or

2. Create a Boolean attribute for file_object ... such are
dereference_sym_links=x   which would create the behavior outlined in 
#1 to take place.>
I would like to hear other thoughts on this

Don Peddicord

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

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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

dpeddicord
Thanks David,
You are enlightening as usual.
Thanks also to David Rothernberg for the link to the original thread.
Don


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Solin
Sent: Wednesday, July 29, 2015 1:16 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.

Hi Don,

Any variable that points to an object that doesn’t exist generates an error, it has nothing to do with whether or not there is a file at the path to which the link points.

From the OVAL definitions-schema documentation (emphasis added):

< variable >

The variable element is an abstract element that is meant to be extended (via substitution groups) by the different types of variables. An actual variable element is not valid. The different variable types describe different sources for obtaining a value(s) for the variable. There are currently three types of variables; local, external, and constant. Please refer to the description of each one for more specific information. The value(s) of a variable is treated as if it were inserted where referenced. One of the main benefits of variables is that they allow tests to evaluate user-defined policy. For example, an OVAL Test might check to see if a password is at least a certain number of characters long, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element that defines the length.

If a variable defines a collection of values, any entity that references the variable will evaluate to true depending on the value of the var_check attribute. For example, if an entity 'size' with an operation of 'less than' references a variable that returns five different integers, and the var_check attribute has a value of 'all', then the 'size' entity returns true only if the actual size is less than each of the five integers defined by the variable. If a variable does not return any value, then an error should be reported during OVAL analysis.



Nevertheless, as I sketched out below, it is still possible to write any definition to account and correct for the possibility of this particular error.

Best regards,

—David Solin


        On Jul 29, 2015, at 11:32 AM, Peddicord, Don <[hidden email]> wrote:
       
        Steve, David...
        I could not find the discussion / proposal for adding an  attribute, though I  am sure I seen it proposed before.
       
        A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.
       
        If the target does not exist then there are no permissions / attributes to gather (hence my "does not exist" idea.)
       
        Don
       
       
        -----Original Message-----
        From: [hidden email] [mailto:[hidden email]] On Behalf Of Steve Grubb
        Sent: Wednesday, July 29, 2015 12:25 PM
        To: [hidden email]
        Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
       
        On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:
       

                Hi Don,
               
                I agree with you that the ambiguity needs to be addressed.  Whatever
                proposal emerges from this discussion should apply to both
                unix:file_object and unix_fileextendedattribute_object.
               
                There is a way to build an OVAL test so that it applies generically to
                either a file or its symlink target.  OVAL 5.11 introduced a
                symlink_test/object.  This object can be used to obtain the ultimate
                destination file path for a symlink (even if the target file itself
                does not exist).
               
                It is therefore possible to use a symlink_object whose filepath entity
                references a variable based on the original file_object’s filepath
                field, to construct another variable based on that symlink_object’s
                canonical_path field, and use that variable’s value to determine the
                filepath entity of yet another file_object, which will either produce
                an error (if the original file is not a symlink), or will represent
                the actual file that is the link target.
               
                An error is produced whenever a variable value is based on an object
                that doesn’t exist (due to a note to that effect in the OVAL specification).
                But that can be worked-around by ORing the result of the
                error-producing test, with a test for non-existence of the
                symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE,
                FALSE OR FALSE => FALSE produces the necessary range of results for
                testing whether the target satisfies a comparison with a state, provided that the target exists).
               
                If we were to go with your proposal #1, we would be attesting in OVAL
                that symlink files that point to invalid paths do not themselves
                exist, and I think we don’t really want that.
               
                Your proposal #2 requires a new attribute to unix:FileBehaviors.  
                There was actually a MITRE proposal about modifying Unix FileBehaviors
                to solve this class of problems.  I think Michael (Andy) Chisolm made
                the proposal?  It died, IIRC because there was insufficient time to
                consider whether it had any unforeseen side-effects before the 5.11 deadline.
               
                I cannot seem to find that proposal on the Making Security Measurable
                list archive.  Can anyone dredge it up so we can take another look?
               


        This has been asked before:
        http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html
       
        My position on the subject is in this thread:
       
        http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-test-td7581356.html
       
        -Steve
       
       
       
       

                        On Jul 29, 2015, at 9:58 AM, Peddicord, Don
                        <[hidden email]> All, The current definition of file
                        object behavior appears to have too much ambiguity. As you well know
                        in unix and unix-like systems symbolic links permissions are
                        meaningless as the actual file permissions are the permissions of
                        the symlink target. I believe the ambiguity lies in the issue that a
                        symbolic link (like most unix things) is a file and therefore should
                        be treated as such. Although there are means of implementing such
                        file_object with current OVAL specs. It does tend to obscure the
                        meaning/intent of the content at times.> I propose that the
                        committee reduce the ambiguity by selecting one of two options:
                        1. Define permissions of symbolic links as the permissions of the  target
                        (de-referenced file.) If the target does not exist, then "does not
                        exist" status would make sense.>
                        Or
                       
                        2. Create a Boolean attribute for file_object ... such are
                        dereference_sym_links=x   which would create the behavior outlined in
                        #1 to take place.>
                        I would like to hear other thoughts on this
                       
                        Don Peddicord
                       
                        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].
       


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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

David Solin-3
Unfortunately that thread doesn't include the proposal I was thinking about. Does anyone else remember it?

Sent from my iPhone

> On Jul 29, 2015, at 12:29 PM, Peddicord, Don <[hidden email]> wrote:
>
> Thanks David,
> You are enlightening as usual.
> Thanks also to David Rothernberg for the link to the original thread.
> Don
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of David Solin
> Sent: Wednesday, July 29, 2015 1:16 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>
> Hi Don,
>
> Any variable that points to an object that doesn’t exist generates an error, it has nothing to do with whether or not there is a file at the path to which the link points.
>
> From the OVAL definitions-schema documentation (emphasis added):
>
> < variable >
>
> The variable element is an abstract element that is meant to be extended (via substitution groups) by the different types of variables. An actual variable element is not valid. The different variable types describe different sources for obtaining a value(s) for the variable. There are currently three types of variables; local, external, and constant. Please refer to the description of each one for more specific information. The value(s) of a variable is treated as if it were inserted where referenced. One of the main benefits of variables is that they allow tests to evaluate user-defined policy. For example, an OVAL Test might check to see if a password is at least a certain number of characters long, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element that defines the length.
>
> If a variable defines a collection of values, any entity that references the variable will evaluate to true depending on the value of the var_check attribute. For example, if an entity 'size' with an operation of 'less than' references a variable that returns five different integers, and the var_check attribute has a value of 'all', then the 'size' entity returns true only if the actual size is less than each of the five integers defined by the variable. If a variable does not return any value, then an error should be reported during OVAL analysis.
>
>
>
> Nevertheless, as I sketched out below, it is still possible to write any definition to account and correct for the possibility of this particular error.
>
> Best regards,
>
> —David Solin
>
>
>    On Jul 29, 2015, at 11:32 AM, Peddicord, Don <[hidden email]> wrote:
>    
>    Steve, David...
>    I could not find the discussion / proposal for adding an  attribute, though I  am sure I seen it proposed before.
>    
>    A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.
>    
>    If the target does not exist then there are no permissions / attributes to gather (hence my "does not exist" idea.)
>    
>    Don
>    
>    
>    -----Original Message-----
>    From: [hidden email] [mailto:[hidden email]] On Behalf Of Steve Grubb
>    Sent: Wednesday, July 29, 2015 12:25 PM
>    To: [hidden email]
>    Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>    
>    On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:
>    
>
>        Hi Don,
>        
>        I agree with you that the ambiguity needs to be addressed.  Whatever
>        proposal emerges from this discussion should apply to both
>        unix:file_object and unix_fileextendedattribute_object.
>        
>        There is a way to build an OVAL test so that it applies generically to
>        either a file or its symlink target.  OVAL 5.11 introduced a
>        symlink_test/object.  This object can be used to obtain the ultimate
>        destination file path for a symlink (even if the target file itself
>        does not exist).
>        
>        It is therefore possible to use a symlink_object whose filepath entity
>        references a variable based on the original file_object’s filepath
>        field, to construct another variable based on that symlink_object’s
>        canonical_path field, and use that variable’s value to determine the
>        filepath entity of yet another file_object, which will either produce
>        an error (if the original file is not a symlink), or will represent
>        the actual file that is the link target.
>        
>        An error is produced whenever a variable value is based on an object
>        that doesn’t exist (due to a note to that effect in the OVAL specification).
>        But that can be worked-around by ORing the result of the
>        error-producing test, with a test for non-existence of the
>        symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE,
>        FALSE OR FALSE => FALSE produces the necessary range of results for
>        testing whether the target satisfies a comparison with a state, provided that the target exists).
>        
>        If we were to go with your proposal #1, we would be attesting in OVAL
>        that symlink files that point to invalid paths do not themselves
>        exist, and I think we don’t really want that.
>        
>        Your proposal #2 requires a new attribute to unix:FileBehaviors.  
>        There was actually a MITRE proposal about modifying Unix FileBehaviors
>        to solve this class of problems.  I think Michael (Andy) Chisolm made
>        the proposal?  It died, IIRC because there was insufficient time to
>        consider whether it had any unforeseen side-effects before the 5.11 deadline.
>        
>        I cannot seem to find that proposal on the Making Security Measurable
>        list archive.  Can anyone dredge it up so we can take another look?
>        
>
>
>    This has been asked before:
>    http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-Capabilities-UNCLASSIFIED-td6158009.html
>    
>    My position on the subject is in this thread:
>    
>    http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-test-td7581356.html
>    
>    -Steve
>    
>    
>    
>    
>
>            On Jul 29, 2015, at 9:58 AM, Peddicord, Don
>            <[hidden email]> All, The current definition of file
>            object behavior appears to have too much ambiguity. As you well know
>            in unix and unix-like systems symbolic links permissions are
>            meaningless as the actual file permissions are the permissions of
>            the symlink target. I believe the ambiguity lies in the issue that a
>            symbolic link (like most unix things) is a file and therefore should
>            be treated as such. Although there are means of implementing such
>            file_object with current OVAL specs. It does tend to obscure the
>            meaning/intent of the content at times.> I propose that the
>            committee reduce the ambiguity by selecting one of two options:
>            1. Define permissions of symbolic links as the permissions of the  target
>            (de-referenced file.) If the target does not exist, then "does not
>            exist" status would make sense.>
>            Or
>            
>            2. Create a Boolean attribute for file_object ... such are
>            dereference_sym_links=x   which would create the behavior outlined in
>            #1 to take place.>
>            I would like to hear other thoughts on this
>            
>            Don Peddicord
>            
>            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].
>    
>
>
> 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

drothenberg
David,
I believe you are referencing the "Path Datatypes in OVAL" discussion- http://making-security-measurable.1364806.n2.nabble.com/Path-Datatypes-in-OVAL-td7578604.html.

Thanks,
David Rothenberg

-----Original Message-----
From: David Solin [mailto:[hidden email]]
Sent: Wednesday, July 29, 2015 11:04 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion <[hidden email]>
Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.

Unfortunately that thread doesn't include the proposal I was thinking about. Does anyone else remember it?

Sent from my iPhone

> On Jul 29, 2015, at 12:29 PM, Peddicord, Don <[hidden email]> wrote:
>
> Thanks David,
> You are enlightening as usual.
> Thanks also to David Rothernberg for the link to the original thread.
> Don
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of David
> Solin
> Sent: Wednesday, July 29, 2015 1:16 PM
> To: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>
> Hi Don,
>
> Any variable that points to an object that doesn’t exist generates an error, it has nothing to do with whether or not there is a file at the path to which the link points.
>
> From the OVAL definitions-schema documentation (emphasis added):
>
> < variable >
>
> The variable element is an abstract element that is meant to be extended (via substitution groups) by the different types of variables. An actual variable element is not valid. The different variable types describe different sources for obtaining a value(s) for the variable. There are currently three types of variables; local, external, and constant. Please refer to the description of each one for more specific information. The value(s) of a variable is treated as if it were inserted where referenced. One of the main benefits of variables is that they allow tests to evaluate user-defined policy. For example, an OVAL Test might check to see if a password is at least a certain number of characters long, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element that defines the length.
>
> If a variable defines a collection of values, any entity that references the variable will evaluate to true depending on the value of the var_check attribute. For example, if an entity 'size' with an operation of 'less than' references a variable that returns five different integers, and the var_check attribute has a value of 'all', then the 'size' entity returns true only if the actual size is less than each of the five integers defined by the variable. If a variable does not return any value, then an error should be reported during OVAL analysis.
>
>
>
> Nevertheless, as I sketched out below, it is still possible to write any definition to account and correct for the possibility of this particular error.
>
> Best regards,
>
> —David Solin
>
>
>    On Jul 29, 2015, at 11:32 AM, Peddicord, Don <[hidden email]> wrote:
>    
>    Steve, David...
>    I could not find the discussion / proposal for adding an  attribute, though I  am sure I seen it proposed before.
>    
>    A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.
>    
>    If the target does not exist then there are no permissions /
> attributes to gather (hence my "does not exist" idea.)
>    
>    Don
>    
>    
>    -----Original Message-----
>    From: [hidden email] [mailto:[hidden email]] On Behalf Of Steve Grubb
>    Sent: Wednesday, July 29, 2015 12:25 PM
>    To: [hidden email]
>    Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>    
>    On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:
>    
>
>        Hi Don,
>        
>        I agree with you that the ambiguity needs to be addressed.  Whatever
>        proposal emerges from this discussion should apply to both
>        unix:file_object and unix_fileextendedattribute_object.
>        
>        There is a way to build an OVAL test so that it applies generically to
>        either a file or its symlink target.  OVAL 5.11 introduced a
>        symlink_test/object.  This object can be used to obtain the ultimate
>        destination file path for a symlink (even if the target file itself
>        does not exist).
>        
>        It is therefore possible to use a symlink_object whose filepath entity
>        references a variable based on the original file_object’s filepath
>        field, to construct another variable based on that symlink_object’s
>        canonical_path field, and use that variable’s value to determine the
>        filepath entity of yet another file_object, which will either produce
>        an error (if the original file is not a symlink), or will represent
>        the actual file that is the link target.
>        
>        An error is produced whenever a variable value is based on an object
>        that doesn’t exist (due to a note to that effect in the OVAL specification).
>        But that can be worked-around by ORing the result of the
>        error-producing test, with a test for non-existence of the
>        symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE,
>        FALSE OR FALSE => FALSE produces the necessary range of results for
>        testing whether the target satisfies a comparison with a state, provided that the target exists).
>        
>        If we were to go with your proposal #1, we would be attesting in OVAL
>        that symlink files that point to invalid paths do not themselves
>        exist, and I think we don’t really want that.
>        
>        Your proposal #2 requires a new attribute to unix:FileBehaviors.  
>        There was actually a MITRE proposal about modifying Unix FileBehaviors
>        to solve this class of problems.  I think Michael (Andy) Chisolm made
>        the proposal?  It died, IIRC because there was insufficient time to
>        consider whether it had any unforeseen side-effects before the 5.11 deadline.
>        
>        I cannot seem to find that proposal on the Making Security Measurable
>        list archive.  Can anyone dredge it up so we can take another look?
>        
>
>
>    This has been asked before:
>    
> http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-C
> apabilities-UNCLASSIFIED-td6158009.html
>    
>    My position on the subject is in this thread:
>    
>    
> http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-
> test-td7581356.html
>    
>    -Steve
>    
>    
>    
>    
>
>            On Jul 29, 2015, at 9:58 AM, Peddicord, Don
>            <[hidden email]> All, The current definition of file
>            object behavior appears to have too much ambiguity. As you well know
>            in unix and unix-like systems symbolic links permissions are
>            meaningless as the actual file permissions are the permissions of
>            the symlink target. I believe the ambiguity lies in the issue that a
>            symbolic link (like most unix things) is a file and therefore should
>            be treated as such. Although there are means of implementing such
>            file_object with current OVAL specs. It does tend to obscure the
>            meaning/intent of the content at times.> I propose that the
>            committee reduce the ambiguity by selecting one of two options:
>            1. Define permissions of symbolic links as the permissions of the  target
>            (de-referenced file.) If the target does not exist, then "does not
>            exist" status would make sense.>
>            Or
>            
>            2. Create a Boolean attribute for file_object ... such are
>            dereference_sym_links=x   which would create the behavior outlined in
>            #1 to take place.>
>            I would like to hear other thoughts on this
>            
>            Don Peddicord
>            
>            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].
>    
>
>
> 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

David Solin-3
No, that was one I was happy to see die.  I specifically recall a recent (as in the last 18 months, anyway) MITRE-developed proposal to update File behaviors across object types.  Maybe it was just a dream… a too-real dream!

David A. Solin
Co-Founder, Research & Technology
[hidden email]

 

   



> On Jul 30, 2015, at 7:29 AM, Rothenberg, David B. <[hidden email]> wrote:
>
> David,
> I believe you are referencing the "Path Datatypes in OVAL" discussion- http://making-security-measurable.1364806.n2.nabble.com/Path-Datatypes-in-OVAL-td7578604.html.
>
> Thanks,
> David Rothenberg
>
> -----Original Message-----
> From: David Solin [mailto:[hidden email]]
> Sent: Wednesday, July 29, 2015 11:04 PM
> To: oval-developer-list OVAL Developer List/Closed Public Discussion <[hidden email]>
> Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>
> Unfortunately that thread doesn't include the proposal I was thinking about. Does anyone else remember it?
>
> Sent from my iPhone
>
>> On Jul 29, 2015, at 12:29 PM, Peddicord, Don <[hidden email]> wrote:
>>
>> Thanks David,
>> You are enlightening as usual.
>> Thanks also to David Rothernberg for the link to the original thread.
>> Don
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of David
>> Solin
>> Sent: Wednesday, July 29, 2015 1:16 PM
>> To: [hidden email]
>> Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>>
>> Hi Don,
>>
>> Any variable that points to an object that doesn’t exist generates an error, it has nothing to do with whether or not there is a file at the path to which the link points.
>>
>> From the OVAL definitions-schema documentation (emphasis added):
>>
>> < variable >
>>
>> The variable element is an abstract element that is meant to be extended (via substitution groups) by the different types of variables. An actual variable element is not valid. The different variable types describe different sources for obtaining a value(s) for the variable. There are currently three types of variables; local, external, and constant. Please refer to the description of each one for more specific information. The value(s) of a variable is treated as if it were inserted where referenced. One of the main benefits of variables is that they allow tests to evaluate user-defined policy. For example, an OVAL Test might check to see if a password is at least a certain number of characters long, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element that defines the length.
>>
>> If a variable defines a collection of values, any entity that references the variable will evaluate to true depending on the value of the var_check attribute. For example, if an entity 'size' with an operation of 'less than' references a variable that returns five different integers, and the var_check attribute has a value of 'all', then the 'size' entity returns true only if the actual size is less than each of the five integers defined by the variable. If a variable does not return any value, then an error should be reported during OVAL analysis.
>>
>>
>>
>> Nevertheless, as I sketched out below, it is still possible to write any definition to account and correct for the possibility of this particular error.
>>
>> Best regards,
>>
>> —David Solin
>>
>>
>>   On Jul 29, 2015, at 11:32 AM, Peddicord, Don <[hidden email]> wrote:
>>
>>   Steve, David...
>>   I could not find the discussion / proposal for adding an  attribute, though I  am sure I seen it proposed before.
>>
>>   A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.
>>
>>   If the target does not exist then there are no permissions /
>> attributes to gather (hence my "does not exist" idea.)
>>
>>   Don
>>
>>
>>   -----Original Message-----
>>   From: [hidden email] [mailto:[hidden email]] On Behalf Of Steve Grubb
>>   Sent: Wednesday, July 29, 2015 12:25 PM
>>   To: [hidden email]
>>   Subject: Re: [OVAL-DEVELOPER-LIST] unix_def:file_object and symbolic links.
>>
>>   On Wednesday, July 29, 2015 11:11:54 AM David Solin wrote:
>>
>>
>>       Hi Don,
>>
>>       I agree with you that the ambiguity needs to be addressed.  Whatever
>>       proposal emerges from this discussion should apply to both
>>       unix:file_object and unix_fileextendedattribute_object.
>>
>>       There is a way to build an OVAL test so that it applies generically to
>>       either a file or its symlink target.  OVAL 5.11 introduced a
>>       symlink_test/object.  This object can be used to obtain the ultimate
>>       destination file path for a symlink (even if the target file itself
>>       does not exist).
>>
>>       It is therefore possible to use a symlink_object whose filepath entity
>>       references a variable based on the original file_object’s filepath
>>       field, to construct another variable based on that symlink_object’s
>>       canonical_path field, and use that variable’s value to determine the
>>       filepath entity of yet another file_object, which will either produce
>>       an error (if the original file is not a symlink), or will represent
>>       the actual file that is the link target.
>>
>>       An error is produced whenever a variable value is based on an object
>>       that doesn’t exist (due to a note to that effect in the OVAL specification).
>>       But that can be worked-around by ORing the result of the
>>       error-producing test, with a test for non-existence of the
>>       symlink_object (because TRUE OR ERROR => TRUE, FALSE OR TRUE => TRUE,
>>       FALSE OR FALSE => FALSE produces the necessary range of results for
>>       testing whether the target satisfies a comparison with a state, provided that the target exists).
>>
>>       If we were to go with your proposal #1, we would be attesting in OVAL
>>       that symlink files that point to invalid paths do not themselves
>>       exist, and I think we don’t really want that.
>>
>>       Your proposal #2 requires a new attribute to unix:FileBehaviors.  
>>       There was actually a MITRE proposal about modifying Unix FileBehaviors
>>       to solve this class of problems.  I think Michael (Andy) Chisolm made
>>       the proposal?  It died, IIRC because there was insufficient time to
>>       consider whether it had any unforeseen side-effects before the 5.11 deadline.
>>
>>       I cannot seem to find that proposal on the Making Security Measurable
>>       list archive.  Can anyone dredge it up so we can take another look?
>>
>>
>>
>>   This has been asked before:
>>
>> http://making-security-measurable.1364806.n2.nabble.com/UNIX-Symlink-C
>> apabilities-UNCLASSIFIED-td6158009.html
>>
>>   My position on the subject is in this thread:
>>
>>
>> http://making-security-measurable.1364806.n2.nabble.com/The-unix-file-
>> test-td7581356.html
>>
>>   -Steve
>>
>>
>>
>>
>>
>>           On Jul 29, 2015, at 9:58 AM, Peddicord, Don
>>           <[hidden email]> All, The current definition of file
>>           object behavior appears to have too much ambiguity. As you well know
>>           in unix and unix-like systems symbolic links permissions are
>>           meaningless as the actual file permissions are the permissions of
>>           the symlink target. I believe the ambiguity lies in the issue that a
>>           symbolic link (like most unix things) is a file and therefore should
>>           be treated as such. Although there are means of implementing such
>>           file_object with current OVAL specs. It does tend to obscure the
>>           meaning/intent of the content at times.> I propose that the
>>           committee reduce the ambiguity by selecting one of two options:
>>           1. Define permissions of symbolic links as the permissions of the  target
>>           (de-referenced file.) If the target does not exist, then "does not
>>           exist" status would make sense.>
>>           Or
>>
>>           2. Create a Boolean attribute for file_object ... such are
>>           dereference_sym_links=x   which would create the behavior outlined in
>>           #1 to take place.>
>>           I would like to hear other thoughts on this
>>
>>           Don Peddicord
>>
>>           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].
>>
>>
>>
>> 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
|  
Report Content as Inappropriate

Re: unix_def:file_object and symbolic links.

Darren J Moffat
In reply to this post by dpeddicord
On 07/29/15 17:32, Peddicord, Don wrote:
> A symbolic link can be "valid" even if the target does not exist.  I am not sure that that should be an error, which could be problem with the current method.

On Solaris 11 systems there are also "special" symbolic links that while
they look like a symlink they are really reparse points for NFS referals
and Microsoft SMB DFS.

If viewed with 'ls -l' they look something like this:

$ ls -l /export/home/alice
lrwxrwxrwx   1 root     root          62 Aug  5 14:05 /export/home/alice
-> @{REPARSE@{nfs-basic:nas1.example.com:/vol/users/us/ca/alice}}

They also have the XAT_REPARSE system attribute set on them.

The data format of the "link target" comes from the BSD "magic" symlinks
as defined here:  http://www.daemon-systems.org/man/symlink.7.html


--
Darren J Moffat

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].
Loading...