Does anyone on Sup Forums use Qubes? How is it in practice?

Does anyone on Sup Forums use Qubes? How is it in practice?

Other urls found in this thread:

libreboot.org/faq.html
twitter.com/SFWRedditVideos

honeypot os

any linux distro with systemdick is vulnerable

slow, resource intensive and insecure because they still use xen.

any linux with dockerized services, selinux and seccomp works better and is less resource intense.

If you're computer has the Intel Management Engine in its hardware for Intel and AMD, then Tails and Qubes OS are pointless. Tails admits the they cannot prevent the Management Engine (pic related). Invest in a Libreboot computer if you're looking for privacy.

Nonsense, and stuff done in Qubes can't be done with dockerized services.

you can buy anything prior PSP and ME: libreboot.org/faq.html
basically anything that is FX from AMD and anything around Core 2 or basically everything that is 65nm.

My threat model doesn't include the NSA hacking me through the processor. What I'm concerned about is all the shit I run on my computer having access to everything instead of being isolated to their own containers.

There's no reason for many of the applications on my computer to have any access to my crypto keys, source codes, personal and business documents... Qubes provides the best isolation.

like what? you just create an additional layer of obscurity and hope that'll secure your system. virtualization is not a security feature, it's the exact opposite. virtualization as security bases itself on a broken hardware platform and a insecure software platform, this is not how you do security, no matter how "good" the folks behind the project are. the amount of shit they have to separate in a vm so your dom doesn't get hijacked is nothing but obscure overhead with absolutely no benefit because your OS, hypervisor and CPU has so many security holes, that can't be fixed with virtualizing an entire stack again and again.

any openbsd with docker would be by far more secure and faster simply because of things like pledge which is far superior to the garbage that seccomp is and by default every process is chrooted.

use selinux, problem solved

>
>like what? you just create an additional layer of obscurity and hope that'll secure your system. virtualization is not a security feature, it's the exact opposite. virtualization as security bases itself on a broken hardware platform and a insecure software platform, this is not how you do security, no matter how "good" the folks behind the project are. the amount of shit they have to separate in a vm so your dom doesn't get hijacked is nothing but obscure overhead with absolutely no benefit because your OS, hypervisor and CPU has so many security holes, that can't be fixed with virtualizing an entire stack again and again.
>any openbsd with docker would be by far more secure and faster simply because of things like pledge which is far superior to the garbage that seccomp is and by default every process is chrooted.
Or instead of heaping another load of shit on top of whatever OS you're running (lol libcontainer), just go for broke and use Xen for its intended purpose: separation and segregation.
>virtualization as security bases itself on a broken hardware platform and a insecure software platform, this is not how you do security, no matter how "good" the folks behind the project are.
Any additional layer that buys you time to react and act to a compromise is an advantage. I get a shell on your OpenBSD one-system wonder, I have access to anything within the privileges of that services' user account. That has wide implications. Contrast against compromising the sys-net on Qubes. I gain next to nothing in terms of information, and still have an unknown number of machines yet to compromise on my way.
And before you spew "Much Insecure Xen", need I remind you that Amazon uses it for a reason, and has likely one of the largest attack surfaces of any company exposed to the internet?

>And before you spew "Much Insecure Xen", need I remind you that Amazon uses it for a reason, and has likely one of the largest attack surfaces of any company exposed to the internet?
xen is an insecure platform which even qubes people figured out and want to migrated away from it because it is fundamentally broken and has had so many severe issues it's more a liability than anything else. beside that you did not even mention the reason why amazon uses it, you just said that amazon has reasons. be more vague please.

>Or instead of heaping another load of shit on top of whatever OS you're running (lol libcontainer), just go for broke and use Xen for its intended purpose: separation and segregation.
just shows you don't understand how containers or openbsd works, but i wouldn't expect someone who desperately justifies the horrors of xen to be the savior for security, privacy and stability.

>Any additional layer that buys you time to react and act to a compromise is an advantage.
no it doesn't because in most cases you have a sophisticated attack, you don't even know how you got fucked over, it doesn't buy you time, it gives the attacker time to hide tracks. security isn't about complexity kid, never was and never will be.


you are so full of shit it actually hurts

