I just saw Micah Lee from FPF wrote this article about Qubes OS:

https://pressfreedomfoundation.org/blog/2014/04/operating-system-can-protect-you-even-if-you-get-hacked

It's generally good and very positive but I have two comments:

1) The AppVM's rootfs non-persistency should *not* be generally treated
as a security feature. I have just added an explicit note to the wiki
page about this:

http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=diff&version=9&old_version=8

2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
no networking, one should remember about the possibility of the malware
in that AppVM to leak secrets using a (sophisticated) covert channel,
e.g. via CPU cache, to some other AppVM. This naturally assumes that
this other AppVM has also been compromised and that the malware in the
"air-gapped" machine cooperates with the malware in the other AppVM
(which we assume is network-connected).

Such covert channels through CPU cache has been described and even
implemented in some "lab environments" and IIRC they might allow for
bandwidths of even a few tens of bits/sec. It is unclear to me if such
channels could be implemented in a "real world" system, where multiple
VMs execute at the same time, each running tens or hundreds of
processes, all using the same cache memory, but it's worth keeping in
mind. Of course this wold require special malware written specifically
to attack Qubes OS, and perhaps even specific Qubes OS version and
perhaps specific Qubes OS configuration. Nevertheless might be possible.

True air-gapping is generally hard. I remember I saw some papers about
how a compromised air-gapped machine could establish a covert channel
with another one using a mic and speakers.

So, these were my comments to the article. I also have some questions to
Micah, as he seem to be much involved into Tails:

1) So, what advantage there might potentially be of running Tails on
baremetal vs. inside of Qubes HVM?

2) Considering Tails running on baremetal (or even inside *one* Qubes
HVM): if the attacker compromises your Firefox through a 0day, what
prevents the attacker from disabling tor or just reading various info
identifying the user (e.g. MAC, real IP, etc)? Does Tails use some form
of sandboxing like SELinux or LXC?

Anyway, thanks for promoting Qubes OS!

Cheers,
joanna.

On 04/11/14 06:29, Joanna Rutkowska wrote:
> 2) Considering Tails running on baremetal (or even inside *one* Qubes
> HVM): if the attacker compromises your Firefox through a 0day, what
> prevents the attacker from disabling tor or just reading various info

> identifying the user (e.g. MAC, real IP, etc)? [...]

An excellent point that I hadn't thought of before WRT torvm.

Good to see Qubes getting more recognition!

On 04/11/14 03:29, Joanna Rutkowska wrote:
> I just saw Micah Lee from FPF wrote this article about Qubes OS:
>
> https://pressfreedomfoundation.org/blog/2014/04/operating-system-can-protect-you-even-if-you-get-hacked
>
> It's generally good and very positive but I have two comments:

Thanks!

> 1) The AppVM's rootfs non-persistency should *not* be generally treated
> as a security feature. I have just added an explicit note to the wiki
> page about this:
>
> http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=diff&version=9&old_version=8

I had thought of this, and I'm glad you updated the wiki to make it more
explicit.

I still think it's probably helpful for many drive-by untargetted
attacks. I imagine there's malware out there waiting to see if it's
running in Linux and then installing a rootkit in the kernel if it is,
never checking to see if it's in a VM, or running in Qubes.

So maybe it's a security feature in the same way that anti-virus
software is a security feature. :)

> 2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
> no networking, one should remember about the possibility of the malware
> in that AppVM to leak secrets using a (sophisticated) covert channel,
> e.g. via CPU cache, to some other AppVM. This naturally assumes that
> this other AppVM has also been compromised and that the malware in the
> "air-gapped" machine cooperates with the malware in the other AppVM
> (which we assume is network-connected).
>
> Such covert channels through CPU cache has been described and even
> implemented in some "lab environments" and IIRC they might allow for
> bandwidths of even a few tens of bits/sec. It is unclear to me if such
> channels could be implemented in a "real world" system, where multiple
> VMs execute at the same time, each running tens or hundreds of
> processes, all using the same cache memory, but it's worth keeping in
> mind. Of course this wold require special malware written specifically
> to attack Qubes OS, and perhaps even specific Qubes OS version and
> perhaps specific Qubes OS configuration. Nevertheless might be possible.

I wonder, are there other covert channels that could be used to
communicate between AppVMs, or is CPU cache the only one?

> True air-gapping is generally hard. I remember I saw some papers about
> how a compromised air-gapped machine could establish a covert channel
> with another one using a mic and speakers.

Yup, this was allegedly what was going on with badBIOS. In laptops it's
generally very easy to physically remove the wifi card, and that
normally also contains the bluetooth interface (both of these might have
vulnerable firmware, even if the devices are "off" in the OS).
Speakers/mic are more difficult, but a simple way to close that hole is
to buy cheap earplugs, plug them into the speaker/mic ports, and cut the
remaining cable off.

> So, these were my comments to the article. I also have some questions to
> Micah, as he seem to be much involved into Tails:
>
> 1) So, what advantage there might potentially be of running Tails on
> baremetal vs. inside of Qubes HVM?

If malware in another AppVM manages to exploit Xen/Qubes and compromise
dom0, then it can spy on Tails. As unlikely as this is, it's still
possible, and I think this is the main advantage of running on baremetal.

Tails is also designed to not leave any trace of it ever running on your
computer. When you boot to it on baremetal it doesn't touch the hard
drive. Obviously this wouldn't be the case of you have a VM dedicated to
using it -- however I think this feature is only useful for a very
specific threat model. (Like, if you get stopped at a checkpoint in
Syria and they search your computer for encryption software and arrest
you if they find it; I've heard this this happens.)

The other advantage is that Tails is designed as a live distro. There's
no concept of "installing" it on a computer, which means you need to
mount the DVD image each time you boot the HVM. If it detects that it's
running in a VM, it pops up a warning on boot telling you that if the
host machine is compromised Tails can be compromised too.

And finally, using a "persistent volume" in Tails is very useful, and
it's impossible (or at least very challenging) to create one inside of a
VM, (or while booted to a DVD). The "persistent volume" expects you to
be booted from a USB stick, and helps you create an encrypted partition
on it that can automatically restore specific files each time you boot
(e.g. a folder for documents ~/Persistent, and also ~/.gnupg, ~/.purple,
etc.).

> 2) Considering Tails running on baremetal (or even inside *one* Qubes
> HVM): if the attacker compromises your Firefox through a 0day, what
> prevents the attacker from disabling tor or just reading various info
> identifying the user (e.g. MAC, real IP, etc)? Does Tails use some form
> of sandboxing like SELinux or LXC?

