CIFS crawl - Directory Traverse Enforcement

[Steve Kearns <ke...@gmail.com>]

Hi,

I am setting up a crawler for a Windows Share (CIFS), with output to a Solr
4 index.

I was able to get things up and running quite well -- thanks for the great
documentation, it has all worked as expected, with one rather nuanced
question around security.

My internal users are quite security conscious, and some of them have
raised the question of how security works with regard to directory
traversal permissions.

Here's an example to illustrate:

\\server\Folder1\Folder2\Foo.txt

The share allows Domain Users to connect.
Folder1 also allows Domain Users to read.
Folder2 does not inherit permissions from Folder1, and only the user Admin1
has read/write permissions. Domain Users do have permissions to traverse
the folder.
Foo.txt has explicit permissions that enable Domain Users to read and write
the file.


In a modern Active Directory, there is a Group Policy Object (GPO) setting
called "Bypass Traverse," which is granted to *Everyone* by default. This
setting causes windows ACL security checks to ignore whether a user has
traversal rights on a folder, and looks only at the file itself.
However, it's not present pre-Windows7 and it can be disabled for specific
groups, so let's assume that Domain Users does not have the Bypass Traverse
setting.

If this is the case, then users in the Domain Users group would not be able
to see and open Foo.txt, even though they have explicit RW permissions on
it -- Windows would see that they don't have the rights to traverse the
folder leading to the file, and it will deny access.



Now on to the questions:

1. Is this a common scenario? In other words, do other users here worry
about this directory traverse setting when crawling/quering CIFS shares and
Windows folders? How do others handle this?

2. If Bypass Traverse is allowed, a Domain User could read Foo.txt, but
only if they knew the explicit path. By indexing it for search and
returning it in search results, the user now knows something they may not
have known before. This seems like a potential security issue, do you
agree?

3. Is there a way to configure Apache ManifoldCF to perform traversal
checking for CIFS shares and Windows folders?


Thanks in advance!
Steve

Re: CIFS crawl - Directory Traverse Enforcement

[Karl Wright <da...@gmail.com>]

Hi Steve,

My apologies for the terse request earlier -- it's rather busy today and I
keep getting interrupted.

What I want to stress is that there is no magic in MCF having to do with
manipulation of acls, other than obtaining them from Windows.  Prior to
CONNECTORS-886 work, there were two bins of acls which describe a
document's security: a "share" bin and a "document" bin.  These two
operated independently of each other; a document would only be visible if
BOTH the share acls said it was OK AND the document acls said it was OK.
Windows recently added a THIRD bin of acls (which is what CONNECTORS-886
covers) having to do with permissions on parent directories.  But to
support all this there are only three SMB calls to get acls from Windows -
document level, share level, and parent level.  So I believe that Windows
digests its permission structure down to those three somehow.  If not, I
don't know how Windows manages its permissions within the domain, since it
uses SMB as well.  But let's confirm that.

Karl



On Mon, Feb 24, 2014 at 12:57 PM, Karl Wright <da...@gmail.com> wrote:

