philosofy on qubes and other environment

121 views
Skip to first unread message

pleo...@gmail.com

unread,
Oct 15, 2016, 12:14:44 AM10/15/16
to qubes-users
philosofy of qubes is that you are safe when your app is isolatet.This is wrong just keep app in sandboxes or jails and what wrong can be happen?

pleo...@gmail.com

unread,
Oct 15, 2016, 12:18:52 AM10/15/16
to qubes-users
yep i know someone exploit ur app and take control on ur environment.. but ... if app is in sandbox then he cant take any control on system bcs its a jail or sanbox.

pleo...@gmail.com

unread,
Oct 15, 2016, 12:26:53 AM10/15/16
to qubes-users, pleo...@gmail.com
And if there is some kind of exploaitaion so the secure system should not been build on the same topology as its qubes bcs of chain exploits.So this system under security measures dont have any value ... bcs its build on the same linux topology ... someone brake 1 pcs brake on chain logic whole environment.

better way for secure environment is mix topology than duplicate or clone them.

raah...@gmail.com

unread,
Oct 15, 2016, 7:19:50 AM10/15/16
to qubes-users, pleo...@gmail.com
On Saturday, October 15, 2016 at 12:14:44 AM UTC-4, pleo...@gmail.com wrote:
> philosofy of qubes is that you are safe when your app is isolatet.This is wrong just keep app in sandboxes or jails and what wrong can be happen?

I think its more like you can never be 100% safe lol. sanboxes are jails is a form of isolation no? Qubes just takes it to the extreme level.

pleo...@gmail.com

unread,
Oct 15, 2016, 7:33:40 AM10/15/16
to qubes-users, pleo...@gmail.com
in AppVM is the same topology sys so its posible chain logic atack.1 break exploit get down and other vms have the same system so its like domino.Multiple topology can solve this.

pleo...@gmail.com

unread,
Oct 15, 2016, 7:35:47 AM10/15/16
to qubes-users, pleo...@gmail.com
i realy think that is more safer Ubuntu apparmored than this qubes OS.

prance...@sigaint.org

unread,
Oct 15, 2016, 7:58:35 AM10/15/16
to pleo...@gmail.com, qubes-users
> i realy think that is more safer Ubuntu apparmored than this qubes OS.
Could you expand on this? I would have thought the attack surface for an
exploit to escape a vm in qubes (xen + qubes) is a lot smaller than the
attack surface for privilege escalation in ubuntu (apparmored or no).

pleo...@gmail.com

unread,
Oct 15, 2016, 9:04:49 AM10/15/16
to qubes-users, pleo...@gmail.com
you never break armored ubuntu,this is fact... dont try be einstein to know some way to do this.No way.

pleo...@gmail.com

unread,
Oct 15, 2016, 9:08:07 AM10/15/16
to qubes-users, pleo...@gmail.com
rather faster is find a way to break this qubes bcs users of this has hypoteticaly meaning that his system is unbrakable.

raah...@gmail.com

unread,
Oct 15, 2016, 12:33:56 PM10/15/16
to qubes-users, pleo...@gmail.com
On Saturday, October 15, 2016 at 7:35:47 AM UTC-4, pleo...@gmail.com wrote:
> i realy think that is more safer Ubuntu apparmored than this qubes OS.

u can use apparmor with debian in qubes.

Manuel Amador (Rudd-O)

unread,
Oct 15, 2016, 2:48:11 PM10/15/16
to qubes...@googlegroups.com
On 10/15/2016 01:04 PM, pleo...@gmail.com wrote:
> you never break armored ubuntu,this is fact... dont try be einstein to know some way to do this.No way.
>

This e-mail in particular has caused me to burst into uncontrollable
laughter.


--
Rudd-O
http://rudd-o.com/

pleo...@gmail.com

unread,
Oct 15, 2016, 5:39:32 PM10/15/16
to qubes-users, pleo...@gmail.com
Message has been deleted

pleo...@gmail.com

unread,
Oct 15, 2016, 5:48:16 PM10/15/16
to qubes-users, pleo...@gmail.com
@ raah..@gmail.com

dont know if this have any sense bcs everything in qubes in default configuration is user accesible.Firstly to use this it should be configured user acces control wich qubes dont provide in default configuration.

raah...@gmail.com

