Simpler, lighter security approach inspired by Qubes OS

[Andrey Utkin]

TL;DR: Who wants to work/comment/object on implementing Qubes approach
with simpler mechanisms, like UNIX user accounts or maybe LXC? Or who is
already working on it?


Qubes OS uses Xen VMs for isolation of tasks and data. AFAIK it is
feasible to implement usage of LXC for isolation, but Qubes OS
developers don't consider it priority objective. Of course, it is
isolation of different quality, but performance benefits may be worth
it, especially on not so powerful average laptops. Unfortunately, a lot
of personal computers won't allow running Qubes OS comfortably.

At the same time, it is possible to improve security of sensitive data
of *nix user by separation of tasks and data to multiple system user
accounts. This is common practice for various system services. Some
power users follow this approach for security gains. But following this
approach requires manual maintenance, and many users don't bother to do
that because this looks complicated.
My proposal is to develop this approach to the level of Qubes OS, to
provide visibility and ease, and to guide the beginners about good
practice. This will apply much lower hardware resources requirements
than Qubes OS. Of course, this is totally different (lower) level of
security comparing to Qubes OS, but it is still an improvement comparing
to usual Linux setup: before, an application exploit would get access to
user data immediately, and now it has nothing except what is given to
that pseudo-user dedicated to running particular app, unless the
attacker hacks the OS kernel. The latter is feasible, but requires quite
more advancement from the attacker, making user of proposed approach
vulnerable in quite less share of cases.

This isolation scheme allows also usage of Split GPG technique.

Thanks for any kind comment!


P. S. Offtop: any recommendations for/against particular PGP siging
standard - inline PGP vs. PGP/MIME attachment? Please email me off-list
if you feel to explain this to me. Thank you very much.

--
OpenPGP usage is appreciated (it also helps your letter to bypass spam
filters). To email me with encryption easily, go
https://encrypt.to/0xC6FCDB11

[Eric Shelton]

I suppose that either what you propose, or using KVM, represents the most likely candidate for a non-Xen implementation of Qubes, which is what all of the rearchitecting to implement the Hypervisor Abstraction Layer (HAL/Qubes Odyssey) was all about.  Qubes R3 is built on top of libvirt, and http://libvirt.org/ claims that libvirt supports LXC, so it may not be all that bad.

http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html

I anticipate two significant categories of problems: (1) everything other than KVM appears to be a second-class citizen under libvirt, which means that some of the libvirt features that Qubes relies upon may not be fully implemented for LXC, and you will have to implement them; and (2) being the first non-Xen Qubes implementation, you will be the first to put the HAL to the test, and you _will_ find places where the abstractions break down and need to be fixed up (despite how awesome Marek and Joanna are).  A third category, but probably less of a showstopper, is that some things like Qubes Manager are set up to allocate certain amounts of memory to VMs, etc, which likely won't all apply in an LXC-based implementation (in other words, you may need or want to specify certain settings for Xen but not LXC, and vice versa).

I don't know how a Windows-based or other HVM-type VM fits into your picture.  If you decide to pursue it, I don't know if or how Xen + LXC works, or KVM + LXC for that matter.  This could lead to some kind of a hybrid approach, where you can introduce LXC as a secondary separation mechanism on top of Xen (if that is possible) to realize some of the benefits of LXC, while delivering some of the harder security guarantees provided by Xen (for example, being able to rely on VT-d for NetVM).  One possible problem with the hybrid approach is that if you are effectively giving people a selectable sliding scale for security, it will tend towards increased user confusion about the security promises being delivered by the OS, and resulting security mistakes - people still misuse things even under Qubes' more clearly defined security model.

Finally, you mention performance issues on laptops.  The only one I really have seen involves successfully allocating memory across VMs, especially if you have an HVM.  For example, I found 4GB of RAM too constrained for my purposes.  I have not noticed Xen imposing much CPU overhead, if that is something you were suggesting.

Best,

Eric

[Radoslaw Szkodzinski]

On Sat, Nov 21, 2015 at 2:20 AM, Andrey Utkin <andrey....@gmail.com> wrote:
> TL;DR: Who wants to work/comment/object on implementing Qubes approach
> with simpler mechanisms, like UNIX user accounts or maybe LXC? Or who is
> already working on it?
>
>
> Qubes OS uses Xen VMs for isolation of tasks and data. AFAIK it is
> feasible to implement usage of LXC for isolation, but Qubes OS
> developers don't consider it priority objective. Of course, it is
> isolation of different quality, but performance benefits may be worth
> it, especially on not so powerful average laptops.

No, they are not. Xen in PV mode is pretty fast, and not much slower
in HVM mode either; could be even faster in PVH mode.
The only important benefit is memory usage - and if you want to
sacrifice security for memory, you could enable memory sharing,
frontswap and frontcache.
This should improve disk performance too if that matters.

> Unfortunately, a lot
> of personal computers won't allow running Qubes OS comfortably.

Where do you get this assumption from? Is "a lot of personal
computers" just "machines with 3/4 GB of RAM?".
Yes, in current default settings, for fully comfortable use w, Qubes
needs about 8 GB of RAM, mostly because certain web browsers cannot
deal with low memory properly.

The additional load by X, audio and block device separation is
generally small, though important if you want to e.g. play videos,
because you won't get hardware acceleration.
If you abolish that, might as well just use any other distro than Qubes.

> At the same time, it is possible to improve security of sensitive data
> of *nix user by separation of tasks and data to multiple system user
> accounts.

Of course not really, one kernel exploit and you're done. LXC doesn't
help it at all - which is why Docker is madness from security point of
view.
SELinux, AppArmor and especially PAX (from grSecurity) help somewhat
by making it harder to execute exploits, but they are not infallible.

> This is common practice for various system services. Some
> power users follow this approach for security gains. But following this
> approach requires manual maintenance, and many users don't bother to do
> that because this looks complicated.

Wrong. Distributions actually do it for important but predictable
services (e.g. systemd, PulseAudio) quite often, but not for
everything - and you cannot unshare X without a major loss of
functionality yet. (OpenGL)
Fedora uses SELinux, while Ubuntu uses AppArmor. These are usually
much stronger than the buggy Linux Containers. (just read CVEs)

You could generate per-user and/or per-application additional security
rules for these MAC systems. I've tested this approach myself in
securing Firefox on a less secure distribution. You get about as much
inconvenience as in Qubes - a special directory you can write to and
read from; optionally a bunch of rules to allow microphone, sound
device access and OpenGL (DRM device).

It is not appreciably faster, but can grab a lot more memory, so you
can run many more tabs.

In fact, you could get a lot of additional "security" by just changing
$HOME when running more than one web browser instance.

> My proposal is to develop this approach to the level of Qubes OS, to
> provide visibility and ease, and to guide the beginners about good
> practice. This will apply much lower hardware resources requirements
> than Qubes OS

Which resources? Memory? Maybe. Disk? Maybe a bit, but it's usually
not important.
Instead, fix the resource hogs, such as web browsers, to work properly
in lower memory conditions, or work to enable frontcache/frontswap in
Qubes, with a big fat warning.

> Of course, this is totally different (lower) level of
> security comparing to Qubes OS, but it is still an improvement comparing
> to usual Linux setup: before, an application exploit would get access to
> user data immediately, and now it has nothing except what is given to
> that pseudo-user dedicated to running particular app, unless the
> attacker hacks the OS kernel.

That's a big unless. Any not completely worthless attacker will use a
secondary payload (or multiple) to attempt bypassing kernel security.
It's a requirement in this SELinux, AppArmor "infested" world.

> The latter is feasible, but requires quite
> more advancement from the attacker, making user of proposed approach
> vulnerable in quite less share of cases.

No, it doesn't, for the reasons explained above.

> This isolation scheme allows also usage of Split GPG technique.

Again, good distros could have an SELinux/AppArmor/grSecurity rule
essentially enforcing split GPG for the same level of security as in
LXC-based design (or better), without any modifications.

R.

[Radoslaw Szkodzinski]

Oh, I've forgot to mention. In my personal experiment, Xen can run a
Linux PV domain with a DNS server in about 64 MB of RAM and with
decent performance. 32MB when I've experimented with uclibc and x86
target.
A pure X server with Fluxbox and you're looking at ~160 MB for this to
work properly with any applications.

Certain ARM embedded devices have 256 MB of RAM and they can run linux
desktop, albeit very slowly and have major trouble with hoggy web
browsers.
Qubes does not need or want most of the desktop environment running
inside each and every VM - it's additional (but relatively
unimportant) attack surface.

R.

[qubesloverno1]

warning: the below message is intended to be technically accurate and funny, not offensive.

