Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > See discussion in https://github.com/QubesOS/qubes-issues/issues/2518 Great, thanks! Best Regards, Raffaele. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlqFxWUACgkQjTxG+6f1 ce7VchAAiIaJTSR00JrO9oxaI0CDDSjDH0e+z8FuYUEuR6W5vx2omp0NcbTTCGj3 ycFDDvdNEWJozkX76+O8UNJ8uzsxcdb2PVyh0jqLM6gQFm1ReJ/zycqp8eAC5JPa 7Vrq0IUyDQ3NFVKQckiNgFofS2BfuYO68FuS5V2NHq/zCMCzIeN1OgeCV11BwO9m o2m43FDBQL3KKi6pFeJNwY0nwd06Xx0OOu2Gsi52aUqtv3MucMx9lY4XXjwwxvms ayRmzWNLQC6ncqarxRePfijVo+QUEZE7gRfy8Byc1Z57NkNQgVJaPgyC9ne/ZWUn iTW4nmTjv4w9g88308q5kdtOZEm0+KusSF14tv/Qbk0e/+fMwmXqPytNOkSPpQez gMvQrDGarIzXw4G5nndblf6Ox/04D8it5KLl1b1iTB2EoyiqqsdORlvCwwLbppJP BNnckFCZgeSlzLR1WrZgpO7coB2oMpuD7M9+9ZeWiCLJZpxvgOvr0MUx+GalX5+M WCvF1BYsubfA+u2bOLwfzZtlqF/P8UiwcCLs9IodurxXGOk0vln6nfqfLdjBiWwo cGXYECncC9gosqKE8jB1StGs2yGYA3ve/d1V+x1OzV1aBE+bBkno4J+bEfJoksly RJg4yG5Ekl63icU4aADxkD6m3UoN5gWDCQqjWzM6g/9CdXgXgJU= =jwDF -END PGP SIGNATURE- -- 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/yapNjgu8QWjqp15_eYJYK12Ny8dFFhDYvP0donkQnjffSjlCxTlpcKv5BYvp173QZq-A_2V2vr9105hMBreO_I53IKp2HMCVfdI1wR-k6Uk%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Thu, Feb 1, 2018 at 7:16 AM, 'Raffaele Florio' via qubes-devel wrote: > [...] > I've a question about if is acceptable (in term of performance, specifically > latency) to have some form of signed USB input, from a usbvm. A lot of laptop > (the majority?) has only an USB controller and without reset capabilities. > The most susceptible device, IMHO, is USB keyboard. So if it's possible to > put a proxy USB signer device (e.g. a rPi Zero) between the USB keyboard and > the usbvm, Dom0 could verify that input come from the signer device. > However thanks the Qubes 4.0 flexibility this necessity could be suppressed > by "Qubes Air". Unfortunately I cannot try Qubes 4.0-rcX. I hope that the > 4.0-rc4 hasn't any major problem. So it became the stable release, <3. See discussion in https://github.com/QubesOS/qubes-issues/issues/2518 -- 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/CABQWM_B4osBDSVh2MPaH3yOCrHSTdm%2BBmOSr8Y3oN4LyWqF6bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I can also work on the Thunderbird extension. However I've just submitted the Firefox extension to Mozilla for their signing. Best Regards, Raffaele. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp0ercACgkQjTxG+6f1 ce69aw//dGUEpn6rhLDF3Z7FP/gFyfXA4XKwZkhnCuNlkY69XAOHzFQitWhM9fT3 oySZJy4n+s+pR5RJptnhFZcxcwrsyXWvontGR9h+2b754+YzdiIDifVBk7lyvl6n +wj2O2+R9dPCwGIFQnS0xI2g+X/Wu8b9+vD++zL6hIX7YAeKiD8LfDkcWY3ChHO7 tcZw41IcHpnlGs6B9AObAbSnssPMl98MczH2IFfX+VmaqUYUucZfNlAjVkfnunTc qfI1nNd4eNuiCKzG7oM4Y4s5kBi+Z64xoSFF4GB1KF2ZaZnxXITXydeLxwScIh0T Gxtc9vpTnAC5tCSG6/cqtl938RK3RS6SQVqUiKDBJZUvdp2JbiI5T/mWcb0B7u2E mBo6qZIpnfDZi08NQ9b5PwOs8f9bk4OqtDWmb24gTVv0Qh2kAahvFqBle7R+NJ/j 1nVP+W4A1omOdRpRsCtasL4do+E9I/xcIcBcAucNIwLM26crKK4d4N6BP8BBaTIW +IjRwd7Y2TsGA9EKBpn+UpKaUZEwn6MKqyF0MEFZT6yXyzZ6cn7SIFZQ0b6j3Wzs fLRuR1i3SWQznp5Up8MQGQgs5KbGCYip44p2rUfiKdV9m6zrTuJvTE0an+bZWFBn SJb8EwY/BVwetcku/N7QAJSrc2h1Rl/izPNHhj+8jk65BTR/Vl8= =GSFa -END PGP SIGNATURE- -- 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/btmtw4Jd2-oFJBQntbVDnYskJgzPOuyjRLIm06eA6Nl_-elWEqTjYVjaygRwbICt3-Xnw3G4Xc4Zy8vDVx6eSJzwI3O1IW813j1lPK1bNno%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On 02/01/2018 07:16 AM, Raffaele Florio wrote: > Hi all :), > During past months I worked on idea [0]. Currently it's supported only by > Firefox and Chrome. The repo is at [1] and the qubes-issue regarding > contribution message is at [2]. It was assigned to the 4.1 milestone. > > I've a question about if is acceptable (in term of performance, specifically > latency) to have some form of signed USB input, from a usbvm. A lot of laptop > (the majority?) has only an USB controller and without reset capabilities. > The most susceptible device, IMHO, is USB keyboard. So if it's possible to > put a proxy USB signer device (e.g. a rPi Zero) between the USB keyboard and > the usbvm, Dom0 could verify that input come from the signer device. > However thanks the Qubes 4.0 flexibility this necessity could be suppressed > by "Qubes Air". Unfortunately I cannot try Qubes 4.0-rcX. I hope that the > 4.0-rc4 hasn't any major problem. So it became the stable release, <3. > > > [0] = https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions > [1] = https://github.com/raffaeleflorio/qubes-url-redirector > [2] = https://github.com/QubesOS/qubes-issues/issues/3152 great, I missed this development! Shall I remove the Firefox/Chrome extensions from the GSoC 2018 list of prospective projects, and keep the Thunderbird extension there for now? Michael -- 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/0537ef17-2d31-89f1-81ed-c457db6db739%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all :), During past months I worked on idea [0]. Currently it's supported only by Firefox and Chrome. The repo is at [1] and the qubes-issue regarding contribution message is at [2]. It was assigned to the 4.1 milestone. I've a question about if is acceptable (in term of performance, specifically latency) to have some form of signed USB input, from a usbvm. A lot of laptop (the majority?) has only an USB controller and without reset capabilities. The most susceptible device, IMHO, is USB keyboard. So if it's possible to put a proxy USB signer device (e.g. a rPi Zero) between the USB keyboard and the usbvm, Dom0 could verify that input come from the signer device. However thanks the Qubes 4.0 flexibility this necessity could be suppressed by "Qubes Air". Unfortunately I cannot try Qubes 4.0-rcX. I hope that the 4.0-rc4 hasn't any major problem. So it became the stable release, <3. [0] = https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions [1] = https://github.com/raffaeleflorio/qubes-url-redirector [2] = https://github.com/QubesOS/qubes-issues/issues/3152 Best Regards, Raffaele. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlpzBJgACgkQjTxG+6f1 ce7qcRAA2PCmR/KM5lhNvpmd3P9vp0SC8whx7C2VdNhhgCd1yd9t6eVMHLHTk3ti 7hVZWNmsfwqaF2fdlaLoYkXdlgO2AiUWTWvVwobYZzsycHTZRC7U5dekstkJTsc9 zbYs4MtKNQRjvuXh77Vc5/Sh7c5kUA+ODaQyPn6FuIpI9o9CoWjbIGGU6ADidXUV uD1ZIjHWto5sjLvzJbrMIZo5yPC7/Ybpye7Q8bwIiQQjmrli6otB2/9w6OFjeZA6 gDxwT+qJ2gje37usi2qfAC4J4gSb20FVhftswntiOsZFHfy4wqsDB/lclHGBKiqi +3ilRDQ94ZfQw9MuUnOA6skKkkTdDSNmymY/6UQFH7RZNU507MMzufQlJpYRbOLM unBXS+Kx86cDaZ/UpDHEI1mWKdAhZwwDPTL0lr3DYDKdJKOlSCGFPZmcsMRL7gS5 NrwsioJsKo0jjq4VaKEtmv0VXk0myFNByr2P1zIbKYRzCMVnlt7nF3gXB/gIkrQl Ei2+wInrk6HSHUQKhfi1rK5SQymvCcVSqHymHnTlmxzlZrbTsVkgUy/Unes46c7n 4k+j+SjLmkuvlEIUrvkR7P62nvShpU5JRKOr6RDmRX/10Y7lEHHMMrF0BK4HbFE2 VXRzqzsW2n1q++1nYoAIdBuW03AqDUy5V3rUa73RmPMkjOa+R9E= =+COA -END PGP SIGNATURE- -- 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/mdB0Y7MfXOFfHZymvaZOgTDfwHToA37ul8wvnkWmq015NV-Z0QmWFdMc2ynkS06NooRwovM_SW9kuSlSUTc0TdZ90f2aLZWH8YjjF7-XwY0%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jan 21, 2018 at 06:35:25PM -0500, Michael Carbone wrote: > On 01/09/2018 09:32 PM, Andrew David Wong wrote: > > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > > the Qubes community to contribute ideas to the Qubes ideas list. [2] > > You can find our 2017 ideas list here: > > > > https://www.qubes-os.org/gsoc/ > > > > (This page will be updated for GSoC 2018.) > > > > Please feel free to submit pull requests against that page or send > > replies to this thread. > > > > > > [1] https://summerofcode.withgoogle.com/ > > [2] https://summerofcode.withgoogle.com/rules/ > > Hi all, > > Now is the time to start submitting pull requests against the doc file > for projects. The template is here: > > https://www.qubes-os.org/gsoc/#project-ideas > > Also please remove any projects that are no longer relevant, or if a > mentor is no longer able to mentor those projects. On the other hand, if someone want to be a mentor, please let us know! > Should we remove the 2017 projects from last year "Qubes MIME Handlers" > and "Making AEM protection..."? Or keep them up for further work to be > done on them? I'd remove them. - -- 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/THMrX1ywFAlpl2WUACgkQ24/THMrX 1yw0nwf8CIwUso89h8EecKiS2NtLuBj2GIA3nESXPFzLqy0p3cWRC+rgR3IcBeVe 0ApmN0xO3Fb0KlzLSR3bcZxfBNgoe3SqOzC1SnntcErqGckCir3tKoFdTaJjbEPh bl/A5UirUxda5MVZ0kgMjHe5/PIub0C3HoEgHOQ+zr3fNM2wY3GzGquozlSEZEgO 9oepnLzVQS84DO57SikwoVevaBLFokFdlLw6dSttbHZymjFKz+4eTwEnDtt3+GOQ xEYH2+5prJIADTx02A5bh19+OPOVjQfc+qzpEiLyeMl2YHJoUCP/hdkHsIcm7uP2 bnZ6F0257okuiCrE5h54omjI5cuvlQ== =VfFJ -END PGP SIGNATURE- -- 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/20180122123029.GW2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On 01/09/2018 09:32 PM, Andrew David Wong wrote: > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > the Qubes community to contribute ideas to the Qubes ideas list. [2] > You can find our 2017 ideas list here: > > https://www.qubes-os.org/gsoc/ > > (This page will be updated for GSoC 2018.) > > Please feel free to submit pull requests against that page or send > replies to this thread. > > > [1] https://summerofcode.withgoogle.com/ > [2] https://summerofcode.withgoogle.com/rules/ Hi all, Now is the time to start submitting pull requests against the doc file for projects. The template is here: https://www.qubes-os.org/gsoc/#project-ideas Also please remove any projects that are no longer relevant, or if a mentor is no longer able to mentor those projects. Should we remove the 2017 projects from last year "Qubes MIME Handlers" and "Making AEM protection..."? Or keep them up for further work to be done on them? Michael -- 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/5b060131-fe51-4164-77c5-c85f00e7feb6%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Sunday, 21 January 2018 22:19:37 CET bowa...@gmail.com wrote: > OK understood now (limit to 2D square/line/bitmap/... rendering, obivously > fonts will have to stay out ). Agreed, which is not a problem :) The way font rendering works in, for instance Qt (basing this on the first version years ago) is that a pixmap is reserved in GPU memory and as text is being rendered into it character by character (glyphs, really). Then when this same character is again needed, the command is given to copy a small section of that pixmap into the correct place. Your text-document rendering then becomes a pure in-GPU-memory operation of plotting small sections of a larger pixmap onto screen. Its insanely fast. > > Due to the fact that such software rendering stacks exist, I postulate > > that we have a very good chance of rejecting any unsafe GPU constructs. > > > > This is why I went into the explanation of how painting currently works > > in a hardware-accelerated toolkit doing its rendering. Because those > > simple constructs are trivial to forward and much cheaper to transport > > from AppVM to graphics-VM than pixels are. > > > > Hope this makes it a bit clearer. > > Yes very much. > > So with the correct understanding I completely agree that the level of > risk if far lower. Awesome :) > However I am not convinced that we have a real problem to solve. The > current solution is fast enough to stream youtube videos. The only > application I can see is image editing of big 2D SVG diagram/plan... as > 3D is starting to reach the border line (also as the pipeline is probably > functional/"immutable" it may be applicable). If you use KDE5 for a while, you may change your mind. When I first started to use Qubes I had to use XFCE4 and GTK and it felt like going back to the 1980s. The user interfaces are just soo shocking and simple. If you add or remove a file in dolphin (in icon-view) the view adjusts by moving smoothly the other files. This is especially useful if a file is added by you saving it from a different app. You can see immediately what changed. Not just that *something* changed, but the primitive part of your brain understands without thought exactly what changed. This kind of little usability touch are all over the place. Little animations, small kinds of shading. A fade-in instead of a brutal change. Those things have been proven by researchers to actually help people use computers because its much closer to how the real world works. The hard part is; it has to be done in a smooth stable framerate to avoid losing the entire positive effect. If I run this simple 'move icon to the left' animation inside of an AppVM (at pretty big icons) I get rather annoying looking tearing effects. :-( Not to mention the fact that on battery-using devices it will use a magnitude more power than the solution outlined in my proposal. Based on this I disagree that it is unneeded. > I prefer the idea of limiting the number of VM that can do 3D to the This proposal is not about doing 3D, but using a (GPU based) hardware painting pipeline which is almost entirely 2D based. > I like current Qubes philosophy which is to decompose the problem and > apply simple solutions on the right edges. I would say this fits right in. It is indeed re-using the current idea of Qubes forwarding bitmaps to the graphics-card and upgrading it to reflect that today's computers come with newer hardware and the pipeline we have available can lead to huge gains. -- 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-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/1760547.14VRJzhR2e%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Sunday, 21 January 2018 12:33:59 UTC, Tom Zander wrote: > On Saturday, 20 January 2018 15:03:38 CET bowa...@gmail.com wrote: > > I don't think I have miss-understood. Your proposal is for the client VM > > to sent OpenGL instruction to the Dom0 GPU. > > Your understanding isn't entire wrong, but you miss the subtleties. > Applying your description to webbrowsers javascript it is like you say it > allows code downloaded to be executed on your CPU. > > Well, not wrong, but definitely not correct. > > Like that javascript engine, you don't just execute any code anyone throws > at you on your privileged GPU. That would obviously be silly and completely > break the encapsulation xen provides. > > The usecases I was talking about (hardware accelerated 2D rendering of > widgets and text etc) doesn't use shader applications, it certainly doesn't > freely program the GPU or give any sort of results back to the calling > application. > As we today render such screens using multi-threaded CPU based code into a > pixel-buffer with no visual artifacts (using mesa) you might follow my > thinking that taking the existing stack and replacing the part where it > renders into a pixel-buffer with forwarding commands to the GPU-using VM. OK understood now (limit to 2D square/line/bitmap/... rendering, obivously fonts will have to stay out ;) ). > > Due to the fact that such software rendering stacks exist, I postulate that > we have a very good chance of rejecting any unsafe GPU constructs. > > This is why I went into the explanation of how painting currently works in a > hardware-accelerated toolkit doing its rendering. Because those simple > constructs are trivial to forward and much cheaper to transport from AppVM > to graphics-VM than pixels are. > > Hope this makes it a bit clearer. Yes very much. So with the correct understanding I completely agree that the level of risk if far lower. However I am not convinced that we have a real problem to solve. The current solution is fast enough to stream youtube videos. The only application I can see is image editing of big 2D SVG diagram/plan... as 3D is starting to reach the border line (also as the pipeline is probably functional/"immutable" it may be applicable). I prefer the idea of limiting the number of VM that can do 3D to the number of extra video card you have and stream the rendered output to Dom0 and be confident with my simple security model. But probably some people would be interested as it is a nice idea (as long as the safe option is present by default). I like current Qubes philosophy which is to decompose the problem and apply simple solutions on the right edges. sys-firewall is the same, also I would remove state management in the firewall (only source/dest port and get the sequence number checking to the VM that is being protected so the attack surface is even smaller and I am even more confident that I can trust it). Look at SELinux and how the blotted beast does not inspire any confidence :) > > I won't have any time to work on this, I was hopeful some graphics savvy > people would be interested in making apps like Chromium and Qt5 based apps > again fast in Qubes. I know I would be very appreciative. > -- > 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-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/8f421198-6d4f-4e19-9b7f-3f8a67138c4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Saturday, 20 January 2018 15:03:38 CET bowa...@gmail.com wrote: > I don't think I have miss-understood. Your proposal is for the client VM > to sent OpenGL instruction to the Dom0 GPU. Your understanding isn't entire wrong, but you miss the subtleties. Applying your description to webbrowsers javascript it is like you say it allows code downloaded to be executed on your CPU. Well, not wrong, but definitely not correct. Like that javascript engine, you don't just execute any code anyone throws at you on your privileged GPU. That would obviously be silly and completely break the encapsulation xen provides. The usecases I was talking about (hardware accelerated 2D rendering of widgets and text etc) doesn't use shader applications, it certainly doesn't freely program the GPU or give any sort of results back to the calling application. As we today render such screens using multi-threaded CPU based code into a pixel-buffer with no visual artifacts (using mesa) you might follow my thinking that taking the existing stack and replacing the part where it renders into a pixel-buffer with forwarding commands to the GPU-using VM. Due to the fact that such software rendering stacks exist, I postulate that we have a very good chance of rejecting any unsafe GPU constructs. This is why I went into the explanation of how painting currently works in a hardware-accelerated toolkit doing its rendering. Because those simple constructs are trivial to forward and much cheaper to transport from AppVM to graphics-VM than pixels are. Hope this makes it a bit clearer. I won't have any time to work on this, I was hopeful some graphics savvy people would be interested in making apps like Chromium and Qt5 based apps again fast in Qubes. I know I would be very appreciative. -- 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-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/1708765.rJ20DFuX3g%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Saturday, 20 January 2018 09:32:43 UTC, bow...@gmail.com wrote: > On Thursday, 11 January 2018 14:47:39 UTC, Tom Zander wrote: > > On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote: > > > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > > > the Qubes community to contribute ideas to the Qubes ideas list. [2] > > > You can find our 2017 ideas list here: > > > > Here is a suggestion that may be fun, it will certainly be useful. > > Not specifically aimed at GSOC, just an idea I had some weeks ago, > > something > > that needs to be done one way or another :-) > > > > > > # Modernize painting pipeline > > > > The Qubes design is that each virtual machine runs its own xorg server and > > applications running on that VM paint into a specially crafted device > > driver. > > Changes are sent as pixmaps to the actual user-visible xorg server creating > > the illusion of all applications running on one desktop. > > > > Since the rise of GPUs available for everyone, the design of painting in a > > pixel-buffer is outdated and modern GUI toolkits are severely slowed down > > in > > the Qubes pipeline as it is today. > > A Graphics Processing Unit (GPU) is dedicated hardware for updating your > > screen, most CPUs ship with a GPU on-board today. The actual operations > > that > > modern toolkits give in order to create their graphical windows is > > dramatically different on such systems and as a result it is sub-optimal to > > force them through a pixmap causing slow refreshes. > > > > The task is to research a way to build an xorg driver (using open source > > libraries like mesa) which can be used inside of an embedded virtual > > machine > > for applications to draw into. > > The information (does not have to be pixels!) gained from that should be > > possible to send over a connection to our GUI virtual machine (currently > > dom0) for display where the scene should be rendered using opengl based > > instructions. I don't think I have miss-understood. Your proposal is for the client VM to sent OpenGL instruction to the Dom0 GPU. The attack surface is significantly larger (thousand times more lines of code and logic to verify, you would need formal verification). I prefer to work a gaming PC on the side with a dedicated email address and credit card for my gaming/3d "life". > > > > A bit of background to explain the actual problem; > > Imagine a list of an address-book. A picture and some text and some lines. > > In the old style painting the GUI would be drawn using 1 thread, into a > > pixel buffer. It would loop over each person in the address book and draw > > the picture, then the text then the decorations. > > This is how Qubes operates now. > > This is incorrect in the sense that are not looking at what Qubes does but > the full pipeline. Qubes takes the approach that security flaws comes with > complexity. It's principle is simple: > - The VM render it's UI (using whatever best method it has) > - Qubes copy the memory region which would have been displayed by the window > manager of that VM and gives it to be displayed in a decorated window in Dom0 > as an image. > > This way the attack surface of Qubes code is very small. The copy operation > of the array received which is not parsed on the receiving end. > > A GPU is another computer in your computer attached with a bus. It has a > firmware, run-time, memory, processor. Rootkits exists to attack the run-time > and even to stay persistent in the GPU (not sure if these attacks are still > possible on the persistence side) > Therefore Dom0 is the only OS that can have code running on it (until you > have GPU hardware virtualization). > > With systems with 2 GPU, you can have Dom0 using one (use the integrated one > as you don't need the power for Dom0) and One single other VM (possible > multiple in the same risk zone at different point in time) can use the other > one. The output of that GPU going to another monitor. > Work could be done as part of Qubes to do the same and copy the memory area > of the GPU that is the stream sent to the monitor (or a sub-region) and send > it to Dom0 for rendering. You however have to do that without introducing too > much latency and fast enough for that buffer to not have been refreshed to > not drop frames. You also need enough BW on the bus to push the info across > (so you won't be able to have 144Hz). > > > > > Using a GPU this can be sped up immensely by realizing that starting a > > stream of instructions is what takes the time on such hardware, executing > > the instructions happens totally inside of the GPU. > > The toolkit would first paint all the backgrounds. Then it would set a > > different pen and paint all things in that color, which in our case would > > be > > the decorations. > > Notice that we no longer loop over each address-book item, they are all > > done > > at the same time. > > The border ar
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Thursday, 11 January 2018 15:47:30 CET 'Tom Zander' via qubes-devel wrote: > # Modernize painting pipeline A poster (Foppe de Haan) in the user mailinglist pointed out this project called "Looking-glass" that is very similar to the (very naive) proposal I made; https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387 They seem to actually have a proof-of-concept post published last November which shows that for GPU accelerated graphics this approach greatly speeds up display without losing the benefits of speed over moving pixel-buffers. Maybe the qubes-developers can check with them and see if they are doing GSoC. -- 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-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/11491104.l0clanvJyn%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Saturday, 20 January 2018 10:14:00 CET bowa...@gmail.com wrote: > This way the attack surface of Qubes code is very small. The proposal does not change the attack surface at all. Reading on what you wrote below, I think you have misunderstood the proposal to one of GPU passthrough. > A GPU is another computer in your computer attached with a bus. It has a > firmware, run-time, memory, processor. Rootkits exists to attack the > run-time and even to stay persistent in the GPU (not sure if these > attacks are still possible on the persistence side) Therefore Dom0 is the > only OS that can have code running on it Yes, I think you misunderstood the proposal, the GPU is not being shared or made available to anyone but dom0 in the proposal. Making your worry irreleavnt. The proposal is made specifically to avoid needing to make the GPU available for all Qubes. -- 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-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/1884306.4Qn7dAWZx5%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Thursday, 11 January 2018 14:47:39 UTC, Tom Zander wrote: > On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote: > > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > > the Qubes community to contribute ideas to the Qubes ideas list. [2] > > You can find our 2017 ideas list here: > > Here is a suggestion that may be fun, it will certainly be useful. > Not specifically aimed at GSOC, just an idea I had some weeks ago, something > that needs to be done one way or another :-) > > > # Modernize painting pipeline > > The Qubes design is that each virtual machine runs its own xorg server and > applications running on that VM paint into a specially crafted device > driver. > Changes are sent as pixmaps to the actual user-visible xorg server creating > the illusion of all applications running on one desktop. > > Since the rise of GPUs available for everyone, the design of painting in a > pixel-buffer is outdated and modern GUI toolkits are severely slowed down in > the Qubes pipeline as it is today. > A Graphics Processing Unit (GPU) is dedicated hardware for updating your > screen, most CPUs ship with a GPU on-board today. The actual operations that > modern toolkits give in order to create their graphical windows is > dramatically different on such systems and as a result it is sub-optimal to > force them through a pixmap causing slow refreshes. > > The task is to research a way to build an xorg driver (using open source > libraries like mesa) which can be used inside of an embedded virtual machine > for applications to draw into. > The information (does not have to be pixels!) gained from that should be > possible to send over a connection to our GUI virtual machine (currently > dom0) for display where the scene should be rendered using opengl based > instructions. > > A bit of background to explain the actual problem; > Imagine a list of an address-book. A picture and some text and some lines. > In the old style painting the GUI would be drawn using 1 thread, into a > pixel buffer. It would loop over each person in the address book and draw > the picture, then the text then the decorations. > This is how Qubes operates now. This is incorrect in the sense that are not looking at what Qubes does but the full pipeline. Qubes takes the approach that security flaws comes with complexity. It's principle is simple: - The VM render it's UI (using whatever best method it has) - Qubes copy the memory region which would have been displayed by the window manager of that VM and gives it to be displayed in a decorated window in Dom0 as an image. This way the attack surface of Qubes code is very small. The copy operation of the array received which is not parsed on the receiving end. A GPU is another computer in your computer attached with a bus. It has a firmware, run-time, memory, processor. Rootkits exists to attack the run-time and even to stay persistent in the GPU (not sure if these attacks are still possible on the persistence side) Therefore Dom0 is the only OS that can have code running on it (until you have GPU hardware virtualization). With systems with 2 GPU, you can have Dom0 using one (use the integrated one as you don't need the power for Dom0) and One single other VM (possible multiple in the same risk zone at different point in time) can use the other one. The output of that GPU going to another monitor. Work could be done as part of Qubes to do the same and copy the memory area of the GPU that is the stream sent to the monitor (or a sub-region) and send it to Dom0 for rendering. You however have to do that without introducing too much latency and fast enough for that buffer to not have been refreshed to not drop frames. You also need enough BW on the bus to push the info across (so you won't be able to have 144Hz). > > Using a GPU this can be sped up immensely by realizing that starting a > stream of instructions is what takes the time on such hardware, executing > the instructions happens totally inside of the GPU. > The toolkit would first paint all the backgrounds. Then it would set a > different pen and paint all things in that color, which in our case would be > the decorations. > Notice that we no longer loop over each address-book item, they are all done > at the same time. > The border around a picture is drawn by drawing a black square and last the > images of the users are drawn on top of that. > > The main thing to notice is that this new way of doing things has as a side- > effect that many pixels are overwritten many times. This is not a downside > if it happens completely in the GPU, but you do notice this effect in the > Qubes pipeline. > > This new approach allows modern toolkits to update their GUI and reach a 30- > frames-per-second update strategly, even on modest hardware. So it really > works, and the goal is to build on top of that and make Qubes GUIs much more > perform ants as well. >
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Monday, 15 January 2018 00:31:14 CET Marek Marczykowski-Górecki wrote: > I'm trying to show you how things one can consider a configuration, may > enable you to compromise a VM. This may show the underlying reason for the mis-communication. What is considered a configuration is not really open to discussion, it is well documented and there are specifications on freedesktop.org and wikipedia of most of this stuff. So, I see why you are saying the above; you have been thinking about a lot more file-types and I understand you feel uncomfortable about shell scripts and many others. Maybe just to get a better idea, I think if you limit yourself to ~/.config/*rc you'll have a more specific set of the actual subject matter. Hope that explains this better. If you feel uncomfortable with it, it was just an GSoC project-idea, no harm done if you ignore it. -- 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-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/5856407.XtigafrElP%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jan 14, 2018 at 11:54:38PM +0100, 'Tom Zander' via qubes-devel wrote: > On Sunday, 14 January 2018 22:09:10 CET Marek Marczykowski-Górecki wrote: > > Ok, lets start with ~/.config/xdg/autostart/*.desktop. "files with > > key/value pairs", right? Those don't have executable bit either. > > I'm not sure why you are trying really hard to misunderstand me :( > > I wrote that this is a project about _config_ files. I wrote the _intention_ > of those files and I even specifically wrote about how things that get > executed are _not_ to be copied. > .desktop files are not config files. Shell scripts are not config files. > > I don't understand why you trying so hard to misunderstand the goal? > > None of the items you bring up fall within the concept I presented as a > configuration. > Yet you bring them up like they are reasons to reject the idea for a GSoC > project... > > Investigating which files are secure to (not) include should definitely be > part of the GSoC. Its a learning project for students, research is a useful > part of any GSoC project. I'm trying to show you how things one can consider a configuration, may enable you to compromise a VM. Writing a tool that automatically verify that given configuration is "safe" will be specific to each configuration file and because of this, will scale poorly (you will end up with a short list of supported applications). You can consider manual verification (asking the user whether to propagate specific config change), but you'll loose "fully automatic" property then. > > > Having exectly one minion on the entire system doesn't make it a > > > management stack. > > > > Well, the above is about configuring dom0. > > I think you misunderstood, nothing in the original proposal would ever need > touch anything in dom0. That's alternative approach to the same problem, which may co-exist with something else. With salt you can have dom0 enforcing some particular configuration in VMs. - -- 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/THMrX1ywFAlpb6EIACgkQ24/THMrX 1yywgQf+MmlzHi/P2tIv/BavRMfQYyFF4G/L5K7Buszb0Ietb528FZOj48HgeuBZ ymuMIjduCdZCOplVtPZy8QrgJdprZjkokESpz3K1ZkMG32TnG5+IyjdSKmondUf8 E6LxwugRRIlbswd3YFyZSkE9tNx4EXz3NNYOWONAtCyVjZ1n6BLSKohHPzCGvs1G k80VwO0VAFFfKIJBjdRsqAUbgvzsE8BknWb9aEzrQNpFyV89JBDRne1kBiCYEnt/ Y5nvVvZ11DGp4UUwDTy2/8XP4OE6Tmv9D4WetkeewXBHzC6DTwrc+76zzZBenOPV QeoThc9VE5nPWSdb7L77rn6Jd/w7sA== =P6DC -END PGP SIGNATURE- -- 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/20180114233114.GX2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Sunday, 14 January 2018 22:09:10 CET Marek Marczykowski-Górecki wrote: > Ok, lets start with ~/.config/xdg/autostart/*.desktop. "files with > key/value pairs", right? Those don't have executable bit either. I'm not sure why you are trying really hard to misunderstand me :( I wrote that this is a project about _config_ files. I wrote the _intention_ of those files and I even specifically wrote about how things that get executed are _not_ to be copied. .desktop files are not config files. Shell scripts are not config files. I don't understand why you trying so hard to misunderstand the goal? None of the items you bring up fall within the concept I presented as a configuration. Yet you bring them up like they are reasons to reject the idea for a GSoC project... Investigating which files are secure to (not) include should definitely be part of the GSoC. Its a learning project for students, research is a useful part of any GSoC project. > > Having exectly one minion on the entire system doesn't make it a > > management stack. > > Well, the above is about configuring dom0. I think you misunderstood, nothing in the original proposal would ever need touch anything in dom0. -- 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-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/1529877.8g5FPUQDrr%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jan 13, 2018 at 05:22:11PM +, Tom Zander wrote: > On Friday, 12 January 2018 15:18:39 GMT Marek Marczykowski-Górecki wrote: > > Well, such sanitization would need to be application specific, and would > > be *very* fragile element. For example .bashrc is a plain ASCII file, not > > executable (as of permissions), but allow you to execute any command > > placed in there. There are a lot more such places. > > Bashrc isn't really a config file, it is literally executable code. I agree > that you don't want to leak that from a potentially exploited qube. > > You say there are a lot of configuration files on your system that are > executables? I am a KDE user, and this is certainly not the case there. But > maybe my views are limited to the software I'm most familiar with. Would tou > be able to share your knowledge of applications that execute config files? > > The idea is really mostly about "real" config files. In the truest sense of > the word. :-) > This is about many files in ~/.config dir. Ok, lets start with ~/.config/xdg/autostart/*.desktop. "files with key/value pairs", right? Those don't have executable bit either. > Stuff I'd love to get synced are dolphinrc (file browser config), > balloofilerc > (desktop-search, specifically turning it off), kcalcrc, okularrc (pdf > viewer), gwenviewrc (imag viewer), gtk-3.0/settings.ini, terminal > settings... Does ~/.local/share also counts? This is for example where "konsole" keeps profile settings - you want to keep them, right? If so, lets see what happens when you modify ~/.local/share/konsole/default.keytab and add this line: key Return : "\necho this is totally not a code execution\n" I'm sure you can be more creative in making it stealth. I see there is also an option to configure what applications are bound to different file types (a place to put a command), various dolphin plugins and such. This is just result of 5 min search, I'm sure there is more. > That was the goal, sorry for confusing stuff and making you think this is > about shell scripts. It is not. > > > I don't believe it would be possible to write working, generic enough, > > verifier for such config files. > > This is only if you want shell scripts and similar execuable code, > lets not call bashrc a config file. > > Actual config files are lists of key/value pairs, nothing that will ever be > treated as "code". > > > The problem here is verification of potentially malicious change sent by > > untrusted VM. But if we could avoid the "untrusted" part, it would be > > better. For example have a single VM (template?) used to configure > > applications, and have some mechanism to selectively share those files > > with different VMs. For new VMs, you can use /etc/skel - it is used to > > initialize home of newly created VMs. > > Please be aware that /etc/skel is an extremely limited solution to the point > where I don't even consider it a "solution" for the situation that was > outlined in the original task. > > Qubes is great in that it allows us to limit certain usages to certain > domains. You can end up with a dozen almost identical domains where the only > real difference is the data that is stored in it. > But with the addition of each individual qube you highten the mental load > and dumb maintainance work when it comes to configuring and using the tools > that you have and use in many of them. > This GSoC project is meant to take the brunt of that burden and allow users > to treat those file browsers and similar apps as > "configure once, run anywhere". Yes, such thing would need also some kind of synchronization, not only one time provisioning. > > One thing that comes to my mind is salt management stack, which have > > exactly this purpose - manage configuration. See here for some > > documentation and examples: > > > > https://www.qubes-os.org/doc/salt/ > > https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html > > The page you linked to makes me question how useful it would be; > From the qubes docs; > > > Salt is a client-server model, where the server (called master) manages > > its clients (called minions). In typical situations, it is intended that > > the administrator interacts only with the master and keeps the > > configurations there. In Qubes, we don’t have a master. Instead we have > > one minion which resides in dom0 and manages domains from there. > > Having exectly one minion on the entire system doesn't make it a management > stack. Well, the above is about configuring dom0. Since Qubes 3.2 it is also possible to configure VMs. From the user point of view, every VM looks like a separate minion, controlled from a single master. So, you can apply your favorite dolphinrc to a group of VMs. > The salt stuff is so unifinished and unusable that basing a GSoC on it sounds > very irresponsible to me. Salt documentation indeed could use some improveme
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
Perhaps a method to change the presented screen resolution in a VM to make browser fingerprinting more difficult? -- 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/13bba268-170f-5dbe-8299-0761710a278e%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Friday, 12 January 2018 15:18:39 GMT Marek Marczykowski-Górecki wrote: > Well, such sanitization would need to be application specific, and would > be *very* fragile element. For example .bashrc is a plain ASCII file, not > executable (as of permissions), but allow you to execute any command > placed in there. There are a lot more such places. Bashrc isn't really a config file, it is literally executable code. I agree that you don't want to leak that from a potentially exploited qube. You say there are a lot of configuration files on your system that are executables? I am a KDE user, and this is certainly not the case there. But maybe my views are limited to the software I'm most familiar with. Would tou be able to share your knowledge of applications that execute config files? The idea is really mostly about "real" config files. In the truest sense of the word. :-) This is about many files in ~/.config dir. Stuff I'd love to get synced are dolphinrc (file browser config), balloofilerc (desktop-search, specifically turning it off), kcalcrc, okularrc (pdf viewer), gwenviewrc (imag viewer), gtk-3.0/settings.ini, terminal settings... That was the goal, sorry for confusing stuff and making you think this is about shell scripts. It is not. > I don't believe it would be possible to write working, generic enough, > verifier for such config files. This is only if you want shell scripts and similar execuable code, lets not call bashrc a config file. Actual config files are lists of key/value pairs, nothing that will ever be treated as "code". > The problem here is verification of potentially malicious change sent by > untrusted VM. But if we could avoid the "untrusted" part, it would be > better. For example have a single VM (template?) used to configure > applications, and have some mechanism to selectively share those files > with different VMs. For new VMs, you can use /etc/skel - it is used to > initialize home of newly created VMs. Please be aware that /etc/skel is an extremely limited solution to the point where I don't even consider it a "solution" for the situation that was outlined in the original task. Qubes is great in that it allows us to limit certain usages to certain domains. You can end up with a dozen almost identical domains where the only real difference is the data that is stored in it. But with the addition of each individual qube you highten the mental load and dumb maintainance work when it comes to configuring and using the tools that you have and use in many of them. This GSoC project is meant to take the brunt of that burden and allow users to treat those file browsers and similar apps as "configure once, run anywhere". > One thing that comes to my mind is salt management stack, which have > exactly this purpose - manage configuration. See here for some > documentation and examples: > > https://www.qubes-os.org/doc/salt/ > https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html The page you linked to makes me question how useful it would be; >From the qubes docs; > Salt is a client-server model, where the server (called master) manages > its clients (called minions). In typical situations, it is intended that > the administrator interacts only with the master and keeps the > configurations there. In Qubes, we don’t have a master. Instead we have > one minion which resides in dom0 and manages domains from there. Having exectly one minion on the entire system doesn't make it a management stack. The salt stuff is so unifinished and unusable that basing a GSoC on it sounds very irresponsible to me. -- 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-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/4053807.Oi6W6S34UW%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jan 12, 2018 at 02:12:47PM -, 'awokd' via qubes-devel wrote: > On Fri, January 12, 2018 1:12 pm, 'Tom Zander' via qubes-devel wrote: > > On Friday, 12 January 2018 11:21:27 GMT 'awokd' via qubes-devel wrote: > > > >> Securing this sounds hard, > >> > > > > My thinking is that using something like git controls setting files > > executables bits, serverside. So you can't magically get a new executable > > scripts in your homedir. Next its pretty easy to write a convert app that > > scans config files for non- ASCII content and maybe something like > > pointing to non-local paths (HTTP etc). > > > > As such I figured this seals off any attack vector as the *only* thing > > you will let in are plain-text files with non-executable payload. > > > > Do you see any other attack vectors? > > I was thinking of some type of Shellshock exploit but nevermind, I think > as long as those plaintext configs are sanitized somehow it should be OK. Well, such sanitization would need to be application specific, and would be *very* fragile element. For example .bashrc is a plain ASCII file, not executable (as of permissions), but allow you to execute any command placed in there. There are a lot more such places. I don't believe it would be possible to write working, generic enough, verifier for such config files. The problem here is verification of potentially malicious change sent by untrusted VM. But if we could avoid the "untrusted" part, it would be better. For example have a single VM (template?) used to configure applications, and have some mechanism to selectively share those files with different VMs. For new VMs, you can use /etc/skel - it is used to initialize home of newly created VMs. One thing that comes to my mind is salt management stack, which have exactly this purpose - manage configuration. See here for some documentation and examples: https://www.qubes-os.org/doc/salt/ https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html The issue with salt for broad usage is that it require some skills to write such configuration. So, maybe a tool to help with that could be useful? Like generate it automatically? Or provide ready to use snippets? - -- 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/THMrX1ywFAlpY0c8ACgkQ24/THMrX 1yzTZgf8Cpb5uQX4PwEcJLPL4oBr52nGoD7am6U9b26UlkPKytnCudhr5lGJUhLa clQ/TAHlHX40er0YMDGE1t7nfsfrY/FsLjZ1BtJCD+T6K77vfwdlQ15HGdkDS/mK A5Ja7TUxoQZi7l1lMmvi3AQAtW6A2yaHaKI54vETndbqgLzSUldQ3zc5/I5MzBl5 ea2hmnw8XWnPReTnrZH0qmlHyVQl5JME6aCduGxoPaZdE3d7JNKtSnrl49iQiTQv Zmdm4iha43p55u+17HTuFkLoXLiiYI77lZ2PNXB2547QgjLxv10k3CyMR5Ndlj+e jMIPlTJq89IZVoXf5WqsZu+NUXXmkQ== =qWzh -END PGP SIGNATURE- -- 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/20180112151839.GK2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Fri, January 12, 2018 1:12 pm, 'Tom Zander' via qubes-devel wrote: > On Friday, 12 January 2018 11:21:27 GMT 'awokd' via qubes-devel wrote: > >> Securing this sounds hard, >> > > My thinking is that using something like git controls setting files > executables bits, serverside. So you can't magically get a new executable > scripts in your homedir. Next its pretty easy to write a convert app that > scans config files for non- ASCII content and maybe something like > pointing to non-local paths (HTTP etc). > > As such I figured this seals off any attack vector as the *only* thing > you will let in are plain-text files with non-executable payload. > > Do you see any other attack vectors? I was thinking of some type of Shellshock exploit but nevermind, I think as long as those plaintext configs are sanitized somehow it should be OK. -- 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/5c0531a9915fdd552daa07fa6dc07902.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Friday, 12 January 2018 11:21:27 GMT 'awokd' via qubes-devel wrote: > Securing this sounds hard, My thinking is that using something like git controls setting files executables bits, serverside. So you can't magically get a new executable scripts in your homedir. Next its pretty easy to write a convert app that scans config files for non- ASCII content and maybe something like pointing to non-local paths (HTTP etc). As such I figured this seals off any attack vector as the *only* thing you will let in are plain-text files with non-executable payload. Do you see any other attack vectors? > but could the existing update proxy system be > utilized for this? Possibly, at minimum the qrexec communication channel should be the same and the reason I suggested gitolite is because there is no reason to try and re- invent all the tech that already exists. Specifically; synchronizing n editable copies of a file (where n > 2) is non- trivial and git solved it. Why not use that. :-) -- 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-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/5121519.MbWqTiX2xb%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Fri, January 12, 2018 11:10 am, 'Tom Zander' via qubes-devel wrote: > The beauty of Linux is that practically all config files are plain-text. > As > such we can make sure with only minimal effort that if we were to > auto-copy config files between qubes that we do not introduce any security > issues. > > The task; > create a setup where each VM has a hidden directory with a git repository > that we will be copying the config files into. Add a new qube which runs > a git server like gitolite. On the server side you need some checks in a > git push- hook that rejects any changes that could be a security issue. > Executable > files, non-text files etc. Securing this sounds hard, but could the existing update proxy system be utilized for this? -- 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/49b721c15e2071724f84ebd8198393e5.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote: > Please feel free to submit pull requests against that page or send > replies to this thread. I have an idea for a standalone project that should be easy enough to setup, but for a student it may be challenging enough to last a couple of months. The problem we want to solve; since v4.0 each and every VM has their own homedir. This is great for security, but it is not so great for usability. The main issue is that configurations in user configs (from .bashrc to your favourite text editor config settings and Firefox bookmarks) are not shared between qubes. In various cases this is intentional. Some VMs just need to work differently. In many others it is just annoying to have to re-apply a change in config, or not have available that bookmark in all qubes. The beauty of Linux is that practically all config files are plain-text. As such we can make sure with only minimal effort that if we were to auto-copy config files between qubes that we do not introduce any security issues. The task; create a setup where each VM has a hidden directory with a git repository that we will be copying the config files into. Add a new qube which runs a git server like gitolite. On the server side you need some checks in a git push- hook that rejects any changes that could be a security issue. Executable files, non-text files etc. Then as a 3rd component each participating qube needs an application to look for the default locations for config files. Typically ~/.config, and allow the user to configure which ones they want to share between qubes. Communication between qubes and the central gitolite server can happen over qrexec, or maybe over a mapping in the firewall. The result should be that changes in a known set of config files can be shared automatically between qubes, fully automated. Stretch goal may be to have the application that looks for changes in config files use Linux features that notify you of any changes made in monitored directories. This avoids using CPU periodically to check for changes. Required knowledge; git and some programming language (python or something else, depends on what the mentor accepts). You need a Qubes computer set up. -- 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-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/3430023.xyE23NDl8N%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
Yes, this is interesting direction for research. I'd throw wayland into that picture - it may make things much easier. The key point here is to keep it simple and secure. For example allowing VM to send commands directly to GPU could be very bad idea, because such VM could steal whole screen content. Intel GVT-g[1] (formerly Xen-GT) could be interesting here, but also needs to be properly evaluated. Related ticket: https://github.com/QubesOS/qubes-issues/issues/3366 [1] https://01.org/igvt-g - -- 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/THMrX1ywFAlpYHTsACgkQ24/THMrX 1ywcnQf/bk9i7IVanLQjQ1jPE239fT7CeA1204PAfBVnG8pWkwebv494WY2PoLI6 C1I6JLH4PBqrqiO40z85O3ivNN5VP1AP9PCbJzH+KGNzpsahdvt98QJQMqyH0gU2 bki6yN/IaIeVBsu4w/DD8+X9zMaFqOe3k3sxZaQ/Sjp8I7sNXRwIHyDSvRX8jNLi zACXfyIvRDoGtlgBtJv7aQ00uL3Hw51WbSjHOQIFfowCEgZcshLJil8tey+XCUrj Gdm7xqEfzmnwGRUChnywQN8ZxVvpT5UPhNkOZ5GVAVhkCWxJM6pfqm6oxbl31PLl 1hip9q6mj0Dh6LT8vW01XsJt6L2k8w== =v2zK -END PGP SIGNATURE- -- 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/20180112022811.GI2653%40mail-itl. For more options, visit https://groups.google.com/d/optout. Wouldn't wayland also increase the security of the screenlocker in dom0? -- 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/nhnYpsyGiU7itcFxpuhSV7J8LfxPy66MmERBceUmwqj3YEnm44dTAPL-3N4l2S9LyUAcUpfeX02tG9Zi5JaW7E0XQJ-UxFZUYiSRkXSXMck%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jan 11, 2018 at 02:47:30PM +, Tom Zander wrote: > On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote: > > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > > the Qubes community to contribute ideas to the Qubes ideas list. [2] > > You can find our 2017 ideas list here: > > Here is a suggestion that may be fun, it will certainly be useful. > Not specifically aimed at GSOC, just an idea I had some weeks ago, something > that needs to be done one way or another :-) > > > # Modernize painting pipeline > > The Qubes design is that each virtual machine runs its own xorg server and > applications running on that VM paint into a specially crafted device > driver. > Changes are sent as pixmaps to the actual user-visible xorg server creating > the illusion of all applications running on one desktop. > > Since the rise of GPUs available for everyone, the design of painting in a > pixel-buffer is outdated and modern GUI toolkits are severely slowed down in > the Qubes pipeline as it is today. > A Graphics Processing Unit (GPU) is dedicated hardware for updating your > screen, most CPUs ship with a GPU on-board today. The actual operations that > modern toolkits give in order to create their graphical windows is > dramatically different on such systems and as a result it is sub-optimal to > force them through a pixmap causing slow refreshes. > > The task is to research a way to build an xorg driver (using open source > libraries like mesa) which can be used inside of an embedded virtual machine > for applications to draw into. > The information (does not have to be pixels!) gained from that should be > possible to send over a connection to our GUI virtual machine (currently > dom0) for display where the scene should be rendered using opengl based > instructions. > > A bit of background to explain the actual problem; > Imagine a list of an address-book. A picture and some text and some lines. > In the old style painting the GUI would be drawn using 1 thread, into a > pixel buffer. It would loop over each person in the address book and draw > the picture, then the text then the decorations. > This is how Qubes operates now. > > Using a GPU this can be sped up immensely by realizing that starting a > stream of instructions is what takes the time on such hardware, executing > the instructions happens totally inside of the GPU. > The toolkit would first paint all the backgrounds. Then it would set a > different pen and paint all things in that color, which in our case would be > the decorations. > Notice that we no longer loop over each address-book item, they are all done > at the same time. > The border around a picture is drawn by drawing a black square and last the > images of the users are drawn on top of that. > > The main thing to notice is that this new way of doing things has as a side- > effect that many pixels are overwritten many times. This is not a downside > if it happens completely in the GPU, but you do notice this effect in the > Qubes pipeline. > > This new approach allows modern toolkits to update their GUI and reach a 30- > frames-per-second update strategly, even on modest hardware. So it really > works, and the goal is to build on top of that and make Qubes GUIs much more > perform ants as well. > > > Expected results: > > * A proof of concept application which uses two xorg servers and running an > opengl aware app (Any Qt5 application) in one will show its window in the > other while sending mostly opengl instructions and a minimum of bitmaps over > the connection. > > > Knowledge prerequisite: > > * Programming in C > * opengl and xorg experience are highly useful Yes, this is interesting direction for research. I'd throw wayland into that picture - it may make things much easier. The key point here is to keep it simple and secure. For example allowing VM to send commands directly to GPU could be very bad idea, because such VM could steal whole screen content. Intel GVT-g[1] (formerly Xen-GT) could be interesting here, but also needs to be properly evaluated. Related ticket: https://github.com/QubesOS/qubes-issues/issues/3366 [1] https://01.org/igvt-g - -- 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/THMrX1ywFAlpYHTsACgkQ24/THMrX 1ywcnQf/bk9i7IVanLQjQ1jPE239fT7CeA1204PAfBVnG8pWkwebv494WY2PoLI6 C1I6JLH4PBqrqiO40z85O3ivNN5VP1AP9PCbJzH+KGNzpsahdvt98QJQMqyH0gU2 bki6yN/IaIeVBsu4w/DD8+X9zMaFqOe3k3sxZaQ/Sjp8I7sNXRwIHyDSvRX8jNLi zACXfyIvRDoGtlgBtJv7aQ00uL3Hw51WbSjHOQIFfowCEgZcshLJil8tey+XCUrj Gdm7xqEfzmnwGRUChnywQN8ZxVvpT5UPhNkOZ5GVAVhkCWxJM6pfqm6oxbl31PLl 1hip9q6mj0Dh6LT8vW01XsJt6L2k8w== =v2zK -END PGP SIGNATURE- -- You received this message because you are su
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
On Wednesday, 10 January 2018 02:32:02 GMT Andrew David Wong wrote: > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > the Qubes community to contribute ideas to the Qubes ideas list. [2] > You can find our 2017 ideas list here: Here is a suggestion that may be fun, it will certainly be useful. Not specifically aimed at GSOC, just an idea I had some weeks ago, something that needs to be done one way or another :-) # Modernize painting pipeline The Qubes design is that each virtual machine runs its own xorg server and applications running on that VM paint into a specially crafted device driver. Changes are sent as pixmaps to the actual user-visible xorg server creating the illusion of all applications running on one desktop. Since the rise of GPUs available for everyone, the design of painting in a pixel-buffer is outdated and modern GUI toolkits are severely slowed down in the Qubes pipeline as it is today. A Graphics Processing Unit (GPU) is dedicated hardware for updating your screen, most CPUs ship with a GPU on-board today. The actual operations that modern toolkits give in order to create their graphical windows is dramatically different on such systems and as a result it is sub-optimal to force them through a pixmap causing slow refreshes. The task is to research a way to build an xorg driver (using open source libraries like mesa) which can be used inside of an embedded virtual machine for applications to draw into. The information (does not have to be pixels!) gained from that should be possible to send over a connection to our GUI virtual machine (currently dom0) for display where the scene should be rendered using opengl based instructions. A bit of background to explain the actual problem; Imagine a list of an address-book. A picture and some text and some lines. In the old style painting the GUI would be drawn using 1 thread, into a pixel buffer. It would loop over each person in the address book and draw the picture, then the text then the decorations. This is how Qubes operates now. Using a GPU this can be sped up immensely by realizing that starting a stream of instructions is what takes the time on such hardware, executing the instructions happens totally inside of the GPU. The toolkit would first paint all the backgrounds. Then it would set a different pen and paint all things in that color, which in our case would be the decorations. Notice that we no longer loop over each address-book item, they are all done at the same time. The border around a picture is drawn by drawing a black square and last the images of the users are drawn on top of that. The main thing to notice is that this new way of doing things has as a side- effect that many pixels are overwritten many times. This is not a downside if it happens completely in the GPU, but you do notice this effect in the Qubes pipeline. This new approach allows modern toolkits to update their GUI and reach a 30- frames-per-second update strategly, even on modest hardware. So it really works, and the goal is to build on top of that and make Qubes GUIs much more perform ants as well. Expected results: * A proof of concept application which uses two xorg servers and running an opengl aware app (Any Qt5 application) in one will show its window in the other while sending mostly opengl instructions and a minimum of bitmaps over the connection. Knowledge prerequisite: * Programming in C * opengl and xorg experience are highly useful -- 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-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/5944843.NrBmjiJkSD%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
Hi all, I propose a GSOC project to implement more converters (like the Qubes PDF converter). For instance, converts for * documents (such as Word) with pandoc * video files with ffmpeg * audio files with sox * archive files (such as zip) -- perhaps this should work recursively? * other formats, such as spreadsheets, databases, web browser bookmarks, ... Cheers, Andrew On 10 January 2018 at 02:32, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > In preparation for Google Summer of Code (GSoC) 2018 [1], we invite > the Qubes community to contribute ideas to the Qubes ideas list. [2] > You can find our 2017 ideas list here: > > https://www.qubes-os.org/gsoc/ > > (This page will be updated for GSoC 2018.) > > Please feel free to submit pull requests against that page or send > replies to this thread. > > > [1] https://summerofcode.withgoogle.com/ > [2] https://summerofcode.withgoogle.com/rules/ > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpVeyAACgkQ203TvDlQ > MDDLqhAAveoDz1WmjU8zQc/D9ZvFV02V9c49dGi5uRS61505daSizdXERNW/KeF2 > jhEh8to/aJvqRSwPJLrJtC6FArArNVMwjm0ezuJN1nZwAzhntPr5aH+Pz1wwb6e4 > AfdKjplZhUErBfqVnLMslZez/rKNjXMf9qtlHNxdjo+BPBtwtM7nhm0CCjcxb+2P > GcujFSPzphH/QvEqZij43Vy7DcMoFF4fwlOCcTukgnEFx2zkRt07yLZQ3N3k/J3Z > K1KesXkA4ZNvyxBCR69s6GhNNbUrDtFrdWJWmOJlbiPUqXQx4rxrTC9U6T4zZ7ZV > AlrH6XnyrKZ8o8aAIC2JMyupJjR5JRptxH3CQ3g0Bpc8OK6FOuVvxLfl734+tmfp > KzelTLbeqtLf2LffynB+m3h11MyhtiEaWKtxF8eQsXZW5D6LVYAh53da1+98mEEN > djBh+s/LZwRnoGKeByzWL/3vLO58y75OSZ8epHbA1XIJpIB7bSDOnS99zp0blyYW > dMOo66C6LXHgGYn3Lw2HoGPoZh5123FVjS7fb8TJ7/4nbfLQWW5lpsRz1wSN8qEh > O/XhGVThQftWn03zluLhwjPkIWx8LiU8J1nUyuwgoq9quVzIuyX7SosARYLBOAJ5 > XrOIt2Ei8HRqKvlEbLJcsd9KEdCH4GGRXOov1UxgRbsJZ23L87c= > =KipJ > -END PGP SIGNATURE- > > -- > 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/e8ef9142-778a-a0a2-8312-7dc2570d43d7%40qubes-os.org. > For more options, visit https://groups.google.com/d/optout. > -- 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/CAAXZBW%2Boek7ij57yyYbEaxozDu7Tm006w3SmEd04rTLR2u8p6g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Jan 10, 2018 at 03:19:39AM -0500, Blacklight447 wrote: > I might have some ideas, > > How about intergrating a dispvm as usb qube. The situation now is (to my > knowledge, correct me if I am wrong) that if a usb infects the usb qube, it > means all future usb`s may become infected too once they connect to sys-usb. > By using a dispvm, all traces of malware should be gone the next time it > reboots(or atleast raise the bar of difficulty to make persitent malware) > > I can think of several ways this can be implemented but the question will be > when the usb qube should be rebooted. Everytime a usb disconnects, maybe > everytime the computer reboots? These would be some things to figure out. Well, as for "everytime the computer reboots", it should be trivial in Qubes 4.0, simply create sys-usb with a "DispVM" class and you're good. Please remember that GSoC idea should be a base for "3 months project". If we want more frequent sys-usb restarts (with sensible security), it would require USB controller supporting reset (FLR or similar). Which on current Intel hardware isn't the case :( But, something similar - sys-net restart, could be better project. Many network adapters either support FLR or are connected on separate PCI bus - - which also allow resetting them. So, restarting it more often could be an improvement. And there is definitely more work with this: - solve https://github.com/QubesOS/qubes-issues/issues/1426 (which itself may be 1 month of work or so) - design and implement mechanism to safely store network access credentials (so, DispVM based sys-net couldn't use it for persistent compromise) - add some automation for easily use this feature > My next idea would be to have an option during installation to use a mirage > os unikernel for sys-net or sys-firewall. This would give us severel > advantages over the current fedora sys-nets. Not sure about sys-net (you need device drivers there, and I don't think there are many for mirage os), but sys-firewall is a good idea. There is already implementation of static firewall approach there. We already have this project on the list: https://www.qubes-os.org/gsoc/#unikernel-based-firewallvm-with-qubes-firewall-settings-support > Number one would be ofcourse security, a unikernel has alot less attack > surface because it uses alot less code, this also makes it easier to audit. > Furtermore, less memory useage might be an advantage as well, since you can > run a mirage vm with a mere 30mb of ram(good for users with low end > machines). Another advantage would be faster boot up and shutdown times, > booting a mirage vm on my old thinkpad takes roughly 1/2 seconds. Another project could be MirageOS based split gpg. I've seen on 34c3 someone with very interesting unikernel-based projects, including ssh-agent, some basic GUI support and more. - -- 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/THMrX1ywFAlpWE+wACgkQ24/THMrX 1ywguQgAiySs4lj0M31OiZouvJBvC1nQ47WL7wr+JXrt1NXtspXlzm4X4uwucmdF SJHdkwITXxnEIzfiYTblWAM6Z3ApJbBym59tbmLvoQfyo8YrTQreIid8Iv+X9mnQ qAqGIWPknKiSxZzmc0up7XosqGULv0gmCjIA9l4rwRAmRuZoEZ1aDFzZJyHdlKfz 0CcZ+NAEUC172NBHSoTQQkBWpLKmYO8wvPMvIkMGyeyaEQ+v8a/uDs8v1xK5Mme5 xhmEWvDMDq7dJ3ZGqHEjnXuFm4F6mqM0TeTo5zljeKNH1gy1mwN42X3ZB03Hk3zm oFBbOYGnP3+/tfOjoUbqTW5C0KcXcg== =x8jM -END PGP SIGNATURE- -- 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/20180110132356.GU2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
I might have some ideas, How about intergrating a dispvm as usb qube. The situation now is (to my knowledge, correct me if I am wrong) that if a usb infects the usb qube, it means all future usb`s may become infected too once they connect to sys-usb. By using a dispvm, all traces of malware should be gone the next time it reboots(or atleast raise the bar of difficulty to make persitent malware) I can think of several ways this can be implemented but the question will be when the usb qube should be rebooted. Everytime a usb disconnects, maybe everytime the computer reboots? These would be some things to figure out. My next idea would be to have an option during installation to use a mirage os unikernel for sys-net or sys-firewall. This would give us severel advantages over the current fedora sys-nets. Number one would be ofcourse security, a unikernel has alot less attack surface because it uses alot less code, this also makes it easier to audit. Furtermore, less memory useage might be an advantage as well, since you can run a mirage vm with a mere 30mb of ram(good for users with low end machines). Another advantage would be faster boot up and shutdown times, booting a mirage vm on my old thinkpad takes roughly 1/2 seconds. Anyway these are my ideas of how we could improve qubes. These are all speculations based of my current knowledge and understanding of qubes, so please feel free to correct me if I was wrong somewhere. So, what do you think? Cheers, Blacklight447 -- 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/6rTwWbMuumJb9xh3XYoq-1NJftb8V4HO-zpw78ToJjVzzWE99eVN6LaEGs1CZbG0UvwnEZN8S5JU0WWq3o2TW9CxPdU1MU4H1JMroPQ5N5k%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Invitation to submit ideas for Google Summer of Code (GSoC) 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-09 20:32, Andrew David Wong wrote: > In preparation for Google Summer of Code (GSoC) 2018 [1], we > invite the Qubes community to contribute ideas to the Qubes ideas > list. [2] You can find our 2017 ideas list here: > > https://www.qubes-os.org/gsoc/ > > (This page will be updated for GSoC 2018.) > > Please feel free to submit pull requests against that page or send > replies to this thread. > You should also feel free to start a new thread for your idea, especially if your proposal is a long one, or you'd like to keep the discussion organized in its own thread. > > [1] https://summerofcode.withgoogle.com/ [2] > https://summerofcode.withgoogle.com/rules/ > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpVe9gACgkQ203TvDlQ MDAwBQ//cKI++BRNChtSz6fTOSHm9+e75cVDCiePDETaNIAHvxlpBdrG72VZXVXr UqyO3eUgZAxj3Gq6r7aXL9NUXjyxJlJ/88LPuG9xuc+DI6zruFFLQfhW0TkZEuXn QIyQxTuwHNBqxvRL5m/38rlSThHMkiKMxQN1o/ORzx8OjD4Aty3ndo3IiJuFo3HC PlMHX5zFsGvjJPtBxpoUh4GnYzFIOy/H5ku1xcjru9wItiHz6Ke3zHwhETfqMAWr xjTiNWEygir6Sopskile/9FkBAuR1YkZAF5mSQ7KhIXrSSmrx7pE2kzobIM4Jiwe 1bcqVk2niZ7376T3VIT0vk/8dFlUrDBoVil/CPwT+L9WJcLowdl9QyCj4nPfA+jP yi+TZQxsHllwHa++Dto+Hr44yZ+hge8984b8UHa8+FOkcrPuBfdOYncVnPuZtR45 Evdb96s8NsW4/bff2or+aNV8S/D0TL6GdAEpOVUEeyn75uFGPdE0spBb6VanhBJx C92R5nXKrQOqY/RqqTsNwoiqhrScx9mNcvKAG4ySgMxTstrf7H19VMh+L4jI7Thp t/dNr9a6k9VSmUT/sfonrR0soTCB0pWJCYEQvoLz3dpyXdipiy+QfDTmlnb/nGqx kzRK+sqAknV2qAlTQz/bv/yUYgzzfYoMPPJwWqUvg2tUSOSmEKk= =SL5u -END PGP SIGNATURE- -- 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/abb2e8ce-2099-2298-9074-31c9f8033c05%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
