manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: CIFS crawl - Directory Traverse Enforcement
Date Mon, 24 Feb 2014 18:32:16 GMT
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 <daddywri@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 <kerzwik@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 <daddywri@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 <daddywri@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 <kerzwik@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message