If Firefox (or in the case of Tails, Iceweasel) gets compromised, the
attacker can then do anything that the "amnesia" user can do, such as
try to store malware in the persistent volume (which isn't the simplest
-- nothing runs automatically, and it doesn't store your whole Iceweasel
profile, only your bookmarks, etc.). But the attacker could definitely
exfiltrate your data.

You can also choose to boot without mounting your persistent volume, and
this is recommended unless you specifically need it. And unless you
change a setting on boot, the Linux user in Tails doesn't have root, so
the attacker then needs to use a local root exploit before it can do
things like modify the data on the Tails USB to contain persistent malware.

I believe there's really networking things going on that make it so if
you stop Tor everything stops working and doesn't fallback to not using
Tor. However, an attacker (even without root) can almost certainly
compromise the anonymity of Tails.

It looks like sandboxing is in the works, but won't be ready for some time:

https://labs.riseup.net/code/issues/5385
https://labs.riseup.net/code/issues/5525

But it's also true that it's significantly more difficult to target a
Tails or Tor Browser user than it is to target most other people. The
browsers look identical, can't be uniquely fingerprinted, and aren't
accustomed to leaking the same unique cookies all the time like normal
browsers are.

In practice, if you want to target a specific Tor user you really need
to target *all Tor users* of a specific website and hope your target is
one of them, e.g. like what happened in the Freedom Hosting situation.

> Anyway, thanks for promoting Qubes OS!
>
> Cheers,
> joanna.
>

--
Micah Lee

On 11.04.2014 16:49, Micah Lee wrote:
> And finally, using a "persistent volume" in Tails is very useful, and
> it's impossible (or at least very challenging) to create one inside of a
> VM, (or while booted to a DVD). The "persistent volume" expects you to
> be booted from a USB stick, and helps you create an encrypted partition
> on it that can automatically restore specific files each time you boot
> (e.g. a folder for documents ~/Persistent, and also ~/.gnupg, ~/.purple,
> etc.).

You can attach boot volume as "disk" instead of "cdrom" (simply use qvm-start
--hddisk instead of qvm-start --cdrom). Every HVM also have private.img
created, so you can use it, but IIUC it isn't simple because of tools
available in Tails.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

On 04/11/14 16:49, Micah Lee wrote:
>> 1) So, what advantage there might potentially be of running Tails on
>> > baremetal vs. inside of Qubes HVM?
> If malware in another AppVM manages to exploit Xen/Qubes and compromise
> dom0, then it can spy on Tails. As unlikely as this is, it's still
> possible, and I think this is the main advantage of running on baremetal.

So, it's basically whether you believe the following attack on Qubes:

1) Compromise one of the user "normal" AppVMs (most likely via a Web
browser or PDF exploit), and then:
2) Escape Qubes AppVM

is more or less likely than the following attack on Tails:

1) Exploit the Tails Web browser
2) Use one of the millions of ways to get from normal linux user to root
user (or kernel directly)

?

I would expect that stage #1 in any of the above attacks is of more or
less comparable difficulty.

I would expect that Stage #2 in the attack against Tails is *trivial*
for any government attacker (and simple for other attackers). I believe
that the stage #2 above in case of Qubes OS is "difficult" to "extremely
difficult"[*].

And, BTW, does Tail use any sort of mechanism to assure the user that he
or she is booting into a "real" (trusted) Tails image? Something ala
Anti Evil Maid we have? [2]

joanna.

[*] Take a look at our Qubes Security Bulletins page [1] -- in the last
4 years only really one (1) attack could qualify as practical VM escape.
It was the SYSRET attack found by Rafal QSB #2), and even that was more
of a CPU hardware bug than a Xen/Qubes bug, not to mention that it
affected lots of other OSes (although, notably not Linux). Perhaps also
our VT-d attack(s) could qualify here (QSB #1) -- again problem with
Intel hardware. How many user->root or user->kernel attacks have been
found on Linux systems during that time?

[1] http://wiki.qubes-os.org/trac/wiki/SecurityBulletins

[2] http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html

On 04/11/14 16:49, Micah Lee wrote:

>> 1) The AppVM's rootfs non-persistency should *not* be generally treated
>> > as a security feature. I have just added an explicit note to the wiki
>> > page about this:
>> >
>> > http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=diff&version=9&old_version=8
> I had thought of this, and I'm glad you updated the wiki to make it more
> explicit.
>
> I still think it's probably helpful for many drive-by untargetted
> attacks. I imagine there's malware out there waiting to see if it's
> running in Linux and then installing a rootkit in the kernel if it is,
> never checking to see if it's in a VM, or running in Qubes.
>
> So maybe it's a security feature in the same way that anti-virus
> software is a security feature. :)
>

I like that reasoning ;)

joanna.

Head of PR,
The Qubes Project

On Fri, Apr 11, 2014, at 13:49, Joanna Rutkowska wrote:
> On 04/11/14 16:49, Micah Lee wrote:
> >> 1) So, what advantage there might potentially be of running Tails on
> >> > baremetal vs. inside of Qubes HVM?
> > If malware in another AppVM manages to exploit Xen/Qubes and compromise
> > dom0, then it can spy on Tails. As unlikely as this is, it's still
> > possible, and I think this is the main advantage of running on baremetal.
>
> So, it's basically whether you believe the following attack on Qubes:
>
> 1) Compromise one of the user "normal" AppVMs (most likely via a Web
> browser or PDF exploit), and then:
> 2) Escape Qubes AppVM
>
> is more or less likely than the following attack on Tails:
>
> 1) Exploit the Tails Web browser
> 2) Use one of the millions of ways to get from normal linux user to root
> user (or kernel directly)

Would there be any benefit to using TAILS as a TemplateVM instead of TorVM?

On 04/11/14 16:49, Micah Lee wrote:

>> 2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
>> > no networking, one should remember about the possibility of the malware
>> > in that AppVM to leak secrets using a (sophisticated) covert channel,
>> > e.g. via CPU cache, to some other AppVM. This naturally assumes that
>> > this other AppVM has also been compromised and that the malware in the
>> > "air-gapped" machine cooperates with the malware in the other AppVM
>> > (which we assume is network-connected).
>> >
>> > Such covert channels through CPU cache has been described and even
>> > implemented in some "lab environments" and IIRC they might allow for
>> > bandwidths of even a few tens of bits/sec. It is unclear to me if such
>> > channels could be implemented in a "real world" system, where multiple
>> > VMs execute at the same time, each running tens or hundreds of
>> > processes, all using the same cache memory, but it's worth keeping in
>> > mind. Of course this wold require special malware written specifically
>> > to attack Qubes OS, and perhaps even specific Qubes OS version and
>> > perhaps specific Qubes OS configuration. Nevertheless might be possible.
> I wonder, are there other covert channels that could be used to
> communicate between AppVMs, or is CPU cache the only one?
>