> (You)
>>And before you spew "Much Insecure Xen", need I remind you that Amazon uses it for a reason, and has likely one of the largest attack surfaces of any company exposed to the internet?
>xen is an insecure platform which even qubes people figured out and want to migrated away from it because it is fundamentally broken and has had so many severe issues it's more a liability than anything else. beside that you did not even mention the reason why amazon uses it, you just said that amazon has reasons. be more vague please.
Because their sheer size combined with the fact that they execute foreign code nearly constantly in their virtualization centers means they have an enormous reaction time and noisy baseline to base their monitoring on. Yet despite this, we don't hear stories of amazon taking 0days up the ass all the time, do we?

>>Or instead of heaping another load of shit on top of whatever OS you're running (lol libcontainer), just go for broke and use Xen for its intended purpose: separation and segregation.
>just shows you don't understand how containers or openbsd works, but i wouldn't expect someone who desperately justifies the horrors of xen to be the savior for security, privacy and stability.
Containers are for separation and portability. Not segregation. Anything running inside of a container has to be treated as running on the host for all intents and purposes. And before you say "Muh OpenBSD" and start parroting Theo, Docker-on-OpenBSD has the gotcha of- guess what?- running Linux on a hypervisor to get it running.

Cont.

I didn't spend thousands of dollars on hardware to run an OS that doesn't support even half of it.

>>Any additional layer that buys you time to react and act to a compromise is an advantage.
>no it doesn't because in most cases you have a sophisticated attack, you don't even know how you got fucked over, it doesn't buy you time, it gives the attacker time to hide tracks. security isn't about complexity kid, never was and never will be.
If we're arguing a 'Sophisticated' attack, then it only serves right that our defense is equally equipped. Do the words 'Tripwire', 'Snort', 'Surricata', or even fucking 'Syslog' ring a bell? Noisy things make noise, and things that don't behave get noticed.

>you are so full of shit it actually hurts
That's because I bother to take it to the loo, Pajeet. Work on your English, and your grammar too.

>Because their sheer size combined with the fact that they execute foreign code nearly constantly in their virtualization centers means they have an enormous reaction time and noisy baseline to base their monitoring on. Yet despite this, we don't hear stories of amazon taking 0days up the ass all the time, do we?
you think that arguing about not disclosing leaks is a pro argument for their security? nigga please

>Containers are for separation and portability. Not segregation. Anything running inside of a container has to be treated as running on the host for all intents and purposes.
mainly yes but can be used for segregation as well, the footprint is small enough to implement exactly that.

>And before you say "Muh OpenBSD" and start parroting Theo, Docker-on-OpenBSD has the gotcha of- guess what?- running Linux on a hypervisor to get it running.
no it doesn't. just comparing docker with a standard hypervisor is retarded and just show how much you talk out of your ass.


>If we're arguing a 'Sophisticated' attack, then it only serves right that our defense is equally equipped. Do the words 'Tripwire', 'Snort', 'Surricata', or even fucking 'Syslog' ring a bell? Noisy things make noise, and things that don't behave get noticed
yeah like surricata can tell the difference between forged packets delivered via compromised update services. just because you run inline dpi firewalls or ids doesn't mean shit. most of the time you notice a real sophisticated attack it's already to late

>That's because I bother to take it to the loo, Pajeet. Work on your English, and your grammar too.
when you are out of solid arguments you take it to a lower level. stay classy m8

> (You)
>you think that arguing about not disclosing leaks is a pro argument for their security? nigga please
Because security statements mandate it. If a compromise or vulnerability is found you can bet Amazon's SOC is writing reports about it, phonecalls are made and chatter happens. Laws mandate that these things are announced as it impacts their customers.

>mainly yes but can be used for segregation as well, the footprint is small enough to implement exactly that.
By doing so with no real benefits of security. The kernel of the host is still exposed by the requirements of Docker, and programs are still being executed on the host OS. Their emphasis is on portability, not security.