"... (but relatively unimportant) attack surface."- 4 great fucking years with fuckin qubes but this one fucking thing makes my fucking eyes and ears bleed all over the fucking place (see note #3 beow). fucking-a man, for the fucking love of fucking fuck and for fucks sake will you fucks cut this fucking shit out? thanks. :)

"mostly because certain web browsers cannot deal with low memory properly."- no fucking offense but here's a fucking brotip: fuck your fucking browser, the fucker that fucking wrote your fucking browser, and fuck anything that fucking looks like your fucking browser. what the fuck? qubes is not a fucking web browsing platform (re:whonix)

"... Xen can run a Linux PV domain with a ... "- not on fucking qubes it fucking doesnt. it fucking can (fuck yes, it fucking totally can), but that doesn't fucking change the fucking fact that it fucking doesn't... now does it fucker? 

the main point is that qubes needs to de-bloat itself in general, and in the process it should ditch fedora (arguably the dumbest possible option from available popular distros, anything worse than fedora would be sinfully and insultingly insane) for trisquel (probably the only possible intelligent solution for qubes... no arguments please, your obedience is sufficient by itself). while were at it please fix the way disposable vms are implemented. right now dispvm functionality is a short-sighted yet elegant firefox wrapper hackjob. we should have multiple dispvm-templates from any templatevm and a user action response system that isnt tied to the health of a browser process (how many times do i have to close a browser window and watch other apps die?). the implementation is so short sighted it hurts my feelings (re:whonix). the more you read this paragraph the more you should understand why andrey even bothered to rethink what qubes should be and he was playing with some generally intelligent ideas as potential alternative design decisions. his lack of experience in certain areas are clear in his suggestions but the reason behind his dialogue is the confusion caused by a few seriously fucked up design decisions (i was there, i know where they came from, no need to explain, just fix plz). the technically immature parts of suggestions should not distract us from this.

*Note 1: the word "fuck" as it appears above is used as an industry-specific technical term. "fuck" was chosen for comedic value and as a demonstration of a type of linguistic madness only available in the english language. furthermore, profanity can and should be used metaphorically to express complex sentiment and emphasize magnitude in the interest of efficiency, thus rendering some of the more vulgar technologists among us into champions of environmental conservation and saving valuable computational and communication resources for the rest of the noobs. the word "fuck" is in no way meant to imply direct or indirect offense to the great lady joanna, the hard working members of the qubes team, or the dumbass noobs who use it.

*Note 2: yes, i am stating that qubes intentionally and thoughtfully picked the arguably dumbest possible distro (within reason), and that the stupidity of this decision is abundantly obvious, thus increasing the magnitude of this negligent crime. please don't be insecure about this (pun intended) - i should be allowed to respectfully offer constructive criticism without degrading my respect and appreciation for qubes and the selfless people who build it. in the interest of fairness i should say here that with some work qubes can be cleaned up by the user, i have used it for many years, and i also acknowledge that qubes is basically evolving into the odyssy framework and that qubes-os is the POC implementation of that framework without really trying to address everything else under the sun. that said, the qubes-fedora thing is to joanna as the 1 button mouse was to steve jobs (except steve had half of joannas intelligence so we should be more critical of joanna... we would not want to spoil her).

*Note 3: there is a similar "dont worry qubes fixes everything" argument from 2013 on this list. the exact same flawed logic (joanna please forgive me) from below applies to your "relatively unimportant" argument. exploit chains love bloat (and false negatives). exploit chains will take whatever they can get. period.
sauce: https://groups.google.com/forum/#!msg/qubes-devel/Er3WukiA-bI/B2c9eQtXjEoJ
revenge: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-007-2013.txt
kilo revenge: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-015-2015.txt
mega revenge: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt

lol @ "scary scary."

p.s. <3 joanna. H8 fedora.

[paymo...@gmail.com]

oh, i forgot to include that the value of what andrey is suggesting is that he was pointing at the design decisions behind making an abstraction layer to support alternatives to xen. Much more importantly as everyone mentioned in this thread, although qubes focuses almost exclusively on attack surface reduction and not on "hardening", something like lxc, chroots, mount options, user separation, permissions etc can be added as an additional layer (both in dom0 and in domu).

andrey might not have organized his message this way, but he is both asking for hardening to be added to qubes and he is also asking for the odyssey hal to be ported and developed (making xen and traditional hypervisor virtualization optional). I think the latter is in process and has high priority, but the former shouldn't be missed.

[Radoslaw Szkodzinski]

On Wed, Nov 25, 2015 at 7:52 PM, <paymo...@gmail.com> wrote:
> oh, i forgot to include that the value of what andrey is suggesting is that
> he was pointing at the design decisions behind making an abstraction layer
> to support alternatives to xen.

You're talking about HAL. This is being done but is not quite ready yet.
LXC is a major complication for HAL, unlike supporting other
hypervisors e.g. KVM.
Libvirt has only basic support for setting up LXC - and does so in a
patently insecure way, because it does not have enough information
about the usage of the container.
Trying to implement specific code specifically for setting up LXC is a
lot of work and easy to get wrong. Look at Docker CVEs.

There are much more productive uses of time related to security, such as...

> Much more importantly as everyone mentioned
> in this thread, although qubes focuses almost exclusively on attack surface
> reduction and not on "hardening", something like lxc, chroots, mount
> options, user separation, permissions etc can be added as an additional
> layer (both in dom0 and in domu).

Qubes can run your chosen defense in depth already. (Either in HVM or
in PV; pick properly configured distribution of your choice.)
Feel free to implement your own hardened template and publish it. It's
even been done. (Whonix, Arch Linux, someone has made Gentoo work
incl. dom0 I think.)

Fedora itself is a somewhat iffy choice - it has some degree of
SELinux hardening, but not a lot. I think it was chosen mostly for
developer convenience.

If you mean "switch default templates to distro <x>", consider that
first those templates have to be implemented.
For example, running a nicely working NetVM or SoundVM requires
non-negligible modifications of the template startup scripts.
The security benefit might not be as big as you think - as long as
you're using Qubes VM separation properly and extensively.

Mount options are worthless as most of the file system is tossed -
essentially read only.
Internal VM permissions are largely worthless, because there are few
external devices to control and the VM is designed to be used by a
single user, preferably for a single task.
Qubes Dom0 is still essentially single user too.

> andrey might not have organized his message this way, but he is both asking
> for hardening to be added to qubes

Fedora 16 has partial hardening, applications are built with stack
protector and PIE, SELinux is enabled and configured for some
services.
I'd like additional kernel hardening such as PAX.

> and he is also asking for the odyssey hal
> to be ported and developed (making xen and traditional hypervisor
> virtualization optional). I think the latter is in process and has high
> priority, but the former shouldn't be missed.

He was asking specifically for LXC/Unix accounts and for reasons that
are not security-related. Yes, improving Qubes usability should be an
important factor, but consider the available resources and how well it
currently works.

I've explained why "convert security model to use LXC/chroot for
separation" won't net anywhere near as much of an improvement as he
thought, unless you relax device separation much more to include
OpenGL or abolish hard file system barriers between containers.

>> warning: the below message is intended to be technically accurate and
>> funny, not offensive.

You seem to have failed, it does not come across as funny, but as a troll post.
I have skipped sections because the tone is clearly a troll one and is
disgusting. Please do not continue using it.

>>
>> "mostly because certain web browsers cannot deal with low memory
>> properly."- no fucking offense but here's a fucking brotip: fuck your
>> fucking browser, the fucker that fucking wrote your fucking browser, and
>> fuck anything that fucking looks like your fucking browser. what the fuck?
>> qubes is not a fucking web browsing platform (re:whonix)

But it is a web browsing platform among other things. One of the main
use cases is to do internet banking or shopping in a much more secure
way.
Specifically, so that in case your random gaming and video site crack
does not even have a chance at getting your important banking data or
faking the banking website.
Similarly, access to webmail might be important.

There are alternative browsers that do not explode with <1 GB of RAM,
but sadly they do not support enough fancy JavaScript, DOM and HTML5
for certain sites to work at all.
(I might be wrong here, pure Webkit might be enough and not have such
issues; I have only tried Chrome, Chromium and Firefox.)
So the currently best answers involve both fixing the hogs and
evangelism to not require the hogs.
Tossing more memory at a problem will only delay it for some time.
I've seen these have trouble on a machine with 16 GB RAM after
prolonged usage.

If power saving is more important than security, why not use a less
secure distribution instead? Or in fact, just not use Linux and go
straight for Windows, where vendors do most of the work.
Alternatively, why not fix Xen? (The last part is much easier said than done.)

>> while were at it please fix the way disposable vms are implemented.
>> right now dispvm functionality is a short-sighted yet elegant firefox
>> wrapper hackjob.

Which can apparently run GPG signature verification and display PDFs.
Oh, and also open LibreOffice documents.
It can even partly scrub PDFs into safer form.

>> we should have multiple dispvm-templates from any
>> templatevm

Please do it and show why it is better. It's not even hard.

>> *Note 2: yes, i am stating that qubes intentionally and thoughtfully
>> picked the arguably dumbest possible distro (within reason), and that the
>> stupidity of this decision is abundantly obvious,

Putting the terrible troll tone aside for a sec...

Porting Qubes toolkit to another Linux distribution is not really that
hard. Now, developing it is another matter altogether.
See above.

It's mostly open source, the closed parts are for Windows. The code is
quite readable and modern, reasonably distro-agnostic.
Will be a bit more work now to get it running without systemd, but
it's still doable.

Keeping all of this up to date and running requires a lot of work
though; not to mention that ITL is involved in finding bugs in and
fixing Xen too.

>> thus increasing the
>> magnitude of this negligent crime. please don't be insecure about this (pun
>> intended) - i should be allowed to respectfully offer constructive criticism
>> without degrading my respect and appreciation for qubes and the selfless
>> people who build it.

This is not constructive criticism and the tone is terrible.

>> in the interest of fairness i should say here that with
>> some work qubes can be cleaned up by the user, i have used it for many
>> years, and i also acknowledge that qubes is basically evolving into the
>> odyssy framework and that qubes-os is the POC implementation of that
>> framework without really trying to address everything else under the sun.

Excellent. You know what helps convert POC into high quality software?
Development.
Not criticism, especially totally not constructive. Bug reports?
Maybe, if you can use them.

>> *Note 3: there is a similar "dont worry qubes fixes everything" argument
>> from 2013 on this list. the exact same flawed logic (joanna please forgive
>> me) from below applies to your "relatively unimportant" argument. exploit
>> chains love bloat (and false negatives). exploit chains will take whatever
>> they can get. period.

Please do show such an exploit chain in use, starting from, say, a
juicy target like Firefox or Chrome or some email client, and show
which steps prevent it.
I bet LXC is not even on the list. It's either stopped by fixing the
darn thing, or using mitigation measures like NoScript which prevent
the exploit from running or PAX/stack-protector/ASan which *will*
crash the browser instead in many cases.