> Hi Steve,
>
> Can you look at the acls that are included in the document acls?  The CIFS
> connector talks to Windows using SMB, so I'm not certain for this kind of
> security whether the access tokens would appear in the "document" acls or
> the "parent" acls.  Please just try to confirm that they are NOT in the
> "document" acls before we go deeper.
>
> Thanks!
> Karl
>
>
>
> On Mon, Feb 24, 2014 at 12:52 PM, Steve Kearns <ke...@gmail.com> wrote:
>
>> Hi Karl,
>>
>> What timing! Thanks for the quick reply.
>>
>> I just pulled trunk from SVN, and after a fresh build and fresh Solr
>> install (with the 2 new fields in the schema), I have had no luck in seeing
>> the new fields ( [allow,deny]_token_parent) populated in Solr when doing a
>> Windows Share crawl.
>>
>> Is there an extra setting needed to the Windows Share connector to make
>> this happen?
>>
>> In a simple test, I don't see the new fields being given anything other
>> than their default value, so I'm worried that I did something wrong.
>>
>>
>>
>> Here was the directory structure I crawled:
>>
>> \\<server>\share - Share-level access to Domain Users and
>> \\<server>\share  - ACLs set to allow access to Everyone.
>> \\<server>\share\FileEveryoneCanRead.txt - inherits ACLs from parent
>> folder.
>> \\<server>\share\folder - Explicitly do *not* inherit permissions. Allow
>> only domain administrator account to read/write.
>> \\<server>\share\folder\Test.txt - Inherit from parent directory, and
>> also explicitly allow Domain Users to Read/Write.
>>
>>
>> Here's when this matters:
>>
>> Windows shares, run from a modern Windows server with default settings,
>> will let Domain Users read/write test.txt, because of the "Bypass Traverse"
>> GPO setting, which ignores the fact that Domain Users don't have directory
>> traverse privileges on \\<server>\share\folder. In some environments,
>> traversal is enforced, and the flattened security settings can't account
>> for it.
>>
>> I was hoping that there would be a way for me to index "Directory
>> Traverse" permissions for each level of directory between the share root
>> and a given file, and enforce it at query time. I'm not sure that is what
>> CONNETORS-886 is intended to do, is it?
>>
>> Thanks!
>> Steve
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 24, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
>>
>>> Hi Steve,
>>>
>>> Work on the CONNECTORS-886 ticket is now completed.  It would be great
>>> to try this out on your particular CIFS setup to be sure it properly
>>> captures your particular security situation.  If you are willing, this is
>>> how to do that:
>>>
>>> - Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
>>> - Build it: ant make-core-deps make-deps build
>>> - Download the appropriate plugin release candidate, either from
>>> http://people.apache.org/~kwright/apache-manifoldcf-solr-3.x-plugin-2.0or frome
>>> http://people.apache.org/~kwright/apache-manifoldcf-solr-4.x-plugin-2.0
>>> - Install the plugin on your Solr instance, being sure to configure all
>>> SIX fields that it requires
>>> - Run ManifoldCF and try indexing content that is protected via path to
>>> that Solr instance, and see whether security is appropriately enforced
>>> - Let us know what happens!
>>>
>>> Thanks for all your help!
>>>
>>> Karl
>>>
>>>
>>>
>>> On Fri, Feb 21, 2014 at 2:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>>> Hi Steve,
>>>> A ticket was recently opened and worked on which (I believe) covers
>>>> this.  See:
>>>>
>>>> https://issues.apache.org/jira/browse/CONNECTORS-886
>>>>
>>>> The fix for this has been committed to trunk (except for the
>>>> ElasticSearch component support).  If you are in a position to try this out
>>>> against your domain, you could confirm that it works as planned.
>>>>
>>>> Thanks,
>>>> Karl
>>>>
>>>>
>>>> On Fri, Feb 21, 2014 at 1:26 PM, Steve Kearns <ke...@gmail.com>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am setting up a crawler for a Windows Share (CIFS), with output to a
>>>>> Solr 4 index.
>>>>>
>>>>> I was able to get things up and running quite well -- thanks for the
>>>>> great documentation, it has all worked as expected, with one rather nuanced
>>>>> question around security.
>>>>>
>>>>> My internal users are quite security conscious, and some of them have
>>>>> raised the question of how security works with regard to directory
>>>>> traversal permissions.
>>>>>
>>>>> Here's an example to illustrate:
>>>>>
>>>>> \\server\Folder1\Folder2\Foo.txt
>>>>>
>>>>> The share allows Domain Users to connect.
>>>>> Folder1 also allows Domain Users to read.
>>>>> Folder2 does not inherit permissions from Folder1, and only the user
>>>>> Admin1 has read/write permissions. Domain Users do have permissions to
>>>>> traverse the folder.
>>>>> Foo.txt has explicit permissions that enable Domain Users to read and
>>>>> write the file.
>>>>>
>>>>>
>>>>> In a modern Active Directory, there is a Group Policy Object (GPO)
>>>>> setting called "Bypass Traverse," which is granted to *Everyone* by
>>>>> default. This setting causes windows ACL security checks to ignore whether
>>>>> a user has traversal rights on a folder, and looks only at the file
>>>>> itself.
>>>>> However, it's not present pre-Windows7 and it can be disabled for
>>>>> specific groups, so let's assume that Domain Users does not have the Bypass
>>>>> Traverse setting.
>>>>>
>>>>> If this is the case, then users in the Domain Users group would not be
>>>>> able to see and open Foo.txt, even though they have explicit RW permissions
>>>>> on it -- Windows would see that they don't have the rights to traverse the
>>>>> folder leading to the file, and it will deny access.
>>>>>
>>>>>
>>>>>
>>>>> Now on to the questions:
>>>>>
>>>>> 1. Is this a common scenario? In other words, do other users here
>>>>> worry about this directory traverse setting when crawling/quering CIFS
>>>>> shares and Windows folders? How do others handle this?
>>>>>
>>>>> 2. If Bypass Traverse is allowed, a Domain User could read Foo.txt,
>>>>> but only if they knew the explicit path. By indexing it for search and
>>>>> returning it in search results, the user now knows something they may not
>>>>> have known before. This seems like a potential security issue, do you
>>>>> agree?
>>>>>
>>>>> 3. Is there a way to configure Apache ManifoldCF to perform traversal
>>>>> checking for CIFS shares and Windows folders?
>>>>>
>>>>>
>>>>> Thanks in advance!
>>>>> Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: CIFS crawl - Directory Traverse Enforcement