>>And before you say "Muh OpenBSD" and start parroting Theo, Docker-on-OpenBSD has the gotcha of- guess what?- running Linux on a hypervisor to get it running.
>no it doesn't. just comparing docker with a standard hypervisor is retarded and just show how much you talk out of your ass.
>
>any openbsd with docker would be by far more secure and faster simply because of things like pledge which is far superior to the garbage that seccomp is and by default every process is chrooted.
You stated here to combine the two but as far as a trivial web search reveals, OpenBSD needs to run it under VMM. Which renders those userland hardening moot for the purposes of Docker.

>yeah like surricata can tell the difference between forged packets delivered via compromised update services. just because you run inline dpi firewalls or ids doesn't mean shit. most of the time you notice a real sophisticated attack it's already to late
What is package signing, hashes and PKI infrastructure? Something that had been running for his many years now?

>when you are out of solid arguments you take it to a lower level. stay classy m8
Ad Hominem for Ad Hominem. Bantz can be fun to work on.

>Because security statements mandate it. If a compromise or vulnerability is found you can bet Amazon's SOC is writing reports about it, phonecalls are made and chatter happens. Laws mandate that these things are announced as it impacts their customers.
which ones exactly?

>By doing so with no real benefits of security. The kernel of the host is still exposed by the requirements of Docker, and programs are still being executed on the host OS. Their emphasis is on portability, not security.

>You stated here to combine the two but as far as a trivial web search reveals, OpenBSD needs to run it under VMM. Which renders those userland hardening moot for the purposes of Docker.
true, i should have probably searched before making that statement. though, if it were to run native it would be theoretically be the best solution, provided that it runs on obsd.

>What is package signing, hashes and PKI infrastructure? Something that had been running for his many years now?
wouldn't be the first time when an infrastructures that provides update services gets compromised. the one thing an attacker looks always to is infrastructure services, active directory, update services, jumphosts, logservers, dns, etc and work their way from there on

> (You)
>>Because security statements mandate it. If a compromise or vulnerability is found you can bet Amazon's SOC is writing reports about it, phonecalls are made and chatter happens. Laws mandate that these things are announced as it impacts their customers.
>which ones exactly?
I work in a SOC. When a P1 happens, C-levels get involved sometimes. It wouldn't surprise me if they make a dumb broadcast by bulk email to as many people as they can. Mind you, I'm only intuiting this.

>>By doing so with no real benefits of security. The kernel of the host is still exposed by the requirements of Docker, and programs are still being executed on the host OS. Their emphasis is on portability, not security.
>>You stated here to combine the two but as far as a trivial web search reveals, OpenBSD needs to run it under VMM. Which renders those userland hardening moot for the purposes of Docker.
>true, i should have probably searched before making that statement. though, if it were to run native it would be theoretically be the best solution, provided that it runs on obsd.
While I'd certainly be inclined to agree, so much would have to change first to get this sort of thing to run. A better (and probably safer!) solution would be to make some wrapper around jails using a set of shell scripts. Less binary code, while still having the advantages that OpenBSD provides. I think it'd be neat.

>>What is package signing, hashes and PKI infrastructure? Something that had been running for his many years now?
>wouldn't be the first time when an infrastructures that provides update services gets compromised. the one thing an attacker looks always to is infrastructure services, active directory, update services, jumphosts, logservers, dns, etc and work their way from there on
Just to make sure I'm understanding this right, are we talking about compromising a root update server (for instance, Debian's package repo) or a local one to a corp (Puppet)?

>I work in a SOC. When a P1 happens, C-levels get involved sometimes. It wouldn't surprise me if they make a dumb broadcast by bulk email to as many people as they can. Mind you, I'm only intuiting this.
i haven't worked in the security field but i personally have seen a few large coorporations refusing to publish this. i mean, look at equifax or the recent microsoft leak of their compromised bugtrack, that's the norm, and i honestly expect amazon or any other company to act the same way.

>Just to make sure I'm understanding this right, are we talking about compromising a root update server (for instance, Debian's package repo) or a local one to a corp (Puppet)?
why not both. but let's just say you don't use spacewalk/satellite or anything to distribute your packages (i actually have no idea how debian does it other than through /etc/apt/), you setup a company wide repository server and deploy your repository config via the config mgt tool of choice to always point to your repo server in your internal network. you could just replace any package and generate an new repodata.xml and you'd have to hope that your AIDE, tripwire, ossec, whatever throws an alarm. but as far as i know most companies, they don't run their integrity checks on repo servers because they are lazy and uploading and maintaining hash list of new packages which are pushed to the repo server is to much work apparently ...