I would expect more timing-based covert channels exploiting things such
as common backends (in case of Qubes that would at least be the disk
backend), some hypercalls perhaps. There might also a chance that some
hypercalls might be used for directly leaking data between VMs, although
I would expect these (if exists) to qualify as implementation bugs,
which should be easily fixable (in contrast to timing channels which are
not easily fixable if we don't want to sacrifice performance of the
whole system dramatically). I'm not an expert on cooperative covert
channels in VMM systems though.

joanna.

On 04/11/14 19:33, Joanna Rutkowska wrote:
> On 04/11/14 19:16, Marek Marczykowski-Górecki wrote:
>> [offlist]

>>
>> On 11.04.2014 18:59, Joanna Rutkowska wrote:
>>> On 04/11/14 16:49, Micah Lee wrote:

>> Assuming two *cooperating* VMs, IMO it is doable to establish not only
>> low-bandwidth covert channel, but simple xen shared memory, which would be
>> high-bandwidth channel. You need for this:
>> 1. the other domain ID (on both sides) - rather easy to guess as it is int <
>> 100 in most cases (*),
>> 2. grant ref (on "receiving" side), also some small int, looks like <10^6 (**).
>>
>> The whole operation would be:
>> 1. VM1 allocate some memory page, share it to all reasonable domain ids (100
>> grants or so)
>> 2. VM2 tries to bruteforce domain id of VM1 and grant reference - something
>> about 100*10^6 tries, perhaps even less if some hypercall error code allows to
>> validate domain id (distinguish invalid domain id from invalid grant reference).
>>
>> (*) If one of this domains is netvm, it is very likely it has XID 1.
>> (**) AFAIR that grant ref is assigned by sharing VM kernel. Maybe if attacker
>> control the VM1 kernel, he/she have influence on grant reference number, so
>> can use some known value.
>>
>
> Ah, that's true. I wonder whether Xen XSM allows to setup a policy on
> which VMs could share pages with which VMs? If it did (and I would
> expect so), it would be the actual first useful thing in practice that
> XSM provides. Perhaps we should investigate this for Qubes R3?
>
> joanna.
>

[Sorry for screwing up the CC -- now copying to qubes-users, as it should.]

And then, there is also xenstore, which would have to be audited to not
allow one VM to publish anything readable by (select) other VM.

So, these are probably doable things (whether via XSM or via custom
patches on Xen), the question is, however, is it really worth it? To
answer that question we should first estimate the real-world bandwidth
through cache-based and other hard-to-eliminate channels, because if
these alone provide for large communication, then it's not worth to
tinker with Xen IMHO.

joanna.

It would be rather hard to do this. First of all any VM needs to share some
pages with other VMs (blkfront, netfront, gui, qrexec) - ok, dom0 in most
cases (so probably can be limited by policy). But then comes our new VM-VM
qrexec, which needs direct VM-VM page sharing. I don't believe that XSM allows
dynamic policy for that case...

>>
>> joanna.
>>
>
> [Sorry for screwing up the CC -- now copying to qubes-users, as it should.]
>
> And then, there is also xenstore, which would have to be audited to not
> allow one VM to publish anything readable by (select) other VM.
>
> So, these are probably doable things (whether via XSM or via custom
> patches on Xen), the question is, however, is it really worth it? To
> answer that question we should first estimate the real-world bandwidth
> through cache-based and other hard-to-eliminate channels, because if
> these alone provide for large communication, then it's not worth to
> tinker with Xen IMHO.

The difference here is the bandwidth. While using convert channels you
probably need days/weeks/months to leak reasonable amount of data, but using
xen shm/xenstore you probably can do this in a matter of minutes.

It's easy to think of a special flag for a VM (the domain struct on Xen)
say: "airgapped". If set, the VM would only be allowed to share pages
with Dom0. This would require a "fallback" to qrexec that uses Dom0 as a
proxy (like it is currently in R2 -- doable for R3 using even the new
qrexec I think).

Whether XSM allows to effectively implement such "airgapped" per-VM
flag, or whether we would need to patch Xen manually, is less of a
concern I think.

>>>
>>> joanna.
>>>
>>
>> [Sorry for screwing up the CC -- now copying to qubes-users, as it should.]
>>
>> And then, there is also xenstore, which would have to be audited to not
>> allow one VM to publish anything readable by (select) other VM.
>>
>> So, these are probably doable things (whether via XSM or via custom
>> patches on Xen), the question is, however, is it really worth it? To
>> answer that question we should first estimate the real-world bandwidth
>> through cache-based and other hard-to-eliminate channels, because if
>> these alone provide for large communication, then it's not worth to
>> tinker with Xen IMHO.
>
> The difference here is the bandwidth. While using convert channels you
> probably need days/weeks/months to leak reasonable amount of data, but using
> xen shm/xenstore you probably can do this in a matter of minutes.
>

Sure, but we should first ensure there are no other cc offering high
bandwith (other like this legal memory sharing API).

joanna.

Joanna Rutkowska:

> On 04/11/14 18:58, J.M. Porup wrote:
>> On Fri, Apr 11, 2014, at 13:49, Joanna Rutkowska wrote:
>>> On 04/11/14 16:49, Micah Lee wrote:
>>>>> 1) So, what advantage there might potentially be of running Tails on
>>>>>> baremetal vs. inside of Qubes HVM?
>>>> If malware in another AppVM manages to exploit Xen/Qubes and compromise
>>>> dom0, then it can spy on Tails. As unlikely as this is, it's still
>>>> possible, and I think this is the main advantage of running on baremetal.
>>>
>>> So, it's basically whether you believe the following attack on Qubes:
>>>
>>> 1) Compromise one of the user "normal" AppVMs (most likely via a Web
>>> browser or PDF exploit), and then:
>>> 2) Escape Qubes AppVM
>>>
>>> is more or less likely than the following attack on Tails:
>>>
>>> 1) Exploit the Tails Web browser
>>> 2) Use one of the millions of ways to get from normal linux user to root
>>> user (or kernel directly)
>>

>> Would there be any benefit to using TAILS as a TemplateVM instead of Qubes/TorVM?

>>
>
> I believe it would be a great benefit of splitting Tails into user-apps
> part (Web browser, email clients, etc) and the backend part (tor proxy).
> This way a compromise of user apps would not lead to a compromise of tor
> or the netvm, so reveling of the MAC/IP, and other info (e.g. shooting
> photos via the built in camera).
>