Once this barrier is past, generally the attacker has everything they
want - because achieving actual superuser access is pretty easy. Even
a local user exploit allows a plenty of possibilities.

--

LXC (not even mentioning Unix user) does not make an exploit that much
harder and does not provide strong enough file protection. It's not an
empty assertion, but is backed by known CVE history.
Xen CVEs generally required a lot of low level knowledge to exploit
and find and yet more to fire reliably.

Of course, it would be nice to switch to a more secure mechanism than
Xen at cost of functionality for specific usage. This is why Odyssey
is important, but very definitely not why one should use LXC or Unix
accounts as the backends.

Unix accounts and LXC are simple to make irrelevant via techniques
similar to double chrooting, exploiting wrong permission setup, VFS
bugs or any number of kernel driver bugs we know and don't. The attack
surface is humongous.
Ones set up directly via Libvirt are even more vulnerable. See Docker
CVEs for examples of issues that are strictly related to LXC setup,
and they were already much smarter than Libvirt at it.

--

Analogy time: (instead of abuse of f-words)
You do not put a padlocked wooden box in a wall safe to achieve
additional security for things stored in the safe. You build a better
safe and place the safe in a concrete bunker with guards.
(Yes, this analogy is a bit mean to LXC and Linux security devs. But
that's how it is. LXC is a padlocked box compared to Xen being a
standard safe.)

I'd say that much better examples would be use of PAX or executable
hardening techniques.
(Such as building everything with the newfangled Address Sanitizer
enabled, at a non negligible cost; stack protector and PIE are low
cost and easy in comparison.)
Equivalent to writing your important letter on hard to copy paper in a
code. Harder to crack, but obviously not impossible.
The trouble is, you need to rebuild and/or fix most of the packages;
3-5 people are probably not enough to handle the resulting problems
and especially QA issues. A good start would be to consider truly
critical packages, arbitrarily.
Or get a huge player interested in desktop security from this point of view.

We could use improved attack/issue detection and notification - so
that you can avoid using a compromised VM.
Similar to a fire alarm. Good when there's only a small fire, does not
help if everything of importance burned down.

Dynamic VMs help with this a lot of course, but you seem to be averse.
That is the equivalent of putting your documents in a self destructing envelope.

Enough of this silliness. There are better uses of our time.

--
Radosław Szkodziński

[Paymon Sharif]

ok sorry for the tone if you don't find it funny. i didnt think it was a troll post given i put a warning at the top and put in a cleverly articulated joke at the bottom, but that doesnt stop me from appreciating the attention to detail with which you responded to my post given the fact that you found it "disgusting". i hope you enjoy responding to this email more than the last one, but id like to add everyone should lighten up a bit. 

"Trying to implement specific code specifically for setting up LXC is a lot of work and easy to get wrong. Look at Docker CVEs."

my mere mention of LXC kind of derailed the conversation. I do not look at LXC in and of itself as a very useful hardening method in the context of qubes. i mentioned it in the context of the HAL and to touch on the suggestions in the original post. in addition i pointed out that the reason OP was going in the wrong direction is that he was confused by the resource intensiveness of qubes. what he really needs is less bloat, not a switch from xen to LXC (this is why i started bashing the fedora choice). perhaps my "funny tone" was distracting. we agree on the topic of LXC though.

"Fedora itself is a somewhat iffy choice - it has some degree of
SELinux hardening, but not a lot. I think it was chosen mostly for
developer convenience."

- ok so we agree here too. i even eluded to this when i said "i was there, i know where they came from, no need to explain". that doesnt mean that we should standardize the 3rd non-beta release of a mission critical computational instrument on a lab/dev tool out of convenience, unless qubes wants to maintain that qubes-os is an experimental POC not recommended for real world use. the users however are SO appreciative of how awesome qubes is that the type of craziness that can plainly be seen on the mailing lists resulting from fedora hasn't killed the user base (and i would argue that it wont).

"Qubes can run your chosen defense in depth already. (Either in HVM or
in PV; pick properly configured distribution of your choice.)
Feel free to implement your own hardened template and publish it. It's
even been done. (Whonix, Arch Linux, someone has made Gentoo work
incl. dom0 I think.)"

- i did, thanks to joanna, qubes dev team, whonix, and some of my own time. that wasnt the point. the point is that qubes ships a non-beta FOSS product that deserves and demands the constructive contributions (whether through criticism or through code submission). furthermore, the projects you mentioned have voiced many of my same concerns for the same reasons that i voiced them in this mailing list. the point is not to make me happy (why dont you go do this or that), the point is to make qubes better because i appreciate your work. you might not like all of my criticism but you DEMANDED it when you published qubes.

"If you mean "switch default templates to distro <x>", consider that
first those templates have to be implemented.
For example, running a nicely working NetVM or SoundVM requires
non-negligible modifications of the template startup scripts.
The security benefit might not be as big as you think - as long as
you're using Qubes VM separation properly and extensively."

- i am advocating the change from fedora to something sane for dom0 and also for the default template. permanently. i would argue for the health of the project that lab/experiment time should be over at this point and i would also suggest that the developers consider trisquel because of obvious reasons (there is no answer to "what is the best linux distro?", but for qubes i think there are very few contenders). that said i appreciate the amount of work that needs to go into compensating for the original choices after such a long time, so it would not be fair to think i am trivializing the issue (used qubes long enough to know). dont look at me though, the longer you continue the mistake the more it hurts to fix it.

"Mount options are worthless as most of the file system is tossed -
essentially read only.
Internal VM permissions are largely worthless, because there are few
external devices to control and the VM is designed to be used by a
single user, preferably for a single task.
Qubes Dom0 is still essentially single user too."

- although i agree with the points you made, you are completely neglecting features like non executable file systems, nosuid, etc etc. combine that with chrooted processes and there is a whole new world of "your exploit wont work here" instead of "your exploit is mitigated here, have fun trying to do anything, you will probably and hopefully fail". granted the "probably and hopefully fail" part of that sentence is very powerful if you use qubes properly, but we now know that there were exploit paths (xen+browser,etc) that would have been mitigated with more hardening, especially against non-targetted/live attacks.

"So the currently best answers involve both fixing the hogs and
evangelism to not require the hogs."

- for humanity yes, but i think for qubes the answer is more immediate and simple. qubes should tighten up the resource requirements and make conservative defaults, especially ditching fedora. furthermore there shouldnt be a one-size-fits-all, "dump all your binaries here", template. if i am browsing the internet i dont need to have executable, system integrated, library-happy, executable binaries from anything else to be lying around for privilege escalation convenience. there should be separate default templates for sys-net and sys-firewall (which shouldnt launch and grab 3gb of my ram btw), and a separate "application specific template" for things like libreoffice and the more common application templates (firefox, libreoffice, etc) should have disposable variants (there is some current movement towards this like fedora minimal). the storage/cpu/ram per template should be tuned to the intended application for the template. then if someone wants to run something bloated and hog their resources its a choice, not a requirement. the whole firefox/libreoffice/trustedpdf/dispvm approach is an excellent example of a wonderful implementation, except i would advocate different disposable templates for firefox, libreoffice, etc. the list of things that should ship with qubes that would need this type of attention is not long, especially if you throw out all the bloat from fedora and include software on an as-needed basis.

"Excellent. You know what helps convert POC into high quality software?
Development.
Not criticism, especially totally not constructive. Bug reports?
Maybe, if you can use them."

although i agree with encouraging dev and bugreports, i dont see why you would prioritize development and bug reports over design decision dialogues, which are INFINITELY more important. i might in some ways think youre short sighted and you may think im disgusting, but less experienced users and developers will learn from our arguments and regardless of the outcome qubes will either change for the better or stay the same for the better after being discussed. there has definitely not been enough discussion on some of these topics, and this is probably largely due to the amazing skill and talent within the qubes team. who will have these discussions with you out of the qubes user base? journalists and oppressed students from third world countries with their massive infosec expertise? government intelligence communities? UFO hunters? criminals? no. you are stuck with the disgusting, immature, funny hackers like me. sorry bro, but if i don't add a counterbalance of feedback and accountability what kind of qubes user will? im just here to help make design decisions and you might have some qubes users more experienced than me to do that (i have seen some weak attempts from seemingly intelligent people) but dismissing what I say because i am "disgusting" is pretty short sighted. you are not inviting me to contribute to qubes with your tone, you are inviting me to fork qubes (which i wont because this is much better).

"Please do show such an exploit chain in use, starting from, say, a
juicy target like Firefox or Chrome or some email client, and show
which steps prevent it.

Once this barrier is past, generally the attacker has everything they
want - because achieving actual superuser access is pretty easy. Even
a local user exploit allows a plenty of possibilities.
"

i like to get in the way of those possibilities. here i go (im sure ill miss something so take this with a grain of salt) firefox chrooted into a read only ramdisk with tmp folders mounted on another rw noexec ramdisk  inside a vm with every file and binary whitelisted for firefox inside of the chroot, and a very minimal setup outside of the choot, including chrooted X on a ro filesystem with tty device node on a dedicated ramsidk so all the other filesystems can have sane mount options without having to support dev nodes etc. between file system permissions, mount options, and chroots there are much much much fewer usable attack vectors. preference for ramdisks for antiforensics as well. the attacker would have a hard time taking advantage of exploits through a juicy target on qubes to escalate further. if you cant execute anything interesting, you cant bring your own executables easily, and the attack surface is uninteresting, you then have to rely on special case scenarios that are highly unlikely even with an awesome collection of zero days for your attack to get you more than you already have (for example if i use qubes properly and go to a website with FF they know whats in my browser DOM already because they just served it to me, so if they exploit FF and stop there they got nothing, now if they can have free reign of my FF VM they could potentially escalate privileges both theoretically and practically... for example xen is great but we have seen some recent events that... well... you know). you can quote me on this: for any given highly skilled technologist, it is highly likely that the highest priority failures will be from highly unlikely events, and thus tolerance for highly unlikely events should be a floor threshold for failure and not an end goal. qubes needs to take this even more seriously in my not-humble-in-this-case opinion (bold statement considering this is qubes but i stand by it).