with puppet it doesn't really matter. if you don't have a dedicated puppet team that approves and confirms every new module company wide, and every new commit per department, you might as well include whatever the fuck you want. exploiting shitily managed configuration management servers isn't exactly difficult.

example of pki and signature based update services being compromised, the first that comes to mind is actually just microsoft. the other repo breaches i know of was freebsd because they didn't have package signing for their binaries as well as arch

Can you Docs please start talking in English?

no

Fedora based botnet

>i haven't worked in the security field but i personally have seen a few large coorporations refusing to publish this. i mean, look at equifax or the recent microsoft leak of their compromised bugtrack, that's the norm, and i honestly expect amazon or any other company to act the same way.
Leaks are one thing. As a company providing a product, the situation is a little different. I don't think any customer data was compromised in the event. The Equifax clusterfuck is still probably ongoing, and we can expect one hell of a lawsuit from it.

>why not both. but let's just say you don't use spacewalk/satellite or anything to distribute your packages (i actually have no idea how debian does it other than through /etc/apt/), you setup a company wide repository server and deploy your repository config via the config mgt tool of choice to always point to your repo server in your internal network. you could just replace any package and generate an new repodata.xml and you'd have to hope that your AIDE, tripwire, ossec, whatever throws an alarm.
That's part of the problem, but having separate access controls for that sort of thing helps. But if a bad guy just logs in and pushes an update, there's bigger problems involved already. Like how they got the creds in the first place!

>with puppet it doesn't really matter. if you don't have a dedicated puppet team that approves and confirms every new module company wide, and every new commit per department, you might as well include whatever the fuck you want.
This is sort of why Debian is so slow on updates. Everything needs another set of eyes to get pushed, which both helps verify what's going in as well as catching bullshit before it hits something in prod.

And I know from personal experience that finding plaintext passwords in Salt config files is hilariously funny. Keep that stuff secure, people! Lowly analysts shouldn't have access to root logins!

Cont.

>example of pki and signature based update services being compromised, the first that comes to mind is actually just microsoft. the other repo breaches i know of was freebsd because they didn't have package signing for their binaries as well as arch
Arch moves so fast. I'm honestly quite curious if people even review one another's changes as they're pushed to the repos. While they might be signed and hashed, can the maintainers be trusted?

I'm at work right now, and my brain is busy being cooked by the stuffs we use. Just being able to type is nice.

>Can you Docs please start talking in English?
Go meme about phones or something somewhere else.

You're better off using bhyve with FreeBSD

An untested, unaudited, and relatively obscure hypervisor? Why's that?

QubesOS is a meme

>As a company providing a product, the situation is a little different.
i wouldn't say that's any different for microsoft. not disclosing that their internal bugtracker got hacked does have an impact on the end customers. if it's not high prio bug they neglect it and that bugtracker is a feast for every skiddie to blackhat on the planet. equifax is a huge clusterfuck and most other finance business are. finance, insurance and medical business are terrible, full of legacy stuff that nobody's willing to touch or even migrated, creating huge backlogs for the administration, etc.

>And I know from personal experience that finding plaintext passwords in Salt config files is hilariously funny. Keep that stuff secure, people! Lowly analysts shouldn't have access to root logins!
yeah ... i know exactly what you are talking about but if you don't have a drill sergeant who chews you out whenever you do it, people will continue to do so.

>Arch moves so fast. I'm honestly quite curious if people even review one another's changes as they're pushed to the repos. While they might be signed and hashed, can the maintainers be trusted?
trust gotta start somewhere, if you can't trust your maintainers you might as well start building everything yourself and even that doesn't confirm if there are backdoors in the source or not. either way, arch is a shit distro in so many ways, better stick to rpm based distros, they are solid.

bhyve is doa, even vmm has more relevance than Sup Forumshyve