> Our Qubes/TorVM could probably readily be used as the backend part. I also

> remember there were heavy discussions on both our mailing lists some
> weeks ago on using/porting/adopting Whonix (a competition to Tails which
> already uses this split architecture as I understand) to play as this
> user-apps part on Qubes OS.
>
> Unfortunately I haven't got enough cognitive resources at that time to
> follow all the discussions, so I'm not sure what the final conclusion

> was? Is Whonix port coming to Qubes? Is it gonna be using our Qubes/TorVM? How

> is Whonix's user-app part better than Tails? From the user's perspective
> it would probably be beneficial for at least Tails and Whonix to merge.
> And ideal if they had a spinoff that would work on Qubes OS, utilizing
> Qubes infrastructure.
>
> joanna.
>

Tails aims to serve a very different use-case than Whonix and
Qubes/TorVM (which are more similar). All three currently have different
benefits and drawbacks. There is a good comparison here:
https://www.whonix.org/wiki/Comparison_with_Others

In particular, from a Qubes perspective, the main weakness of Tails (as
you've pointed out above) is that it is monolithic, just like any
ordinary OS. If the web browser gets compromised, then the attacker owns
the system. Qubes has a major advantage here. However, this weakness in
Tails is mitigated (not eliminated) by its main strength, which is that
it is a live CD specifically designed with anti-forensics in mind.[1]
This is a significant advantage over Qubes, which currently has no
anti-forensics option. (It was initially hoped that DispVMs would serve
that function, but it was later determined that they do not. At least,
not yet.)

Unlike Tails, both Whonix and Qubes/TorVM aim to use isolation in order
to provide a persistent, Torified environment. The differences here are
more subtle. With Whonix, the user can choose between physical or
virtual isolation (in both cases, isolating user apps from the Tor
process). Virtual isolation uses VirtualBox, whereas physical isolation
requires a second physical machine for running Tor. Unlike Tails, if the
web browser gets compromised in either Whonix or Qubes/TorVM, the
attacker should not thereby own the whole system. Most importantly, the
attacker should not thereby have access to the Tor process itself (and
should not thereby be able to leak, e.g., the real external IP).

IMHO, Qubes/TorVM currently has the following main advantages over Whonix:
 * Type 1 hypervisor (Xen) vs. Type 2 hypervisor (VirtualBox) when not
using Whonix physical isolation
 * Arbitrary number of AnonVMs (domUs/AppVMs connected to TorVM),
allowing for extreme isolation (limited mainly by system memory). (IIUC,
all user apps in Whonix run in a single "Workstation.")

IMHO, Whonix currently has the following main advantages over Qubes/TorVM:
 * Gateway (which runs Tor) and Workstation (which runs user apps) are
specifically designed to work together in order to mitigate
fingerprinting.[2][3] (Qubes/TorVM mostly ignores this or leaves it up
to the user.)
 * Whonix is designed to prevent network time attacks.[4] (AFAIK,
Qubes/TorVM ignores this.)
 * Whonix-Workstation is specifically designed to be run as (in Qubes
terms) an "AnonVM" and includes many features and tweaks to serve this
purpose.[5] (By contrast, Qubes AnonVMs are just regular AppVMs that are
connected to the TorVM. They were not designed to be used as AnonVMs and
therefore lack many "quality of life" features relevant to anonymity.)

In summary, the "ultimate solution" which combines the best of all three
would have the following (in order of presentation, not importance):
 * A strong anti-forensics option (Tails)
 * Secure isolation between user and Tor processes on the same physical
machine (Qubes/TorVM)
 * As many securely isolated environments as the user wants (Qubes/TorVM)
 * Protection against fingerprinting (Whonix)
 * Protection against network time attacks (Whonix)
 * Anonymity-oriented features in the user environments (Whonix)

Ideally, this "ultimate solution" would be integrated into Qubes, so
that the same physical machine can safely be used for both anonymous and
non-anonymous tasks.

-----
[1] The lack of secure isolation in Tails is still a huge problem, since
the fact that Tails "starts clean" each time is little consolation if
critical secrets were leaked or stolen during your previous
(compromised) session.
[2] https://www.whonix.org/wiki/Comparison_with_Others#Fingerprint
[3]
https://www.whonix.org/wiki/Comparison_with_Others#Flash_.2F_Browser_Plugin_Security
[4] https://www.whonix.org/wiki/Comparison_with_Others#Network_Time_related
[5] https://www.whonix.org/wiki/Comparison_with_Others#Features

Joanna Rutkowska:

> I believe it would be a great benefit of splitting Tails into user-apps
> part (Web browser, email clients, etc) and the backend part (tor proxy).
> This way a compromise of user apps would not lead to a compromise of tor
> or the netvm, so reveling of the MAC/IP, and other info (e.g. shooting
> photos via the built in camera).
>
> Our TorVM could probably readily be used as the backend part. I also
> remember there were heavy discussions on both our mailing lists some
> weeks ago on using/porting/adopting Whonix (a competition to Tails which
> already uses this split architecture as I understand) to play as this
> user-apps part on Qubes OS.
>
> Unfortunately I haven't got enough cognitive resources at that time to
> follow all the discussions, so I'm not sure what the final conclusion
> was?

I am in process of splitting Whonix into smaller packages. Debian
packaging for Whonix's fingerprinting defenses, usability, timesync etc.
additions. That's the status for now.

It's a big task, other tasks such as funding and bureaucracy get into
the way so it will take a while until this task will be completed. Help
is welcome.

After finishing the task, it will be simpler to rpm package these
additions so they could be installed in a Qubes AnonVM or eventually in
parts even upstreamed to Debian/Fedora.

> Is Whonix port coming to Qubes?

Before the re-organizing/packaging task I spoke about above has been
finished, I won't be able to think about a port to QubesOS and no one
else is working on it. After that, I am interested in this. Better don't
hold your breath for it.

> Is it gonna be using our TorVM?

An eventual port [long way to go] would fork/extend TorVM or try to
provide a TorVM 2.0 which combines Whonix-Gateway's advantages with
TorVM's advantages.

> How is Whonix's user-app part better than Tails?

Whonix's environment allows to run the original TBB package without Tor
over Tor, but multi language support is less usable (needs changing
config files to download a native language version of Tor Browser
instead of en-US) while Tails builds/patches their own Firefox, which
causes fingerpriting issues, but on the other hand has better multi
language support.

Tails ships privacy-enhanced Pidgin config for IRC, Whonix ships
privacy-enhanced XChat config for IRC.

...and other differences. Not sure we can say, that either one is
"better" in this regard. I guess it will be better, when Whonix's
additions are easier to port to other projects.

> From the user's perspective
> it would probably be beneficial for at least Tails and Whonix to merge.

Agreed. Unfortunately, project merge is very unlikely. (In summary: it
has been internally discussed, we have different views, it is a
productive cooperation [for example: [1]).)

> And ideal if they had a spinoff that would work on Qubes OS, utilizing
> Qubes infrastructure.

Agreed.

[1] https://mailman.boum.org/pipermail/tails-dev/2013-January/002457.html

Axon:

Mostly no different views from my side. Just a small addition.

Axon:

> IMHO, Qubes/TorVM currently has the following main advantages over Whonix:

> ...

>  * Arbitrary number of AnonVMs (domUs/AppVMs connected to TorVM),
> allowing for extreme isolation (limited mainly by system memory). (IIUC,
> all user apps in Whonix run in a single "Workstation.")

Multiple Whonix-Workstation's are also possible with Whonix:
https://www.whonix.org/wiki/Multiple_Whonix-Workstations
Usability of that feature however is not very good yet.

> In summary, the "ultimate solution" which combines the best of all three
> would have the following (in order of presentation, not importance):
>  * A strong anti-forensics option (Tails)
>  * Secure isolation between user and Tor processes on the same physical
> machine (Qubes/TorVM)
>  * As many securely isolated environments as the user wants (Qubes/TorVM)
>  * Protection against fingerprinting (Whonix)
>  * Protection against network time attacks (Whonix)
>  * Anonymity-oriented features in the user environments (Whonix)
>
> Ideally, this "ultimate solution" would be integrated into Qubes, so
> that the same physical machine can safely be used for both anonymous and
> non-anonymous tasks.

Yes.

On Apr 11, 2014 6:49 PM, "Micah Lee" <mi...@micahflee.com> wrote:
>
> On 04/11/14 03:29, Joanna Rutkowska wrote:
> > I just saw Micah Lee from FPF wrote this article about Qubes OS:
> >
> > https://pressfreedomfoundation.org/blog/2014/04/operating-system-can-protect-you-even-if-you-get-hacked
> >
> > It's generally good and very positive but I have two comments:
>
> Thanks!
>
> > 1) The AppVM's rootfs non-persistency should *not* be generally treated
> > as a security feature. I have just added an explicit note to the wiki
> > page about this:
> >
> > http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=diff&version=9&old_version=8
>
> I had thought of this, and I'm glad you updated the wiki to make it more
> explicit.
>
> I still think it's probably helpful for many drive-by untargetted
> attacks.