"You do not put a padlocked wooden box in a wall safe to achieve
additional security for things stored in the safe. You build a better
safe and place the safe in a concrete bunker with guards."

as i explained earlier about my stance on LXC this statement is misleading in context of my message because i am not an LXC advocate and therefore i am not suggesting a "wooden" box. in my world the guards are the hardening in dom0, the bunker is qubes odyssey, and the safe would be best practice paranoid linux hardening inside the vm. right now we just have a bunker with plenty of space for fooling around, though nothing is SUPPOSED to penetrate the concrete to get out and hurt the guards.

"The trouble is, you need to rebuild and/or fix most of the packages;
3-5 people are probably not enough to handle the resulting problems
and especially QA issues. A good start would be to consider truly
critical packages, arbitrarily."

YAY! now youre talking my language! that would be cool. im sure you agree why using fedora as shipped with qubes is a bad starting point for this (or pretty much anything qubes related). im sure you can think back on the mailing list about some complaints.

"We could use improved attack/issue detection and notification - so
that you can avoid using a compromised VM.
Similar to a fire alarm. Good when there's only a small fire, does not
help if everything of importance burned down."

a HIDS in the template and a NIDS inline as a gateway is  a good start and straight forward to do with qubes. very elegant because the hids in the appvm can log to the nids inline and qubes facilitates this nicely. it just comes down to tuning after that. in fact my qubes machine is basically an entire infrastructure in a single box.

"Enough of this silliness. "

at some point if we ever become friends id like to go back to talking silly but only if it doesnt offend you. im not even being sarcastic here... profanity is the precipice of prose until someone is pissed.

"There are better uses of our time."

ok so you asked me not to be profane and im going to ask you not to be arrogant. it shouldnt be hard to imagine that people like me are your most valuable users, because unlike those who blindly use qubes or ditch it because of some religious reasons (no feedback from either),  im one of the subset who have both the inclination and knowledge to give meaningful feedback. right now qubes is a genius implementation of genius concepts programmed by geniuses who also picked a few wrong tools and mislabeled some releases in my not-so-humble-in-this-case opinion. what will qubes be in the future? i have very very high hopes and confidence but i can tell you this: without some users like me you will just become venture-bait for the next noobs that want to add infosec to their investment portfolio before you watch them trash your beautiful work (i predict whoracle). as i sad earlier in this email you can theoretically get feedback from students (low skill), journalists (no skill), criminals (no contact), pedophiles (wtf), military (yeah right), intelligence (if they find something wrong theyll exploit it not fix it), infosec noob wannabes (no skill), and last but not least people who are both willing and able but perhaps "disgusting". i dont take offense to your disgust because i know as well as you do that when you read my message you were thinking "oh god heres a jackass that doesnt know what he is talking about but somehow has enough knowledge to force me to waste my time and demands a detailed response because everyone is reading this on the mailing list blah blah grumble grumble" so you felt "disgusted". you might be distracted by my poetic profanity (i'd rather you werent so ill cut it out) but you should know now that i am not a dumb conversation partner. at minimum anyone good enough to appreciate your work out of understanding (not just because they like it) is good enough that you cannot be arrogant with them or dismiss their feedback (the fact that i'm right makes this point more important, and to your benefit it is worth mentioning that i couldnt be right if i didnt already agree with almost everything you said, in fact much of this email was written to clarify that i agree with you).  

[Radoslaw Szkodzinski]

Please show how Trisquel is better for security. Credible points, not
handwavium.
Cost benefit analysis.

From what I see, they don't support MP3 playback out of the box for a
reason. They cut functionality not for security reasons, but for legal
reasons.
Security itself is not a major focus at all in it from what I can see or read.
There has not been a release in quite long time.

> that said i appreciate the
> amount of work that needs to go into compensating for the original choices
> after such a long time, so it would not be fair to think i am trivializing
> the issue (used qubes long enough to know). dont look at me though, the
> longer you continue the mistake the more it hurts to fix it.

Provide an actual alternative that is reasonably better than Fedora at
being a desktop.
Remember that we do not care about the desktop environment as long as
it's trimmed.

> "Mount options are worthless as most of the file system is tossed -
> essentially read only.
> Internal VM permissions are largely worthless, because there are few
> external devices to control and the VM is designed to be used by a
> single user, preferably for a single task.
> Qubes Dom0 is still essentially single user too."
>
> - although i agree with the points you made, you are completely neglecting
> features like non executable file systems, nosuid, etc etc. combine that
> with chrooted processes

Chrooted processes are again worthless in Qubes.
No amount of filesystem protection will stop local kernel exploit from
working - unless it has to be launched from the filesystem. It's at
best a minor inconvenience.

Many, if not most, VFS bugs were related to either special FS like
proc, sys, dev or to actual writes, not execution.

>and there is a whole new world of "your exploit wont
> work here" instead of "your exploit is mitigated here, have fun trying to do
> anything, you will probably and hopefully fail".

Chroots don't mitigate exploits on their own. (What they do is enforce
partitioned design and focus on interfaces. If you replace chroots
with VMs, you should get additional security at additional cost.)

> granted the "probably and
> hopefully fail" part of that sentence is very powerful if you use qubes
> properly, but we now know that there were exploit paths (xen+browser,etc)
> that would have been mitigated with more hardening, especially against
> non-targetted/live attacks.

Please provide an example of such an attack that would be mitigated by
adding a chroot, or making the file system noexec, or making the file
system nosuid.
Note that it does not have to be already mitigated by Qubes separation.

> "So the currently best answers involve both fixing the hogs and
> evangelism to not require the hogs."
>
> - for humanity yes, but i think for qubes the answer is more immediate and
> simple. qubes should tighten up the resource requirements

The resource reqs of Qubes alone are slightly lower than of Fedora
itself. I've checked. The cut down KDE is very nicely trimmed.
Start it, launch one or two applications. Measure memory usage.

Do the same on a distro of your choice with same applications, but
much lower security. Compare. Do this after replacing the applications
with tiny variants, measure again.
Data, not assumptions.

What you're advocating is really premature optimization.

> and make
> conservative defaults, especially ditching fedora.

This sounds like "I hate Fedora but I can't say why." There are valid
reasons to dislike it of course, but you need to actually say them.

What does "conservative defaults" mean? It's still a desktop, not a
single use web appliance.

> furthermore there
> shouldnt be a one-size-fits-all, "dump all your binaries here", template.

Because? What is improved by removing such a template?

Definitely not maintenance or ease of development. Or ease of use.

> if
> i am browsing the internet i dont need to have executable, system
> integrated, library-happy, executable binaries from anything else to be
> lying around for privilege escalation convenience.

You don't. But do actually explain the threat model behind this reasoning.
Is it script kiddies with poor scripts?

> there should be separate
> default templates for sys-net and sys-firewall (which shouldnt launch and
> grab 3gb of my ram btw),

They don't. They reserve up to 256 MB ram each (I'll have to check the
actual number). You could make them smaller somewhat too, I mean, to
about 128 MB each.
The main gobbler in NetVM is... Network Manager's GUI, which requires X.

However, replacing that with code in Dom0 is foolish from security
PoV. Factoring it out into a separate "display VM" is a lot of work
for not a lot of memory saving and major increase in Qubes comm
protocol complexity.
The latter means bugs and security issues.

> and a separate "application specific template" for
> things like libreoffice and the more common application templates (firefox,
> libreoffice, etc) should have disposable variants (there is some current
> movement towards this like fedora minimal).

Please explain how this helps over having an icon that launches a
disposable VM with this running.
I'm not being facetious here at all.

> the storage/cpu/ram per template
> should be tuned to the intended application for the template.

Do it. See what you can and cannot do. I've tried myself, the gains
are... less than satisfactory. And it's a lot of work.
Note that Qubes templates do not run a pretty large chunk of DE already.

Again, the main hog in a GUI VM is... actual GUI subsystem and actual
target application.

If you want Qubes ballooning to be more tweaked towards faster
changing requirements, why not say so? And preferably do so.
Feel free to also try to use Xen's autoballooning, frontswap,
frontcache and *post the results*.

I've actually had trouble getting Qubes to play nice with that stack.

> then if
> someone wants to run something bloated and hog their resources its a choice,
> not a requirement.

It never was. Strawman if I ever seen one. The user picks what they
run, mostly. The extras are vastly limited, run ps or top in the VM to
see them.

> the whole firefox/libreoffice/trustedpdf/dispvm approach
> is an excellent example of a wonderful implementation, except i would
> advocate different disposable templates for firefox, libreoffice, etc.

See above about having to at least explain how it is better. I've
considered this problem personally at length too and came to different
conclusion.

> the
> list of things that should ship with qubes that would need this type of
> attention is not long, especially if you throw out all the bloat from fedora
> and include software on an as-needed basis.

Assumption. Please provide data.

> "Excellent. You know what helps convert POC into high quality software?
> Development.
> Not criticism, especially totally not constructive. Bug reports?
> Maybe, if you can use them."
>
> although i agree with encouraging dev and bugreports, i dont see why you
> would prioritize development and bug reports over design decision dialogues,

You need to first show that you're going to need a thing before you
implement it. You haven't done that.
This is not design discussion until you do so.

> which are INFINITELY more important. i might in some ways think youre short
> sighted and you may think im disgusting,

Thank you for appreciation. :E Maintainability was never a
consideration in your alleged untested design, was it?

> communities? UFO hunters? criminals? no. you are stuck with the disgusting,
> immature, funny hackers like me.

