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)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e855daee-13e4-4f64-b9c7-975cd53f9ad7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to