+1

> I imagine there's malware out there waiting to see if it's
> running in Linux and then installing a rootkit in the kernel if it is,
> never checking to see if it's in a VM, or running in Qubes.
>
> So maybe it's a security feature in the same way that anti-virus
> software is a security feature. :)

Avers suck if attack is new & targeted.

> > 2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
> > no networking, one should remember about the possibility of the malware
> > in that AppVM to leak secrets using a (sophisticated) covert channel,
> > e.g. via CPU cache, to some other AppVM. This naturally assumes that
> > this other AppVM has also been compromised and that the malware in the
> > "air-gapped" machine cooperates with the malware in the other AppVM
> > (which we assume is network-connected).
> >
> > Such covert channels through CPU cache has been described and even
> > implemented in some "lab environments" and IIRC they might allow for
> > bandwidths of even a few tens of bits/sec.

Thanks for notice on this.

> But it's also true that it's significantly more difficult to target a
> Tails or Tor Browser user than it is to target most other people. The
> browsers look identical, can't be uniquely fingerprinted, and aren't
> accustomed to leaking the same unique cookies all the time like normal
> browsers are.

Once the user logs in to the site with a cookie based logged in state - what is the problem in cookie based tracking (assuming ssl is bypassed by a root cert or other attack)?

>
> In practice, if you want to target a specific Tor user you really need
> to target *all Tor users* of a specific website and hope your target is
> one of them, e.g. like what happened in the Freedom Hosting situation.

I didn't dig this case . Though what stops from targeting exactly one user by a compromised server?

The story when feds where attacking everyone is due to all users are potentially criminals. IMO. 

Joanna Rutkowska:

> So, here are some important questions (specifically to Patrick aka
> adrelanos):
>
> 1) How much $ (or BTC) would it cost to port Whonix-workstation to be
> deploy-able as a "one-click solution" in Qubes (AnonVM), as well as to
> port some of the Whonix/Tails-specific improvements to our TorVM?
>
> 2) Are there any technical features that the above task would require
> that current Qubes OS (as of R2-rc1, say) does not provide?
>
> 3) Assuming we implemented that, how would then the comparison between
> Qubes+Whonix vs. Tails then look like? Would it only be
> non-persistence/anti-forensic that would be the Tails advantage?
> Something else? (Besides being a live cd, which is a great advantage for
> many people, I admit).
>
> 4) Regarding anti-forensic support -- what features should Qubes OS
> provide to make that possible?
>
> After we agree on the above, perhaps we might consider some coordinated
> fund-raising (BTC donations, etc) to make the above reality...? Looks
> like lots of Qubes users are indeed interested in reasonably strong
> anonymity.
>
> joanna.
>

These are good questions. I attempt to get closer to an answer within
the next days. Need to learn more about Qubes and Fedora first.

I have some questions as well.

1) I don't know how rpm packaging works. However, the TorVM rpm
packaging seems simpler to me and introduce less overhead than Debian
packaging at first view. Is there something like config-package-dev for
Fedora? config-package-dev is a package to overtake ownership of other
package's files. Such as, in Debian the Tor package owns
/usr/share/tor/tor-service-defaults-torrc. Whonix needs to modify that
file and keep it updated. config-package-dev can be used to avoid
getting the file being overwritten when upstream releases and upgrade.
Is there something like this for Fedora or is this even required? That
would make a port much simpler, because for many parts, it's just
diverted config files.

2) How big is Qubes's user base?

Cheers,
Patrick

[1] http://debathena.mit.edu/config-packages/

On Mon, Apr 21, 2014, at 11:15, Patrick Schleizer wrote:
> 2) How big is Qubes's user base?

Expect growth. :)

j

qubes-tor pacakages provides own config file (tor --defaults-torrc option
used), so no need to override the one provided by tor package.

But to answer your question - no, rpm do not have option to take ownership of
files from other packages, but to workaround this (rather sensible) limitation
you can modify the config in triggers (so the file will be modified after each
original package update).

Note that a Debian package is in the work and pending upload to our
community repo:

