On Saturday, 24 February 2018 03:44:07 UTC, Alex Dubois wrote:
> On Tuesday, 20 February 2018 13:04:15 UTC, Wojtek Porczyk wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel
> > wrote:
> > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki
> > > wrote:
> > > > We've decided to deprecate the '$' character from qrexec-related usage.
> > > > Instead, to denote special tokens, we will use the '@' character,
> > > > which we believe is less likely to be interpreted in a special way
> > > > by the relevant software.
> > >
> > > I would argue against the @ sign on account that it is a special
> > > character
> > > in bash as well.
> > >
> > > Search for it here;
> > > https://linux.die.net/man/1/bash
> > > I don't immediately see a way to exploit it, but why risk it?
> >
> > We absolutely need a special character that is not allowed in qube name to
> > make the special tokens immediately obvious in policy. The process I used
> > was
> > to list available characters (POSIX Portable Character Set [1]) and
> > substract
> > the characters that are special to some relevant things:
> > - - qube name: a-z A-Z 0-9 _ -
> > - - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
> > - - POSIX shell reserved words [3]: ! { }
> > - - non-POSIX things [3]: [ ]
> > - - special qrexec character: +
> > - - path separators (POSIX and NT): / \ :
> > - - regular expressions: ^. (and other already excluded)
> >
> > This leaves: '\0\a\b,@'. The point is, all characters are special to
> > something. I'm sure if I searched for more "special" characters, I'd find
> > them
> > ('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
> > ',' we use in other context in policy). So I stopped there and by consensus
> > we
> > picked '@'.
> >
> > If I missed something, could you please point out? I know shell just good
> > enough to know that it's not possible to know every shell quirk. :)
> >
> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
> > [2]
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
> > [3]
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
> >
> >
> > - --
> > pozdrawiam / best regards _.-._
> > Wojtek Porczyk .-^' '^-.
> > Invisible Things Lab |'-.-^-.-'|
> > | | | |
> > I do not fear computers,| '-.-' |
> > I fear lack of them.'-._ : ,-'
> > -- Isaac Asimov `^-^-_>
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
> > 24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
> > SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
> > 0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
> > 72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
> > MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
> > TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
> > BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
> > 9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
> > 2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
> > /PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
> > t9joU8uqhcS4Wt6nA9lh
> > =EN6G
> > -END PGP SIGNATURE-
>
> I fail to grasp fully the problem. Could you maybe provide an example of an
> attack (sourceVM script and sourceVMname, policy and targetVM script).
>
> After multiple rewording on my understanding and reading some doc I have the
> feeling that I am getting closer.
>
> The policy validation service evaluate the policy file and does not
> interpolate the string with $. It compares $variable (as a string) with a set
> of strings (i.e. $dispvm, $tag, etc...). Are you not able to white-list this
> part?
> Or to use non authorized character in the policy file but keep $ in the
> sourceVMscript (is it what you suggested). Or use a trailing character as
> well.
> i.e. anon-whonix %dispvm% allow,target=%dispvm%:anon-whonix-dvm
>
> Another option might be to play with the formatting of the policy files
> (multiple line per rule)?
> i.e. 0 anon-whonix 1 dispvm allow,target=1 dispvm:0 anon-whonix-dvm
> ('1 ' is $ '0 ' no $).
>
> Is there not also a problem after the policy evaluation with the string
> substitution itself in Dom0? policy should be more explicit when no argument
> is allowed.
> i.e.:
> /etc/qubes-rpc/policy/FileCopy+ (default argument policy)
> /etc/qubes-rpc/policy/FileCopy (no argument policy)
> /etc/qubes-rpc/policy/FileCopy+blah (argument blah policy)
Please ignore. reading the commits was the for me. Apologies for the noise.
--
You received this message because you are subscribed to the Google