> (You)
>>As a company providing a product, the situation is a little different.
>i wouldn't say that's any different for microsoft. not disclosing that their internal bugtracker got hacked does have an impact on the end customers. if it's not high prio bug they neglect it and that bugtracker is a feast for every skiddie to blackhat on the planet. equifax is a huge clusterfuck and most other finance business are. finance, insurance and medical business are terrible, full of legacy stuff that nobody's willing to touch or even migrated, creating huge backlogs for the administration, etc.
It largely seems to depend on whether harm was caused or not. Yay, laws.

>yeah ... i know exactly what you are talking about but if you don't have a drill sergeant who chews you out whenever you do it, people will continue to do so.
Sadly. Or you can give it to a nearby bored analyst and tell him not to break anything. It might be irresponsible, but the ensuing freakout would be lulzy. And they'll remember it.
> (You)
>>Arch moves so fast. I'm honestly quite curious if people even review one another's changes as they're pushed to the repos. While they might be signed and hashed, can the maintainers be trusted?
>trust gotta start somewhere, if you can't trust your maintainers you might as well start building everything yourself and even that doesn't confirm if there are backdoors in the source or not. either way, arch is a shit distro in so many ways, better stick to rpm based distros, they are solid.
Its not that I don't trust them, it's that if either:
A) They fuck up and push something bad that bricks stuff,
or B) They get compromised and push something malicious.
Don't take those two statements as implications of trust or lack thereof, just having a second set of eyes helps catch stuff as it comes through. Its damage control and reduction. People are human and occasionally screw up, yeah?

So after all that, can anyone actually list a full build (hardware and software) for a security focused device, usable by the technically inept.

>My threat model doesn't include the NSA hacking me through the processor
pleb

>So after all that, can anyone actually list a full build (hardware and software) for a security focused device, usable by the technically inept.

Realistically, we need to be looking at a RISC-V machine either running OpenBSD or something based on seL4. The Qubes approach of piling layers and layers of shit on top of each other isn't a sensible long term security solution.

I imagine the NSA would only do so if you were a terry, moments away from snackbaring all over 72 virgin. Its not worth the time and effort for some pleb who browses derp web every few weeks.

I don't think RISC-V gives out machines willy nilly. And I don't trust OpenBDS

>Don't take those two statements as implications of trust or lack thereof
while you aren't wrong, you still have to trust your source, because what you do by default is assume that they a) don't fuck up and b) don't intentionally compromise or build packages in a secure environment which is not compromised.

i once would have said copperheadOS for andoird but since grsec is now closed source, it's more or less dead. and there is always the thing with the gsm blobs which are always closed, then you have ARM which isn't really a trustworthy architecture because of trust zone which is basically ME or PSP just for ARM

risc-v sounds nice but i'm not very optimistic on it

>And I don't trust OpenBDS
care to elaborate why? what makes you trust in any software product you use, independent of open source or not

All these names and abbreviations makes no sense to me. I've heard of Tor but don't know what BDS,ARM,PSP,ME,RISCV,LGBT,ASL and all the other shit is about. Security ought to be accessible for all, not just those who spend months learning how to configure randomly obscure shit via command line on HeadsWNIXTAILQUBE. Fuck.

>
>I imagine the NSA would only do so if you were a terry, moments away from snackbaring all over 72 virgin. Its not worth the time and effort for some pleb who browses derp web every few weeks.

Even then, I doubt it. Most snackbars don't use that weird thing we call the internet for much more than zuckerbook.
> (You)
>>Don't take those two statements as implications of trust or lack thereof
>while you aren't wrong, you still have to trust your source, because what you do by default is assume that they a) don't fuck up and b) don't intentionally compromise or build packages in a secure environment which is not compromised.

>
>i once would have said copperheadOS for andoird but since grsec is now closed source, it's more or less dead. and there is always the thing with the gsm blobs which are always closed, then you have ARM which isn't really a trustworthy architecture because of trust zone which is basically ME or PSP just for ARM
Technically, GrSec went shared source that was available for purchase. The Copperhead group might have purchased it to continue using it.

i'm sure you will become a doctor or a chemist with that attitude, you seem like a very intelligent fella

>Most snackbars don't use that weird thing we call the internet

Forgetting how ISIS had a recruitment site on dank web? Pretty sure they got dicked over and all applicant details were leaked iirc

>he isn't terry on steroids
plebx2

Can you use plebx2 on BDS? also, satanic post ID