https://groups.google.com/forum/#!topic/qubes-devel/EBxvtMlwp5k

So, if this template indeed works (I haven't tested it myself) it
perhaps might be a good starting point for porting Whonix workstation?

> 2) How big is Qubes's user base?
>

Using the method suggested by Zrubi some weeks ago to check our yum
server logs for the number of connections fetching updates and counting
unique IPs:

[user@qubes ~]$ ssh joa...@yum.qubes-os.org
[joanna@www ~]$ su -
[root@www ~]# grep -h 'repomd.xml' /var/log/httpd/access_log* | cut -f1
-d' ' | sort -u | wc -l
2349

The earliest log analyzed by the command above is from Mar 30:

[root@www ~]# ll /var/log/httpd/access_log*
-rw-r--r-- 1 root root 10766268 Apr 23 12:15 /var/log/httpd/access_log
-rw-r--r-- 1 root root 26235695 Mar 30 04:25
/var/log/httpd/access_log-20140330
-rw-r--r-- 1 root root 24743692 Apr  6 03:16
/var/log/httpd/access_log-20140406
-rw-r--r-- 1 root root 24828434 Apr 13 03:15
/var/log/httpd/access_log-20140413
-rw-r--r-- 1 root root 33897552 Apr 20 03:37
/var/log/httpd/access_log-20140420

So, within the last ~3 weeks there were 2.5k unique IPs checking for
updates for Qubes OS.

The above method has some obvious limitations:

1) It might count some users twice or more due to them using Dynamic IPs
(so, overestimation)

2) It might treat some users as just one due to them being behind NAT
(so, undercounting)

Anyway, some interesting findings:

* Let's see how many users (IPs) are running Qubes OS R2rc1:

[root@www ~]# grep -h 'r2/.*repomd.xml' /var/log/httpd/access_log* | cut
-f1 -d' ' | sort -u | wc -l
436

*... and how many still on R2B3:

[root@www ~]# grep -h 'r2-beta3/.*repomd.xml' /var/log/httpd/access_log*
| cut -f1 -d' ' | sort -u | wc -l
1817

* ... and how many still living on R1:

[root@www ~]# grep -h 'r1.*repomd.xml' /var/log/httpd/access_log* | cut
-f1 -d' ' | sort -u | wc -l
114

(Hey, Qubes R2 is waaay cooler than R1, I suggest you consider an
upgrade to R2rc1...)

* Now, this is shocking to me:

[root@www ~]# grep -h 'r1-beta.*repomd.xml' /var/log/httpd/access_log* |
cut -f1 -d' ' | sort -u | wc -l
26

Why would anybody still using Qubes R1 Beta in 2014? Plz, guys :)

joanna.

On 23 April 2014 14:26, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:

> Using the method suggested by Zrubi some weeks ago to check our yum
> server logs for the number of connections fetching updates and counting
> unique IPs:
>
> [user@qubes ~]$ ssh joa...@yum.qubes-os.org
> [joanna@www ~]$ su -
> [root@www ~]# grep -h 'repomd.xml' /var/log/httpd/access_log* | cut -f1
> -d' ' | sort -u | wc -l

..

> The above method has some obvious limitations:
>
> 1) It might count some users twice or more due to them using Dynamic IPs
> (so, overestimation)
>
> 2) It might treat some users as just one due to them being behind NAT
> (so, undercounting)

I think You can eliminate these problems if you only 'watch' one
specific package vesrion because normaly* every single Qubes
installation will download that package only once.

* forced downloads/reinstalls  still make it false of course.

> Now, this is shocking to me:
>
> [root@www ~]# grep -h 'r1-beta.*repomd.xml' /var/log/httpd/access_log* |
> cut -f1 -d' ' | sort -u | wc -l
> 26
>
> Why would anybody still using Qubes R1 Beta in 2014? Plz, guys :)

indexing robots maybe?



--
Zrubi

On 23.04.2014 15:47, Zrubecz Laszlo wrote:
> On 23 April 2014 14:26, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:

>> Now, this is shocking to me:
>>
>> [root@www ~]# grep -h 'r1-beta.*repomd.xml' /var/log/httpd/access_log* |
>> cut -f1 -d' ' | sort -u | wc -l
>> 26
>>
>> Why would anybody still using Qubes R1 Beta in 2014? Plz, guys :)
>
> indexing robots maybe?

Indeed, none was using yum (based on user-agent).

Joanna Rutkowska:

> 2) Are there any technical features that the above task would require
> that current Qubes OS (as of R2-rc1, say) does not provide?

Can Qubes OS leave VM's clocks untouched and keep time sync to the VM or
is there some forced-VM-timesync-with-dom-0 that can not be turned off?
In that case, that would be a bad.

> 3) Assuming we implemented that, how would then the comparison between
> Qubes+Whonix vs. Tails then look like? Would it only be
> non-persistence/anti-forensic that would be the Tails advantage?
> Something else? (Besides being a live cd, which is a great advantage for
> many people, I admit).

Correct so far.

- Hardware requirements would differ.
- Qubes builds wouldn't be verifiable?
https://www.whonix.org/wiki/Comparison_with_Others#Verifiable_Builds

> 4) Regarding anti-forensic support -- what features should Qubes OS
> provide to make that possible?

You tell me. ;) Existing discussion:
https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4

Hi,

sorry for the delay! These are difficult questions...

Joanna Rutkowska:
> So, here are some important questions (specifically to Patrick aka
> adrelanos):
>
> 1) How much $ (or BTC) would it cost to port Whonix-workstation to be
> deploy-able as a "one-click solution" in Qubes (AnonVM), as well as to
> port some of the Whonix/Tails-specific improvements to our TorVM?

> After we agree on the above, perhaps we might consider some
coordinated fund-raising (BTC donations, etc) to make the above
reality...? Looks like lots of Qubes users are indeed interested in
reasonably strong anonymity.

The short and professional answer is:
Takes a budged of $ 200.000 and takes 1 year.

The long answer is:
Is that amount of money petty cash for you? Great, we got a deal. :)
That amount of would include paying someone that knows how to get sub
tasks done, that I would otherwise have to teach to myself. I have the
high level overview and could orchestrate the whole thing.

Also depends on how much help I am getting. Having free premium support
as in getting all my questions about Qubes/Fedora/rpm packaging answered
would certainly speed up things.

Difficult to say. I am not a professional coder, everything taught to
myself by using search engines + asking in online public places. I don't
know how long task X will take. Just doing things and noticing how long
it took after the task is done. I am not like a plumber who can say
"estimation of cost costs is 100 $" and after that "repair will cost 500
$". Sorry about that. I wish I had a better answer.