[Karl Wright <da...@gmail.com>]

Hi Steve,

Can you look at the acls that are included in the document acls?  The CIFS
connector talks to Windows using SMB, so I'm not certain for this kind of
security whether the access tokens would appear in the "document" acls or
the "parent" acls.  Please just try to confirm that they are NOT in the
"document" acls before we go deeper.

Thanks!
Karl



On Mon, Feb 24, 2014 at 12:52 PM, Steve Kearns <ke...@gmail.com> wrote:

> Hi Karl,
>
> What timing! Thanks for the quick reply.
>
> I just pulled trunk from SVN, and after a fresh build and fresh Solr
> install (with the 2 new fields in the schema), I have had no luck in seeing
> the new fields ( [allow,deny]_token_parent) populated in Solr when doing a
> Windows Share crawl.
>
> Is there an extra setting needed to the Windows Share connector to make
> this happen?
>
> In a simple test, I don't see the new fields being given anything other
> than their default value, so I'm worried that I did something wrong.
>
>
>
> Here was the directory structure I crawled:
>
> \\<server>\share - Share-level access to Domain Users and
> \\<server>\share  - ACLs set to allow access to Everyone.
> \\<server>\share\FileEveryoneCanRead.txt - inherits ACLs from parent
> folder.
> \\<server>\share\folder - Explicitly do *not* inherit permissions. Allow
> only domain administrator account to read/write.
> \\<server>\share\folder\Test.txt - Inherit from parent directory, and also
> explicitly allow Domain Users to Read/Write.
>
>
> Here's when this matters:
>
> Windows shares, run from a modern Windows server with default settings,
> will let Domain Users read/write test.txt, because of the "Bypass Traverse"
> GPO setting, which ignores the fact that Domain Users don't have directory
> traverse privileges on \\<server>\share\folder. In some environments,
> traversal is enforced, and the flattened security settings can't account
> for it.
>
> I was hoping that there would be a way for me to index "Directory
> Traverse" permissions for each level of directory between the share root
> and a given file, and enforce it at query time. I'm not sure that is what
> CONNETORS-886 is intended to do, is it?
>
> Thanks!
> Steve
>
>
>
>
>
>
> On Mon, Feb 24, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
>
>> Hi Steve,
>>
>> Work on the CONNECTORS-886 ticket is now completed.  It would be great to
>> try this out on your particular CIFS setup to be sure it properly captures
>> your particular security situation.  If you are willing, this is how to do
>> that:
>>
>> - Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
>> - Build it: ant make-core-deps make-deps build
>> - Download the appropriate plugin release candidate, either from
>> http://people.apache.org/~kwright/apache-manifoldcf-solr-3.x-plugin-2.0or frome
>> http://people.apache.org/~kwright/apache-manifoldcf-solr-4.x-plugin-2.0
>> - Install the plugin on your Solr instance, being sure to configure all
>> SIX fields that it requires
>> - Run ManifoldCF and try indexing content that is protected via path to
>> that Solr instance, and see whether security is appropriately enforced
>> - Let us know what happens!
>>
>> Thanks for all your help!
>>
>> Karl
>>
>>
>>
>> On Fri, Feb 21, 2014 at 2:29 PM, Karl Wright <da...@gmail.com> wrote:
>>
>>> Hi Steve,
>>> A ticket was recently opened and worked on which (I believe) covers
>>> this.  See:
>>>
>>> https://issues.apache.org/jira/browse/CONNECTORS-886
>>>
>>> The fix for this has been committed to trunk (except for the
>>> ElasticSearch component support).  If you are in a position to try this out
>>> against your domain, you could confirm that it works as planned.
>>>
>>> Thanks,
>>> Karl
>>>
>>>
>>> On Fri, Feb 21, 2014 at 1:26 PM, Steve Kearns <ke...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am setting up a crawler for a Windows Share (CIFS), with output to a
>>>> Solr 4 index.
>>>>
>>>> I was able to get things up and running quite well -- thanks for the
>>>> great documentation, it has all worked as expected, with one rather nuanced
>>>> question around security.
>>>>
>>>> My internal users are quite security conscious, and some of them have
>>>> raised the question of how security works with regard to directory
>>>> traversal permissions.
>>>>
>>>> Here's an example to illustrate:
>>>>
>>>> \\server\Folder1\Folder2\Foo.txt
>>>>
>>>> The share allows Domain Users to connect.
>>>> Folder1 also allows Domain Users to read.
>>>> Folder2 does not inherit permissions from Folder1, and only the user
>>>> Admin1 has read/write permissions. Domain Users do have permissions to
>>>> traverse the folder.
>>>> Foo.txt has explicit permissions that enable Domain Users to read and
>>>> write the file.
>>>>
>>>>
>>>> In a modern Active Directory, there is a Group Policy Object (GPO)
>>>> setting called "Bypass Traverse," which is granted to *Everyone* by
>>>> default. This setting causes windows ACL security checks to ignore whether
>>>> a user has traversal rights on a folder, and looks only at the file
>>>> itself.
>>>> However, it's not present pre-Windows7 and it can be disabled for
>>>> specific groups, so let's assume that Domain Users does not have the Bypass
>>>> Traverse setting.
>>>>
>>>> If this is the case, then users in the Domain Users group would not be
>>>> able to see and open Foo.txt, even though they have explicit RW permissions
>>>> on it -- Windows would see that they don't have the rights to traverse the
>>>> folder leading to the file, and it will deny access.
>>>>
>>>>
>>>>
>>>> Now on to the questions:
>>>>
>>>> 1. Is this a common scenario? In other words, do other users here worry
>>>> about this directory traverse setting when crawling/quering CIFS shares and
>>>> Windows folders? How do others handle this?
>>>>
>>>> 2. If Bypass Traverse is allowed, a Domain User could read Foo.txt, but
>>>> only if they knew the explicit path. By indexing it for search and
>>>> returning it in search results, the user now knows something they may not
>>>> have known before. This seems like a potential security issue, do you
>>>> agree?
>>>>
>>>> 3. Is there a way to configure Apache ManifoldCF to perform traversal
>>>> checking for CIFS shares and Windows folders?
>>>>
>>>>
>>>> Thanks in advance!
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Re: CIFS crawl - Directory Traverse Enforcement