unread,
Oct 15, 2016, 7:08:24 PM10/15/16
to qubes-users, pleo...@gmail.com
On Saturday, October 15, 2016 at 5:48:16 PM UTC-4, pleo...@gmail.com wrote:
> @ raah..@gmail.com
>
> dont know if this have any sense bcs everything in qubes in default configuration is user accesible.Firstly to use this it should be configured user acces control wich qubes dont provide in default configuration.

I think you can make a root user during install i could be wrong. But it wouldn't make much of a difference anyways man.

raah...@gmail.com

unread,
Oct 15, 2016, 7:09:00 PM10/15/16
to qubes-users, pleo...@gmail.com, raah...@gmail.com

but also apparmor works on root too.

raah...@gmail.com

unread,
Oct 15, 2016, 7:16:22 PM10/15/16
to qubes-users, pleo...@gmail.com, raah...@gmail.com

ya but again, its more about what user wants to do on his computer that makes them vulnerable, and I'm sure there is 0 days out there for everyone, so big money gov'ts pwn us all, i mean if they that bored but at least we can stop the robots hopefully.

pleo...@gmail.com

unread,
Oct 15, 2016, 7:19:42 PM10/15/16
to qubes-users, pleo...@gmail.com
the idea of apparmor is to resist to app to resources they need to run and nothing more.

pleo...@gmail.com

unread,
Oct 15, 2016, 7:20:54 PM10/15/16
to qubes-users, pleo...@gmail.com
If there is no user acces control like a real root real user then its no sense to use it.

Andrew

unread,
Oct 15, 2016, 7:43:16 PM10/15/16
to qubes...@googlegroups.com
pleo...@gmail.com:
> If there is no user acces control like a real root real user then its no sense to use it.
>

I think you've missed something pretty fundamental.

Throw out everything you know about the Linux kernel and how it enforces
security (including MAC). Qubes takes the position that the Linux
kernel code base is simply too large and complex to meaningfully trust,
and that any security policies must be enforced by a smaller, more
trustable hypervisor.

The security problem is then less about user accounts, process
separation, etc. and more about ensuring guest VMs only modify their own
state, and interact with other VMs only through simple, easier-to-audit
and easier-to-securely-implement channels.

IMO all the Qubes magic is about these over-the-top channels. You can
use bare Xen (or ESXi, or HyperV or whatever) to get similar VM
isolation, but it will be cumbersome to orchestrate typical user actions
(inter-VM file copying, PDF conversion, networking/firewalling,
trustable DWM, ...). Qubes makes it easy.

Andrew

PS: Let me give an example. Suppose your typical Linux desktop has a
'user1' account and a 'tor' account. Suppose the latter is used for
running a Tor relay. Normally you would expect the Linux kernel to
enforce access control, to ensure any code running with the 'tor' uid
will not be able to access 'user1''s files. In Qubes, you just install
Tor into a separate VM from the VM you use for the 'user1' persona.
Thus the barrier for Tor to access 'user1''s data is the hypervisor, not
the Linux kernel.

pleo...@gmail.com

unread,
Oct 15, 2016, 7:56:07 PM10/15/16
to qubes-users, pleo...@gmail.com
But look every vms in qubes base on the same,so if someone compromize sys-net VM then it should not be so hard to compromize other VMs.

Andrew

unread,
Oct 15, 2016, 8:08:33 PM10/15/16
to qubes...@googlegroups.com
Andrew:
Sorry for adding to the spam, but I feel obliged to add two important
points:

1) It's not just the kernel. Practical user security depends on a lot
of userland system components, too. That's why it really is appropriate
for Qubes to abstract security domains as independent VMs.

2) While I wrote 'similar VM isolation', I still believe Qubes is the
most secure practical virtualization platform. For example, the VENOM
(CVE-2015-3456) vulnerability affected nearly every other Xen
vendor--but not Qubes. To quote Marek:

"[The solution] is already there - there is no other option in Qubes.
We've never considered running such a bloatware as qemu directly in dom0
;) "

This kind of security-first posture is what has made Qubes famous.
Trust it or not, but I hope the architecture now makes sense!

Andrew

Andrew

unread,
Oct 15, 2016, 8:11:27 PM10/15/16
to qubes...@googlegroups.com
pleo...@gmail.com:
> But look every vms in qubes base on the same,so if someone compromize sys-net VM then it should not be so hard to compromize other VMs.
>

