Re: Fix filter string behaviour to be more intuitive before lots of people start depending on it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 05/31/2012 03:34 PM, David Jaša wrote:
SSIA

The current "grandfathered" filter format behaves counter-intuitively.
Let me describe it based on my experiments:
      1. there is a "hard default" that disables all devices (aka
         -1,-1,-1,-1,0), it must be always overwritten if you wish to
         auto-share anything. This is not advertised anywhere

AFAIK this is the same behavior as the filter for incentive pro, the
filter format is based on that of incentive pro, so the things like
the filter-editor tool and old filters can be reused.

More importantly then the "incentive pro did it this way" argument though,
is that it is a safe default from security pov. These filter strings are
used in more then one place:

1) In the client to decide which devices to auto-redirect when new devices
   are hotplugged
2) In the client to specify (already plugged in) devices to redirect on
   client connect (*)
3) On the qemu cmdline to specify which redirected devices will be accepted

*) Not yet available, to be implemented soon.

For 2 and 3 deny by default clearly is the right policy, for 2 having a
redirect everything that does not match policy means redirecting all
devices the client has on client connect, not good. For 3 an allow by
defautl policy is simple not an option from a security pov.


      2. there is a "soft default" that enables everything but HID
         devices (aka 3,-1,-1,-1,0|-1,-1,-1,-1,1)
      3. when user specifies a custom filter string, it
               * replaces string from #2
               * is based on top of #1

All combined together cause unexpected behaviours like the one described
in https://bugzilla.redhat.com/show_bug.cgi?id=823541 .

The most straightforward fix seems to get rid of "soft default" #2 and
use its value in "hard default" #1. That way, when user specifies
--spice-usbredir-filter="11,-1,-1,-1,0", the effective filter string
will be what user will expect:
"3,-1,-1,-1,0|11,-1,-1,-1,0|-1,-1,-1,-1,1"

instead of current behaviour where such string will become
"11,-1,-1,-1,0|-1,-1,-1,-1,0", effectively block-all "-1,-1,-1,-1,0"

Hans, do you think this is doable in a short time frame? If it is not
done this way soon, people will constantly ask about that...

Doable yes, desirable no. Having a default policy is one thing, but
mandatory adding (in a very hidden way) "11,-1,-1,-1,0" to any
filter is just plain wrong, as it will surprise the user.

And as discussed above I believe that an allow by default if nothing
matches the given filter is a bad idea!

Regards,

Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]