unlikely. unless you can prove you are a business they won't hand out licenses. even ngo's get the patch sponsored by supporters because most of them apparently can't afford it.

i don't know about the shared part, i think it doesn't really matter, because if they find out who leaked the source of any new patch, they'd immediately terminate the contract which i think nobody would risk. and knowing how paranoid the pax team and spengler is, i wouldn't be surprised that they sign each patch individually or something like that to catch whoever publishes it

While on that note, the release of the sources only tracks up to version 4.9. Given the age of most kernels on android phones, CopperheadOS shouldn't be too heavily impacted by this. As bug reports come in, things can be fixed and patched. So at the least, the protections gartered are still very much usable and applicable.

i thought android and linux are still developed separately. linux merges most of what's architecture related to mainline but android should still be a separate source tree iirc

sure most of what was available with the last test patch could be still used but there will be no bug fixes or new mitigations. might as well just stick to selinux and hope for the best

they should have called it "pubes"
because anyone that uses it thinking it will protect them clearly hasnt got any pubes

> (You)
>i thought android and linux are still developed separately. linux merges most of what's architecture related to mainline but android should still be a separate source tree iirc
They mostly are, what with the 3.4/3.10 kernel versions being the most frequently used. For instance, my Copperhead phone uses 3.10.73.

>sure most of what was available with the last test patch could be still used but there will be no bug fixes or new mitigations. might as well just stick to selinux and hope for the best
An older kernel is not necessarily worse, especially so if you have security features that nuke entire classes of attacks. Newer kernel versions don't have things like GRSec, PAX, kASLR... But those versions do.

It sucks for general use. It's basically only good for out of the box whonix .

You know that Rutkowska is a tranny, right, guys?

If you made a proprietary platform to compete with an open source one like Xen wouldn't you want to disseminate exaggerated flaws in the free alternative?

Any news short of a working exploit coming from this company about how much more secure they are is complete bullshit.

i did run the last patch until few month ago on a hardened gentoo until i simply couldn't deal with the skylake bugs any longer and ditched gentoo entirely. if you have older hardware that might work but if you wanna run it on new stuff ... not that great.

anyhow, going to bed, nice chatting with you. cya around

> (You)
>i did run the last patch until few month ago on a hardened gentoo until i simply couldn't deal with the skylake bugs any longer and ditched gentoo entirely. if you have older hardware that might work but if you wanna run it on new stuff ... not that great.
>anyhow, going to bed, nice chatting with you. cya around

Seeya M8. And keep learning. Its rare to find legitimate gentoomen around here these days.

Its just Linux which is based on another Linux. Its all the same. You linux fags are insufferable.

Virtualization protects against kernel-level exploits, selinux is a great tool, but it is a MAC framework for userspace.

What Pic?

>risc-v sounds nice but i'm not very optimistic on it.

Get on a Rocket and go BOOM.
If you get this. You win a cookie.

Think outside the bun.

>when you are out of solid arguments you take it to a lower level. stay classy m8
You're the one using shittalking in place of actual arguments, douchebag

>BDS
*BSD. Berkely Software Distribution. Family of operating systems based on UNIX. Separate from GNU/Linux.
>ARM
A computer architecture, like x86; commonly used in Smartphones.
>ME
Intel's processor operating system that allows them access and control over the machine the CPU is installed in
>RISC-V
another computer architecture. I believe it's free software, no? it's currently used for workstation computers and pretty expensive or something

virtualization does not protect against kernel exploits, where the fuck did you get this bullshit from?
if you use full virtualization you exploit the local kernel, if you use paravirtualization you exploit the host kernel. most modern vm technology is full virtualization but that doesn't imply that either guest or host is safe. there are attacks on deduplication, on aslr, etc, that go way past the guest

no you wouldn't because your business model would be rather obvious and people would try to avoid you and the crap that you produce and sell. the way how companies usually do it, if you take vmware as an example, they simply remove features from the free esxi an make them only available to customers with certain licenses and the included features are different per license model as well

>the NSA
Intel ME has vulnerabilities which are more or less in the open now, there are most likely exploits in the wild.

i'd really like to see that happen in masses, that should shake up the industry good enough to not bend for cunts like the US gov and their 5 eyes scum