I prefer immature, funny hackers that provide proofs of concepts
and/or actual design with pros/cons. Much better than handwaving.

> sorry bro, but if i don't add a
> counterbalance of feedback and accountability what kind of qubes user will?

It's not feedback, you're trying to redesign Qubes, without actually
verifying the properties of current and target design. Might as well
just not redesign it and develop at random.

> im just here to help make design decisions

You're not with this kind of approach.

> "Please do show such an exploit chain in use, starting from, say, a
> juicy target like Firefox or Chrome or some email client, and show
> which steps prevent it.
>
> Once this barrier is past, generally the attacker has everything they
> want - because achieving actual superuser access is pretty easy. Even
> a local user exploit allows a plenty of possibilities.
> "
>
> i like to get in the way of those possibilities.

I like that too. Please build a proof of your concepts.

> here i go (im sure ill miss
> something so take this with a grain of salt) firefox chrooted

It is already in a virtual machine. What does the additional chroot get you?

>into a read
> only ramdisk

Template VM is already read only - you'll modify the volatile part of
it. You have prevented access to disk, but the attack still has all
kinds of access to memory.

> with tmp folders mounted on another rw noexec ramdisk

You mean like a volatile image in DispVM or AppVM? It's already there?
AppVM has the home directory persisted for a reason. This is why it's
not a DispVM.

Noexec flag does not change the fact that the attacker who broke
Firefox can do anything with Firefox memory, including loading code
and running it inside Firefox process space.

> inside a
> vm with every file and binary whitelisted for firefox inside of the chroot,

Again, if the attacker broke Firefox, they can upload any payload they
like into memory and execute it.

> and a very minimal setup outside of the choot, including chrooted X

What does this buy when X is already in the VM other than vastly
increased setup complexity?

> on a ro
> filesystem with tty device node

Beautiful. Now X has access to real TTY? Actually, in Qubes it doesn't.

> on a dedicated ramsidk so all the other
> filesystems can have sane mount options without having to support dev nodes

Devices in Xen VM are plenty limited already. You mean lack of access
to /dev/zero will make an exploit harder?

Lack of access to /dev/xvba etc. does not prevent anyone from invoking
Xen hypervisor APIs more directly or make it much harder at all.

> etc. between file system permissions, mount options, and chroots there are
> much much much fewer usable attack vectors.

You haven't shown that at all.

> preference for ramdisks for
> antiforensics as well. the attacker would have a hard time taking advantage
> of exploits through a juicy target on qubes to escalate further.

They will not, they can upload half a linux into Firefox process space
and go from there. Well, unless you're on a metered connection.

I'm actually making a hyperbole - a full linux system can fit in about
2 MB. (It does in initramfs.)
You prevented me from executing command "cat" from disk? I'll send you
busybox in a payload.
(Probably not necessarily in the primary one if I'd be running a
widely deployed attack, but in a secondary to compromised machines.)

> if you cant
> execute anything interesting, you cant bring your own executables easily,

You can. Extremely easily. You've shown that you cannot *write them to
disk*, so persistence is a bit harder. Although nowadays people do not
like to restart machines, virtual or otherwise.

But again, not harder than in a DispVM which is already there and implemented.

> "The trouble is, you need to rebuild and/or fix most of the packages;
> 3-5 people are probably not enough to handle the resulting problems
> and especially QA issues. A good start would be to consider truly
> critical packages, arbitrarily."
>
> YAY! now youre talking my language! that would be cool. im sure you agree
> why using fedora as shipped with qubes is a bad starting point for this

No, it's an ok starting point. There is decent support for external
repositories - which Qubes already uses for its modifications.
To use another distribution you get to port the advanced update
mechanism there too or sacrifice the added security it brings.
If you get to rely on untested or buggy tools to do so, you're very
definitely not better off.

Also remember it's a desktop, not mostly immutable server. Something
like Debian Stable or RHEL would get pretty annoying quickly.
It could make sense to use one of these in a NetVM or a ProxyVM
though. People have attempted FreeBSD NetVMs. I don't remember if they
were successful.

> "We could use improved attack/issue detection and notification - so
> that you can avoid using a compromised VM.
> Similar to a fire alarm. Good when there's only a small fire, does not
> help if everything of importance burned down."
>
> a HIDS in the template and a NIDS inline as a gateway is a good start and

It's not a good start at all. It's a "nice to have" thing that is not
essential as long as you use the security features of Qubes properly.

To begin with, show me a HIDS and NIDS that actually work in an actual
*desktop* environment. I bet you don't have anything on hand - it's a
major effort to get it to work reasonably with low false positive
rate.

The former is very tricky to implement too, and you cannot just really
run it inside the VM where it can be easily circumvented - but that'd
be better than nothing still.
Running it in Dom0 is a major security risk. It is a complex piece of
software with many failure modes.
So, now you get to implement a monitoring domain which Xen might be
able to do, but I haven't been able to coax it to do so.
Using some framework like Volatility to inspect the critical paths in
a VM memory space; having a peek at the volatile image file to spot
garbage.

The NIDS is best run in a ProxyVM.
You still need appropriate GUI for the target end user somewhere.

Note this vastly conflicts with your "save resources" concept.

Take care,
--
Radosław Szkodziński

[Paymon Sharif]

before we go further thought i should add something for clarity and to make sure you understand some of the assumptions behind my thoughts (in a nice quotable run-on sentence format):

for a given scenario in which a system with high security requirements and measures to meet those requirements (that do not involve sensitivities or compromises regarding user negligence, user adoption, or user ignorance) and for a given threat to that system which has a given set of capabilities in such terms as human resources, computational resources, communication resources, tricks, intelligence, and exploits - some of said attacker capabilities can be mitigated or eliminated through some of the security measures that one might otherwise be tempted to dismiss out of seeming irrelevance or laziness, because said measures break dependencies or introduce delays for the meeting and/or bypassing of said dependencies for a combination of said capabilities to perform meaningful penetration and compromise, and considering that the window of opportunity for the attack is always limited by definition thus magnifying the mitigation capability of said measures in many cases (especially in the case of an intelligent target with an environment that requires exploration for meaningful penetration),  the best approach is for any given system with any given security measures is to use all of said security measures except in the case where the introduction of said security measure would degrade system security or make impossible the introduction of a more important security measure - thus implying that the selection of said security measures for architectural inclusion within said system should also be prioritized for inclusion based on metrics such as impact and mitigation value, noting that the ideal implementation of said systems architecture will have to be re-prioritized on a per application basis to maximize the effectiveness of the conglomerate set of system security measures in mitigation of compromise.

i know qubes is not the security hero for everything under the sun, but given the above philosophy (which applies to most of the "relevant" qubes users) i would argue that right now qubes needs to be sandwiched between a hardened domu and a hardened dom0. we have both mentioned whonix and other projects for example but i want to see qubes prioritize better default templates (especially for servicevm), better disposable vms, support for multiple dispvm templates, better dom0 hardening, and software package by software package dispvm templates for the core packages that are included.

now on to what you wrote:

"Please show how Trisquel is better for security. Credible points, not
handwavium.
Cost benefit analysis.

From what I see, they don't support MP3 playback out of the box for a
reason. They cut functionality not for security reasons, but for legal
reasons.
Security itself is not a major focus at all in it from what I can see or read.
There has not been a release in quite long time."

im bothered by this... i havent kept up to date. i take it back. ive been using qubes for so long im over a year out of date on this topic. i would like to change my suggestion to debian out of available alternatives simply because closer to whonix, which is a major part of the ecosystem for many people, and also because re-use of whonix security measures. for the record if youre curious i brought up trisquel because purism/richard stallman/minimalism/noblob/etc. given the long philosophical sentence from above i thought it would be one of the ideal starting points just because it would be easier. i stand corrected. fortunately that just leaves dom0 since the templatevms for debian have been in qubes for a while now. thanks for pointing this out.

"Provide an actual alternative that is reasonably better than Fedora at
being a desktop."

debian a la whonix. see above

Remember that we do not care about the desktop environment as long as
it's trimmed."

fvwm, jwm, openbox, and fluxbox are great choices. xfce and lxde could be offered as a bloated alternatives for people who like shiny objects. (gnome/kde=madness). openbsd ships a super hardened fvwm implementation that is old but rock solid/battle tested.

"Chrooted processes are again worthless in Qubes.
No amount of filesystem protection will stop local kernel exploit from
working - unless it has to be launched from the filesystem. It's at
best a minor inconvenience. Many, if not most, VFS bugs were related to either special FS like
proc, sys, dev or to actual writes, not execution. "

i mildly agree here, and only because the magnitude of mitigation from qubes in your scenario is so great that it casts a shadow over other issues. ill make up a use-case: theres a guy named joe in a place we'll call "snufflez" who worships "shamalama". unfortunately for joe it is a crime punishable by death to warship shamalama for the people os snufflez. hes sitting in his living room and downloading the holy book of shamalama. this guy doesnt need to be kernel exploited to have his head chopped off, and he doesnt want people to easily profile his setup or location because of a browser bug. a couple little things are enough. let me fix your sentence: "Chrooted processes are practically worthless in Qubes in the context of protecting from many types of exploits that would shatter the qubes security model of context separation, especially the worst ones, and especially considering that the security afforded by chroots is in almost all cases covered by existing qubes/xen security features." to which i would add "however if we broaden our paranoia to a much higher level of sensitivity to the extent that even enumerating and looking around a vm sandbox is a major threat then other things count"

 
"Please provide an example of such an attack that would be mitigated by
adding a chroot, or making the file system noexec, or making the file
system nosuid.
Note that it does not have to be already mitigated by Qubes separation. "

im wondering if after reading what i wrote so far in this message you still want me to answer this question. try to put yourself in my head first and think real world.