At the moment I can't even effort the time to get more familiar with
Qubes nor for an estimation of cost.

Recently I've spent time to eventually get funding for Whonix. Writing
up things that I can get done within a year and estimating costs. In the
Debian/Whonix ecosystem, that's simpler, because I am already familiar.

Best thing to keep me working on this is keeping me alive. Having a
unconditional basic income would help keeping me working on Free
Software. Since we don't have this yet...

Sustaining my live on subsistence level costs 1000 Eur / month or 1300 $
/ month. That's also the amount of stable income per month I wish to to
get for working on Whonix.

This might sound like a lot money. It's not. Germany is expensive. ~240
€ per month for rent at the town's edge, ~350 € for compulsory health
insurance, 30 € electricity, ~20 € internet flatrate, ~18 € compulsory
public TV (gez, rundfunkbeitrag), food, clothes, transportation, tax...
Isn't a lot money in comparison.

So if that's peanuts to you, by all means, sponsor me.

Cheers,
Patrick

I say move to Prague and restate your base income at 700€ :)

That base income doesn't sound unreasonable at all, it's less than what Joey Hess[1][2] asks for his projects and he's certainly not known for his extravigant life style. 

[1] https://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-but-with-your-own

[2]  http://campaign.joeyh.name/

On 04.05.2014 18:30, Patrick Schleizer wrote:
> Joanna Rutkowska:
>> 2) Are there any technical features that the above task would require
>> that current Qubes OS (as of R2-rc1, say) does not provide?
>
> Can Qubes OS leave VM's clocks untouched and keep time sync to the VM or
> is there some forced-VM-timesync-with-dom-0 that can not be turned off?
> In that case, that would be a bad.

Currently time synchronization is done in some silly way: qvm-sync-clock
called each 6min from dom0 cron. That tool fetch the current time using
ntpdate in netvm (VM set as clockvm in qubes-prefs), then pass the result to
'date -s' in each VM.

You can disable this mechanism globally by unsetting(*) clockvm (qubes-prefs
-s clockvm none).

(*) Which apparently was broken, fix will be included in updates soon.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

On 05/05/14 03:16, Marek Marczykowski-Górecki wrote:
> On 04.05.2014 18:30, Patrick Schleizer wrote:
>> Joanna Rutkowska:
>>> 2) Are there any technical features that the above task would require
>>> that current Qubes OS (as of R2-rc1, say) does not provide?
>>
>> Can Qubes OS leave VM's clocks untouched and keep time sync to the VM or
>> is there some forced-VM-timesync-with-dom-0 that can not be turned off?
>> In that case, that would be a bad.
>
> Currently time synchronization is done in some silly way: qvm-sync-clock
> called each 6min from dom0 cron. That tool fetch the current time using
> ntpdate in netvm (VM set as clockvm in qubes-prefs), then pass the result to
> 'date -s' in each VM.
>
> You can disable this mechanism globally by unsetting(*) clockvm (qubes-prefs
> -s clockvm none).
>
> (*) Which apparently was broken, fix will be included in updates soon.
>

How about we change this mechanism to have a VM to initiate the clock
syncing for itself? This could be called: 1) in response to the VM
getting notification about resume, and 2) every once in a while. This
could be done via qrexec service, perhaps even going directly to a
select netvm (but the VM would need to know its name somehow).

In that case this could then be controlled on a per-vm basis via: 1)
systemd services on/off switching and 2) qrexec policy in dom0.

joanna.

So, just out of curiosity: how does that 12*1000 EUR compare to $200k
quoted at the beginning? That's like $15k vs $200k...

joanna.

Joanna Rutkowska:
$15k:
Protects me from starvation, protects me homelessness, ensures minimal
social participation, protects me from jail (tax consultant -> tax
office), protects me from being forced to take a regular job that takes
up most of the time of the week and depletes most mental resources, lets
me pursue my real interest for profession, which is working on Free
Software/anonymity/security/privacy/packaging/maintenance/documentation/support/etc/teaching
missing knowledge to myself; political education, research, advocacy
[money system, unconditional basic income, post-growth and more].

$200k:
Certainly does what $15k above does. + With 200k I could guarantee
finishing the task within 1 year. Because then I could pay honorarium to
subcontractors who either implement stuff on request or teach me stuff
which I otherwise have to slowly teach to myself.

Cheers,
Patrick

Joanna Rutkowska:

> On 05/05/14 03:16, Marek Marczykowski-Górecki wrote:
>> On 04.05.2014 18:30, Patrick Schleizer wrote:
>>> Joanna Rutkowska:
>>>> 2) Are there any technical features that the above task would require
>>>> that current Qubes OS (as of R2-rc1, say) does not provide?
>>>
>>> Can Qubes OS leave VM's clocks untouched and keep time sync to the VM or
>>> is there some forced-VM-timesync-with-dom-0 that can not be turned off?
>>> In that case, that would be a bad.
>>
>> Currently time synchronization is done in some silly way: qvm-sync-clock
>> called each 6min from dom0 cron. That tool fetch the current time using
>> ntpdate in netvm (VM set as clockvm in qubes-prefs), then pass the result to
>> 'date -s' in each VM.
>>
>> You can disable this mechanism globally by unsetting(*) clockvm (qubes-prefs
>> -s clockvm none).
>>
>> (*) Which apparently was broken, fix will be included in updates soon.
>>
>
> How about we change this mechanism to have a VM to initiate the clock
> syncing for itself? This could be called: 1) in response to the VM
> getting notification about resume, and 2) every once in a while.

This sounds nice from perspective of anonymity distributions. No
unexpected forced clock change from host (dom0) and ability to get an
opinion from host. Would make time syncing very flexible.

If Tor/Anon-VM's can easily disable forced time sync from host (dom0) [
/etc/xxx.d configuration style folders are my preference here] then it's
just perfect.

On 04/11/14 16:49, Micah Lee wrote:
>> 1) The AppVM's rootfs non-persistency should *not* be generally treated
>> > as a security feature. I have just added an explicit note to the wiki
>> > page about this:
>> >
>> > http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateVM?action=diff&version=9&old_version=8
> I had thought of this, and I'm glad you updated the wiki to make it more
> explicit.
>
> I still think it's probably helpful for many drive-by untargetted
> attacks. I imagine there's malware out there waiting to see if it's
> running in Linux and then installing a rootkit in the kernel if it is,
> never checking to see if it's in a VM, or running in Qubes.
>
> So maybe it's a security feature in the same way that anti-virus
> software is a security feature. :)
>