[Steve Kearns <ke...@gmail.com>]

Hi Karl,

What timing! Thanks for the quick reply.

I just pulled trunk from SVN, and after a fresh build and fresh Solr
install (with the 2 new fields in the schema), I have had no luck in seeing
the new fields ( [allow,deny]_token_parent) populated in Solr when doing a
Windows Share crawl.

Is there an extra setting needed to the Windows Share connector to make
this happen?

In a simple test, I don't see the new fields being given anything other
than their default value, so I'm worried that I did something wrong.



Here was the directory structure I crawled:

\\<server>\share - Share-level access to Domain Users and
\\<server>\share  - ACLs set to allow access to Everyone.
\\<server>\share\FileEveryoneCanRead.txt - inherits ACLs from parent
folder.
\\<server>\share\folder - Explicitly do *not* inherit permissions. Allow
only domain administrator account to read/write.
\\<server>\share\folder\Test.txt - Inherit from parent directory, and also
explicitly allow Domain Users to Read/Write.


Here's when this matters:

Windows shares, run from a modern Windows server with default settings,
will let Domain Users read/write test.txt, because of the "Bypass Traverse"
GPO setting, which ignores the fact that Domain Users don't have directory
traverse privileges on \\<server>\share\folder. In some environments,
traversal is enforced, and the flattened security settings can't account
for it.