It would compromise sys-net. Any writes to the template-based volume
(with /bin, /usr, /var, etc.) are discarded upon VM reboot. They are
not written to the base template--only the template itself can do that.

It's possible malware could persist in sys-net, though, by compromising
its /rw partition, which *does* persist across reboots (but is only used
by that specific VM). But even then: it only compromizes sys-net.

Andrew

pleo...@gmail.com

unread,
Oct 15, 2016, 8:16:37 PM10/15/16
to qubes-users, pleo...@gmail.com
look guys if someone compromize sys-net then go route trafic by fake dns and sites.You paste your credit card or something and all data goes to the hacker.

pleo...@gmail.com

unread,
Oct 15, 2016, 8:20:17 PM10/15/16
to qubes-users, pleo...@gmail.com
or the worst thing if hacker cant do this he can try to compromize sys-firewall in the same way as sysnet bcs its the same topology.And after compromizing sys-firewall then can do whatever he like.

johny...@sigaint.org

unread,
Oct 15, 2016, 9:17:14 PM10/15/16
to qubes...@googlegroups.com
> Andrew:
> This kind of security-first posture is what has made Qubes famous.

I agree that Qubes separation is probably the most secure basis for a
reasonably usable PC-based platform today. It's all I'll use. (I worry
about 4.0 not working on my hardware, tho. And upgrading hardware brings
its own security risks.)

That being said, there are a few things that stuck out like sore thumbs as
being terribly insecure in the default install, which surprised me:

- (There are some outstanding tickets on this one): All the daemons
started by systemd, some of which phone home (at the very least, leaking
your IP address) to Microsoft (resolving SMB names, even when you don't
use SMB) or RedHat (default network connectivity check for NetworkManger).

exim4, cupsd, ntpd (on by default in debian-8) don't need to be running,
and can potentially leak information (and increase the attack surface).
pulseaudio and the speaker daemon can potentially leak information from a
VM through audio channels, and aren't needed in most cases.

The default templates should be very much stripped of having any software
run by default, or unexpectedly. The package (such exim, cups) can be
included in the template, sure, but not on by default.

- Fairly loose default iptables/firewall setup (particularly for outbound
connections). No inherent DNS leakage protection. (whonix or a VPN can
solve this.) Fairly limited firewall configuration.

- No apparmor by default. When I tried to install it in a VM, I got
errors about a missing kernel module, and haven't explored it further.

Yes, VM separation keeps rogue processes at bay, but it'd still be nice if
a compromised Firefox just didn't have the option of going through
~/Documents and uploading the contents to some .ru site. :)

Apparmor and its profiles would add this extra layer of protection. Wow,
being able to run *two* or more apps in a VM without worry of them spying
on each other's data or connect to the net in ways they shouldn't! :)

Keeping every useful work file on separate or non-networked machines to
avoid rogue applications is too much of a PITA for most people. Or at
least for me.

- Unencrypted /boot partition. This one is a huge hole and could be
fixed. I've converted my /boot to luks filesystem successfully, grub
supports it. Adding a Grub password doesn't hurt, either. (As well as a
BIOS password, but I'm digressing.)

- Some of the things trumpeted in the earlier design documents and press
coverage just aren't there. Sound cards, video cards, storage devices,
USB, all (by default) live in dom0, not safely tucked in VMs.

(Not sure why my network card's Linux module seems to load in dom0 as well
as sys-net, but I'm assuming that's not an issue, and the network card is
fully in sys-net.)

Individual VM's disks aren't encrypted with their own luks filesystem and
keys, which is mentioned in a few articles or papers I read. Not sure how
important this one is, but where it is listed as a feature in some
reviews, I thought I'd mention it for clarity. It might be useful if
someone compromised root, that they wouldn't necessarily have access to
the data on your VM's. But that's a lot more password juggling and
layered encryption with associated CPU cost, so I dunno. (Qubes VM
Manager would end up being a bit of a password vault in itself, ugh.)

I'm only pointing these out in a constructive way, I still love the
system, and just want to suggest ways to make it even better for those who
don't spend the time or have the knowledge to tweak up these security
risks.

Cheers.

JJ

Manuel Amador (Rudd-O)

