mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-25 07:19:33 -05:00
Fix a few typos
This commit is contained in:
r00t
parent
5ae0d5dfb0
commit
0baa097f9b
@ -43,7 +43,7 @@ stored on or accessed by this computer, such as health records, confidential
|
||||
communications, or thoughts written in a private journal. Malware can also
|
||||
interfere with the activities you perform with your computer. For example,
|
||||
if you use your computer to conduct financial transactions, the malware
|
||||
might allow its creator to make fradulent transactions in your name.
|
||||
might allow its creator to make fraudulent transactions in your name.
|
||||
|
||||
|
||||
Aren't antivirus programs and firewalls enough?
|
||||
@ -67,7 +67,7 @@ these bugs from being exploited.
|
||||
How does Qubes provide security?
|
||||
--------------------------------
|
||||
|
||||
Qubes takes an appraoch called **security by compartmentalization**, which
|
||||
Qubes takes an approach called **security by compartmentalization**, which
|
||||
allows you to compartmentalize the various parts of your digital life into
|
||||
securely isolated virtual machines (VMs). A VM is basically a simulated
|
||||
computer with its own OS which runs as software on your physical computer. You
|
||||
@ -185,4 +185,3 @@ technical details have been omitted here for the sake of presentation.
|
||||
[devel-faq]: /doc/devel-faq/
|
||||
[downloads]: /downloads/
|
||||
[getting started]: /doc/getting-started/
|
||||
|
||||
|
||||
@ -188,7 +188,7 @@ Run `systemctl enable NetworkManager-dispatcher.service` in the TemplateVM upon
|
||||
|
||||
### My keyboard layout settings are not behaving correctly. What should I do?
|
||||
|
||||
Please read [this disccusion](https://groups.google.com/d/topic/qubes-devel/d8ZQ_62asKI/discussion).
|
||||
Please read [this discussion](https://groups.google.com/d/topic/qubes-devel/d8ZQ_62asKI/discussion).
|
||||
|
||||
### My dom0 and/or TemplateVM update stalls when attempting to update via the GUI tool. What should I do?
|
||||
|
||||
@ -200,7 +200,7 @@ In your TemplateVMs, open a terminal and run `sudo yum upgrade`.
|
||||
|
||||
### How do I run a Windows HVM in non-seamless mode (i.e., as a single window)?
|
||||
|
||||
Enable "debug mode" in the AppVM's settings, either by checking the box labelled "Run in debug mode" in the Qubes VM Manager AppVM settings menu or by running the [qvm-prefs command](/doc/dom0-tools/qvm-prefs/).)
|
||||
Enable "debug mode" in the AppVM's settings, either by checking the box labeled "Run in debug mode" in the Qubes VM Manager AppVM settings menu or by running the [qvm-prefs command](/doc/dom0-tools/qvm-prefs/).)
|
||||
|
||||
|
||||
### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.
|
||||
@ -232,8 +232,8 @@ This is an intended feature. A device which was previously assigned to a less tr
|
||||
or
|
||||
|
||||
1. Go to the sysfs (`/sys/bus/pci`), find the right device, detach it from the pciback driver and attach back to the original driver. Replace `<BDF>` with your device, for example `00:1c.2`:
|
||||
|
||||
|
||||
echo 0000:<BDF> > /sys/bus/pci/drivers/pciback/unbind
|
||||
MODALIAS=`cat /sys/bus/pci/devices/0000:<BDF>/modalias`
|
||||
MOD=`modprobe -R $MODALIAS | head -n 1`
|
||||
echo <BDF> > /sys/bus/pci/drivers/$MOD/bind
|
||||
echo <BDF> > /sys/bus/pci/drivers/$MOD/bind
|
||||
|
||||
@ -27,7 +27,7 @@ As of Qubes R2B3, these functions are integrated into the Qubes VM Manager GUI.
|
||||
Creating a Backup
|
||||
-----------------
|
||||
|
||||
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Backup VMs** in the dropdown list. This brings up the **Qubes Backup VMs** window.
|
||||
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Backup VMs** in the drop-down list. This brings up the **Qubes Backup VMs** window.
|
||||
|
||||
2. Move the AppVMs which you desire to back up to the right-hand **Selected** column. AppVMs in the left-hand **Available** column will not be backed up.
|
||||
|
||||
@ -37,8 +37,8 @@ Creating a Backup
|
||||
|
||||
3. Select the destination for the backup:
|
||||
|
||||
- If you wish to send your backup to a [USB mass storage device](/doc/stick-mounting/), select the device in the dropdown box next to **Device** (feature removed in R3, select appropriate **Target AppVM** and mount the stick with one click in file selection dialog).
|
||||
- If you wish to send your backup to a (currently running) AppVM, select the AppVM in the dropdown box next to **Target AppVM**.
|
||||
- If you wish to send your backup to a [USB mass storage device](/doc/stick-mounting/), select the device in the drop-down box next to **Device** (feature removed in R3, select appropriate **Target AppVM** and mount the stick with one click in file selection dialog).
|
||||
- If you wish to send your backup to a (currently running) AppVM, select the AppVM in the drop-down box next to **Target AppVM**.
|
||||
|
||||
You must also specify a directory on the device or in the AppVM, or a command to be executed in the AppVM as a destination for your backup. For example, if you wish to send your backup to the `~/backups` folder in the target AppVM, you would simply type `backups` in this field. This destination directory must already exist. If it does not exist, you must create it manually prior to backing up.
|
||||
|
||||
@ -56,14 +56,14 @@ Creating a Backup
|
||||
Restoring from a Backup
|
||||
-----------------------
|
||||
|
||||
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Restore VMs from backup** in the dropdown list. This brings up the **Qubes Restore VMs** window.
|
||||
1. In **Qubes VM Manager**, click **System** on the menu bar, then click **Restore VMs from backup** in the drop-down list. This brings up the **Qubes Restore VMs** window.
|
||||
|
||||
2. Select the source location of the backup to be restored:
|
||||
|
||||
- If your backup is located on a [USB mass storage device](/doc/stick-mounting/), select the device in the dropdown box next to **Device**.
|
||||
- If your backup is located in a (currently running) AppVM, select the AppVM in the dropdown box next to **AppVM**.
|
||||
- If your backup is located on a [USB mass storage device](/doc/stick-mounting/), select the device in the drop-down box next to **Device**.
|
||||
- If your backup is located in a (currently running) AppVM, select the AppVM in the drop-down box next to **AppVM**.
|
||||
|
||||
You must also specify the directory in which the backup resides (or a command to be executed in an AppVM). If you followed the instructions in the previous section, "Creating a Backup," then your backup is most likely in the location you chose as the destination in step 3. For example, if you had chosen the `~/backups` directory of an AppVM as your destination in step 3, you would now select the same AppVM and again type `backups` into the **Backup directory** field.
|
||||
You must also specify the directory in which the backup resides (or a command to be executed in an AppVM). If you followed the instructions in the previous section, "Creating a Backup", then your backup is most likely in the location you chose as the destination in step 3. For example, if you had chosen the `~/backups` directory of an AppVM as your destination in step 3, you would now select the same AppVM and again type `backups` into the **Backup directory** field.
|
||||
|
||||
**Note:** After you have typed the directory location of the backup in the **Backup directory** field, click the ellipsis button `...` to the right of the field.
|
||||
|
||||
@ -101,4 +101,3 @@ Notes
|
||||
* The Qubes backup system relies on `openssl enc`, which is known to use a very weak key derivation scheme. The Qubes backup system also uses the same passphrase for authentication and for encryption, which is problematic from a security perspective. Users are advised to use a very high entropy passphrase for Qubes backups. For a full discussion, see [this thread](https://groups.google.com/d/msg/qubes-devel/CZ7WRwLXcnk/u_rZPoVxL5IJ).
|
||||
* For the technical details of the backup system, please refer to [this thread](https://groups.google.com/d/topic/qubes-devel/TQr_QcXIVww/discussion).
|
||||
* If working with symlinks, note the issues described in [this thread](https://groups.google.com/d/topic/qubes-users/EITd1kBHD30/discussion).
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ Copy and Paste between domains
|
||||
|
||||
Qubes fully supports secure copy and paste operation between domains. In order to copy a clipboard from domain A to domain B, follow those steps:
|
||||
|
||||
1. Click on the application window in the domain A where you have selected text for copying. Then use the *app-specific* hot-key (or menu option) to copy this into domain's local clipboard (in other words: do the copy operation as usual, in most cases by pressing Ctrl-C).
|
||||
1. Click on the application window in domain A where you have selected text for copying. Then use the *app-specific* hot-key (or menu option) to copy this into domain's local clipboard (in other words: do the copy operation as usual, in most cases by pressing Ctrl-C).
|
||||
2. Then (when the app in domain A is still in focus) press Ctrl-Shift-C magic hot-key. This will tell Qubes that we want to select this domain's clipboard for *global copy* between domains.
|
||||
3. Now select the destination app, running in domain B, and press Ctrl-Shift-V, another magic hot-key that will tell Qubes to make the clipboard marked in the previous step available to apps running in domain B. This step is necessary because it ensures that only domain B will get access to the clipboard copied from domain A, and not any other domain that might be running in the system.
|
||||
4. Now, in the destination app use the app-specific key combination (usually Ctrl-V) for pasting the clipboard.
|
||||
@ -27,7 +27,7 @@ Note that only simple plain text copy/paste is supported between AppVMs. This is
|
||||
On Copy/Paste Security
|
||||
----------------------
|
||||
|
||||
The scheme is *secure* because it doesn't allow other VMs to steal the content of the clipboard. However, one should keep in mind that performing a copy and paste operation from *less trusted* to *more trusted* domain can always be potentially insecure, because the data that we insert might potentially try to exploit some hypothetical bug in the destination VM (e.g. the seemingly innocent link that we copy from untrusted domain, might turn out to be, in fact, a large buffer of junk that, when pasted into the destination VM's word processor could exploit a hypothetical bug in the undo buffer). This is a general problem and applies to any data transfer between *less trusted to more trusted* domain. It even applies to copying files between physically separate machines (air-gapped) systems. So, you should always copy clipboard and data only from *more trusted* to *less trusted* domains.
|
||||
The scheme is *secure* because it doesn't allow other VMs to steal the content of the clipboard. However, one should keep in mind that performing a copy and paste operation from *less trusted* to *more trusted* domain can always be potentially insecure, because the data that we insert might potentially try to exploit some hypothetical bug in the destination VM (e.g. the seemingly innocent link that we copy from untrusted domain, might turn out to be, in fact, a large buffer of junk that, when pasted into the destination VM's word processor could exploit a hypothetical bug in the undo buffer). This is a general problem and applies to any data transfer between *less trusted to more trusted* domains. It even applies to copying files between physically separate machines (air-gapped) systems. So, you should always copy clipboard and data only from *more trusted* to *less trusted* domains.
|
||||
|
||||
See also [this article](http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html) for more information on this topic, and some ideas of how we might solve this problem in some future version of Qubes.
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ redirect_from:
|
||||
Copying files between domains
|
||||
=============================
|
||||
|
||||
Qubes also supports secure file coping between domains. In order to copy file(s) from domain A to domain B, follow those steps:
|
||||
Qubes also supports secure file coping between domains. In order to copy file(s) from domain A to domain B, follow these steps:
|
||||
|
||||
GUI
|
||||
---
|
||||
@ -36,7 +36,7 @@ On inter-domain file copy security
|
||||
|
||||
The scheme is *secure* because it doesn't allow other domains to steal the files that are being copying, and also doesn't allow the source domain to overwrite arbitrary file on the destination domain. Also, Qubes file copy scheme doesn't use any sort of virtual block devices for file copy -- instead we use Xen shared memory, which eliminates lots of processing of untrusted data. For example, the receiving domain is *not* forced to parse untrusted partitions or file systems. In this respect our files copy mechanism provides even more security than file copy between two physically separated (air-gapped) machines!
|
||||
|
||||
However, one should keep in mind that performing a data transfer from *less trusted* to *more trusted* domain can always be potentially insecure, because the data that we insert might potentially try to exploit some hypothetical bug in the destination VM (e.g. a seemingly innocent JPEG that we copy from untrusted domain, might turned out to be specially craft exploit for some hypothetical bug in JPEG parsing application in the destination domain). This is a general problem and applies to any data transfer between *less trusted to more trusted* domain. It even applies to the scenario of copying files between air-gapped machines. So, you should always copy data only from *more trusted* to *less trusted* domains.
|
||||
However, one should keep in mind that performing a data transfer from *less trusted* to *more trusted* domain can always be potentially insecure, because the data that we insert might potentially try to exploit some hypothetical bug in the destination VM (e.g. a seemingly innocent JPEG that we copy from untrusted domain, might turned out to be specially craft exploit for some hypothetical bug in JPEG parsing application in the destination domain). This is a general problem and applies to any data transfer between *less trusted to more trusted* domains. It even applies to the scenario of copying files between air-gapped machines. So, you should always copy data only from *more trusted* to *less trusted* domains.
|
||||
|
||||
See also [this article](http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html) for more information on this topic, and some ideas of how we might solve this problem in some future version of Qubes.
|
||||
|
||||
|
||||
@ -60,7 +60,7 @@ Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for
|
||||
|
||||
- So, are the template VMs as trusted as Dom0?
|
||||
|
||||
Not quite. Dom0 compromise is absolutely fatal, and it leads to Game Over (TM). However, a compromise of a template affects only a subset of all your AppVMs (in case you use more than one template, or also some standalone VMs). Also, if your AppVMs are network disconnected, even though their filesystems might got compromised due to the corresponding template compromise, it still would be difficult for the attacker to actually leak out the data stolen in an AppVM. Not impossible (due to existence of cover channels between VMs on x86 architecture), but difficult and slow.
|
||||
Not quite. Dom0 compromise is absolutely fatal, and it leads to Game Over<sup>TM</sup>. However, a compromise of a template affects only a subset of all your AppVMs (in case you use more than one template, or also some standalone VMs). Also, if your AppVMs are network disconnected, even though their filesystems might got compromised due to the corresponding template compromise, it still would be difficult for the attacker to actually leak out the data stolen in an AppVM. Not impossible (due to existence of cover channels between VMs on x86 architecture), but difficult and slow.
|
||||
|
||||
Standalone VMs
|
||||
--------------
|
||||
|
||||
@ -15,8 +15,8 @@ How to Mount USB Sticks to AppVMs
|
||||
|
||||
Qubes supports the ability to attach a USB stick (or just one or more of its partitions) to any AppVM easily, no matter which VM actually handles the USB controller. (The USB controller may be assigned on the **Devices** tab of an AppVM's settings page in Qubes VM Manager or by using the [qvm-pci command](/doc/assigning-devices/).)
|
||||
|
||||
As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manager GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. This, however, only works for the whole device.
|
||||
If you would like to attach individual partitions you must use the command-line tool (shown below). The reason for this is that when attaching a single partition, it used to be that Nautilus file manager would not see it and automatically mount it (see [this ticket](https://github.com/QubesOS/qubes-issues/issues/623)). This problem, however, seems to be resolved (see [this issue comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051)).
|
||||
As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manager GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. This, however, only works for the whole device.
|
||||
If you would like to attach individual partitions you must use the command-line tool (shown below). The reason for this is that when attaching a single partition, it used to be that Nautilus file manager would not see it and automatically mount it (see [this ticket](https://github.com/QubesOS/qubes-issues/issues/623)). This problem, however, seems to be resolved (see [this issue comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051)).
|
||||
If for some reason the device does not appear in nautilus and you still need to attach just a single partition to a device, you will need to mount it manually; the device will show up as /dev/xvdi (or /dev/xvdj if there is already one device attached - if two, /dev/xvdk and so on).
|
||||
|
||||
The command-line tool you may use to mount whole USB sticks or their partitions is `qvm-block`. This tool can be used to assign a USB stick to an AppVM as follows:
|
||||
@ -31,7 +31,7 @@ The command-line tool you may use to mount whole USB sticks or their partitions
|
||||
in your system, no matter which VM hosts the controller. The name of the
|
||||
VM hosting the USB controller is displayed before the colon in the device
|
||||
name. The string after the colon is the name of the device used within the
|
||||
VM. Like this:
|
||||
VM. Like this:
|
||||
|
||||
dom0:sdb1 Cruzer () 4GiB
|
||||
|
||||
@ -45,8 +45,8 @@ The command-line tool you may use to mount whole USB sticks or their partitions
|
||||
1. Assuming our USB stick is attached to dom0 and is sdb, we attach the device to an AppVM like so:
|
||||
|
||||
`qvm-block -a personal dom0:sdb`
|
||||
|
||||
This will attach the device to the AppVM as "/dev/xvdi", if not already taken by another attached device, or "/dev/xvdj" etc.
|
||||
|
||||
This will attach the device to the AppVM as "/dev/xvdi", if not already taken by another attached device, or "/dev/xvdj" etc.
|
||||
|
||||
You may also mount one partition at a time by using the same command with the partition number after sdb.
|
||||
|
||||
@ -62,7 +62,7 @@ The command-line tool you may use to mount whole USB sticks or their partitions
|
||||
|
||||
1. You may now remove the device.
|
||||
|
||||
**Warning: Do not remove the device before detatching it from the VM!** Otherwise you
|
||||
**Warning: Do not remove the device before detaching it from the VM!** Otherwise you
|
||||
will not be able to attach it anywhere later. See [this
|
||||
ticket](https://github.com/QubesOS/qubes-issues/issues/1082) for details.
|
||||
|
||||
@ -93,7 +93,7 @@ this steps:
|
||||
`qvm-block` output. In order:
|
||||
|
||||
* `testvm` - name of target VM to which device was attached - listed in brackets by `qvm-block` command
|
||||
* `phy:/dev/sda` - physical path at which device appears in source VM (just after source VM name in `qvm-block` output)
|
||||
* `phy:/dev/sda` - physical path at which device appears in source VM (just after source VM name in `qvm-block` output)
|
||||
* `backend=sys-usb` - name of source VM, can be omitted in case of dom0
|
||||
* `xvdi` - "frontend" device name (listed at the end of line in `qvm-block` output
|
||||
|
||||
|
||||
@ -11,9 +11,9 @@ redirect_from:
|
||||
Network Bridge Support (EXPERIMENTAL and UNSUPPORTED)
|
||||
=====================================================
|
||||
|
||||
The Qubes developpement team does not support bridging the network interfaces found in NetVM and don't plan to support it at all. Several reasons for that:
|
||||
The Qubes development team does not support bridging the network interfaces found in NetVM and don't plan to support it at all. Several reasons for that:
|
||||
|
||||
- Using a bridged VM is almost only necessary for developpers testing or working on OSI layer 2 or layer 3 tools (MAC or routing protocols). If not for testing, such tools are almost only used directly on routers ...).
|
||||
- Using a bridged VM is almost only necessary for developers testing or working on OSI layer 2 or layer 3 tools (MAC or routing protocols). If not for testing, such tools are almost only used directly on routers ...).
|
||||
- Most of these tools can be anyway used directly inside the NetVM, which has direct access to the network card.
|
||||
- It is also possible to use a secondary network card plugged into a specific development VM.
|
||||
- Such a setup could break security features of Qubes such as AppVM firewalling.
|
||||
@ -23,7 +23,7 @@ Now if you really want to work with OSI layer2 / layer 3 tools, that you don't h
|
||||
Qubes manager patch (Qubes R2B2)
|
||||
--------------------------------
|
||||
|
||||
The following patches can be applied to the Qubes Manager GUI in order to add an option to easily bridge a VM. Use it at your own risk. If the patch breaks the Qubes Manager, you can try to restore the qubes packages:
|
||||
The following patches can be applied to the Qubes Manager GUI in order to add an option to easily bridge a VM. Use it at your own risk. If the patch breaks the Qubes Manager, you can try to restore the Qubes packages:
|
||||
|
||||
~~~
|
||||
# qubes-dom-update qubes-core-dom0 qubes-manager
|
||||
@ -75,7 +75,7 @@ Modify manually the Template you use for your NetVM (not the NetVM itself). This
|
||||
-A FORWARD -j DROP
|
||||
~~~
|
||||
|
||||
Ensure that the IP addresses used by default in qubes are in the form 10.137.1.\* or 10.137.2.\* by running ifconfig. Of course, this setup won't work with IPv6.
|
||||
Ensure that the IP addresses used by default in Qubes are in the form 10.137.1.\* or 10.137.2.\* by running ifconfig. Of course, this setup won't work with IPv6.
|
||||
|
||||
Now you need to restart the NetVM and FirewallVM or only iptables in both VMs if you prefer:
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ Installation
|
||||
|
||||
`yum install postfix procmail make`
|
||||
|
||||
Procmail is not strictly neccessary, but is useful to sort your incoming mail, for example to put each mailing list in its own directory. Make is also not neccessary, but is used to keep Postfix lookup tables. You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `yum remove ssmtp` or something.
|
||||
Procmail is not strictly necessary, but is useful to sort your incoming mail, for example to put each mailing list in its own directory. Make is also not necessary, but is used to keep Postfix lookup tables. You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `yum remove ssmtp` or something.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
@ -104,7 +104,7 @@ your.mail@exmaple.com [mail.example.com]:submission
|
||||
your.other@mail.com [smtp.mail.com]:smtp
|
||||
~~~
|
||||
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to abovementioned servers. It depends on provider if you need to put whole email as username or just the part before `@`.
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on provider if you need to put whole email as username or just the part before `@`.
|
||||
|
||||
~~~
|
||||
[mail.example.com]:submission your.mail:y0urP4ssw0rd
|
||||
@ -118,7 +118,7 @@ spamdomain1.com DISCARD
|
||||
spamdomain2.com DISCARD
|
||||
~~~
|
||||
|
||||
Now run `make` in `/usr/local/etc/postfix`. It will hopefully compile four abovementioned lookup tables (`generic.db`, `sender_relay.db`, `saslpass.db` and `sender_access`).
|
||||
Now run `make` in `/usr/local/etc/postfix`. It will hopefully compile four above mentioned lookup tables (`generic.db`, `sender_relay.db`, `saslpass.db` and `sender_access`).
|
||||
|
||||
### procmail
|
||||
|
||||
|
||||
@ -11,8 +11,7 @@ redirect_from:
|
||||
Resize Disk Image
|
||||
-----------------
|
||||
|
||||
There are several disk images which can be easily extended.
|
||||
But pay attention to the overall consumed space of your sparse disk images.
|
||||
There are several disk images which can be easily extended. But pay attention to the overall consumed space of your sparse disk images.
|
||||
|
||||
### Private disk image
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ Installation
|
||||
Xresources
|
||||
----------
|
||||
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below. `!`-lines are comments and may be left out. `#`-lines are directives to CPP (C preprocessor) and are neccessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below. `!`-lines are comments and may be left out. `#`-lines are directives to CPP (C preprocessor) and are necessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
|
||||
~~~
|
||||
! CGA colour palette
|
||||
|
||||
@ -50,7 +50,7 @@ A *module* is a Python extension to salt that is responsible for actually
|
||||
enforcing the state in a particular area. It exposes some *imperative* functions
|
||||
for administrator. For example there is `system` module that has `system.halt`
|
||||
function that, when issued, will immediately halt the computer. There is another
|
||||
function called `state.highstate` which will synchronise the state of the system
|
||||
function called `state.highstate` which will synchronize the state of the system
|
||||
with the administrator's will.
|
||||
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ Template installation
|
||||
|
||||
> [dom0]#qubes-dom0-update qubes-template-fedora-21-minimal
|
||||
|
||||
*Note*: the template may not start in qubes R3 when using kernel 3.19 (unstable). In this case, switch the AppVM or TemplateVM to the kernel 3.18.
|
||||
*Note*: the template may not start in Qubes R3 when using kernel 3.19 (unstable). In this case, switch the AppVM or TemplateVM to the kernel 3.18.
|
||||
|
||||
*Note*: If you have doubts about a set of tool or package you want to install, start installing and testing it in an AppVM. You can then reproduce it later in your TemplateVM if you are satisfied. That the (QubesOS?) template philosophy.
|
||||
|
||||
@ -27,7 +27,7 @@ Administration (documented)
|
||||
|
||||
sudo pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat usbutils
|
||||
|
||||
*Notes*: nmap can be used to discover a network (nmap -sP [network]), especially if you are inside a Microsoft network, because your AppVM will be protected/NATted behind Qubes firewall (microsoft / home network are heavily using autodiscovery technologies which require to beint in the same local network (no firewall/no NAT), eg: your printer.
|
||||
*Notes*: nmap can be used to discover a network (nmap -sP [network]), especially if you are inside a Microsoft network, because your AppVM will be protected/NATted behind Qubes firewall (microsoft / home network are heavily using autodiscovery technologies which require to be in the same local network (no firewall/no NAT), eg: your printer.
|
||||
|
||||
Some recommendation here: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to allow temporarily the Qubes Firewall if you are inside a TemplateVM.
|
||||
|
||||
@ -86,9 +86,9 @@ Printer Setup
|
||||
|
||||
system-config-printer system-config-printer-applet cups
|
||||
|
||||
Dependency Note: depends on python3 + python3 additionnal libraries which takes more than 40 M once installed.
|
||||
Dependency Note: depends on python3 + python3 additional libraries which takes more than 40 M once installed.
|
||||
|
||||
Dependency Note: cups depends on ghostscript and require installing additionnal printing fonts (not documented here), so it can takes several dozen of MB
|
||||
Dependency Note: cups depends on ghostscript and require installing additional printing fonts (not documented here), so it can takes several dozen of MB
|
||||
|
||||
Manual operations
|
||||
---------------------------
|
||||
@ -97,7 +97,7 @@ Manual operations
|
||||
|
||||
- First you need to search for your printer. If you don't know its name or IP, search for it using nmap: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to allow temporarily the Qubes Firewall if you are inside a TemplateVM.
|
||||
|
||||
- Once you identifed your printer, run system-config-printer GUI to install your printer
|
||||
- Once you identified your printer, run system-config-printer GUI to install your printer
|
||||
|
||||
- You man need to cancel the operation to install more adapted printer drivers (eg: if the driver cannot be found automatically). Use yum search printername to find potential drivers (eg yum search photosmart)
|
||||
|
||||
@ -112,9 +112,9 @@ lxterminal dejavu-sans-mono-fonts dejavu-sans-fonts gnome-settings-daemon
|
||||
*Note*: You need to install sans-mono fonts for the terminal or it will be unreadable (overlapping characters....), while the sans fonts are just to get nicer GUI menus.
|
||||
|
||||
*Scite* is a nice notepad that can also highlight scripts with very light dependencies
|
||||
|
||||
|
||||
scite
|
||||
|
||||
|
||||
*Meld* allow comparing two text files/ two configuration files easily.
|
||||
|
||||
meld
|
||||
@ -169,11 +169,11 @@ Cleaning the whole dconf settings is also possible by removing the following fil
|
||||
rm ~/.config/dconf/user
|
||||
~~~
|
||||
|
||||
*Note*: lxappearance only have effect on gtk3 theme so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
|
||||
*Note*: lxappearance only have effect on gtk3 theme so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
|
||||
However, it is very lightweight and can be used to identify the name and look of themes you are interested in.
|
||||
Once you have the name, you can apply it using gsetting command line or gconf-editor.
|
||||
|
||||
*Note*: if you really want a GUI theme editor, you can install gnome-tweak-tools, but this tool have a lot
|
||||
*Note*: if you really want a GUI theme editor, you can install gnome-tweak-tools, but this tool have a lot
|
||||
of gnome dependencies (~150MB of dependencies). Eventually install it and uninstall it as soon as you changed your theme.
|
||||
|
||||
#### Testing notes
|
||||
@ -184,7 +184,7 @@ The following programs can be used to see if theme has been correctly applied:
|
||||
* GTK3 program: lxterminal
|
||||
* QT program: keepassx
|
||||
|
||||
*Note*: testing in a TemplateVM will not work as expected because gnome-settings-daemon is not started in TemplateVM.
|
||||
*Note*: testing in a TemplateVM will not work as expected because gnome-settings-daemon is not started in TemplateVM.
|
||||
so test your themes in an AppVM and then update the TemplateVM accordingly.
|
||||
|
||||
### Forcing theme change for all AppVM depending on a TemplateVM
|
||||
@ -246,7 +246,7 @@ Finally, regenerate the dconf database
|
||||
|
||||
### Uniform look for QT & GTK
|
||||
|
||||
Getting an uniform look for QT & GTK is not acheaved yet. A good source is on the following link [UNIFORMTHEME]
|
||||
Getting an uniform look for QT & GTK is not achieved yet. A good source is on the following link [UNIFORMTHEME]
|
||||
|
||||
Two case:
|
||||
|
||||
@ -254,10 +254,10 @@ Two case:
|
||||
(eg: Adwaita which is the default theme. I did not found another cross framework theme on fedora default packages).
|
||||
|
||||
2. You want to use the GTK theme you selected for Qt but there is no qt package.
|
||||
In this case QGtkStyle will take precedence and convert the style automaticall.
|
||||
In this case QGtkStyle will take precedence and convert the style automatically.
|
||||
You can verify if it is enabled by searching for "style=GTK+" in /etc/xdg/Trolltech.conf.
|
||||
If style is changed to another name, it will be used instead of your GTK theme.
|
||||
|
||||
|
||||
*Note*: check that ~/.config/Trolltech.conf in your AppVMs is not defining another "style=" because it will take precedence over your global QT theme.
|
||||
|
||||
|
||||
|
||||
@ -5,17 +5,17 @@ permalink: /doc/windows-template-customization/
|
||||
redirect_from: /en/doc/windows-template-customization/
|
||||
---
|
||||
|
||||
Disable/Uninstall unecessary features/services
|
||||
Disable/Uninstall unnecessary features/services
|
||||
=============================
|
||||
|
||||
Windows features
|
||||
----------------------------
|
||||
|
||||
Uninstall windows features from Control Panel > Turn windows features On/Off.
|
||||
Uninstall windows features from Control Panel > Turn windows features On/Off.
|
||||
|
||||
Generally, it will be required to reboot after features desinstallation.
|
||||
Generally, it will be required to reboot after features are uninstalled.
|
||||
|
||||
If you do not manage to uninstall some features, it is sometimes necessarry to uninstall them one by one or two by two.
|
||||
If you do not manage to uninstall some features, it is sometimes necessary to uninstall them one by one or two by two.
|
||||
|
||||
Only keep:
|
||||
|
||||
@ -36,8 +36,8 @@ Disable the following services that are not required or have no sense in a VM co
|
||||
* Base Filtering Engine (only required if your want to use Microsoft IPSEC)
|
||||
* DHCP Client
|
||||
* Function Discovery Provider Host
|
||||
|
||||
this will not work anyway because SSDP discovery uses multicast - need to be on the same network which is not the case because of qubes firewall
|
||||
|
||||
this will not work anyway because SSDP discovery uses multicast - need to be on the same network which is not the case because of Qubes firewall
|
||||
* Peer Name Resolution Protocol
|
||||
* Peer Netwoking Grouping
|
||||
* Peer Networking Identity Manager
|
||||
@ -67,10 +67,10 @@ System properties
|
||||
Right click on computer and go to Properties > Advanced > Performances:
|
||||
|
||||
* If your don't care about visual effect, in Visual Effect select "Adjust for best performance"
|
||||
* I personnally tweak the page file size to win some place on my root.
|
||||
|
||||
* I personally tweak the page file size to win some place on my root.
|
||||
|
||||
In Advanced>Performances>Advanced tab, change Virtual memory:
|
||||
|
||||
|
||||
1. unselect automatically manage paging file size for all drive
|
||||
2. click on drive C:
|
||||
3. select no paging file
|
||||
@ -80,22 +80,22 @@ Right click on computer and go to Properties > Advanced > Performances:
|
||||
7. use an initial size of 500 and a max size of 1000. If the page file is too small, you will notify a low memory pop up when working on windows. In this case, it often means that you should extend your AppVM RAM.
|
||||
|
||||
* System Protection
|
||||
|
||||
Here you can disable Shadow Folder because it has little sense in case of qubes because
|
||||
|
||||
Here you can disable Shadow Folder because it has little sense in case of Qubes because
|
||||
|
||||
* we do backup regularly of AppVMs/TemplateVMs;
|
||||
* we can revert at least one template change if we break something.
|
||||
|
||||
|
||||
Select drives where system protection is enabled and click Configure. "Turn of system protection" "Delete all restore points"
|
||||
|
||||
* Remote
|
||||
|
||||
Unselect Allow Remote Assistance connetions to this computer.
|
||||
|
||||
Unselect Allow Remote Assistance connections to this computer.
|
||||
|
||||
Task scheduler
|
||||
-----------------------
|
||||
|
||||
Open the task scheduler and *disable* the following tasks.
|
||||
Open the task scheduler and *disable* the following tasks.
|
||||
|
||||
If you remove these tasks they may be recreated automatically by various windows management tools (such as defragmentation)
|
||||
|
||||
@ -124,9 +124,9 @@ Manual tasks that can/should be started in the template
|
||||
===================================
|
||||
|
||||
* Disk defragmentation
|
||||
|
||||
|
||||
* Windows Update
|
||||
|
||||
|
||||
* Windows file cleaning
|
||||
1. Run windows drive cleaner as Administrator.
|
||||
2. Enable all the task and run the cleaner
|
||||
@ -136,32 +136,31 @@ Manual tasks that can/should be started in the template
|
||||
2. Copy the attached ccleaner configuration file in CCleaner program file folder
|
||||
3. Run ccleaner with all option set except "wipe free space" (it will also remove user history and preferences)
|
||||
4. Run ccleaner only with the option "wipe free space".
|
||||
|
||||
|
||||
It will write zeros in all unused space. This will allow you to strip the root.img file later
|
||||
|
||||
|
||||
* TemplateVM stripping
|
||||
|
||||
|
||||
Ensure that you know what you are doing in this section as you may destroy by error your template root.img file.
|
||||
|
||||
|
||||
* If you ran ccleaner with "wipe free space", follow the following procedure
|
||||
|
||||
|
||||
1. from dom0, go to /var/lib/templates-vm/yourtemplate
|
||||
|
||||
2. copy root.img using the following command
|
||||
|
||||
|
||||
> cp --sparse=always root.img root.img.clean
|
||||
|
||||
3. if the copy worked, you can move the new root file by running this command
|
||||
|
||||
> mv root.img.clean root.img
|
||||
|
||||
* If don't managed to fill the free space with zeroes, you can follow the following *unsafe* undocumented procedure
|
||||
|
||||
|
||||
* If don't managed to fill the free space with zeros, you can follow the following *unsafe* undocumented procedure
|
||||
|
||||
1. from dom0, go to /var/lib/templates-vm/yourtemplate
|
||||
2. check the partitionning to identify the filesystem offset of root.img
|
||||
2. check the partitioning to identify the filesystem offset of root.img
|
||||
3. mount the filesystem
|
||||
4. create a file with zeros inside the filesystem until the mounted filesystem is full
|
||||
5. remove the file
|
||||
6. unmount the partition
|
||||
7. make a copy of root.img in sparse mode.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ redirect_from:
|
||||
- "/wiki/UserDoc/XFCE/"
|
||||
---
|
||||
|
||||
XFCE installtion in dom0
|
||||
XFCE installation in dom0
|
||||
========================
|
||||
|
||||
**Disclaimer: XFCE isn't fully integrated with Qubes environment, it still require notable amount of manual configuration after install**
|
||||
|
||||
@ -55,7 +55,7 @@ COMPONENTS:=$(filter-out desktop-linux-kde desktop-linux-xfce,$(COMPONENTS))
|
||||
|
||||
Just don't forget that you need to comment this line again if you want to build the whole Qubes-OS install CD.
|
||||
|
||||
Make all required qubes components
|
||||
Make all required Qubes components
|
||||
----------------------------------
|
||||
|
||||
The first use of the builder can take several hours depending on your bandwidth as it will install an archlinux chroot:
|
||||
|
||||
@ -65,9 +65,9 @@ The goal of this file is to prepare a development environment of your target OS
|
||||
|
||||
- the \$1 variable will contain the installation directory (INSTALLDIR should contain the same value than \$1 when you run 00\_prepare or 01\_install\_core)
|
||||
- after your base system is installed, you should install development tools and libraries (gcc, make, ...)
|
||||
- create a user called 'user' inside your chroot, and give him enought right to run the command sudo without any password
|
||||
- create a user called 'user' inside your chroot, and give him enough rights to run the command sudo without any password
|
||||
- register all the repository that could be necessary and synchronize the package database
|
||||
- register a custom repository that will be used to store qubes packages
|
||||
- register a custom repository that will be used to store Qubes packages
|
||||
|
||||
### Makefile.yourOSname
|
||||
|
||||
@ -84,7 +84,7 @@ These additional target need to exist once you created your first packages:
|
||||
|
||||
### Testing the development chroot
|
||||
|
||||
You will be able to test these script when making the first qubes packages. Don't forget that the first things that run when running 'make somcomponent-vm' will be these two scripts, and that you will need to debug it at this point.
|
||||
You will be able to test these script when making the first Qubes packages. Don't forget that the first things that run when running 'make somcomponent-vm' will be these two scripts, and that you will need to debug it at this point.
|
||||
|
||||
Qubes packages
|
||||
--------------
|
||||
@ -118,7 +118,7 @@ The goal of this script is to install all the package that you want to use in yo
|
||||
|
||||
### 04\_install\_qubes.sh
|
||||
|
||||
The goal of this script is to install in your template all the packages you built previously. Also you need to edit the fstab file of your template to mount qubes virtual hard drives.
|
||||
The goal of this script is to install in your template all the packages you built previously. Also you need to edit the fstab file of your template to mount Qubes virtual hard drives.
|
||||
|
||||
### 09\_cleanup.sh
|
||||
|
||||
@ -137,13 +137,13 @@ As soon as you manage to make qrexec and qubes-gui-agent working, it should be s
|
||||
|
||||
### Xen libraries
|
||||
|
||||
Several XEN libraries are required for Qubes to work correctly. In fact, you need to make xenstore commands working before anything else. For this, Qubes git can be used as several patches have been selected by Qubes developpers that could impact the activity inside a VM. Start be retrieving a recent git and identify how you can build a package from it: `git clone git://git.qubes-os.org/marmarek/xen`
|
||||
Several XEN libraries are required for Qubes to work correctly. In fact, you need to make xenstore commands working before anything else. For this, Qubes git can be used as several patches have been selected by Qubes developers that could impact the activity inside a VM. Start be retrieving a recent git and identify how you can build a package from it: `git clone git://git.qubes-os.org/marmarek/xen`
|
||||
|
||||
Find the .spec file in the git repository (this is the file being used to build rpm packages), and try to adapt it to your OS in order to build a package similar to the target 'xen-vm'. For example, a PKGBUILD has been created for [ArchLinux](/doc/templates/archlinux/) and can be found on [http://aur.archlinux.org/packages/qu/qubes-vm-xen/PKGBUILD](http://aur.archlinux.org/packages/qu/qubes-vm-xen/PKGBUILD).
|
||||
|
||||
Don't be afraid with the complexity of the PKGBUILD, most of the code is almost a copy/paste of required sources and patches found in the .spec file provided in the git repository.
|
||||
|
||||
Note once the package has been successfully compiled and installed, you need to setup XEN filesystem. Add the folowing line to your fstab (you can create this line in your package install script): `xen /proc/xen xenfs defaults 0 0`
|
||||
Note once the package has been successfully compiled and installed, you need to setup XEN filesystem. Add the following line to your fstab (you can create this line in your package install script): `xen /proc/xen xenfs defaults 0 0`
|
||||
|
||||
Now install the package you built and mount /proc/xen. Verify that xenstore-read works by running: `xenstore-read qubes_vm_type` That should give you the current VM type such as HVM or AppVM.
|
||||
|
||||
|
||||
@ -149,7 +149,7 @@ RPMS will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64:
|
||||
|
||||
### Useful [QubesBuilder](/doc/qubes-builder/) commands
|
||||
|
||||
1. `make check` - will check if all the code was commited into repository and
|
||||
1. `make check` - will check if all the code was committed into repository and
|
||||
if all repository are tagged with signed tag.
|
||||
2. `make show-vtags` - show version of each component (based on git tags) -
|
||||
mostly useful just before building ISO. **Note:** this will not show version
|
||||
|
||||
@ -39,7 +39,7 @@ General typographic conventions
|
||||
|
||||
- Class, functions, variables, and arguments naming convention for **Windows OS** -- exceptionally to preserve Windows conventions please use the following:
|
||||
- `ClassName`, `FunctionName`
|
||||
- `pszArgumentOne`, `hPipe` -- use hungerian notation for argument and variables
|
||||
- `pszArgumentOne`, `hPipe` -- use Hungarian notation for argument and variables
|
||||
|
||||
- Horizontal spacing -- maintain at least decent amount of horizontal spacing, such as e.g. add obligatory space after `if` or before `{` in C, and similar in other languages. Whether to also use spaces within expressions, such as (x\*2+5) vs. (x \* 2 + 5) is left to the developer's judgment. Do not put spaces immediately after and before the brackets in expressions, so avoid constructs like this: `if ( condition )` and use `if (condition)` instead.
|
||||
|
||||
@ -169,4 +169,3 @@ Bash-specific guidelines
|
||||
------------------------
|
||||
|
||||
- Avoid writing scripts in bash whenever possible. Use python instead. Bash-scripts are Unix-specific and will not work under Windows VMs, or in Windows admin domain, or Windows gui domain.
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ cd ~/profiling
|
||||
./Upload.sh
|
||||
~~~
|
||||
|
||||
### Analyse
|
||||
### Analyze
|
||||
|
||||
~~~
|
||||
make
|
||||
|
||||
@ -130,7 +130,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your `${
|
||||
pushd ${HOME}/builder >/dev/null
|
||||
|
||||
# the following are needed only if you have sources outside builder
|
||||
#rm -rf qubes-src/core-admin
|
||||
#rm -rf qubes-src/core-admin
|
||||
#make COMPONENTS=core-admin get-sources
|
||||
|
||||
make core-admin
|
||||
@ -139,7 +139,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your `${
|
||||
|
||||
### Hooking git
|
||||
|
||||
I (woju) have those two git hooks. They ensure tests are passing (or are marked as expected failure) when commiting and pushing. For committing it is only possible to run tests that may be executed from git repo (even if the rest were available, I probably wouldn't want to do that). For pushing, I also install RPM and run tests on testbench.
|
||||
I (woju) have those two git hooks. They ensure tests are passing (or are marked as expected failure) when committing and pushing. For committing it is only possible to run tests that may be executed from git repo (even if the rest were available, I probably wouldn't want to do that). For pushing, I also install RPM and run tests on testbench.
|
||||
|
||||
`core-admin/.git/hooks/pre-commit`: (you may retain also the default hook, here omitted for readability)
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ Main responsibilities of *qubes_guid* are:
|
||||
- whenever AppVM signals damage event, tell local Xorg server to repaint a given window fragment
|
||||
- receive information about window size/position change, apply them to the local window
|
||||
|
||||
Note that keyboard and mouse events are passed to AppVM only if a window belonging to this AppVM has focus. AppVM has no way to get information on keystrokes fed to other AppVMs (e.g. XTEST extension will report the status of local AppVM keyboard only), nor synthetize and pass events to other AppVMs.
|
||||
Note that keyboard and mouse events are passed to AppVM only if a window belonging to this AppVM has focus. AppVM has no way to get information on keystrokes fed to other AppVMs (e.g. XTEST extension will report the status of local AppVM keyboard only), nor synthesize and pass events to other AppVMs.
|
||||
|
||||
Window content updates implementation
|
||||
-------------------------------------
|
||||
@ -123,62 +123,62 @@ The header is followed by message-specific data.
|
||||
|Message name|Structure after header|Action|
|
||||
|:-----------|:---------------------|:-----|
|
||||
|MSG_CLIPBOARD_DATA|amorphic blob (length determined by the "window" field)|Store the received clipboard content (not parsing in any way)|
|
||||
|MSG_CREATE|` struct msg_create { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t parent; `
|
||||
` uint32_t override_redirect; `
|
||||
|MSG_CREATE|` struct msg_create { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t parent; `
|
||||
` uint32_t override_redirect; `
|
||||
` }; `|Create a window with given parameters|
|
||||
|MSG_DESTROY|None|Destroy a window|
|
||||
|MSG_MAP|` struct msg_map_info { `
|
||||
` uint32_t transient_for; `
|
||||
` uint32_t override_redirect; `
|
||||
|MSG_MAP|` struct msg_map_info { `
|
||||
` uint32_t transient_for; `
|
||||
` uint32_t override_redirect; `
|
||||
` }; `|Map a window with given parameters|
|
||||
|MSG_UNMAP|None|Unmap a window|
|
||||
|MSG_CONFIGURE|` struct msg_configure { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t override_redirect; `
|
||||
|MSG_CONFIGURE|` struct msg_configure { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t override_redirect; `
|
||||
` }; `|Change window position/size/type|
|
||||
|MSG_MFNDUMP|` struct shm_cmd { `
|
||||
` uint32_t shmid; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t bpp; `
|
||||
` uint32_t off; `
|
||||
` uint32_t num_mfn; `
|
||||
` uint32_t domid; `
|
||||
` uint32_t mfns[0]; `
|
||||
` }; `|Retrieve the array of mfns that constitute the composition buffer of a remote window.
|
||||
|MSG_MFNDUMP|` struct shm_cmd { `
|
||||
` uint32_t shmid; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t bpp; `
|
||||
` uint32_t off; `
|
||||
` uint32_t num_mfn; `
|
||||
` uint32_t domid; `
|
||||
` uint32_t mfns[0]; `
|
||||
` }; `|Retrieve the array of mfns that constitute the composition buffer of a remote window.
|
||||
The "num_mfn" 32bit integers follow the shm_cmd structure; "off" is the offset of the composite buffer start in the first frame; "shmid" and "domid" parameters are just placeholders (to be filled by *qubes_guid*), so that we can use the same structure when talking to *shmoverride.so*|
|
||||
|MSG_SHMIMAGE|` struct msg_shmimage { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y;`
|
||||
` uint32_t width;`
|
||||
` uint32_t height;`
|
||||
|MSG_SHMIMAGE|` struct msg_shmimage { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y;`
|
||||
` uint32_t width;`
|
||||
` uint32_t height;`
|
||||
` }; `|Repaint the given window fragment|
|
||||
|MSG_WMNAME|` struct msg_wmname { `
|
||||
` char data[128]; `
|
||||
|MSG_WMNAME|` struct msg_wmname { `
|
||||
` char data[128]; `
|
||||
` } ; `|Set the window name; only printable characters are allowed|
|
||||
|MSG_DOCK|None|Dock the window in the tray|
|
||||
|MSG_WINDOW_HINTS|` struct msg_window_hints { `
|
||||
` uint32_t flags; `
|
||||
` uint32_t min_width; `
|
||||
` uint32_t min_height; `
|
||||
` uint32_t max_width; `
|
||||
` uint32_t max_height; `
|
||||
` uint32_t width_inc; `
|
||||
` uint32_t height_inc; `
|
||||
` uint32_t base_width; `
|
||||
` uint32_t base_height; `
|
||||
|MSG_WINDOW_HINTS|` struct msg_window_hints { `
|
||||
` uint32_t flags; `
|
||||
` uint32_t min_width; `
|
||||
` uint32_t min_height; `
|
||||
` uint32_t max_width; `
|
||||
` uint32_t max_height; `
|
||||
` uint32_t width_inc; `
|
||||
` uint32_t height_inc; `
|
||||
` uint32_t base_width; `
|
||||
` uint32_t base_height; `
|
||||
` }; `|Size hints for window manager|
|
||||
|MSG_WINDOW_FLAGS|` struct msg_window_flags { `
|
||||
` uint32_t flags_set; `
|
||||
` uint32_t flags_unset;`
|
||||
|MSG_WINDOW_FLAGS|` struct msg_window_flags { `
|
||||
` uint32_t flags_set; `
|
||||
` uint32_t flags_unset;`
|
||||
` }; `|Change window state request; fields contains bitmask which flags request to be set and which unset|
|
||||
~~~
|
||||
|
||||
@ -202,59 +202,58 @@ The header is followed by message-specific data.
|
||||
~~~
|
||||
|Message name|Structure after header|Action|
|
||||
|:-----------|:---------------------|:-----|
|
||||
|MSG_KEYPRESS|` struct msg_keypress { `
|
||||
` uint32_t type; `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t keycode; `
|
||||
|MSG_KEYPRESS|` struct msg_keypress { `
|
||||
` uint32_t type; `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t keycode; `
|
||||
` }; `|Tell *qubes_drv* driver to generate a keypress|
|
||||
|MSG_BUTTON|` struct msg_button { `
|
||||
` uint32_t type; `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t button; `
|
||||
|MSG_BUTTON|` struct msg_button { `
|
||||
` uint32_t type; `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t button; `
|
||||
` }; `|Tell *qubes_drv* driver to generate mouseclick|
|
||||
|MSG_MOTION|` struct msg_motion { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t is_hint; `
|
||||
|MSG_MOTION|` struct msg_motion { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t is_hint; `
|
||||
` }; `|Tell *qubes_drv* driver to generate motion event|
|
||||
|MSG_CONFIGURE|` struct msg_configure { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t override_redirect; `
|
||||
|MSG_CONFIGURE|` struct msg_configure { `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t width; `
|
||||
` uint32_t height; `
|
||||
` uint32_t override_redirect; `
|
||||
` }; `|Change window position/size/type|
|
||||
|MSG_MAP|` struct msg_map_info { `
|
||||
` uint32_t transient_for; `
|
||||
` uint32_t override_redirect; `
|
||||
|MSG_MAP|` struct msg_map_info { `
|
||||
` uint32_t transient_for; `
|
||||
` uint32_t override_redirect; `
|
||||
` }; `|Map a window with given parameters|
|
||||
|MSG_CLOSE|None|send wmDeleteMessage to the window|
|
||||
|MSG_CROSSING|` struct msg_crossing { `
|
||||
` uint32_t type; `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t mode; `
|
||||
` uint32_t detail; `
|
||||
` uint32_t focus; `
|
||||
|MSG_CROSSING|` struct msg_crossing { `
|
||||
` uint32_t type; `
|
||||
` uint32_t x; `
|
||||
` uint32_t y; `
|
||||
` uint32_t state; `
|
||||
` uint32_t mode; `
|
||||
` uint32_t detail; `
|
||||
` uint32_t focus; `
|
||||
` }; `|Notify window about enter/leave event|
|
||||
|MSG_FOCUS|` struct msg_focus { `
|
||||
` uint32_t type; `
|
||||
` uint32_t mode; `
|
||||
` uint32_t detail; `
|
||||
|MSG_FOCUS|` struct msg_focus { `
|
||||
` uint32_t type; `
|
||||
` uint32_t mode; `
|
||||
` uint32_t detail; `
|
||||
` }; `|Raise a window, XSetInputFocus|
|
||||
|MSG_CLIPBOARD_REQ|None|Retrieve the local clipboard, pass contents to gui-daemon|
|
||||
|MSG_CLIPBOARD_DATA|amorphic blob|Insert the received data into local clipboard|
|
||||
|MSG_EXECUTE|Obsolete|Obsolete, unused|
|
||||
|MSG_KEYMAP_NOTIFY|` unsigned char remote_keys[32]; `|Synchronize the keyboard state (key pressed/released) with dom0|
|
||||
|MSG_WINDOW_FLAGS|` struct msg_window_flags { `
|
||||
` uint32_t flags_set; `
|
||||
` uint32_t flags_unset;`
|
||||
|MSG_WINDOW_FLAGS|` struct msg_window_flags { `
|
||||
` uint32_t flags_set; `
|
||||
` uint32_t flags_unset;`
|
||||
` }; `|Window state change confirmation|
|
||||
~~~
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ This has the following disadvantages:
|
||||
- performance - dom0 has to prepare and attach/detach block devices, which is slow because of hotplug scripts involvement.
|
||||
- security - VM kernel parses partition table and filesystem metadata from the block device; they are controlled by (potentially untrusted) sender VM.
|
||||
|
||||
In Qubes Beta1, we have reimplemented interVM file copy using qrexec, which addresses the abovementioned disadvantages. In Qubes Beta2, even more generic solution (qubes rpc) is used. See the developer docs on qrexec and qubes rpc. In a nutshell, the file sender and the file receiver just read/write from stdin/stdout, and the qubes rpc layer passes data properly - so, no block devices are used.
|
||||
In Qubes Beta1, we have reimplemented interVM file copy using qrexec, which addresses the above mentioned disadvantages. In Qubes Beta2, even more generic solution (qubes rpc) is used. See the developer docs on qrexec and qubes rpc. In a nutshell, the file sender and the file receiver just read/write from stdin/stdout, and the qubes rpc layer passes data properly - so, no block devices are used.
|
||||
|
||||
The rpc action for regular file copy is *qubes.Filecopy*, the rpc client is named *qfile-agent*, the rpc server is named *qfile-unpacker*. For DispVM copy, the rpc action is *qubes.OpenInVM*, the rpc client is named *qopen-in-vm*, rpc server is named *vm-file-editor*. Note that the qubes.OpenInVM action can be done on a normal AppVM, too.
|
||||
|
||||
|
||||
@ -52,7 +52,7 @@ There can be almost arbitrary number of `qrexec-client` processes for a domain
|
||||
(i.e., `qrexec-client` processes connected to the same `qrexec-daemon`);
|
||||
their data is multiplexed independently.
|
||||
|
||||
There is a similar command line utility avilable inside Linux AppVMs (note
|
||||
There is a similar command line utility available inside Linux AppVMs (note
|
||||
the `-vm` suffix): `qrexec-client-vm` that will be described in subsequent
|
||||
sections.
|
||||
|
||||
@ -265,7 +265,7 @@ Players:
|
||||
users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps.
|
||||
|
||||
|
||||
## Windows VMs implemention ##
|
||||
## Windows VMs implementation ##
|
||||
|
||||
`%QUBES_DIR%` is the installation path (`c:\Program Files\Invisible Things
|
||||
Lab\Qubes OS Windows Tools` by default).
|
||||
@ -327,4 +327,3 @@ steps are taken:
|
||||
process to exit, and then destroys the DispVM.
|
||||
|
||||
*TODO: Protocol description ("wire-level" spec)*
|
||||
|
||||
|
||||
@ -17,18 +17,18 @@ From now on, it will be as follows.
|
||||
Qubes distributions and products
|
||||
--------------------------------
|
||||
|
||||
We intend to make it easy to make a remix of qubes, targetting another
|
||||
We intend to make it easy to make a remix of qubes, targeting another
|
||||
hypervisor or isolation provider. We may also create commercial products
|
||||
intended for specific circumstances. There is one distinguished distribution
|
||||
called **Qubes OS**. All source code for it is available for download under GPL
|
||||
licence and is openly developed on the mailing lists. The rest of this document
|
||||
license and is openly developed on the mailing lists. The rest of this document
|
||||
discusses Qubes OS. Another remix may have its own version series.
|
||||
|
||||
Release version
|
||||
---------------
|
||||
|
||||
Qubes OS as a whole is released from time to time. Version scheme for all
|
||||
releases is modelled after Linux kernel version numbers. When announcing new
|
||||
releases is modeled after Linux kernel version numbers. When announcing new
|
||||
release, we decide on the major.minor version (like `3.0`) and release
|
||||
`3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2`
|
||||
and so on. All these versions are considered unstable and not ready for
|
||||
@ -79,7 +79,7 @@ in `current` repository and the cycle starts over. There should be no less than
|
||||
</table>
|
||||
|
||||
Starting with second cycle (that is, after `-rc1`) two weeks into the cycle
|
||||
(after primary bug-reporting period) the Supreme Committee decides wether there
|
||||
(after primary bug-reporting period) the Supreme Committee decides whether there
|
||||
should be another RC. If, based on remaining issues, the Committee decides to
|
||||
release final, then the Committee agrees upon the release date, which should be
|
||||
no later than a week after.
|
||||
|
||||
@ -38,10 +38,10 @@ Pros:
|
||||
|
||||
Cons:
|
||||
|
||||
* Rewriteable. (If the drive is mounted to a compromised machine, the ISO could
|
||||
* Rewritable. (If the drive is mounted to a compromised machine, the ISO could
|
||||
be maliciously altered after it has been written to the drive.)
|
||||
* Untrustworthy firmware. (Firmware can be malicious even if the drive is new.
|
||||
Plugging a drive with rewriteable firmware into a compromised machine can
|
||||
Plugging a drive with rewritable firmware into a compromised machine can
|
||||
also [compromise the drive][BadUSB]. Installing from a compromised drive
|
||||
could compromise even a brand new Qubes installation.)
|
||||
|
||||
@ -66,7 +66,7 @@ Cons:
|
||||
2. Attach a SATA optical drive to a secondary SATA controller, then assign
|
||||
this secondary SATA controller to an AppVM.
|
||||
3. Use a SATA optical drive attached to dom0.
|
||||
|
||||
|
||||
(Option 3 violates the Qubes security model since it entails transferring an
|
||||
untrusted ISO to dom0 in order to burn it to disc, which leaves only the
|
||||
other two options.)
|
||||
|
||||
@ -59,7 +59,7 @@ Live USB variant:
|
||||
stored on the r/w partition (or on another stick).
|
||||
|
||||
A nice variant of this persistence option, especially for frequent
|
||||
travellers, would be to augment our backup tools so that it was
|
||||
travelers, would be to augment our backup tools so that it was
|
||||
possible to create a LiveUSB-hosted backups of select VMs. One could then
|
||||
pick a few of their VMs, necessary for a specific travel, back them to a
|
||||
LiveUSB stick, and take this stick when traveling to a hostile country (not
|
||||
|
||||
@ -44,7 +44,7 @@ After this step you should have `qubes-release-2-5` in your Dom0. Important: if
|
||||
|
||||
1. Upgrade dom0 to R2:
|
||||
|
||||
Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there.
|
||||
Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest Qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there.
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update qubes-dom0-dist-upgrade
|
||||
|
||||
@ -16,7 +16,7 @@ Existing users of Qubes R1 (but not R1 betas!) can upgrade their systems to the
|
||||
Upgrade all Template and Standalone VM(s)
|
||||
-----------------------------------------
|
||||
|
||||
**If you have already R2 Beta1 installed, follow standard template update procedure (e.g. "Update VM" buttom in Qubes Manager) and skip the rest of this section**
|
||||
**If you have already R2 Beta1 installed, follow standard template update procedure (e.g. "Update VM" button in Qubes Manager) and skip the rest of this section**
|
||||
|
||||
By default, in Qubes R1, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. More information on using multiple Template VMs, as well as Standalone VMs, can be found [SoftwareUpdateVM here]. The steps described in this section should be repeated in *all* user's Template and Standalone VMs.
|
||||
|
||||
@ -54,7 +54,7 @@ By default, in Qubes R1, there is only one Template VM, however users are free t
|
||||
Installing new template
|
||||
-----------------------
|
||||
|
||||
Qubes R2 Beta2 brings new fedora-18-x64 template (based on Fedora 18). You can install it from Qubes installation DVD. Insert installation DVD into your drive and issue following commmands:
|
||||
Qubes R2 Beta2 brings new fedora-18-x64 template (based on Fedora 18). You can install it from Qubes installation DVD. Insert installation DVD into your drive and issue following commands:
|
||||
|
||||
~~~
|
||||
$ sudo -s
|
||||
|
||||
@ -21,7 +21,7 @@ Some kernel/Xorg combination use only 640x480 in HVM, which is quite small. To e
|
||||
|
||||
To achieve it (all commands run as root):
|
||||
|
||||
1. Generate XOrg configuratio (if you don't have it):
|
||||
1. Generate XOrg configuration (if you don't have it):
|
||||
|
||||
~~~
|
||||
X -configure :1 && mv ~/xorg.conf.new /etc/X11/xorg.conf
|
||||
|
||||
@ -14,7 +14,7 @@ Installing Whonix in Qubes is simple and only requires a few simple steps.
|
||||
|
||||
Using privacy and anonymization tools like Whonix is not a magical solution that instantly makes you anonymous online. Please consider:
|
||||
|
||||
* Do you know what a metadata or a man-in-the-middle attack is?
|
||||
* Do you know what metadata or a man-in-the-middle attack is?
|
||||
* Do you think nobody can eavesdrop on your communications because you are using Tor?
|
||||
* Do you know how Whonix works?
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ NAME
|
||||
|
||||
qvm-add-appvm - add an already installed appvm to the Qubes DB
|
||||
|
||||
WARNING: Noramlly you would not need this command, and you would use qvm-create instead!
|
||||
WARNING: Normally you would not need this command, and you would use qvm-create instead!
|
||||
|
||||
Date
|
||||
2012-04-10
|
||||
|
||||
@ -115,7 +115,7 @@ Additional drive for the VM (available only for HVMs). This can be used to attac
|
||||
mac
|
||||
Accepted values: MAC address, `auto`
|
||||
|
||||
Can be used to force specific of virtual ethernet card in the VM. Setting to `auto` will use automatic-generated MAC - based on VM id. Especially useful when some licencing depending on static MAC address. For template-based HVM `auto` mode means to clone template MAC.
|
||||
Can be used to force specific of virtual ethernet card in the VM. Setting to `auto` will use automatic-generated MAC - based on VM id. Especially useful when some licenses depends on static MAC address. For template-based HVM `auto` mode means to clone template MAC.
|
||||
|
||||
default\_user
|
||||
Accepted values: username
|
||||
@ -135,7 +135,7 @@ This HVM have qrexec agent installed. When VM have qrexec agent installed, one c
|
||||
guiagent\_installed
|
||||
Accepted values: `True`, `False`
|
||||
|
||||
This HVM have gui agent installed. This option disables full screen GUI virtualization and enables per-window seemless GUI mode. This option will be automatically turned on during Qubes Windows Tools installation, but if you install qubes gui agent in some other OS, you need to turn this option on manually. You can turn this option off to troubleshoot some early HVM OS boot problems (enter safe mode etc), but the option will be automatically enabled at first VM normal startup (and will take effect from the next startup).
|
||||
This HVM have gui agent installed. This option disables full screen GUI virtualization and enables per-window seamless GUI mode. This option will be automatically turned on during Qubes Windows Tools installation, but if you install Qubes gui agent in some other OS, you need to turn this option on manually. You can turn this option off to troubleshoot some early HVM OS boot problems (enter safe mode etc), but the option will be automatically enabled at first VM normal startup (and will take effect from the next startup).
|
||||
|
||||
*Notice:* when Windows GUI agent is installed in the VM, SVGA device (used to full screen video) is disabled, so even if you disable this option, you will not get functional full desktop access (on normal VM startup). Use some other means for that (VNC, RDP or so).
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ OPTIONS
|
||||
Show this help message and exit
|
||||
|
||||
--force
|
||||
Do not prompt for comfirmation
|
||||
Do not prompt for confirmation
|
||||
|
||||
AUTHORS
|
||||
-------
|
||||
|
||||
@ -46,14 +46,14 @@ Reset service to its default state (remove from the list). Default state means "
|
||||
SUPPORTED SERVICES
|
||||
------------------
|
||||
|
||||
This list can be incomplete as VM can implement any additional service without knowlege of qubes-core code.
|
||||
This list can be incomplete as VM can implement any additional service without knowledge of qubes-core code.
|
||||
|
||||
meminfo-writer
|
||||
Default: enabled everywhere excluding NetVM
|
||||
|
||||
This service reports VM memory usage to dom0, which effectively enables dynamic memory management for the VM.
|
||||
|
||||
*Note:* this service is enforced to be set by dom0 code. If you try to remove it (reset to defult state), will be recreated with the rule: enabled if VM have no PCI devices assigned, otherwise disabled.
|
||||
*Note:* this service is enforced to be set by dom0 code. If you try to remove it (reset to default state), will be recreated with the rule: enabled if VM have no PCI devices assigned, otherwise disabled.
|
||||
|
||||
qubes-dvm
|
||||
Default: disabled
|
||||
|
||||
@ -11,7 +11,7 @@ Using Multi-factor Authentication with Qubes
|
||||
============================================
|
||||
|
||||
(Note: This page concerns multi-factor authentication for logging into external
|
||||
severices, not for logging into Qubes itself. For the latter, see
|
||||
services, not for logging into Qubes itself. For the latter, see
|
||||
[here][YubiKey].)
|
||||
|
||||
[Multi-factor authentication (MFA)][MFA] today most commonly takes the form of a
|
||||
@ -82,12 +82,12 @@ Optional Preparation Steps
|
||||
[user@fedora-21-min-mfa ~]$ poweroff
|
||||
|
||||
4. Create an AppVM and set it to use the TemplateVM we just created:
|
||||
|
||||
|
||||
[user@dom0 ~]$ qvm-create -l black mfa
|
||||
[user@dom0 ~]$ qvm-prefs -s mfa template fedora-21-min-mfa
|
||||
|
||||
5. Isolate the new AppVM from the network:
|
||||
|
||||
|
||||
[user@dom0 ~]$ qvm-prefs -s mfa netvm none
|
||||
|
||||
|
||||
@ -134,12 +134,12 @@ is largely the same.
|
||||
|
||||
[user@mfa ~]$ > google
|
||||
[user@mfa ~]$ vi google
|
||||
|
||||
|
||||
#!/bin/bash
|
||||
##My Google Account
|
||||
##me@gmail.com
|
||||
oathtool --base32 --totp "xd2n mx5t ekg6 h6bi u74d 745k n4m7 zy3x"
|
||||
|
||||
|
||||
[user@mfa ~]$ chmod +x google
|
||||
|
||||
Since the secret key stored in the script never changes, we should never
|
||||
@ -147,10 +147,10 @@ is largely the same.
|
||||
|
||||
4. Now, whenever Google prompts us for an authenticator code, all we have to do
|
||||
is this:
|
||||
|
||||
|
||||
[user@mfa ~]$ ./google
|
||||
640916
|
||||
|
||||
|
||||
Done!
|
||||
|
||||
5. Now you can create scripts for any other TOTP-supporting services you use,
|
||||
@ -173,7 +173,7 @@ is largely the same.
|
||||
914625
|
||||
[user@mfa ~]$ ./tumblr
|
||||
701463
|
||||
|
||||
|
||||
For a more complete list of compatible services, see [here][usage].
|
||||
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ In order to allow a service present in an VM to be exposed to the outside world
|
||||
- In the FirewallVM, allow packets to be routed from the NetVM to the VM and allow packets through the FirewallVM firewall
|
||||
- In the VM, allow packets into the VM firewall to reach the service
|
||||
|
||||
As an example we can take the use case of a web server listenning on port 443 that we want to expose on our physical interface eth0, but only to our local network 192.168.0.0/24.
|
||||
As an example we can take the use case of a web server listening on port 443 that we want to expose on our physical interface eth0, but only to our local network 192.168.0.0/24.
|
||||
|
||||
**1. Allow packets to be routed from the outside world for the exposed service to the FirewallVM**
|
||||
|
||||
@ -132,7 +132,7 @@ sudo nano /rw/config/rc.local
|
||||
Make this file executable:
|
||||
|
||||
~~~
|
||||
sudo chmod +x /rw/config/rc.local
|
||||
sudo chmod +x /rw/config/rc.local
|
||||
~~~
|
||||
|
||||
**2. Allow packets to be routed from the firewallVM to the VM**
|
||||
|
||||
@ -13,4 +13,4 @@ Qubes Security Goals
|
||||
|
||||
Qubes implements a Security by Isolation approach by providing the user with the ability to easily create many security domains. These domains are implemented as lightweight Virtual Machines (VMs) running under the Xen hypervisor. Qubes' main objective is to provide strong isolation between these domains, so that even if an attacker compromises one of the domains, the others are still safe. Qubes, however, does not attempt to provide any security isolation for applications running within the same domain. For example, a buggy web browser running in a Qubes domain could still be compromised just as easily as on a regular Linux distribution. The difference that Qubes makes is that now the attacker doesn't have access to all the software running in the other domains.
|
||||
|
||||
Qubes also provides a number of mechanisms that make it easy and convenient for the user to run multiple domains, such as seamless GUI integration onto one common desktop, secure clipboard copy and paste between domains, secure file transfer between domains, disposable VMs, and much more. Qubes also provides an advanced networking infrastructure that allows for the creation of multiple network VMs (which isolate all the world-facing networking stacks) and proxy VMs which can be used for advanced VPN and tunnelling over untrusted connections.
|
||||
Qubes also provides a number of mechanisms that make it easy and convenient for the user to run multiple domains, such as seamless GUI integration onto one common desktop, secure clipboard copy and paste between domains, secure file transfer between domains, disposable VMs, and much more. Qubes also provides an advanced networking infrastructure that allows for the creation of multiple network VMs (which isolate all the world-facing networking stacks) and proxy VMs which can be used for advanced VPN and tunneling over untrusted connections.
|
||||
|
||||
@ -14,11 +14,11 @@ Password-less root access in VM
|
||||
Background ([/etc/sudoers.d/qubes](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes.sudoers) in VM):
|
||||
|
||||
user ALL=(ALL) NOPASSWD: ALL
|
||||
|
||||
|
||||
# WTF?! Have you lost your mind?!
|
||||
#
|
||||
# In Qubes VMs there is no point in isolating the root account from
|
||||
# the user account. This is because all the user data are already
|
||||
# the user account. This is because all the user data is already
|
||||
# accessible from the user account, so there is no direct benefit for
|
||||
# the attacker if she could escalate to root (there is even no benefit
|
||||
# in trying to install some persistent rootkits, as the VM's root
|
||||
|
||||
Loading…
Reference in New Issue
Block a user