I was hoping that there would be a way for me to index "Directory Traverse"
permissions for each level of directory between the share root and a given
file, and enforce it at query time. I'm not sure that is what CONNETORS-886
is intended to do, is it?

Thanks!
Steve






On Mon, Feb 24, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:

> Hi Steve,
>
> Work on the CONNECTORS-886 ticket is now completed.  It would be great to
> try this out on your particular CIFS setup to be sure it properly captures
> your particular security situation.  If you are willing, this is how to do
> that:
>
> - Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
> - Build it: ant make-core-deps make-deps build
> - Download the appropriate plugin release candidate, either from
> http://people.apache.org/~kwright/apache-manifoldcf-solr-3.x-plugin-2.0or frome
> http://people.apache.org/~kwright/apache-manifoldcf-solr-4.x-plugin-2.0
> - Install the plugin on your Solr instance, being sure to configure all
> SIX fields that it requires
> - Run ManifoldCF and try indexing content that is protected via path to
> that Solr instance, and see whether security is appropriately enforced
> - Let us know what happens!
>
> Thanks for all your help!
>
> Karl
>
>
>
> On Fri, Feb 21, 2014 at 2:29 PM, Karl Wright <da...@gmail.com> wrote:
>
>> Hi Steve,
>> A ticket was recently opened and worked on which (I believe) covers
>> this.  See:
>>
>> https://issues.apache.org/jira/browse/CONNECTORS-886
>>
>> The fix for this has been committed to trunk (except for the
>> ElasticSearch component support).  If you are in a position to try this out
>> against your domain, you could confirm that it works as planned.
>>
>> Thanks,
>> Karl
>>
>>
>> On Fri, Feb 21, 2014 at 1:26 PM, Steve Kearns <ke...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am setting up a crawler for a Windows Share (CIFS), with output to a
>>> Solr 4 index.
>>>
>>> I was able to get things up and running quite well -- thanks for the
>>> great documentation, it has all worked as expected, with one rather nuanced
>>> question around security.
>>>
>>> My internal users are quite security conscious, and some of them have
>>> raised the question of how security works with regard to directory
>>> traversal permissions.
>>>
>>> Here's an example to illustrate:
>>>
>>> \\server\Folder1\Folder2\Foo.txt
>>>
>>> The share allows Domain Users to connect.
>>> Folder1 also allows Domain Users to read.
>>> Folder2 does not inherit permissions from Folder1, and only the user
>>> Admin1 has read/write permissions. Domain Users do have permissions to
>>> traverse the folder.
>>> Foo.txt has explicit permissions that enable Domain Users to read and
>>> write the file.
>>>
>>>
>>> In a modern Active Directory, there is a Group Policy Object (GPO)
>>> setting called "Bypass Traverse," which is granted to *Everyone* by
>>> default. This setting causes windows ACL security checks to ignore whether
>>> a user has traversal rights on a folder, and looks only at the file
>>> itself.
>>> However, it's not present pre-Windows7 and it can be disabled for
>>> specific groups, so let's assume that Domain Users does not have the Bypass
>>> Traverse setting.
>>>
>>> If this is the case, then users in the Domain Users group would not be
>>> able to see and open Foo.txt, even though they have explicit RW permissions
>>> on it -- Windows would see that they don't have the rights to traverse the
>>> folder leading to the file, and it will deny access.
>>>
>>>
>>>
>>> Now on to the questions:
>>>
>>> 1. Is this a common scenario? In other words, do other users here worry
>>> about this directory traverse setting when crawling/quering CIFS shares and
>>> Windows folders? How do others handle this?
>>>
>>> 2. If Bypass Traverse is allowed, a Domain User could read Foo.txt, but
>>> only if they knew the explicit path. By indexing it for search and
>>> returning it in search results, the user now knows something they may not
>>> have known before. This seems like a potential security issue, do you
>>> agree?
>>>
>>> 3. Is there a way to configure Apache ManifoldCF to perform traversal
>>> checking for CIFS shares and Windows folders?
>>>
>>>
>>> Thanks in advance!
>>> Steve
>>>
>>>
>>>
>>>
>>
>