unread,
Oct 15, 2016, 9:23:11 PM10/15/16
to qubes...@googlegroups.com
On 10/16/2016 12:16 AM, pleo...@gmail.com wrote:
> look guys if someone compromize sys-net then go route trafic by fake dns and sites.You paste your credit card or something and all data goes to the hacker.

If someone compromises the network card of your AppArmor-enabled Ubuntu
instance, the same thing happens. Except in that case the malware can
access way more than just DNS spoofing.

Advantage: Qubes OS.


--
Rudd-O
http://rudd-o.com/

raah...@gmail.com

unread,
Oct 15, 2016, 9:31:26 PM10/15/16
to qubes-users, johny...@sigaint.org

Microsoft phoning home? what?

debian is not default for qubes vms. Its a community package, But you can customize it how ever you want just like a bare metal debian.

whonix has instructions for how to install apparmor, which will also apply to a debian template. https://www.whonix.org/wiki/Qubes/Install I use it for chromium and hexchat.

VM separation means you don't go to a website that will upload your documents to a .ru site, in a vm that has documents you don't want there. Thats the whole point I think maybe your missing, and understandably what turns alot of people off.

You have to be able to strictly use different vms for diff tasks. Which also means you want alot of memory and hdd space. Its perceived overwhelming to those not used to it. but no different then having lots of file folders on a machine imo.

Andrew

unread,
Oct 15, 2016, 9:47:49 PM10/15/16
to qubes...@googlegroups.com
pleo...@gmail.com:
> or the worst thing if hacker cant do this he can try to compromize sys-firewall in the same way as sysnet bcs its the same topology.And after compromizing sys-firewall then can do whatever he like.
>

I'm not sure what you're trying to say here. Anyway it should be
difficult to compromise sys-firewall, as the attack surface just isn't
that big. But still possible, most likely.

Anyway after compromising sys-firewall, the attacker is still confined
to sys-firewall. This just allows the attacker to observe and modify
network traffic, which is already a part of your threat model. Right?

The attacker would need to break out to dom0 to "do whatever (s)he wants".

Andrew

raah...@gmail.com

unread,
Oct 15, 2016, 9:52:28 PM10/15/16
to qubes-users, pleo...@gmail.com
On Saturday, October 15, 2016 at 8:16:37 PM UTC-4, pleo...@gmail.com wrote:
> look guys if someone compromize sys-net then go route trafic by fake dns and sites.You paste your credit card or something and all data goes to the hacker.

sys-net is considered untrusted as it is, consider your router too most likely. You really shouldn't presume anything not encrypted as private.

always make sure site is https if putting in a credit card, a tip i got on mailing list when using qubes is to go to the site in your normal appvm and look at the cert. Then load the same page up from a torvm and make sure the cert matches. You should also make that qube https only in firewall settings. and use https everywhere using the setting to block everything not encrypted.

pleo...@gmail.com

unread,
Oct 15, 2016, 9:57:19 PM10/15/16
to qubes-users, pleo...@gmail.com
look at qubes how is it build?
vitrualisation of the same environment

1-2-3 is separated but its still the same so somoene exploit 1 then exploit 2-3 on recursive.

i mean by this vitrualisation same topology.

So what i mean is better way to multiple topology than avoid recursive exploits.

pleo...@gmail.com

unread,
Oct 15, 2016, 10:02:32 PM10/15/16
to qubes-users, pleo...@gmail.com
for an example it was much better for security if that no build on the same but somethin like this

ubuntu (sys-net)-pfsense(sys-firewall)- appVM (debian or fedora)

raah...@gmail.com

unread,
Oct 15, 2016, 10:05:42 PM10/15/16
to qubes-users, pleo...@gmail.com
On Saturday, October 15, 2016 at 10:02:32 PM UTC-4, pleo...@gmail.com wrote:
> for an example it was much better for security if that no build on the same but somethin like this
>
> ubuntu (sys-net)-pfsense(sys-firewall)- appVM (debian or fedora)

again probably only making a real difference against a random or automatic qubes designed attack I guess? You can still do what you want yourself man. You don't have to use the default setup.

raah...@gmail.com

unread,
Oct 15, 2016, 10:08:22 PM10/15/16
to qubes-users, pleo...@gmail.com, raah...@gmail.com
I would love to see an openbsd, or some more hardened sys-firewall. There have been some community efforts maybe you can create one. we have minimal templates available now. I read about a unikernel someone made for qubes that looked interesting. Maybe you can create something. Qubes team is not very large and this is still way more secure imo then a traditional linux or windows os man.

