Re: [qubes-devel] How big the exposed surface of the sys-* VM templates

2016-12-27 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 (*Please* do not create duplicate threads. Copying my reply below.) On 2016-12-27 12:02, 'David Shleifman' via qubes-devel wrote: > One of the great things about Qubes OS is the reduction of the surface > exposed to attacks [1]. The road to achieve

Re: [qubes-devel] Exposed surface of the template used for the sys-* VMs

2016-12-27 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-12-27 11:38, 'David Shleifman' via qubes-devel wrote: > One of the great things about Qubes OS is the reduction of the surface > exposed to attacks [1]. The road to achieve this is discussed elsewhere [2]. > > Individual virtual machines su

[qubes-devel] Exposed surface of the template used for the sys-* VMs

2016-12-27 Thread 'David Shleifman' via qubes-devel
One of the great things about Qubes OS is the reduction of the surface exposed to attacks [1]. The road to achieve this is discussed elsewhere [2]. Individual virtual machines such as sys-net, sys-firewall, and sys-usb indeed limit the exposed surface. In Qubes 3.2 they are based on the Fedora

[qubes-devel] DVD burning - PV SCSI (was: Re: [qubes-users] appVm can't detect blank dvd)

2016-12-27 Thread 'David Shleifman' via qubes-devel
Will PV SCSI support writing backups to a DVD-RAM that is connected to the same SATA controller as the system HDDs? -- 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

[qubes-devel] How big the exposed surface of the sys-* VM templates

2016-12-27 Thread 'David Shleifman' via qubes-devel
One of the great things about Qubes OS is the reduction of the surface exposed to attacks [1]. The road to achieve this is discussed elsewhere [2]. Individual virtual machines such as sys-net, sys-firewall, and sys-usb indeed limit the exposed surface. In Qubes 3.2 they are based on the Fedora t

Re: [qubes-devel] T-shirts at 33C3!

2016-12-27 Thread Vít Šesták
OK, I understand you prefer investing the effort in Qubes to selling T-shirts and I am OK with this. But there are some services (I know https://www.redbubble.com/ , but there might be some others) that do all for you, including T-shirts printing, shipping etc. -- You received this message bec

Re: [qubes-devel] T-shirts at 33C3!

2016-12-27 Thread Wojtek Porczyk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Dec 27, 2016 at 05:20:37AM -0800, Vít Šesták wrote: > Cool. Are you planning to make them available also for those that don't > attend CCC? We don't have specific plans, mainly because of logistic reasons (we have neither have time nor expe

[qubes-devel] T-shirts at 33C3!

2016-12-27 Thread Vít Šesták
Cool. Are you planning to make them available also for those that don't attend CCC? Regards, Vít Šesták 'v6ak' -- 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 q

Re: [qubes-devel] Accessibility on Qubes OS

2016-12-27 Thread Vít Šesták
I asgree. I've realized two potential issues of accessible Qubes: First, VM could try to temporarily DoS dom0 sound output, e.g. by requesting much memory and opening many windows and issuing some expensive RPC calls. This could be an issue when dom0 has to notify something important, e.g. chan

Re: [qubes-devel] Accessibility on Qubes OS

2016-12-27 Thread john.david.r.smith
I'd not depend on VM-not-knowing-the-sound. While it could be achieved initially, I think it will eventually leak into VM. For example when user assign a microphone to a VM. at least the issue of data leaking via microphone could be fixed by disabling microphones during playback. but i gues

Re: [qubes-devel] Accessibility on Qubes OS

2016-12-27 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Dec 27, 2016 at 12:32:01AM +, john.david.r.smith wrote: > > > I agree that filtering the trusted sound is very fragile, especially if you > > don't want to add a latency. I'd say this is virtually no way. > > this problem maybe could b