Re: CIFS crawl - Directory Traverse Enforcement

[Karl Wright <da...@gmail.com>]

Hi Steve,

Work on the CONNECTORS-886 ticket is now completed.  It would be great to
try this out on your particular CIFS setup to be sure it properly captures
your particular security situation.  If you are willing, this is how to do
that:

- Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
- Build it: ant make-core-deps make-deps build
- Download the appropriate plugin release candidate, either from
http://people.apache.org/~kwright/apache-manifoldcf-solr-3.x-plugin-2.0 or
frome
http://people.apache.org/~kwright/apache-manifoldcf-solr-4.x-plugin-2.0
- Install the plugin on your Solr instance, being sure to configure all SIX
fields that it requires
- Run ManifoldCF and try indexing content that is protected via path to
that Solr instance, and see whether security is appropriately enforced
- Let us know what happens!

Thanks for all your help!

Karl



On Fri, Feb 21, 2014 at 2:29 PM, Karl Wright <da...@gmail.com> wrote:

> Hi Steve,
> A ticket was recently opened and worked on which (I believe) covers this.
> See:
>
> https://issues.apache.org/jira/browse/CONNECTORS-886
>
> The fix for this has been committed to trunk (except for the ElasticSearch
> component support).  If you are in a position to try this out against your
> domain, you could confirm that it works as planned.
>
> Thanks,
> Karl
>
>
> On Fri, Feb 21, 2014 at 1:26 PM, Steve Kearns <ke...@gmail.com> wrote:
>
>> Hi,
>>
>> I am setting up a crawler for a Windows Share (CIFS), with output to a
>> Solr 4 index.
>>
>> I was able to get things up and running quite well -- thanks for the
>> great documentation, it has all worked as expected, with one rather nuanced
>> question around security.
>>
>> My internal users are quite security conscious, and some of them have
>> raised the question of how security works with regard to directory
>> traversal permissions.
>>
>> Here's an example to illustrate:
>>
>> \\server\Folder1\Folder2\Foo.txt
>>
>> The share allows Domain Users to connect.
>> Folder1 also allows Domain Users to read.
>> Folder2 does not inherit permissions from Folder1, and only the user
>> Admin1 has read/write permissions. Domain Users do have permissions to
>> traverse the folder.
>> Foo.txt has explicit permissions that enable Domain Users to read and
>> write the file.
>>
>>
>> In a modern Active Directory, there is a Group Policy Object (GPO)
>> setting called "Bypass Traverse," which is granted to *Everyone* by
>> default. This setting causes windows ACL security checks to ignore whether
>> a user has traversal rights on a folder, and looks only at the file
>> itself.
>> However, it's not present pre-Windows7 and it can be disabled for
>> specific groups, so let's assume that Domain Users does not have the Bypass
>> Traverse setting.
>>
>> If this is the case, then users in the Domain Users group would not be
>> able to see and open Foo.txt, even though they have explicit RW permissions
>> on it -- Windows would see that they don't have the rights to traverse the
>> folder leading to the file, and it will deny access.
>>
>>
>>
>> Now on to the questions:
>>
>> 1. Is this a common scenario? In other words, do other users here worry
>> about this directory traverse setting when crawling/quering CIFS shares and
>> Windows folders? How do others handle this?
>>
>> 2. If Bypass Traverse is allowed, a Domain User could read Foo.txt, but
>> only if they knew the explicit path. By indexing it for search and
>> returning it in search results, the user now knows something they may not
>> have known before. This seems like a potential security issue, do you
>> agree?
>>
>> 3. Is there a way to configure Apache ManifoldCF to perform traversal
>> checking for CIFS shares and Windows folders?
>>
>>
>> Thanks in advance!
>> Steve
>>
>>
>>
>>
>

