Thoughts on Qubes OS Security... Could be improved.
Sec Tester
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.
Sec Tester
===================
Looks like the DRAMA attack would require root access in VM, to compromises Qubes shared memory
"taskset 0x2 sudo ./measure -p 0.7 -s 16."
https://groups.google.com/forum/#!topic/qubes-users/qAd8NxcJB3I
=====================
I thought of a possible persistent attack vector, that would survive even after rebooting the VM.
If malware wrote its self into rw/config/rc.local it could reinfecting the system every restart.
===================
=======================
Also today i used the CLI command to move files between VM's
"qvm-copy-to-vm"
a dom0 prompt seems to be the only thing stopping an attacker spreading malicious code across the whole machine, including templates.
Using the DRAMA attack to Authorize, bypass or spoof permission to transfer malware across the entire system.
A VM root password would just add that extra layer of prevention.
===================
All of these attacks could be mitigated with a password for root access in VM.
SELinux policies could also limit directories being read & written to.
Im still studying Qubes OS tho. Perhaps there are existing security features in qubes im unaware of that prevent these attacks without requiring a VM root password?
Marek Marczykowski-Górecki
Hash: SHA256
On Fri, Nov 11, 2016 at 07:21:18PM -0800, 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.
can easily run it also as root, because of tremendous attack surface of
linux kernel and all the services running as root. In the worst case one
needs some patience and simply wait for you to authorize some command to
be ran as root (regardless of authorization method - password, qrexec
confirmation as described on https://www.qubes-os.org/doc/vm-sudo/ or
anything else). In the simplest case one may alias 'sudo' to for
example 'sudo /tmp/my-evil-script'.
On the other hand, making it harder to execute arbitrary code in the VM
(reducing attack surface) makes sense. Things like SELinux, AppArmor,
seecomp filters etc.
Take a look at SubgraphOS + QubesOS thread here for more details:
https://secure-os.org/pipermail/desktops/2015-October/000002.html
> 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.
root, so having passwordless root is somehow orthogonal to
SELinux/AppArmor.
> 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.
somehow limited by installation image size. Now it barely fits on DVD
(which also means a lot to download). Adding another Linux-based
template means another few hundreds MBs.
Using unikernel may help here (see MirageOS for firewallVM). It is still
not mature enough to have it in default installation, but I hope it will
be some day. It's hard to do the same with sys-net, because the need for
all the hardware support...
> =================
> 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.
installation image. In some cases this may be even harmful, see here:
https://groups.google.com/d/msgid/qubes-devel/80a370cd-7868-5c2a-e0ff-c9b05a569f10%40gmail.com
> ==================
>
> 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.
> Also today i used the CLI command to move files between VM's
>
> "qvm-copy-to-vm"
>
> a dom0 prompt seems to be the only thing stopping an attacker spreading
> malicious code across
> the whole machine, including templates.
immediate target compromise if you copy a file there. For example files
are always placed in directory named after source VM name. I hope it's
obvious enough to not blindly click on files from
"QubesIncoming/untrusted" directory in your template...
We even consider getting rid of this confirmation in file copy at all:
https://github.com/QubesOS/qubes-issues/issues/2280
> Using the DRAMA attack to Authorize, bypass or spoof permission to
> transfer malware across the
> entire system.
>
> A VM root password would just add that extra layer of prevention.
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYJ1J5AAoJENuP0xzK19csSoYH/0OeKyNOVahyWraOcz4frAlz
KM7A1HLtMk4RlQg8UhFGqzpDtCzX3CiFe/b8ca5gDybG3n8CAN0mCuf/lJlOA8wN
ROba9cIiAZcmjVkNM9xq0hGHrnSNQ40+i4KgNlpbjMCEnvnGSBu5rihwUQhTAJRp
zVG+sR1rr3pmIY4CS3LpU0SphBLLFsvGaZRlH3p0GBJRvTcix3Cg4A+xt4xTYh9J
V5Ix5mgmWSh52OfM+lt3D3pOw2oLtUV3N4nBcUPHroDy4wWuWNkLTh6fGezoYEb5
zqXI6qT+yst8jA5XWUA6wL3poQ5nRYOO/Lv5KZNt5ofMVfm2PGtychgXoTLQLVU=
=tm7H
-----END PGP SIGNATURE-----
Chris Laprise
> 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'shttps://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.
ITL de-emphasized kernel-based security.
If they had kept it as a supported security layer, the
"security-in-depth" mindset would have dominated most of our discussions
and attention... essentially eaten our brains like it does to everyone
else. Seriously, this stuff can be perniciously misleading, and the
moment that "authoritative" voices in the community start looking down
their noses at "dinky little 1MB hypervisor" compared with their heavy
bookshelves full of standard admin guides and certifications... that's
when the security zombies start encroaching.
Therefore, I think it is up to the community to promote the Linux extra
security measures as a kind of add-on. Enabling it could be a good thing
IF and only if we can do it with minimal effort and distraction. But
keep it far away from pre-installed or supported status.
> 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.
Even so, the attackers have to find an exploit for the apps you're
using. The apps are already designed by default not to grant access. But
they have large surface area and Linux could help reduce it somewhat.
Throwing a chair in the path of your attacker (and warding off the
percentage of attackers that can't deal with chairs) is a good thing.
> 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.
get enthusiastic about it.
> ================================
> 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.
low. I don't think it really sacrifices any security to share a template
with sys-net.
Chris
Sec Tester
>On Sunday, 13 November 2016 03:33:50 UTC+10, Marek Marczykowski-Górecki wrote:
> > They have basically said, Elite hackers can gain root, so lets just not even bother with this foundational layer of security.
>
> The point is _if_ someone is able to run arbitrary code as user, he/she
> can easily run it also as root, because of tremendous attack surface of
> linux kernel and all the services running as root. In the worst case one
> needs some patience and simply wait for you to authorize some command to
> be ran as root (regardless of authorization method - password, qrexec
> confirmation as described on https://www.qubes-os.org/doc/vm-sudo/ or
> anything else). In the simplest case one may alias 'sudo' to for
> example 'sudo /tmp/my-evil-script'.
> On the other hand, making it harder to execute arbitrary code in the VM
> (reducing attack surface) makes sense. Things like SELinux, AppArmor,
> seecomp filters etc.
> Take a look at SubgraphOS + QubesOS thread here for more details:
> https://secure-os.org/pipermail/desktops/2015-October/000002.html
Definitely adds those extra layers of protection i was talking about. I hope Qubes consider this in the future.
> Yes, this mostly makes sense. As for out of the box configuration we're
> somehow limited by installation image size. Now it barely fits on DVD
> (which also means a lot to download). Adding another Linux-based
> template means another few hundreds MBs.
> Using unikernel may help here (see MirageOS for firewallVM). It is still
> not mature enough to have it in default installation, but I hope it will
> be some day. It's hard to do the same with sys-net, because the need for
> all the hardware support...
Could the install process not compile a minimal templates from the standard fedora-23 template?
This might add significant time to the install, but could be a tick box option, with a note about extra time.
>
> Again - this may be useful for some, but not as part of default
> installation image. In some cases this may be even harmful, see here:
> https://groups.google.com/d/msgid/qubes-devel/80a370cd-7868-5c2a-e0ff-c9b05a569f10%40gmail.com
> The file copy protocol is specifically designed the way to avoid
> immediate target compromise if you copy a file there. For example files
> are always placed in directory named after source VM name. I hope it's
> obvious enough to not blindly click on files from
> "QubesIncoming/untrusted" directory in your template...
If so then an attacker may try to infect the users ligitmate files with a Parasitic virus, that will be copied & opened at some point.
My point is this kind of activity can currently go on inside our VMs unopposed. There are currntly no preventative layers of security inside VMs. Which is the perfect enviroment to execute attacks on dom0, or infect user & system files.
> We even consider getting rid of this confirmation in file copy at all:
> https://github.com/QubesOS/qubes-issues/issues/2280
IMO if people want a "windows" experience where everything runs as admin, and security is dropped in the name of convince, then they belong on windows.
The demographic that are interested in Qubes OS are security & privacy focused. Honestly if things could transfer between VMs without authorization, then what is the point of even having seperate VMs? and thus even running Qubes?
========================
Hi Chris,
> Its easy to enable apparmor. See the Whonix documentation about this.
>
> Therefore, I think it is up to the community to promote the Linux extra
> security measures as a kind of add-on. Enabling it could be a good thing
> IF and only if we can do it with minimal effort and distraction. But
> keep it far away from pre-installed or supported status.
Say a check box in the VM settings that let dom0 know this VM needs a password before trying to update it.
> I will say this is fair.
>
> Even so, the attackers have to find an exploit for the apps you're
> using. The apps are already designed by default not to grant access. But
> they have large surface area and Linux could help reduce it somewhat.
> Throwing a chair in the path of your attacker (and warding off the
> percentage of attackers that can't deal with chairs) is a good thing.
I read a whitepaper that showed just by NOT running the windows user account with admin privileges, 85% of attacks were defeated.
The vast majority of hackers are script kiddies, any obstacle unaccounted for breaks their script. Only something like 5% of hackers are good enough to find and exploit zero day vulnerabilities.
Is it really too much to ask to want VMs with at least the option to enable root passwords? I think if i tried to enable it now, i would break Qubes functionality in some way..
>
> IIRC, SELinux isn't held in high regard these days. Doubt people will
> get enthusiastic about it.
>
> When you think about what a dedicated firewall does, the risk is very
> low. I don't think it really sacrifices any security to share a template
> with sys-net.
But as mentioned before, i do get install size is an issue. So maybe the installer compiling minimal templates from the full template could solve that?
Or have preconfigured & ready to download dedicated minimal templates for sys-net sys-firewall and even a sys-OpenVPN would save some time.
Chris Laprise
packages needed to create a desktop-friendly template... alongside the
minimal template. This would take a *little* extra time during installation.
Another option would be to simply provide a script that purges all the
packages that are unneeded for a minimal template.
>> Again - this may be useful for some, but not as part of default
>> installation image. In some cases this may be even harmful, see here:
>> https://groups.google.com/d/msgid/qubes-devel/80a370cd-7868-5c2a-e0ff-c9b05a569f10%40gmail.com
> I agree that this doesn't need to be an out of the box feature. But would be nice to be able to implement. glad to see issue has already been raised.
>
>> The file copy protocol is specifically designed the way to avoid
>> immediate target compromise if you copy a file there. For example files
>> are always placed in directory named after source VM name. I hope it's
>> obvious enough to not blindly click on files from
>> "QubesIncoming/untrusted" directory in your template...
> So QubesIncoming container makes self executing code impossible? eg worms etc
> If so then an attacker may try to infect the users ligitmate files with a Parasitic virus, that will be copied & opened at some point.
>
> My point is this kind of activity can currently go on inside our VMs unopposed. There are currntly no preventative layers of security inside VMs. Which is the perfect enviroment to execute attacks on dom0, or infect user & system files.
>
>> We even consider getting rid of this confirmation in file copy at all:
>> https://github.com/QubesOS/qubes-issues/issues/2280
>
> CRAZY.
> IMO if people want a "windows" experience where everything runs as admin, and security is dropped in the name of convince, then they belong on windows.
>
> The demographic that are interested in Qubes OS are security & privacy focused. Honestly if things could transfer between VMs without authorization, then what is the point of even having seperate VMs? and thus even running Qubes?
about enabling the prompts over and over for VMs that are created, and
there is no way to guarantee that 'certain' VMs have integrity to do
this by default.
> ========================
> Hi Chris,
>
>> Its easy to enable apparmor. See the Whonix documentation about this.
>>
> I will have a look thanks. I have read that AppArmor isnt as robust as SELinux, but IMO an extra layer of security is better than none.
>
>> Therefore, I think it is up to the community to promote the Linux extra
>> security measures as a kind of add-on. Enabling it could be a good thing
>> IF and only if we can do it with minimal effort and distraction. But
>> keep it far away from pre-installed or supported status.
> Well how hard is it really to at least provide the option of root password protection for VM's?
>
> Say a check box in the VM settings that let dom0 know this VM needs a password before trying to update it.
suddenly Qubes is in the business of managing users & passwords. And....
can you make them all the same pwd? I wouldn't. Maybe passwords could be
random (and automatic) but then you have to lookup pwd in dom0 to run
sudo in domU (maybe that's not so bad).
So now you know why Joanna's tone gets very dire and insistent when she
reports Xen vulns: The hypervisor is *the* way Qubes does security, by
design and rightly so.
>> I will say this is fair.
>>
>> Even so, the attackers have to find an exploit for the apps you're
>> using. The apps are already designed by default not to grant access. But
>> they have large surface area and Linux could help reduce it somewhat.
>> Throwing a chair in the path of your attacker (and warding off the
>> percentage of attackers that can't deal with chairs) is a good thing.
> The "chair" from my reading actually Stops the Majority of attacks.
>
> I read a whitepaper that showed just by NOT running the windows user account with admin privileges, 85% of attacks were defeated.
Maybe defeating 99% of attacks isn't good enough, because you only need
*one* privilege escalation from a field of dozens.
> The vast majority of hackers are script kiddies, any obstacle unaccounted for breaks their script. Only something like 5% of hackers are good enough to find and exploit zero day vulnerabilities.
>
> Is it really too much to ask to want VMs with at least the option to enable root passwords? I think if i tried to enable it now, i would break Qubes functionality in some way..
>
>> IIRC, SELinux isn't held in high regard these days. Doubt people will
>> get enthusiastic about it.
> Can you link me some research showing SELinux to be ineffective. Obviously it only as effective as its profile policies have been setup. But custom ones can be made.
habit started forming where many howtos started with "Disable SELinux
then type....". High annoyance factor, especially for a PC and the
defaults were known to break a lot of apps.
Also, SElinux close association with American NSA makes some people
squeamish.
>
>> When you think about what a dedicated firewall does, the risk is very
>> low. I don't think it really sacrifices any security to share a template
>> with sys-net.
> If they were using minimized templates i wouldnt mind so much. But they are using the full fedora-23 template.
>
> But as mentioned before, i do get install size is an issue. So maybe the installer compiling minimal templates from the full template could solve that?
>
> Or have preconfigured & ready to download dedicated minimal templates for sys-net sys-firewall and even a sys-OpenVPN would save some time.
add desktop packages to a minimal template could work well as an option
(or a script to cut-down a desktop template).
Chris
Sec Tester
> > This might add significant time to the install, but could be a tick box option, with a note about extra time.
>
> I think a better practice along these lines is to supply the additional
> packages needed to create a desktop-friendly template... alongside the
> minimal template. This would take a *little* extra time during installation.
>
> Another option would be to simply provide a script that purges all the
> packages that are unneeded for a minimal template.
>
Good suggestion. A script that shrinks templates into minimals. I like this idea. A script could then also create a min debian template too.
I just had a look inside the Qubes-R3.2-x86_64.iso
I found the templates under packages/q
I wonder if a script could also be used to turn a whonix-ws into a whonix-gw or vise versa. This could reduce the size of the Qubes.iso by about 500mb. making more room for other goodies.
Marek Marczykowski-Górecki
Hash: SHA256
and whonix-gw - given some not-so-big additional local packages
repository. Search for "apt-get install whonix" on
phabricator.whonix.org. This is on the roadmap, but there are also much
more higher priority tasks...
- --
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-----
Version: GnuPG v2
gKwMcFES8udRYCJa2Q72Alxt5M+oUZHhfBQZxU8O7qGogtenQru9Rc8VlbI5guGl
Wp7wTg0GSWOuRfwaNu8Hp6jcKF+Lx7VU9ILE53ga8r904EK25ccXUjLyW7H+oAmy
MwsC77oYbgbWY47fROJoH8RM42t5Yl2y5sUX5zDB9GrlUJq3fkTOgSYZZsdl6nun
GG1KNPKxkPPS7HdWLZ1kIvp3GVUKYReC4eIWoutkXP0RsR5iHDOxV+vHMIqPxbv+
ATnvKVqcSZFroEOvVkDNk8lYpAAP3/oN8LOGB+MhQhVlWmU5zZ2vFfuMpPyyP3c=
=JQbf
-----END PGP SIGNATURE-----
Manuel Amador (Rudd-O)
> SELinux or AppArmor.
SELinux would be absofuckinglutely great. Confined apps like Firefox
would run much more securely.
I got one DispVM owned by an attacker at Defcon in 2014. Isolation was
nice to have because the machine didn't get owned, but the VM would have
never been owned if SELinux had been active.
--
Rudd-O
http://rudd-o.com/
Eric
Why not grsecurity/PaX? especially with Qubes 4 switching to HVM (or PVHv2 or whatever it's called now), it will apparently work fine.
Sec Tester
> Why not grsecurity/PaX? especially with Qubes 4 switching to HVM (or PVHv2 or whatever it's called now), it will apparently work fine.
Nice suggestion. I would certainly welcome its implementation.
Actually looks like there were successful efforts to implement this back in 2013.
https://groups.google.com/forum/#!topic/qubes-devel/l5mi2dklu18
Seriously, why didnt qubes pick this up and run with it?
Marek Marczykowski-Górecki
Hash: SHA256
https://github.com/coldhakca/coldkernel/issues/35
- --
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-----
Version: GnuPG v2
AxXqrX9bt43xyA6dQja6v4xwXJgR1V7XocwNfcQYhba8sl3c26KTVCZ5c3nqYkf4
5hISr04mzqvAlQZqpsDV892l4Z9sWmdkNOqrYhW62hVMJ0aDLm3/PR0MFjHtHyrN
0S7X3GqM4fPQhfHgxI7sW1Ox+qVecL+9jlaZcZcxQ/E6dLkmsYIzWlQTtRCLD/Ma
Bj4vaXydJSwNOA+hH0vgzhFWjPNepyRJhONj7g5rzoOb54GRr1XngaMRcamRBSXN
gMwnWhE9HwNh8f/53OgjDWATp+DjYjAfJm1dmsqEC0sXGcHiD4Yf0b5iN9zDW7U=
=EEHE
-----END PGP SIGNATURE-----
Manuel Amador (Rudd-O)
>
> That was my first reaction, too. But years later, I am so, soooo glad
> ITL de-emphasized kernel-based security.
>
> If they had kept it as a supported security layer, the
> "security-in-depth" mindset would have dominated most of our
> discussions and attention... essentially eaten our brains like it does
> to everyone else. Seriously, this stuff can be perniciously
> misleading, and the moment that "authoritative" voices in the
> community start looking down their noses at "dinky little 1MB
> hypervisor" compared with their heavy bookshelves full of standard
> admin guides and certifications... that's when the security zombies
> start encroaching.
>
> Therefore, I think it is up to the community to promote the Linux
> extra security measures as a kind of add-on. Enabling it could be a
> good thing IF and only if we can do it with minimal effort and
> distraction. But keep it far away from pre-installed or supported status.
adds security, so it is better than not enabling it. The only question
is what sort of usability problems it can carry. But something that
will prevent, say, Firefox from doing arbitrary shit when owned, that
would be absolutely great.
--
Rudd-O
http://rudd-o.com/
kev27
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 to configure that everytime I open a Dispvm, or any other VM.
The argument against this may be "why bother with that when DispVM will be discarded in minutes to hours anyway?"
Well, first, I'd like the extra protection even within DispVM. As the op said, you could still get VM-escaping exploits in that root-enabled environment.
Second, if I have a Personal VM, and a Work VM, a banking VM, and an Others VM, I'd have to configure Firejail for all of them, too. I'd prefer I'd do it only once. But I guess it wouldn't be THAT much of a hassle if I only had to do it four times once.
I'd still prefer to be able to configure it for DispVM, though. Because I'd probably want more than just Firejail configured. So I'd need a way to configure everything so I can use that configuration for all future DispVMs.
Grzesiek Chodzicki
Marek Marczykowski-Górecki
Hash: SHA256
> W dniu poniedziałek, 14 listopada 2016 21:25:32 UTC+1 użytkownik Marek Marczykowski-Górecki napisał:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Mon, Nov 14, 2016 at 02:44:40AM -0800, Sec Tester wrote:
> > > >
> > > > Why not grsecurity/PaX? especially with Qubes 4 switching to HVM (or PVHv2 or whatever it's called now), it will apparently work fine.
> > >
> > > Nice suggestion. I would certainly welcome its implementation.
> > >
> > > Actually looks like there were successful efforts to implement this back in 2013.
> > >
> > > https://groups.google.com/forum/#!topic/qubes-devel/l5mi2dklu18
> > >
> > > Seriously, why didnt qubes pick this up and run with it?
> >
> > There is ongoing work on this:
> > https://github.com/coldhakca/coldkernel/issues/35
>
default.
- --
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-----
Version: GnuPG v2
WuSgLRbOy7PcaGn+t0Tgh91mnXr60Jfdy2kkeCV2bsVaU/3aS29EfAcPFKAwxfVd
SVZtI+j0ln6Ct3QPVOzYlXVJHAj8cANVy/uYHsl85Ax1j0w1YRaZx9NInZorky7l
17WBXUvs/SBajMTNvkJf+8W8mdTI9yOZ8nwEWYLJ8AKamGdS2ttBNFyjB6eSJkup
PtoP2/6XJqGKbA6BChWgKFNrJKVoFoFJWM/Vlf9TTG2+JXC7a+nNyMO7nz/3zCfA
hDc1hwThNmkBIvjVQEsg3i23+dZcQo1yhdopruItNlz4kAe+M81PXe51DphOKV4=
=sYtJ
-----END PGP SIGNATURE-----
raah...@gmail.com
you can use apparmor too to harden your browser alongside grsec. It is prepackaged for whonix vms so you can refer to their Qubes install instructions on how to install it on debian. We would then have to make sure kernel accepts apparmor but most by default do. although in Qubes all these protections are not as meaningful as a baremetal os I still think they are still useful in ways. definitely helps not having to compile or configure anything yourself to use it, if it is considered ok and safe for official repo.
I still think alot of main security boils down to how many programs/services you have running at one time, and how many listening on network. Thats where compartmentalization helps as well.