"The resource reqs of Qubes alone are slightly lower than of Fedora
itself. I've checked. The cut down KDE is very nicely trimmed.
Start it, launch one or two applications. Measure memory usage.
Do the same on a distro of your choice with same applications, but
much lower security. Compare. Do this after replacing the applications
with tiny variants, measure again.
Data, not assumptions.
What you're advocating is really premature optimization. "

my sys-firewall is currently using over 2gb ram right now bro. also whats with the library goliath desktop environments with bobbles and boobles? i consider xfce bloated. i know exactly what youre saying but the point is not to save on disk space or to only just lower memory requirements. its all too far away from ideal. every time i update my template (at command line) and watch all that funny business scroll by i cringe.

"This sounds like "I hate Fedora but I can't say why." There are valid
reasons to dislike it of course, but you need to actually say them.
What does "conservative defaults" mean? It's still a desktop, not a
single use web appliance. "

i dont hate fedora, i just hate fedora for qubes. you shouldnt have to take things away to make it better. to make it easier ill just compare fedora to debian. i dont trust fedora as much as debian. fedora is manipulated by redhat and that has advantages and disadvantages but for qubes it is scary. redhat is a centralized american company with billions to lose that can sign binaries for qubes and TOR users. furthermore design decisions in fedora, although they take security into account, also take backwards compatibility and interlopability into account. im not religious but i dont like yum/rpm as much as apt/dpkg and the "debian way" of doing things has been traditionally sticking to unix roots so the knowledge of a debian user is more portable between linux distros and/or unix platforms. debian has more spinoffs and runs on more machines so there is more debian associated documentation out there. from an industry standpoint public clouds push debian derivatives more and the debian community seems to be more skilled than the redhat community so more work goes into cooler things while redhat is trying to push productivity workflow automation mumbo jumbo. security wise i suppose both would have to be smacked around pretty hard to be up to par but id much rather go with debian because i can piggy back off whonix. lastly all the good redhat dox are for centos or rhel, where for debian theres no games being played.

"shouldnt be a one-size-fits-all, "dump all your binaries here", template..... Because? What is improved by removing such a template? Definitely not maintenance or ease of development. Or ease of use..... But do actually explain the threat model behind this reasoning. Is it script kiddies with poor scripts? "

have you ever broken into a box and thought "oh darn i wish i could... oh cool this guy has a compiler installed for me!" or "good thing he has blahblah installed i have a priv escalation exploit for that right here! 1 parameter pass and... poof". especially with window of opportunity intervals looming. I think you may be focusing way too much on the areas specific to qubes, but qubes-os as an OS should care about more than xen kernel exploits. look at the example about Joe above... yes actually those are script kiddie govt employees (not even high level) going after joes head but they have enough money and resources to do things. also dont forget window of opportunity because time can make all the difference. stop thinking like a computer scientist for a moment and think like a soccer player (just briefly lol). also for the sake of this argument assume joe isnt using whonix etc.

"They don't. They reserve up to 256 MB ram each (I'll have to check the
actual number). You could make them smaller somewhat too, I mean, to
about 128 MB each.
The main gobbler in NetVM is... Network Manager's GUI, which requires X.
However, replacing that with code in Dom0 is foolish from security
PoV. Factoring it out into a separate "display VM" is a lot of work
for not a lot of memory saving and major increase in Qubes comm
protocol complexity.
The latter means bugs and security issues. "

im aware of the challenges. for the netvm i would say use command line in dom0 (attach to domu) to exec inside the netvm or make a gui wrapper for that. why would that be foolish?

"Please explain how this helps over having an icon that launches a
disposable VM with this running.
I'm not being facetious here at all. "

im not sure you understood me. what i mean is for example we should have a disposable libreoffice vm, not just firefox or a 1 size fits all.

"Do it. See what you can and cannot do. I've tried myself, the gains
are... less than satisfactory. And it's a lot of work.
Note that Qubes templates do not run a pretty large chunk of DE already.
Again, the main hog in a GUI VM is... actual GUI subsystem and actual
target application.
If you want Qubes ballooning to be more tweaked towards faster
changing requirements, why not say so? And preferably do so.
Feel free to also try to use Xen's autoballooning, frontswap,
frontcache and *post the results*.
I've actually had trouble getting Qubes to play nice with that stack.  "

well i suppose that the impression ive always had is that qubes in the interest of keeping things simple just assumes you have ample ram and picks performance oriented rather than resource conservative defaults for everything. ive done some tweaking and i think i have my machine moderately cleaner but since i have 64gb ram this is more for cleanliness than anything. if i see something blow up its noticeable, its not because of big defaults. that said i will consider putting some time into playing with xen. you have more experience than i do so it would be a privilege for me to contribute in that area. i get back to you on that one, but dont hold your breath at all hehe.

"It never was. Strawman if I ever seen one. The user picks what they
run, mostly. The extras are vastly limited, run ps or top in the VM to
see them. "

i can give you one recurring case for me: i want to use a dispvm for something. lets say gedit...

"See above about having to at least explain how it is better. I've
considered this problem personally at length too and came to different

conclusion... Assumption. Please provide data. "

i think i addressed this above but if you disagree we should talk more. in a way you were talking about apples and i was talking about fruit. i dont disagree with you about apples, but i got bananas and oranges to worry about too. this also seems to be a recurring topic of contention between us but i am going to assume for now that you will have new thoughts based on my long scenario and the joe example.

"You need to first show that you're going to need a thing before you
implement it. You haven't done that.
This is not design discussion until you do so. "

u wanna call it a pre-design discussion? i dont know how to start a design discussion without discussing the needs for something first. in addition i didnt think we would be this far apart on some issues so if i had a time machine i would start differently.

"Thank you for appreciation. :E Maintainability was never a
consideration in your alleged untested design, was it? "

actually maintainability is very important to me, but maybe i look at it different than you. you see i have this small group of awesome friends ive never met but they went out of their way to maintain and distribute their hard work all around the world just for my own personal computational pleasure. maintainability for me means to hope there is no fork. it means to encourage you guys to adopt my customizations and desires for the benefit of all. it means going on the dev/user lists once in a while to see whats up. it means getting more people to use qubes so i have more stability. im a user you see. maybe ill develop too. maybe. :)   

i know the above paragraph was smug but im just pointing out the situation. i do appreciate your work and i know you dont owe me anything. my expectations are born of my understanding of who and what ITL is, not because im entitled.

"It's not feedback, you're trying to redesign Qubes, without actually
verifying the properties of current and target design. Might as well
just not redesign it and develop at random. "

i dont think im redesigning... according to you yourself half of what i was suggesting is doable as-is but qubes just doesnt ship that way. the other half is "ditch fedora, ship more hardened", which is not a redesign. i didnt ask to remove anything qubes-specific from qubes-os, and i didnt suggest to change anything that makes a material change to the way qubes works (aside from how dispvms are organized, which is arbitrary to the target design right?) i DID suggest a bunch of things in domu and dom0 though. they might be significant changes in terms of effort but immaterial in terms of odyssey etc.

"It is already in a virtual machine. What does the additional chroot get you?  "

"Template VM is already read only - you'll modify the volatile part of
it. You have prevented access to disk, but the attack still has all
kinds of access to memory. "

you can run anything as firefox, and firefox is the point of that dispvm, but if you need to escalate privs it would be harder. right now in qubes sudo is wide open and ive read the reasoning behind it but please look at my scenario paragraph above.

"What does this buy when X is already in the VM other than vastly

increased setup complexity? Beautiful. Now X has access to real TTY? Actually, in Qubes it doesn't. "

sorry i was talking off the top of my head from something else i set up before. you are correct and the TTY doesnt even apply.

"Lack of access to /dev/xvba etc. does not prevent anyone from invoking
Xen hypervisor APIs more directly or make it much harder at all. "

thanks didnt know that.

"You can. Extremely easily. You've shown that you cannot *write them to
disk*, so persistence is a bit harder. Although nowadays people do not
like to restart machines, virtual or otherwise. "

persistence is not an issue for a dispvm but it is for others. anyway right about now im thinking my example sucks for multiple reasons, one of which i didnt know about until you educated me. ill get back to you. :)

"To begin with, show me a HIDS and NIDS that actually work in an actual
*desktop* environment. I bet you don't have anything on hand - it's a
major effort to get it to work reasonably with low false positive
rate. "

as i said tuning is everything. the assumption there is that everything is profiled over time. you wont get to a low false positive rate for a while. im not happy with my current setup but i just watch for some basic things that have to do with my own behavior. i wont go deeper into this at this time, but ill mention that if i wanted to go with a commercial solution i would have much easier options.

"The former is very tricky to implement too, and you cannot just really
run it inside the VM where it can be easily circumvented - but that'd
be better than nothing still."

actually its better than better than nothing, because the attacker might be able to break in and stop logging or delete local stuff or even nuke the vm but i still get everything on my inline nids. its pretty solid assuming he cant get into the nids.

"Running it in Dom0 is a major security risk. It is a complex piece of
software with many failure modes.
So, now you get to implement a monitoring domain which Xen might be
able to do, but I haven't been able to coax it to do so.

Using some framework like Volatility to inspect the critical paths in
a VM memory space; having a peek at the volatile image file to spot
garbage. "

i am not advocating that. thats not how i do it

"The NIDS is best run in a ProxyVM."

thats exactly how i do it

"You still need appropriate GUI for the target end user somewhere."

2 options: 1 is to hang another vm off the nids-proxy and use it as a management station 2 is to just launch things on the nids-proxy (i use command line and web interface and both work well like this)

"Note this vastly conflicts with your "save resources" concept."

what did you think i was saving the resources for?

"Take care, "

happy thanksgiving. thanks for taking the time to respond. love your work.

[Paymon Sharif]