Re: CIFS crawl - Directory Traverse Enforcement

[Karl Wright <da...@gmail.com>]

Hi Steve,
A ticket was recently opened and worked on which (I believe) covers this.
See:

https://issues.apache.org/jira/browse/CONNECTORS-886

The fix for this has been committed to trunk (except for the ElasticSearch
component support).  If you are in a position to try this out against your
domain, you could confirm that it works as planned.

Thanks,
Karl


On Fri, Feb 21, 2014 at 1:26 PM, Steve Kearns <ke...@gmail.com> wrote:

> Hi,
>
> I am setting up a crawler for a Windows Share (CIFS), with output to a
> Solr 4 index.
>
> I was able to get things up and running quite well -- thanks for the great
> documentation, it has all worked as expected, with one rather nuanced
> question around security.
>
> My internal users are quite security conscious, and some of them have
> raised the question of how security works with regard to directory
> traversal permissions.
>
> Here's an example to illustrate:
>
> \\server\Folder1\Folder2\Foo.txt
>
> The share allows Domain Users to connect.
> Folder1 also allows Domain Users to read.
> Folder2 does not inherit permissions from Folder1, and only the user
> Admin1 has read/write permissions. Domain Users do have permissions to
> traverse the folder.
> Foo.txt has explicit permissions that enable Domain Users to read and
> write the file.
>
>
> In a modern Active Directory, there is a Group Policy Object (GPO) setting
> called "Bypass Traverse," which is granted to *Everyone* by default. This
> setting causes windows ACL security checks to ignore whether a user has
> traversal rights on a folder, and looks only at the file itself.
> However, it's not present pre-Windows7 and it can be disabled for specific
> groups, so let's assume that Domain Users does not have the Bypass Traverse
> setting.
>
> If this is the case, then users in the Domain Users group would not be
> able to see and open Foo.txt, even though they have explicit RW permissions
> on it -- Windows would see that they don't have the rights to traverse the
> folder leading to the file, and it will deny access.
>
>
>
> Now on to the questions:
>
> 1. Is this a common scenario? In other words, do other users here worry
> about this directory traverse setting when crawling/quering CIFS shares and
> Windows folders? How do others handle this?
>
> 2. If Bypass Traverse is allowed, a Domain User could read Foo.txt, but
> only if they knew the explicit path. By indexing it for search and
> returning it in search results, the user now knows something they may not
> have known before. This seems like a potential security issue, do you
> agree?
>
> 3. Is there a way to configure Apache ManifoldCF to perform traversal
> checking for CIFS shares and Windows folders?
>
>
> Thanks in advance!
> Steve
>
>
>
>