Perhaps there is some more value in this, after all.

There is a significant difference between a malware that has installed
itself "somewhere deep in the system rootfs" vs. malware that has just
placed its *triggers* (i.e. exploits triggering malware installation)
somewhere in the user home directory. This is because in the latter
case, when the user updates his or her AppVM, the bugs being exploitable
by the malware trigger might just go away and so the malware will be
automatically deactivated. On normal desktop systems this would not
work, because a compromised system might just (silently) not allow to
install updates as its constantly under the control of the malware. In
case of Qubes OS and its AppVMs this is not the case, as the updates are
installed in the Template VM (and the VM kernels in Dom0), which cannot
be affected by the homedir-persistent malware in one of the AppVMs.

The above reasoning doesn't apply, however, to malware which might be
using "legal triggers", such as the .bashrc or Firefox profile's
extensions. But these triggers, being "legal", are not "hidden", and so
it is easy to think about a simple malware scanner to catch all such
triggers. These could even be running in the same AppVM and run the scan
on the whole /rw/home, before it gets mounted and "parsed" by the
regular AppVMs scripts.

joanna.

On 04/23/14 14:26, Joanna Rutkowska wrote:
>> > 2) How big is Qubes's user base?
>> >
> Using the method suggested by Zrubi some weeks ago to check our yum
> server logs for the number of connections fetching updates and counting
> unique IPs:
>
> [user@qubes ~]$ ssh joa...@yum.qubes-os.org
> [joanna@www ~]$ su -
> [root@www ~]# grep -h 'repomd.xml' /var/log/httpd/access_log* | cut -f1
> -d' ' | sort -u | wc -l
> 2349
>
> The earliest log analyzed by the command above is from Mar 30:
>
> [root@www ~]# ll /var/log/httpd/access_log*
> -rw-r--r-- 1 root root 10766268 Apr 23 12:15 /var/log/httpd/access_log
> -rw-r--r-- 1 root root 26235695 Mar 30 04:25
> /var/log/httpd/access_log-20140330
> -rw-r--r-- 1 root root 24743692 Apr  6 03:16
> /var/log/httpd/access_log-20140406
> -rw-r--r-- 1 root root 24828434 Apr 13 03:15
> /var/log/httpd/access_log-20140413
> -rw-r--r-- 1 root root 33897552 Apr 20 03:37
> /var/log/httpd/access_log-20140420
>
> So, within the last ~3 weeks there were 2.5k unique IPs checking for
> updates for Qubes OS.
>
> The above method has some obvious limitations:
>
> 1) It might count some users twice or more due to them using Dynamic IPs
> (so, overestimation)
>
> 2) It might treat some users as just one due to them being behind NAT
> (so, undercounting)

I just thought that we could easily run the script above (or some
improved version) from cron on our updates server and then have it send
the output number somewhere... This somewhere could be a web app running
on some sever and e.g. generating a nice chart of Qubes User Base over
time, showing how it grows :)

Anybody would like to code and host such a web app?

FWIW, today's results (I added filtering out access from non-yum clients
to eliminate false positives from web robots):

[root@www yum.qubes-os.org]# grep -h 'repomd.xml'
/var/log/httpd/access_log* | grep yum | cut -f1 -d' ' | sort -u | wc -l
2989

joanna.

Hi,
Thanks for sharing. Are these numbers in line with the mailing list user
base? Just curious.

Anyway, maybe it could be useful to gather these stats daily, package
them monthly and make available to download. The web app would follow...
or a script run locally... or an entry to the wiki...

--
Pedro Martins

On 07/19/14 14:28, Joanna Rutkowska wrote:
> I just thought that we could easily run the script above (or some
> improved version) from cron on our updates server and then have it send
> the output number somewhere... This somewhere could be a web app running
> on some sever and e.g. generating a nice chart of Qubes User Base over
> time, showing how it grows :)
>
> Anybody would like to code and host such a web app?

I just made a simple chart page:
http://fixmee.zrubi.hu/QubesCounter.html

It is really just a basic starting point, and this URL will not be
available for long - just for the demo :)

But this is so simple it should be placed directly to the yum repo
server. And it is only needs a CSV data file (QubesCounter.csv) on the
same server with a content something like this:

2014-01,17
2014-02,16
2014-03,2
2014-04,7
2014-05,5
2014-06,9
2014-07,4

This 'database' should be feed by the log parser script running monthly.

FYI:
This charts are using (sourcing) the 3rd party amcharts js library files.

If You like this solution I will put it to github for the easy
deploying/contributing


--
Zrubi

On 09/09/14 18:15, Joanna Rutkowska wrote:

> We've just been talking with Wojtek that probably the best solution
> would be for our yum.qubes-os.org server to expose a static page with
> server statistic at some defined URL (e.g.

Actually my .html page is static - from the server point of view.
All 'dynamic' code is JavaScript which is runs on client side.

> yum.qubes-os.org/user_stats.html or something). This page would be
> generated by a cron script every week or every day and would just
> contain a number of users.

This is nearly the same as I suggested - but a growing .csv gives much
more possibilities...

> Then we could have some nice charting script, like your, running on our
> wiki server or somewhere, take this number and draw nice graphs.

The only downside of splitting the chart and the data is the built in
security feature of the browsers. They simply not load the external URLs
where the data would come from...

This of course easily workarounded by downloading the data - but the
charts still needs .csv (or .json) formatted data.

And generating (and serving) such data on server side is really easy and
secure as I see.


--
Zrubi

On 09/09/14 17:07, Todd Lasman wrote:
> Interesting concept.  Is the y-axis the absolute number of users (that
> is 20, rather than 20 x some power of 10?)  My guess is that if this is
> the absolute number of users, it's way too low.
>
> Where does the data come from?

The current data is just some random numbers - only for the demo.

The actual data should come from the yum repository. - read back this
thread for more details.


--
Zrubi

It's definitely more than 20 ;)

[root@www ~]# grep -h 'repomd.xml' /var/log/httpd/access_log* | grep yum

| cut -f1 -d' ' | sort -u | wc -l

3073

BTW, my recent paper on "Qubes vs. airgap" has been downloaded 68k+
times in just about 2 weeks (I didn't even expect there are so many
security-focused technical people out there). I interpret this fact that
there is quite some interest in Qubes OS, but people are still shy to
try it out :)

[root@www ~]# grep "Software_compart.*pdf" /var/log/httpd/access_log* |
wc -l
68272

j.

Hello,

the covert channels through CPU cache scenario applies to databases. Here you always again and again steam the database through the CPU caches...

And many are very keen to know (& steal) the database content...

Cheers