hey btw i realized something. basically if you dont take into account the window of opportunity, an active watchful user (lets say a person like you or me with some ids), and some additional sensitivities (care about targeted enumeration/etc) then a lot of of what i am saying becomes much less relevant. i suppose some of what i care about has traditionally been part of convention/best-practice coincidentally, and as qubes steps in it messes with convention and intuition. things that did not need debate before now become topics of discussion. 

[Radoslaw Szkodzinski]

A widely used and known technique that works in more than a specific
case will likely be used.
This means trying to not rely on particulars of a target and trying to
bypass as many security measures as possible.

> - some of said attacker
> capabilities can be mitigated or eliminated through some of the security
> measures that one might otherwise be tempted to dismiss out of seeming
> irrelevance or laziness, because said measures break dependencies or
> introduce delays for the meeting and/or bypassing of said dependencies for a
> combination of said capabilities to perform meaningful penetration and
> compromise,

Long-winded and quite pointless. You do not put a padlock against
children inside a hardened safe, then claim it improves security.

> and considering that the window of opportunity for the attack is
> always limited

It's quite often not. Attacks are still made now against ancient
Windows XP machines. Payloads vs older versions of Firefox are in the
wild; or even old Internet Explorer.
You can retry an attack many times unless the target detects it - even
just crashing is not necessarily good enough.

Window of opportunity is mostly limited for physical attacks such as
evil maid - unless there is an update that closes the bug you get to
exploit. But those generally lag quite a bit behind issues they fix,
even in open source projects.

> by definition thus magnifying the mitigation capability of
> said measures in many cases (especially in the case of an intelligent target
> with an environment that requires exploration for meaningful penetration),

Yes, and such a target will not be stopped by a trivial technique. A
guy who can crack safes is not stopped by a padlocked box.

> the best approach is for any given system with any given security measures
> is to use all of said security measures except in the case where the
> introduction of said security measure would degrade system security

(Which it would due to added maintenance and much more complex setup...)

> or make
> impossible the introduction of a more important security measure - thus
> implying that the selection of said security measures for architectural
> inclusion within said system should also be prioritized for inclusion based
> on metrics such as impact and mitigation value, noting that the ideal
> implementation of said systems architecture will have to be re-prioritized
> on a per application basis to maximize the effectiveness of the conglomerate
> set of system security measures in mitigation of compromise.

Ugh that is a mouthful, signifying nothing.
There is no mitigation value in a weaker isolation layer that is
inside a stronger layer.

> i know qubes is not the security hero for everything under the sun, but
> given the above philosophy (which applies to most of the "relevant" qubes
> users) i would argue that right now qubes needs to be sandwiched between a
> hardened domu and a hardened dom0.

Feel free to provide a repository with rebuilt hardened packages.

> we have both mentioned whonix and other
> projects for example but i want to see qubes prioritize better default
> templates (especially for servicevm), better disposable vms, support for
> multiple dispvm templates, better dom0 hardening, and software package by
> software package dispvm templates for the core packages that are included.

Define better and preferably implement them. I'm personally not making
Fedora packages myself, because they are pain in the rear end.
I've tried and I just don't have the time to mess with it, also due to
lack of a machine I could sacrifice for just dom0 development.

Debian ones are as bad to develop if not more.

> im bothered by this... i havent kept up to date. i take it back. ive been
> using qubes for so long im over a year out of date on this topic. i would
> like to change my suggestion to debian out of available alternatives simply
> because closer to whonix,

That is not a virtue by itself. Qubes dom0 is trimmed way more than even Whonix.

> which is a major part of the ecosystem for many
> people, and also because re-use of whonix security measures. for the record
> if youre curious i brought up trisquel because purism/richard
> stallman/minimalism/noblob/etc.

Trisquel is nowhere near as minimal as Qubes Dom0. Seriously, just
take a peek. You'd have to trim it and audit it.

The firmware things are best kept in a device-specific VM, for example
NetVM, USB VM, in the future - GUI VM.
Deblobbing for sake of deblobbing (or "purity") is not worth it, esp.
if the blobs already run in separate VMs.
You can replace the distro in there anyway if you want to.

> "Provide an actual alternative that is reasonably better than Fedora at
> being a desktop."
>
> debian a la whonix. see above

Better at what?

> Remember that we do not care about the desktop environment as long as
> it's trimmed."
>
> fvwm, jwm, openbox, and fluxbox are great choices. xfce and lxde could be
> offered as a bloated alternatives for people who like shiny objects.
> (gnome/kde=madness). openbsd ships a super hardened fvwm implementation that
> is old but rock solid/battle tested.

And unusable, just like a rock should be. ;) Making those usable takes
*a lot* of work.
They lack critical features such as proper pager (Openbox/fluxbox),
multiscreen support, system tray, file manager.
Full mouse support, configurability without editing text files... I
could enumerate further.

Once you add external software to do it, the package becomes less than
stellar and is still clunky.
Their code bases, while small, are ancient and hard to audit. For
FVWM, you get to audit TCL/TK. (OpenBSD didn't do so.)

I don't understand your definition of bloated. Please compare memory
usage instead of empty words like this.
Especially of trimmed Qubes dom0 KDE, which is not your random KDE -
it tosses the heavier, more worthless, internet connected features
that wouldn't work in Dom0.

Marek has already made a version of Xfce for Qubes, while another made
Awesome WM config for Qubes.

> "Chrooted processes are again worthless in Qubes.
> No amount of filesystem protection will stop local kernel exploit from
> working - unless it has to be launched from the filesystem. It's at
> best a minor inconvenience. Many, if not most, VFS bugs were related to
> either special FS like
> proc, sys, dev or to actual writes, not execution. "
>
> i mildly agree here, and only because the magnitude of mitigation from qubes
> in your scenario is so great that it casts a shadow over other issues. ill
> make up a use-case: theres a guy named joe in a place we'll call "snufflez"
> who worships "shamalama". unfortunately for joe it is a crime punishable by
> death to warship shamalama for the people os snufflez. hes sitting in his
> living room and downloading the holy book of shamalama. this guy doesnt need
> to be kernel exploited to have his head chopped off, and he doesnt want
> people to easily profile his setup or location because of a browser bug.

This is not a security issue, but a privacy issue.

Whonix folks are working with Qubes devs to make the VMs less
fingerprintable. That is already much better than what LXC or chroots
provide out of the box.
Chroots don't help it at all. Ever.

If you're arguing to attempt to make Firefox less exploitable, then do
provide better package of Firefox instead of rewriting the whole OS or
adding pointless features.
(Or run Whonix with its well configured Firefox in Qubes AppVM, routed
via TorVM. It's been done.)

The guy shouldn't be keeping his book of shamalama in the same VM as
he downloaded it in, or view it in there. There are DispVMs and other
AppVMs for it.

> a
> couple little things are enough. let me fix your sentence: "Chrooted
> processes are practically worthless in Qubes in the context of protecting
> from many types of exploits that would shatter the qubes security model of
> context separation, especially the worst ones, and especially considering
> that the security afforded by chroots is in almost all cases covered by
> existing qubes/xen security features." to which i would add "however if we
> broaden our paranoia to a much higher level of sensitivity to the extent
> that even enumerating and looking around a vm sandbox is a major threat then
> other things count"

Again, you're arguing for fixing Firefox rather than adding chroots.

If the attacker breaches Firefox, they have access to a huge set of
identifying data if it wasn't ephemeral (like it is in DispVM, which
you should use).
No chroot will prevent Firefox from accessing Firefox data files.
Other files should be kept in another VM and on an external disk, if
you want them to not be found.

> "Please provide an example of such an attack that would be mitigated by
> adding a chroot, or making the file system noexec, or making the file
> system nosuid.
> Note that it does not have to be already mitigated by Qubes separation. "
>
> im wondering if after reading what i wrote so far in this message you still
> want me to answer this question. try to put yourself in my head first and
> think real world.

In a real world, you have automated payloads like Zeus or the advanced
NSA crack kit, or the KSA equivalent (described in literature) that do
all of the things I've described and more.
Please read up on real world attacks. These payloads can be bought or
hired, so there is no huge up front development cost more than once.
There are phishing toolkits, you can even hire a specialists if you
know where and have the money.

This again makes attempts at hardening against badly designed attacks
worthless or negative worth due to added complexity of the setup.

> "The resource reqs of Qubes alone are slightly lower than of Fedora
> itself. I've checked. The cut down KDE is very nicely trimmed.
> Start it, launch one or two applications. Measure memory usage.
> Do the same on a distro of your choice with same applications, but
> much lower security. Compare. Do this after replacing the applications
> with tiny variants, measure again.
> Data, not assumptions.
> What you're advocating is really premature optimization. "
>
> my sys-firewall is currently using over 2gb ram right now bro.

Interesting, it has 256 MB limit set in my Qubes Manager. If what you
say is true, it's a major bug. I'd say it's not true.
Just be careful you're not comparing ballooned sizes. Qubes will
balloon the VMs to allocate unused memory if that option is checked.
This memory will be reallocated to VMs that need it - unless there is a bug.

I might be wrong, but I think ballooning is disabled for ServiceVMs by default.

> also whats
> with the library goliath desktop environments with bobbles and boobles? i
> consider xfce bloated.

Feel free to replace dom0 with whatever you want. Sacrificing
usability for "general public" is not the point of Qubes OS -
providing a secure and *useful* desktop is one.
Also feel free to audit the code you are replacing it with.

> "This sounds like "I hate Fedora but I can't say why." There are valid
> reasons to dislike it of course, but you need to actually say them.
> What does "conservative defaults" mean? It's still a desktop, not a
> single use web appliance. "
>
> i dont hate fedora, i just hate fedora for qubes. you shouldnt have to take
> things away to make it better.

That's security for you. Sacrifice as many features as you can to
reduce attack surface, without making the system unusable.
You're arguing both ways...

> to make it easier ill just compare fedora to
> debian. i dont trust fedora as much as debian.

<snip> Conspiracy theory </snip>

> "shouldnt be a one-size-fits-all, "dump all your binaries here",
> template..... Because? What is improved by removing such a template?
> Definitely not maintenance or ease of development. Or ease of use..... But
> do actually explain the threat model behind this reasoning. Is it script
> kiddies with poor scripts? "
>
> have you ever broken into a box and thought "oh darn i wish i could... oh
> cool this guy has a compiler installed for me!"

No, attackers upload shellcode. It's a binary, with various tricks to
make it smaller.

> or "good thing he has
> blahblah installed i have a priv escalation exploit for that right here! 1
> parameter pass and... poof".

No, attacker uploaded working shellcode with a local root exploit
binary; either together or separately.

What do you think exploit writers are, lazy and dumb? They don't know
all the details of the target beforehand so have to isolate from any
such dependencies on the target - otherwise they risk their thing to
not work.

After you have a command and control connection setup, you can upload
what you need - usually nice static binaries or scripts with your own
statically compiled interpreter.

> <snip> More rant. </snip>

Again, don't assume your adversary is stupid. That way lies disaster.
Nonsense defenses are still nonsense.

> "They don't. They reserve up to 256 MB ram each (I'll have to check the
> actual number). You could make them smaller somewhat too, I mean, to
> about 128 MB each.
> The main gobbler in NetVM is... Network Manager's GUI, which requires X.
> However, replacing that with code in Dom0 is foolish from security
> PoV. Factoring it out into a separate "display VM" is a lot of work
> for not a lot of memory saving and major increase in Qubes comm
> protocol complexity.
> The latter means bugs and security issues. "
>
> im aware of the challenges. for the netvm i would say use command line in
> dom0 (attach to domu) to exec inside the netvm or make a gui wrapper for
> that. why would that be foolish?

