[qubes-users] Re: Qubes 4 with Grsec could make a big splash
On Tuesday, November 22, 2016 at 8:57:56 PM UTC+2, kev27 wrote: > I saw this being retweeted by the Qubes account on Twitter. Can Grsec support > still land in Qubes 4.0, or should we expect it for 4.1 or 4.2, etc? > > I think if Grsec would be enabled by default in Qubes, it would be no > question that Qubes is the most secure operating system out there. Forgot to add the link: https://twitter.com/coldhakca/status/801107979126784000 -- 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/a42439da-ce7a-4909-9439-94929aef9f50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4 with Grsec could make a big splash
I saw this being retweeted by the Qubes account on Twitter. Can Grsec support still land in Qubes 4.0, or should we expect it for 4.1 or 4.2, etc? I think if Grsec would be enabled by default in Qubes, it would be no question that Qubes is the most secure operating system out 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/fda0358a-0bbc-4d69-a607-1cf03c4f3289%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [Qubes R3.1] Installation problem: "NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s!"
On Saturday, May 14, 2016 at 1:48:37 PM UTC+3, Danny Eagle wrote: > Full error message: > [5578494253.737246] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! > [NetworkManager: 1057] > > After choosing "Install Qubes" option this message pops up. > I'm installing it on desktop not laptop. > > If i take "Check hardware and install Qubes" I get to second window and it > freezes. Same bug here. Sometimes it says CPU#2, sometimes CPU #5. I algo get [Xorg 1224] at the end. It's a more recent Asus laptop with Core i7 6700HQ (Skylake) CPU. I should also mention that when I get the installation menu it says "processing" for installation source, and when I select it, it only gives me options for DVD, local iso, an network install - but I'm trying to install from a USB. What's up with that? The installation did boot from the USB and I chose DD mode in Rufus. -- 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/bc13c28b-98b8-4095-8e53-248bdeba35db%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Thoughts on Qubes OS Security... Could be improved.
On Saturday, November 12, 2016 at 5:21:18 AM UTC+2, Sec Tester wrote: > So Im still new to Qubes, but after going through a bit of a learning curve, > building & customizing VM's to suit my security needs, I have a few thoughts > on its security. > > Firstly I really love the direction Qubes has taken the future of operating > systems, and its has definitely become my OS of choice. > > HOWEVER, i feel that Qubes OS relies HEAVILY on ONE security mechanism > > Isolation. > > There are 2 ways we can improve security > > 1. But adding layers of protection. > 2. By reducing the attack surface area. > > > Layers of protection > > In regards to layers of protection, IMO Qubes only has one. By isolating VM's > if a system is infected, it has to breach that VM & gain access to dom0, > where it then has total control of the system. > > The problem is in the current configuration, there is nothing to stop a > hacker or malicious software from running, manipulating VM system files, or > downloading additional hack tools/scripts to attempt to breach into dom0. > > To basic extra layers of protection missing from Qubes that usually hardens > Linux security are; > Password protected root access on VM's > SELinux or AppArmor. > > I have read Qubes excuse for NOT requiring a password for root access in VM's > https://www.qubes-os.org/doc/vm-sudo/ > > I frankly think saying "its highly unlikely if that person (who could breach > a VM to dom0) couldn't also find a user-to-root escalation in VM" as a very > LAZY justification. > > They have basically said, Elite hackers can gain root, so lets just not even > bother with this foundational layer of security. > > So we have VM's where any script kiddies code can run riot. This to me is > over confidence in VM isolation, and a lax attitude because, hey if your > infected you can just reboot & VM is clean again right? Except the infected > files sitting in the home directory, just waiting to be opened again and run > with root permissions. > > And in the example of a server VM, that system may rarely be rebooted very > often? Infecting the system to infect others that connect to that server. NOT > GOOD. > > From what i've read SELinux isn't running do to some compatibility errors, > and because there is no point when the whole system has root access. Well > lets lock down default VM root access, and lets find a way to make SELinux > work in Qubes VMs & even dom0, or possibly AppArmor. Or maybe we need a > totally new piece of software that is Qubes specific. > > The more layers of security in the system the better. > > > Reducing the attack surface area > > Qubes OS through the use of dom0 has reduced the attack surface area of the > kernel, which is good. > > However, where i think Qubes could improve right out of the box, is having > dedicated minimized templates for sys-net & sys-firewall. > > I spent time setting up fedora-23-minimal templates specifically for sys-net, > sys-VPN, banking, email & browsing. I plan to make another for sys-firewall > soon. VM's that have the minimal amount of programs on as possible, reduce > the attack surface, and possible exploits. > > Again SELinux not only adds a layer of protection, it also reduces the attack > surface area vulnerable in the system. > > = > Finial suggestion > = > I would like to see the option to setup a decoy OS in the installation > procedure, similar to true crypt/Veracrypt. > > These days many countries airport security can force you to turn on your > laptop to be inspected, and while i imagine airport security being very > confused by Qubes haha, It would be nice to not have to show them any secure > files. > > Another approach could be decoy VM's (as opposed to another entire decoy > Qubes OS), that boot into different encrypted VM's depending on the password. > == > > I do think the Qubes OS team are doing a great job. And i hope they maintain > a security based focus, and not depend solely on isolation. I'd also rather see Grsecurity. But if for whatever reason that's not possible, both legally (I think Grsec guys require an all or nothing adoption) or technical (Subgraph guys were complaining about Qubes not being compatible with part of Grsecurity), then at least I hope all the security features being introduced into the Linux kernel in the future from the Kernel Self-Protection project, will be adopted and implemented by default by Qubes. I don't know if this is possible with the new management in Qubes 3.2, but what I'd like to see in the immediate future is the possibility to configure some apps and sandboxes ahead of time - like for DispVMs. For instance, let's say I want to see Chromium in a DispVM. I would like to always open DispVM with Chromium sandboxed by Firejail. I wouldn't want
[qubes-users] Qubes OS 4.0 + Wayland + Flatpaks - Can Qubes OS 4.0 become Wayland-only?
I know Joanna has long talked about how insecure X11 is and how the Qubes team worked to isolate the GUI. Wouldn't it be simpler if Qubes became Wayland-only sooner? It seems Fedora 25 will enable Wayland by default [1], but I think it will still have a XWayland layer for app compatibility. Will Qubes need that, too? Or can it become Wayland-only by the time Qubes OS 4.0 is out? Are there still too many components in the Fedora core that need X11 and can't be transitioned to Wayland anytime soon? Also, since flatpaks [2] will take full advantage of Wayland security, and it seems to be the app packaging format to take security seriously the most [3][4][5], maybe encourage flatpak use in Qubes 4.0 somehow, and install its runtime by default in Qubes 4.0? [1] https://linux.slashdot.org/story/16/08/20/0341200/fedora-25-to-run-wayland-by-default-instead-of-xorg-server [2] https://wiki.gnome.org/Projects/SandboxedApps [3] http://flatpak.org/press/2016-06-21-flatpak-released.html [4] https://blogs.gnome.org/uraeus/2016/06/21/fedora-workstation-24-is-out-and-flatpak-is-now-officially-launched/ [5] https://mjg59.dreamwidth.org/42320.html -- 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/a11d3f8b-8234-4ffa-ab11-9a3b1e4f0798%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AMD Zen Secure Encrypted Virtualization (SEV)
On Saturday, August 20, 2016 at 6:05:39 PM UTC+3, J. Eppler wrote: > Hello, > > till now the argument of Qubes OS was that there are no laptops with AMD > CPU's or APU's which Qubes OS can run on. > > Qubes OS primary focus is on laptops and than on workstations. > > Qubes OS uses Xen to isolate "qubes" (vms) from each other. Xen can run on > AMD, Intel, ARM and other platforms. Therefor Qubes itself is not dependent > on the hardware itself. Qubes depends on certain virtualization extensions > like Second Level Address Translation (SLAT), CPU virtualization extension > and IO-Virtualization (IOMMU). AMD has all those virtualization features. So, > in theory Qubes OS could run on AMD chips. > > The problem till now was that AMD was not producing any hardware which was > able to compete with Intel's quasi mono pole. This changed with this weeks > AMD Zen announcement. The next question is: when does AMD Zen CPU's will > appear in laptops? > > The next question is, will AMD offer SEV support for consumer CPU's? I thought I read somewhere that Qubes is moving to hardware-enabled virtualization, though? Zen laptops were supposed to arrive first half of 2017, but I think they got delayed to second half of 2017 now. So yeah, it will be a while until enough people have these. But a Qubes/OEM partnership could still make them relevant sooner. I don't know if ZEV will be in all consumer chips, but considering SGX is in Skylake+ now, I would hope so. AMD does seem to target this at "cloud companies" in their paper, though...I'm sure we'll find out more about it by early next year. -- 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/49209c97-8797-46f6-bbde-edac01c9d918%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AMD Zen Secure Encrypted Virtualization (SEV)
On Friday, August 19, 2016 at 10:44:53 PM UTC+3, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2016-08-19 11:58, kev27 wrote: > >> Secure Encrypted Virtualization (SEV) integrates main memory encryption > >> capabilities with the existing AMD-V virtualization architecture to > >> support encrypted virtual machines. Encrypting virtual machines can help > >> protect them not only from physical threats but also from other virtual > >> machines or even the hypervisor itself. SEV thus represents a new > >> virtualization security paradigm that is particularly applicable to cloud > >> computing where virtual machines need not fully trust the hypervisor and > >> administrator of their host system. > > > > http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/ > > AMD_Memory_Encryption_Whitepaper_v7-Public.pdf > > > > https://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf > > > > Is this something Qubes OS could work with in the future to improve its > > security on AMD Zen chips? Maybe something to keep an eye on. > > > > Sounds very interesting! This reminds me of what Joanna has written about > Intel SGX.[1][2][3] FWIW, however, Joanna has also said: > > "We don't have much experience with AMD: neither research- nor testing-wise. > Right now we have no resources to get acquainted."[4] > > I imagine that could be relevant to this. > > > [1] http://blog.invisiblethings.org/2013/08/30/thoughts-on-intels- > upcoming-software.html > [2] http://blog.invisiblethings.org/2013/09/23/thoughts-on-intels- > upcoming-software.html > [3] http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf > [4] https://twitter.com/rootkovska/status/756052459752128512 > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJXt2GHAAoJENtN07w5UDAwLuQP/3IkhRVoHpTogM4u5hUpzig+ > ni7T69i8FQ5cfbqRQKZa60TY4TAwaWUUKMyAOkUb8gnO9NEFOXHspV8S4kowWq3C > j1OvVrq/DjucsqTchcwVo1x6K+WJsES+Bn92B253YCfmRllYNsGf7Zeolcd0uyVE > 6w6qSkWuoPTjOmdXCHWBllreDh2LlVvgL3FF7207TLRTEjV8BGPFndFzZ8NfNGSx > 6F4Ss7X/WLi0XmA3asJXofOr9piOM3D86sy6W8yK8q1OosbO+WQFAlVrtruoh6FZ > WBhurvmix2Yj9TGOyFvdTBDG+ctybBrA3VatwJT7pcjIZvSKp6BW6h9P7rGAg+af > AvW+UKJFsPD72meS3jyrKNICbz+tAajHCAL4eVF9wltS/zighuWBoIpAugOwxHWu > rIfdN9hmtkPtG7uc/IeJP5utq9GpsbcuN3BjB79dPRrAqGrylriHa4hUGPloSutO > OmXyq9YQW2C+FxLLFcAlfenxZZh1Umg+APPN0IqDjfBdKUS3oOYKJIP0YO0SDJYF > CIZcQRiTs0O/JuKfqGddMU5QzzdWJx5Z2mVV2oTp5ed2sjl1KYYWLAg0gc73mSYB > jcyWeeFvOJiz3csoBobOTh4eLBXJXd/Nzskki5WxOl6qYB7xSi4Vle1qnOels4vz > 2NgLEVxsaJGJSZvJ72FJ > =uIAV > -END PGP SIGNATURE- Well, by the time enough people have Zen machines, it would've passed 2-3 years anyway. So this was more of a heads-up. I understand there's a lack of resources for a project such as Qubes OS, but Intel's monopoly with regular consumers is bad enough and no need to make it worse with Intel exclusivity for Qubes. Perhaps in a few years Qubes will have the resources to support AMD machines, too. Or if there's a new Librem-like partnership between Qubes and some other OEM, the Qubes team can encourage the use of AMD Zen instead. That would mean they get funded for researching AMD's architecture, and at the same time gain enough knowledge for working for AMD chips. -- 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/6050c08c-b67e-462e-9f45-92d690bc7880%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] AMD Zen Secure Encrypted Virtualization (SEV)
> Secure Encrypted Virtualization (SEV) integrates main memory encryption > capabilities with the existing AMD-V virtualization architecture to support > encrypted virtual machines. Encrypting virtual machines can help protect them > not only from physical threats but also from other virtual machines or even > the hypervisor itself. SEV thus represents a new virtualization security > paradigm that is particularly applicable to cloud computing where virtual > machines need not fully trust the hypervisor and administrator of their host > system. http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf https://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf Is this something Qubes OS could work with in the future to improve its security on AMD Zen chips? Maybe something to keep an eye on. -- 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/af69cf92-c19b-4b88-8676-613713c33b38%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