pleo...@gmail.com

unread,
Oct 15, 2016, 11:38:07 PM10/15/16
to qubes-users, pleo...@gmail.com
unikernel u mean this?
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/
i have installed it and work good.

pleo...@gmail.com

unread,
Oct 15, 2016, 11:40:36 PM10/15/16
to qubes-users, pleo...@gmail.com
maybe this mirage-kernel should be add to standard repo config in Qubes.

pleo...@gmail.com

unread,
Oct 15, 2016, 11:56:09 PM10/15/16
to qubes-users, pleo...@gmail.com
But i prefer to build that kind of sys-firewall on something like pfsense bcs its real firewall.

Tell me how to build pFsense (or something familiar) firewall on Qubes and set to default.

pleo...@gmail.com

unread,
Oct 16, 2016, 12:03:59 AM10/16/16
to qubes-users, pleo...@gmail.com
I dont know how to install it,im so stupid omg.Maybe like ProxyVM and route trafic by pFsense? but its no option to choice only fedora debian.WTF im so stupid.I dont know how to install it.

pleo...@gmail.com

unread,
Oct 16, 2016, 1:18:54 AM10/16/16
to qubes-users, pleo...@gmail.com
Ok i probobly figure it out how to do this.Install pfsense as HVM configure and then in qubes managment change HVM to proxy VM.But i dont know how to do this... maybe create proxyVM as name pfsense then delete in directory via terminal and copy HVM on the same name so qubes will see it as a proxyVM.I dont know but it may work.

raah...@gmail.com

unread,
Oct 16, 2016, 11:30:27 PM10/16/16
to qubes-users, pleo...@gmail.com

ya thats what i was talking about, nice I'll have to try it out.

raah...@gmail.com

unread,
Oct 16, 2016, 11:33:08 PM10/16/16
to qubes-users, pleo...@gmail.com
On Sunday, October 16, 2016 at 12:03:59 AM UTC-4, pleo...@gmail.com wrote:
> I dont know how to install it,im so stupid omg.Maybe like ProxyVM and route trafic by pFsense? but its no option to choice only fedora debian.WTF im so stupid.I dont know how to install it.

Its too complicated for me to try, but have a look here maybe will point you in right direction https://www.qubes-os.org/doc/building-non-fedora-template/

Jeremy Rand

unread,
Oct 19, 2016, 7:20:30 PM10/19/16
to qubes...@googlegroups.com
pleo...@gmail.com:
> philosofy of qubes is that you are safe when your app is isolatet.This is wrong just keep app in sandboxes or jails and what wrong can be happen?

Thanks for the spamfest. Looks like my null-routed email address list
finally has someone other than Drew in it. Next time you feel tempted
to send a ridiculous number of 1-line emails to a mailing list, please
don't. There are those of us who actually have useful things to be doing.

Cheers,
-Jeremy

signature.asc

pleo...@gmail.com

unread,
Oct 20, 2016, 1:12:38 PM10/20/16
to qubes-users, pleo...@gmail.com
@Jeremy Rand

realy sorry about that,i didnt think that someone get some emails.But this thing of system security is important.

Manuel Amador (Rudd-O)

unread,
Oct 20, 2016, 8:38:38 PM10/20/16
to qubes...@googlegroups.com
On 10/20/2016 05:12 PM, pleo...@gmail.com wrote:
> @Jeremy Rand
>
> realy sorry about that,i didnt think that someone get some emails.

THOUSANDS of us get "some emails" from you.

> But this thing of system security is important.
>

The fact that security — which you do not seem to understand how it
works — is important, does NOT excuse you spamming the entire list with
many, many poorly-researched allegations that each are one line.

This is not your personal chat room.

Next time, compose your ideas in a single e-mail, and then send them as
a single e-mail.

PLONK!

--
Rudd-O
http://rudd-o.com/

raah...@gmail.com

unread,
Oct 20, 2016, 9:21:09 PM10/20/16
to qubes-users, rud...@rudd-o.com
oh come on this is a google.com forum what are you talking about haha. :) At least he admitted his mistakes so means he learned something. and for anybody else who has the same crazy ideas and reads the thread as well so working as planned. no big deal if not attacking users.
Reply all
Reply to author
Forward
0 new messages