The GUI wrapper has to access possibly attacker-controlled NetVM, so
it has to be fuzzproof, audited and even preferably mathematically
verified if it is to run in Dom0. Risky.
You could put this code in the common GUI VM but that would make
compromising GUI much easier - and if your GUI is compromised you're
in the world of trouble - attacker can insert additional commands to
be executed.

A sane alternative is to run a separate GUI-only (AppVM-like) domain
for the NetVM while having additional communication protocol, but that
is still pretty fat (fatter because you get to run more code and more
VMs) and plenty of work to write such a daemon. Feel free to implement
it if you think it would improve security.

Generally the attack vector for the NetVM is not the control GUI (the
attacker cannot rename interfaces), but network stack, device drivers
and firmware.
The GUI is separated already using Qubes GUI protocol, as in all AppVMs.

> "Please explain how this helps over having an icon that launches a
> disposable VM with this running.
> I'm not being facetious here at all. "
>
> im not sure you understood me. what i mean is for example we should have a
> disposable libreoffice vm, not just firefox or a 1 size fits all.

But why? Are you clinging to the idea that either the attacker needs
application <x> to exploit or that users will be tempted to break
their usage patterns for convenience?

> "Do it. See what you can and cannot do. I've tried myself, the gains
> are... less than satisfactory. And it's a lot of work.
> Note that Qubes templates do not run a pretty large chunk of DE already.
> Again, the main hog in a GUI VM is... actual GUI subsystem and actual
> target application.
> If you want Qubes ballooning to be more tweaked towards faster
> changing requirements, why not say so? And preferably do so.
> Feel free to also try to use Xen's autoballooning, frontswap,
> frontcache and *post the results*.
> I've actually had trouble getting Qubes to play nice with that stack. "
>
> well i suppose that the impression ive always had is that qubes in the
> interest of keeping things simple just assumes you have ample ram and picks
> performance oriented rather than resource conservative defaults for
> everything.

You assume Qubes assumes. :)

No, Qubes defaults are generic, and Qubes modified ballooning is meant
to prevent VMs from gobbling up memory needlessly.
It predates Xen autoballooning, frontswap and frontcache though.

> ive done some tweaking and i think i have my machine moderately
> cleaner but since i have 64gb ram this is more for cleanliness than
> anything.

I've had Qubes work reasonably on a machine with 4 GB of RAM, no
modifications. (Qubes 2.0 RC 1 I think. The machine is not used for
that purpose anymore due to lack of VT-d.)

> "It never was. Strawman if I ever seen one. The user picks what they
> run, mostly. The extras are vastly limited, run ps or top in the VM to
> see them. "
>
> i can give you one recurring case for me: i want to use a dispvm for
> something. lets say gedit...

Then.. launch a DispVM with gedit? It takes a few clicks to add an
icon to do so.
DispVM startup times have been improved a lot in 3.x series, but
they're still not instantaneous, even with SSDs.

> "See above about having to at least explain how it is better. I've
> considered this problem personally at length too and came to different
> conclusion... Assumption. Please provide data. "
>
> i think i addressed this above but if you disagree we should talk more. in a
> way you were talking about apples and i was talking about fruit.

The problem is, you're not talking, you're rambling. It's getting tedious.

> <snip> More rambling </snip>

> "It's not feedback, you're trying to redesign Qubes, without actually
> verifying the properties of current and target design. Might as well
> just not redesign it and develop at random. "
>
> i dont think im redesigning... according to you yourself half of what i was
> suggesting is doable as-is but qubes just doesnt ship that way. the other
> half is "ditch fedora, ship more hardened", which is not a redesign.

Ditching Fedora is a major change. Implement it, patches are accepted,
it's been discussed... So. Many. Times.

The main thing is that Dom0 is pretty sensitive. Qubes team actually
partly audited the code that's in there, tossed unneeded and unsafe
features - this would have to be redone.

Providing additionally hardened packages is fine - but you'd need some
automated and trusted tool to do it or it becomes a large maintenance
load.

> "It is already in a virtual machine. What does the additional chroot get
> you? "
> "Template VM is already read only - you'll modify the volatile part of
> it. You have prevented access to disk, but the attack still has all
> kinds of access to memory. "
>
> you can run anything as firefox, and firefox is the point of that dispvm,
> but if you need to escalate privs it would be harder. right now in qubes
> sudo is wide open and ive read the reasoning behind it but please look at my
> scenario paragraph above.

Sudo gives you access to the VM root.
If you can exploit Firefox, usualy running additional local root
exploit(s) is simple; even kernel hardening like PAX makes it only
moderately more difficult.
(Unless it's an exploit that only allows you access to protected store
or other such Firefox features. But then, sudo is just as irrelevant.)

Are you suggesting it to "secure" multiple applications and use cases
in a single AppVM? Risky and hopefully unnecessary.

> "You can. Extremely easily. You've shown that you cannot *write them to
> disk*, so persistence is a bit harder. Although nowadays people do not
> like to restart machines, virtual or otherwise. "
>
> persistence is not an issue for a dispvm

It is until you shut that VM down.

> but it is for others. anyway right
> about now im thinking my example sucks for multiple reasons, one of which i
> didnt know about until you educated me. ill get back to you. :)
>
> "To begin with, show me a HIDS and NIDS that actually work in an actual
> *desktop* environment. I bet you don't have anything on hand - it's a
> major effort to get it to work reasonably with low false positive
> rate. "
>
> as i said tuning is everything. the assumption there is that everything is
> profiled over time. you wont get to a low false positive rate for a while.

Meaning it's mostly worthless for desktop, where requirements and use
cases change. Anything new?

Not to mention you'll get the Vista effect due to many worthless
popups right off the bat. Unusable security is no better than no
security at all - users will disable the popups/info or learn to
ignore them.

> "The former is very tricky to implement too, and you cannot just really
> run it inside the VM where it can be easily circumvented - but that'd
> be better than nothing still."
>
> actually its better than better than nothing, because the attacker might be
> able to break in and stop logging or delete local stuff or even nuke the vm
> but i still get everything on my inline nids.

Care to show this setup?

> its pretty solid assuming he
> cant get into the nids.

Again assuming the attacker is stupid. Very bad assumption. That said,
NIDS is reasonably isolated in the NetVM or ProxyVM.
It's HIDS that is the problem.

> "Running it in Dom0 is a major security risk. It is a complex piece of
> software with many failure modes.
> So, now you get to implement a monitoring domain which Xen might be
> able to do, but I haven't been able to coax it to do so.
>
> Using some framework like Volatility to inspect the critical paths in
> a VM memory space; having a peek at the volatile image file to spot
> garbage. "
>
> i am not advocating that. thats not how i do it

Yes, do it in a way where it can be easily circumvented, as it's
placed inside the AppVM/DispVM itself?
I was talking about HIDS, not NIDS, mind you.

NIDS are even more worthless. Either you depend on predefined set of
rules (no can do on desktop, even with extensive database) or the
learning mode and hope anything won't change (doesn't work well even
with servers, not to mention desktops).

How do you detect unknown, possibly custom exploit from network
packets? The simple answer is that you don't in general, so you cannot
trust such a system.
It's the same problem thwarting antivirus software.
(As opposed to a good HIDS, where weird usage patterns can be
detected. It shares some of the problems though.)

It's generally better to split tasks that do not require networking
from ones that do, and Qubes has a built-in firewall to enforce it.

> "You still need appropriate GUI for the target end user somewhere."
>
> 2 options: 1 is to hang another vm off the nids-proxy and use it as a
> management station 2 is to just launch things on the nids-proxy (i use
> command line and web interface and both work well like this)

I haven't seen a usable NIDS GUI ever.

> "Note this vastly conflicts with your "save resources" concept."
>
> what did you think i was saving the resources for?

To waste them on unreliable and problematic pseudosecurity measures?

> "Take care, "
>
> happy thanksgiving. thanks for taking the time to respond. love your work.

My work? You mean ITL work? :)

--
Radosław Szkodziński