[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
That is uncalled for and just common. Toms comments were constructive and topic specific. Sure, showing some frustration as we all have from time to time, but your comment was just common thug personal attack and has no place here. In fact I do not see where you have offered a single thing of on topic value, only a vulgar personal attck. FYI. Many of us are professionals in the field and I for one do not expect to be speak or be spoken to by anyone in such a mannner even if it is the net where people can hide behind screen names and distance. Maybe take your own advice if that is how you handle a small bit of critism, debate, and disagreement. Respectfully, Tim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c94b7335-2337-4790-9976-c959da5f45cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, February 20, 2018 at 10:27:24 AM UTC-5, Tom Zander wrote: > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel Hah! I'm starting to have nightmares from my old days programming in APL. There be dragons there... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/deb48d98-5523-4000-93d6-b7a1bb4b3918%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Wednesday, February 21, 2018 at 5:41:41 PM UTC+1, qubenix wrote: > > So let me be blunt as this is likely the last email from me to qubes > anyway; > > Bye, I'm happy to see you go away finally. It was killing me inside that > you were working on the new gui controller. Fuck off back to bcash. > > -- > qubenix > GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 Not trying to understand other people a trap many fall into, even among those who try to understand others, we can all at times fail at it. Especially if something bad is going on in a persons life at the time, which can trigger an otherwise understanding person not to try understand another person, thereby igniting a conflict which wouldn't have happened otherwise. The world is complex. Once the initial conflict has been ignited, personal grudges or even long exhausting and devastating wars, people often forget why they were even fight in the first place. Initial conflicts can go out of control, the lack of understanding being the fuel to seeking protect one self, by harming the opponent, instead of seeing the find the root of the issue and solving it. Conflicts, can become self realized prophecy, what matters is to break this "circle" early on. It's like the butterfly effect in Chaos Theory, the first impression of a person can lead to very complex situations later on. If not taking steps to break the circle, initial conditions will then determine your relationship with that person. Like an unstoppable but irrational momentum. It's not always possible to stop one self to cause more harm rather than try to understand the other, especially if having a bad time from something else in ones own life, but in the very end most people by far don't mean to harm one another. It's simply a lack of understanding of each others. The actual "harm" being done, is not the root, the lack of understanding is what leads to the "harming", not the other way around. So trying to understand is key, to not harm each others. Something we can all fail at, even the most peaceful humans can forget it, we all live complex lives with ups and downs. It's also human nature to be lazy, it's encoded in us from evolution, and it's even an universal law in entropy. The entire universe, and every system in it, including ourselves, have incentives to be lazy and uptimize to the most efficient approach. Even how you walk is highly efficient, the way you conduct your social life is efficient. If one wants to break away from it, then one self needs to introduce more energy to the system from outside the system (entropy). And there lies the issue, conflicts are systems which no energy are given (or effort) to try understand one another. The conflict (or the system of relationship following the universal rules of entropy) will then exhaust itslef and burn out. Even relationships and marriages follow this logic. By in an on it self, we're not channeling enough energy into this relationship, and thereby the relationship is suffering. By being lazy, we justify it by just calling the other "bad" or "evil". But in reality, very few people are actually such. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/43cf9775-cb44-455f-ae9d-83a9cf0dfc12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On 02/21/2018 05:41 PM, qubenix wrote: >> So let me be blunt as this is likely the last email from me to qubes > anyway; > > Bye, I'm happy to see you go away finally. It was killing me inside that > you were working on the new gui controller. Fuck off back to bcash. > I really hope that you will understand one day that the first victim of your hate is yourself. Until this day I prefer that you keep such kind of language out of this mailing list ... Bernhard -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8bef9fe3-5fbe-8025-8885-e60bb9fe5a85%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Wed, February 21, 2018 4:41 pm, qubenix wrote: >> So let me be blunt as this is likely the last email from me to qubes >> > anyway; > > Bye, I'm happy to see you go away finally. It was killing me inside that > you were working on the new gui controller. Fuck off back to bcash. Tom had some constructive criticism to offer, which is healthy. I don't think your response is particularly constructive or appropriate for the mailing lists, however. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2e43f714c9a042127c35756526d64771.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
> So let me be blunt as this is likely the last email from me to qubes anyway; Bye, I'm happy to see you go away finally. It was killing me inside that you were working on the new gui controller. Fuck off back to bcash. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2b004517-b9b8-6507-dd04-173728dc3999%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Wednesday, 21 February 2018 12:12:06 CET Wojtek Porczyk wrote: > This is bad UX. This is frustrating, I spent too many emails making the point clear that this is an API level escape token. Not a user-visible one, and then you respond to the thread showing you still completely missed that. So let me be blunt as this is likely the last email from me to qubes anyway; Fact: Variables given to qrexec are going to be replaced with the actual relevant value. For instance bash takes`ls *` and replaces the star with the actual values _before_ calling ls. Ls or any executable does not have to deal with things like star or dollar sign etc. Your and Marek complaints are that you need to escape the variables when you pass them on to the target VM handler. If you are indeed doing that, you are doing it wrong and you can wait for the next security bulletin like the one we are discussing right now. The point of a variable that is passed from a VM to the dom0 qrexec daemon is that your source VM doesn't have to know about who is $adminVM or what is the actually started dispVM's name. QRexec daemon (in dom0) should do the variable replacement before the user request leaves qrexec-daemon running in dom0. Just like bash does the replacement before it forwards the command-line. Again, if you do not do the variable replacement there, but instead pass it through unvalidated and unrelated software, you are going to continue having security flaws. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3526761.85MCzvWFfn%40strawberry. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 04:27:16PM +0100, Tom Zander wrote: > On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > > 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. > > > > > > 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]) > [] > > 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. :) > > The thing you have to rememeber is that the escape character never needs to > be typed by the user. > In QRexec you are defining an API, applications like qvm-run are using that > API. What the user passes into qvm-run and what is actually sent to dom0 > does not have to be identical. > I guess you do the translation currently as well; '$' turns into '@' in your > new code. > > The consequence of this is that you don't have to limit yourself to the > posix list. > Using the portable characters set for a non-character simply isn't needed. > > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF Thank you for the suggestion, but I don't think it's correct. The character has to be input in at least two places: in /etc/qubes-rpc/policy as the second token (destination) on the line and as argument to qrexec-client[-vm] executable. Using any of the common editors, any language-specific keyboard layout, and any common encoding. Most people have UTF-8, or ISO-8859-*, but we don't exclude the possibility to have admin qube on Windows -- there was at least one serious attempt -- so this brings UTF-16 and Windows-125*. As and example, may I use ÿ character you provided: 1) You're right the codepoint is U+00FF, but UTF-8 encoding is actually "\xc3\xbf", so no, we cannot use it. 2) I don't have it on my keyboard. So anytime I have to input one of those characters, I search all the modifiers for the right one (ý? no. ŷ? neither. ỹ? my font has trouble with that, is that even a letter? ý? tried this one already...). I don't have real data, but I think most people don't even know where to start looking for this and in the optimistic case will end up sourcing it from gucharmap or equivalent. This is bad UX. Maybe there is a character outside portable charset that is portable and writable enough, but I don't know of any. I haven't thought there is hope enough to actually find one, so I didn't bother searching. That's why I've asked. Again, thanks for your review. I think it's helpful, because this change was made behind community's back (for obvious reasons), fast, and in very limited group of people. I wasn't sure if we didn't make some mistake, so the best what I could hope for was to explain myself and get ex post facto review, which you provided. - -- 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 iQIcBAEBCAAGBQJajVQEAAoJEL9r2TIQOiNRpbUQAJjEEAk+rKZOrFjjMkG3WQem /KNCL9gfVt3T6/keBBuEwfX3XcOIiO/FBWNfcf6dxeBGGcMHHQn0pd4Ucj/HZw8b 0/s63gjXH+ru7m4x2VW/3uDI4igkic6UUYPVHDB0sQtbTvGGWsr5pPJxcx7JgbwX +mJmDgt7i/9Y3lAGEva5ex+q7WG4hJd8ArgnJGAVnp7MrTgIduHW1/2QufC6uvvE gRRc3gbZK5FkT5Yg38UumE4sNcmnV0Nvu3m+o/g/cBcEER7wO81XW6TKFj0Ok/Bg Ostsov9NwO3iGv0usSUvMKfw7Aac3VK9SsW0r5sxA/QFe9jVvasVnmvIrxTRwwL+ W+gP5piagxgphLhUcR6LwyEhRPWzb06iDaaztXnLXyInWFEGdei1ATmlQNI0Rmno pNh/QLQqS6YF+hAl8LxSkOj3tjcg7MTYl00y9Z6ePJRUDA84s1hlWT43agWNN4L3 SX55/UzTU8DlhcduL3WmY6DVIKKlfE2Q82VorkprY6i/u/d7fdCblYLOtatZh2JB OK1ZFOprRlAJodYQMUws7o8cDgY3LxfgKX45PC23DJG6o5CDM+WoqmUw72uxMFft jRE299HwUV3qfzxm9/bjLPJqgnP+nSFnY/4J02iHUQxkg3Xb9ibKxFmTWhnf78zd REwcpFmrrjnrVVy14CZ2 =wkxM -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 19:41:19 CET Marek Marczykowski-Górecki wrote: > > On the 'other' side of qrexec (on dom0) you have perfect control over > > the > > situation and you also don't have any need for recoding or encodings or > > anything like that. It still is just 8 bits data, not encoded. > > And then, after policy evaluation, you pass that data to actual service > to execute the operation (which may be in dom0 or another VM). Yes, WITHOUT the escape character. Remember, you escape the special names of VM names that dom0 will substitute. “$adminvm” doesn't end up being the string you offer to qubesd, the string “dom0” is. Likewise; you don't start a service in Dispvm18431 and send it the text “$dispvm”. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2032074.AZcuCm27fB%40strawberry. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 06:57:34PM +0100, Tom Zander wrote: > On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > > The thing you have to rememeber is that the escape character never needs > > > to be typed by the user. > > > In QRexec you are defining an API, applications like qvm-run are using > > > that API. What the user passes into qvm-run and what is actually sent > > > to dom0 does not have to be identical. > > > > In theory yes, but this would introduce more complexity to this code > > (taking care where which encoding is used etc). > > I read the code, there is no encoding. > You correctly used the POSIX Portable Character Set for text. So no need > for encoding. > When you use the qrexec API you just sent a struct with some arrays of bytes > for VM names. > In your qrexec code you use an array of unsigned chars. Also, no encoding. > > The point is that you use encodings only when you have **text** with > characters > 127. Which you don't allow. > > The problem you fear doesn't exist. > > The reason is because when accepting user-input you use encodings. > > When your app starts talking to qrexec/qubsed there is no longer any > encoding. Just an 8-bit bytearray. The text has been standardized. > > On the 'other' side of qrexec (on dom0) you have perfect control over the > situation and you also don't have any need for recoding or encodings or > anything like that. It still is just 8 bits data, not encoded. And then, after policy evaluation, you pass that data to actual service to execute the operation (which may be in dom0 or another VM). > > > I guess you do the translation currently as well; '$' turns into '@' in > > > your new code. > > > > > > The consequence of this is that you don't have to limit yourself to the > > > posix list. > > > Using the portable characters set for a non-character simply isn't > > > needed. > > > > > > So, knowing that your API is actually based on 8-bit characters and not > > > 7 > > > bits which you are limiting yourself to, my suggestion is to take > > > something above 127 and below 256 as a special char. > > > Most fun one would be “ÿ” which is a normal character you can pass on a > > > shell script if you must, its actual byte-value is 0xFF > > > > Until some helpful application (shell or else) will try to interpret it > > as UTF-8. > > Ehm, how would “some helpful application” manage to get in your qrexec > policy-frameowork? If you fear that you have bigger issues as they could > replace anything with anything... I'm not sure if you've read the QSB carefully. The problem is how the thing executing the service handle arguments. Not policy evaluating part - - there '$' or other potentially shell special characters are handled correctly. Anyone can write a qrexec service, and we want to provide a framework that make it hard to shoot yourself in the foot. > Anyway, to answer your fear. > > No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. > (see attached example file) Or, more likely, it will just switch off utf-8. > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMa8cACgkQ24/THMrX 1yyE6gf+McyBJoK/NW4KAfYEL5xritven8tl35yXaWND674jddKz/WXMaaf9mdar 338xMDBLoeDMZvYVpujd2+lbbnwyMPOUvxGtDQ87R+mluWX5YkWcrzNgVWhrjbJu GTczmlkCT+PaW5cYonXCvFMzGyB3Afu2T7BMBD947RU2SUpiaooAfUUqpS1dCGG8 cQF8xe2Ab3vCBF1e1ocOEF5KRYgsC8NsTc1KDqlDp9AORqfLOINHv0ZNFS/Gaksn CLqvKO5VPr+oswHm8v5I4MLQPK5cQuFvn7oJOs3+pOzZqVk9y7xvjZ4xKiVNF4pB tK0B3Tpp3F0VzI9fhAoYHi4pI2PSUg== =mIGj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180220184119.GG2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > The thing you have to rememeber is that the escape character never needs > > to be typed by the user. > > In QRexec you are defining an API, applications like qvm-run are using > > that API. What the user passes into qvm-run and what is actually sent > > to dom0 does not have to be identical. > > In theory yes, but this would introduce more complexity to this code > (taking care where which encoding is used etc). I read the code, there is no encoding. You correctly used the POSIX Portable Character Set for text. So no need for encoding. When you use the qrexec API you just sent a struct with some arrays of bytes for VM names. In your qrexec code you use an array of unsigned chars. Also, no encoding. The point is that you use encodings only when you have **text** with characters > 127. Which you don't allow. The problem you fear doesn't exist. The reason is because when accepting user-input you use encodings. When your app starts talking to qrexec/qubsed there is no longer any encoding. Just an 8-bit bytearray. The text has been standardized. On the 'other' side of qrexec (on dom0) you have perfect control over the situation and you also don't have any need for recoding or encodings or anything like that. It still is just 8 bits data, not encoded. > > I guess you do the translation currently as well; '$' turns into '@' in > > your new code. > > > > The consequence of this is that you don't have to limit yourself to the > > posix list. > > Using the portable characters set for a non-character simply isn't > > needed. > > > > So, knowing that your API is actually based on 8-bit characters and not > > 7 > > bits which you are limiting yourself to, my suggestion is to take > > something above 127 and below 256 as a special char. > > Most fun one would be “ÿ” which is a normal character you can pass on a > > shell script if you must, its actual byte-value is 0xFF > > Until some helpful application (shell or else) will try to interpret it > as UTF-8. Ehm, how would “some helpful application” manage to get in your qrexec policy-frameowork? If you fear that you have bigger issues as they could replace anything with anything... Anyway, to answer your fear. No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. (see attached example file) Or, more likely, it will just switch off utf-8. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2513384.SI2geNoQLk%40strawberry. For more options, visit https://groups.google.com/d/optout. �b
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 04:27:16PM +0100, 'Tom Zander' via qubes-devel wrote: > On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > > 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. > > > > > > 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]) > [] > > 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. :) > > The thing you have to rememeber is that the escape character never needs to > be typed by the user. > In QRexec you are defining an API, applications like qvm-run are using that > API. What the user passes into qvm-run and what is actually sent to dom0 > does not have to be identical. In theory yes, but this would introduce more complexity to this code (taking care where which encoding is used etc). > I guess you do the translation currently as well; '$' turns into '@' in your > new code. > > The consequence of this is that you don't have to limit yourself to the > posix list. > Using the portable characters set for a non-character simply isn't needed. > > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF Until some helpful application (shell or else) will try to interpret it as UTF-8. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMRLUACgkQ24/THMrX 1yxCegf+Iii677oWd0CmJgoygfVfiQnmDl+a7XBX/i+tb8BMqO67AgwzoM6cWXq6 ZaA76a50qKSmcSjj6xSPtg4sPV0hqpgORsnxikAn5zg9vi7QJMJ0q+hKuKVxHAY1 TZSVFynTs6ci0JjgVRiB8QZCrl2eC9hQraGs46u6Zevvj80ZapaEqu0Sh0rowpDe SZ+QbiKi/QD1IeSF03OjnlqtoEyAZtPJ4dMY9F8IpR0P/vzsPxnkx/493HVjSA1i 7Z7kutdCcrGAqCtROhQ9DnS7+GTfdNcDJ5zwZ5yz5fJWlrzFgDSjENuwrSUqU/13 W6HNQVwx/fW+RBseUkJ/o98GHVW8sg== =af4O -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180220155436.GC2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > 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. > > > > 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]) [] > 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. :) The thing you have to rememeber is that the escape character never needs to be typed by the user. In QRexec you are defining an API, applications like qvm-run are using that API. What the user passes into qvm-run and what is actually sent to dom0 does not have to be identical. I guess you do the translation currently as well; '$' turns into '@' in your new code. The consequence of this is that you don't have to limit yourself to the posix list. Using the portable characters set for a non-character simply isn't needed. So, knowing that your API is actually based on 8-bit characters and not 7 bits which you are limiting yourself to, my suggestion is to take something above 127 and below 256 as a special char. Most fun one would be “ÿ” which is a normal character you can pass on a shell script if you must, its actual byte-value is 0xFF -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5355623.KmoKho9gXC%40strawberry. For more options, visit https://groups.google.com/d/optout.
