Re: Get all issues with attached files

On Fri, Oct 3, 2014 at 4:19 PM, Ralf Schlatterbeck <[email protected]> wrote:
> On Fri, Oct 03, 2014 at 03:45:17PM +0300, anatoly techtonik wrote:
>> I am very skeptical about this use case. Can you describe the real
>> attack or case you faced with?
>
> If a user has no 'View' on a property but can query all property she can
> create a query that tells her the contents of the unknown property. This
> works for string properties (because roundups string search is always a
> substring search) as well as Link/Multilink. I have this problem when
> you're using roundup for tracking e.g. working time of users, there you
> have more privacy concerns, see my Time-tracking project
> http://sourceforge.net/projects/timetracktool/
> It doesn't have releases, just a git repo.

Do you mean the query like "give me all users with empty password"
will work even if I don't have view permission on password?

Isn't it the job of a query builder to fail with permission error if an attempt
is made to run a comparison over the data that user can not see?

Why leave permission open and search closed?

> Yes, making permissions part of the schema is probably a good idea. This
> decision dates back a *long* time.

Do you have an exact trace where this happened? Maybe there were some
good reasons that were actual at that time? (I think that some informal blog
post is a good idea for such things).

> There are several locations where query options are ignored silently,
> e.g., malformed properties in a search (e.g. date).

Can we make error reporting optional? If user wants to ignore errors, let
him do this.

> Note that before the introduction of Search permissions the roundup
> machinery already filtered the results it returned to you. So if you
> were not allowed to see certain items these were filtered from the
> search results shown. You can determine that your results are filtered
> by the time the query takes, because filtering happens in python :-)

N-a-a-a-i-ce. =) Well, filtering results seems logical, but if you say that
there is an attack to guess the actual value, then it doesn't work to
conceal info.

So, "I want to run queries that compare data" and "I want to hide data"
are not really reachable at the same time. What is the case when you
need both?

Why not just prevent running query over data that can not be viewed
- why another 'search' permission - I don't get it?

>> As a consequence of this design decision now I need to do extra
>> 5000 queries or even more in a row to b.p.o tracker to find all issues
>> with files.
>
> Isn't it possible to fix the configuration so that your queries work?
> But finding all issues *with* files is still not possible directly
> because the negation ('-2' special id) and querying for unset values
> ('-1') don't mix. This should be fixed ...

I don't have access to tracker and so far I fail to explain how it works and
why I need view permission on file id. If I open
http://bugs.python.org/file34276 the id is in URL. Ticket also has a link
to this id.

>> I don't see any differences between messages and nosy permissions:
>> https://hg.python.org/tracker/python-dev/file/9bab717d18a0/schema.py
>
> msg and file don't include the 'id' property while 'user' does.
> Line 333 for the user perms, line 236 for file and msg permissions.

If file id is filtered from everythere, then why display query works? It is not
secure in any way..

>>> pp (p.display ('issue9644', 'files'))
{'files': ['18578']}

>> > To add search permissions for a property you would add something like the
>> > following:
>> >
>> > p = db.security.addPermission \
>> >     ( name       = 'Search'
>> >     , klass      = 'issue'
>> >     , properties = ('files', 'messages')
>> >     )
>> > db.security.addPermissionToRole ('User', p)
>>
>> Another thing in Roundup that needs refactoring. If only I had the time.. =)
> Yep.
> Reading this above it's probably easiest to grant the 'User' role read
> access to msg.id and file.id.  Otherwise you'd probable need to add
> Search permissions on file and msg, too.

Is it possible to implement "Allow, Deny" rule order? Meaning that every
property is allowed to be accessed unless it is forbidden? In this case
configuration will be much more sane as you can clearly see which fields
are hidden and why.

-- 
anatoly t.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk