Re: [qubes-users] Save session in appvm

2017-03-16 Thread sm8ax1
Hack:
> Hi,
> 
> How can I save session inside appvms (here, Fedora template), for future
> restore, since  /org/gnome/gnome-session does not exist/work.
> 
> Thanks.
> 

I was wondering about something similar too, but from the "xl save" and
"xl restore" angle. e.g. by inroducing "save" and "restore" buttons and
a new VM state in the VM manager. I think something like this would
satisfy the same needs, but would be independent of the OS or desktop
environment. It would probably be harder to implement though. I don't
know if anything like this has been proposed already.

Something similar has been proposed, but it refers to "inactive" VMs
rather than saving on demand.
https://github.com/QubesOS/qubes-issues/issues/832

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b21b1db8-0d68-7a9b-4bd2-f49193786424%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kicking the sudoers dead horse

2017-03-15 Thread sm8ax1
Chris Laprise:
> On 03/14/2017 11:30 PM, sm8ax1 wrote:
> 
>> Second, you mention that ~/.bin/sudo could be overwritten with the
>> attacker's binary or a script. I'm not sure I understand what you mean
>> exactly... the real sudo works by virtue of being owned by root with
>> suid. An attacker running as user cannot create a file owned by root, so
>> neither the real sudo nor a fake one could elevate privileges. If you
>> mean that `sudo` could be aliased to something else, I'm not sure what
>> that would accomplish; the underlying command would still run as the
>> invoking user. I'm just not quite getting what you're saying.
> 
> By changing the order of $PATH paths or adding an alias in .bashrc a
> regular user process can impersonate the sudo and su (and other)
> commands so their version will run and ask for authorization whenever
> you do 'sudo somecommand' instead of '/usr/bin/sudo somecommand' (the
> latter would not be vulnerable). It will look normal and 'somecommand'
> will run, but attacker can piggyback his own commands to execute as root
> also.
> 
> (This is an old issue, resembling the way attacks could be carried out
> in Xwindows like clipboard sniffing, etc. and was ignored.)
> 
> Without ability to write shell init scripts, attacker can only change
> aliases or $PATH (or $LD_PRELOAD) for his own processes, but not for the
> shells or apps you started yourself.

Thanks for clarifying that. Piggybacking his own commands in addition to
the argument to `sudo` is the key part I wasn't getting. The fix to that
I think would be showing the command (binary path + args) in the Dom0
dialog.

e.g.
"my-vm" is attempting to run "/usr/bin/bash -c '/home/user/.malware.sh ;
realcommand'" as root. Allow?
[x] Always do this for requests from this VM in the future.
[Yes] [No] [View environment variables]

It might already have some of these features for all I know. I haven't
tried it yet.

Untrusted environment variables, if allowed by sudo (they are disallowed
by default), present another problem. This could probably be solved by
showing the untrusted/modified ones in the dialog as well.

>>
>> Setting the shell startup files to immutable is a good idea I hadn't
>> thought of. Actually I think setting them to root:root mode 755 would be
>> sufficient, wouldn't it? That would make it one step easier to modify
>> them as needed.
> 
> Not sufficient because 'user' still owns that dir, so it can delete
> those files even if they're root. Then attacker can write their own
> version. Solution needs +i to prevent replacement in a user-owned dir.
> 
> Going the other way--using only +i and not root ownership--should work
> but I was trying to be thorough. In practice user will probably modify
> script as root after using 'sudo chattr' so convenience-wise it doesn't
> matter.
> 

I don't know why I didn't catch that. I guess I have to go back to Unix
101.

Immutable it is. Just a note for the record, this is an added
anti-persistence feature, but it isn't required for vm-sudo to work as
described.

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7a291de8-3591-4983-f27e-55b2be131ca2%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kicking the sudoers dead horse

2017-03-14 Thread sm8ax1
Chris Laprise:
> On 03/14/2017 09:13 AM, sm8ax1 wrote:
> 
> 
>> I still haven't heard any rebuttals against how sudo can help mitigate
>> attacks against the virtualization (persistence aside). Without sudo,
>> unprivileged processes can access /proc/xen/privcmd, raw sockets, memory
>> mappings, etc., and load kernel modules that have even greater
>> capabilities. We can be naïve and just assume that Xen and the kernel
>> are completely secure, or we can be realistic and do a cost-benefit
>> analysis of enabling Dom0 approval of sudo access.
>>
>> How often does the average user really have to elevate privileges
>> anyway? Considering most directories not writable by user:user (with the
>> notable exception of /usr/local and /rw) are non-persistent anyway, I'm
>> not sure there's very much legitimate use for sudo.  I can't figure out
>> what use cases would require it so often that clicking "yes" in Dom0
>> would be especially inconvenient. And I'm speaking in the general case
>> here; there's nothing to prevent someone from installing a specific VM,
>> elevating via Dom0 once, and overriding /etc/sudoers via bind-dirs in
>> that VM (or template) if they have a need for it.
> 
> I think if you leave out use of the 'mount' and 'umount' commands, root
> access tends to be pretty rare. Even so, this is not something that
> regular users of Linux or Mac desktops complain about often (and they
> have to type the passwords).
> 
>>
>> And I'll say it again: all this is in the absence of MACs like SELinux,
>> AppArmor, or Grsec, or internal firewalls e.g. to restrict access to
>> localhost. Obviously, if anything like that were enabled, it would be
>> useless without requiring sudo approval. Since AFAIK there are no plans
>> to enable anything like this in any of the stock templates, one could
>> argue that /etc/sudoers should be overridden by specific templates that
>> need it (have MAC or internal firewalls), but I don't know enough about
>> the template building process to say.
> 
> Well stated.
> 
> But I'll add a small caveat: That dash and bash are naive toward their
> init files (like ~/.profile) which are writable by user. This means an
> attacker's /home/user/.bin/sudo (or su) script can be substituted for
> the real sudo (or su or other auth tools) or some other script via
> 'alias'. Obviously, this is bad (I have a theory about the Unix
> psychology behind this well-known issue) but its easily remedied by
> making the init files immutable:
> 
> # Protect sh and bash init files
> chfiles="/home/user/.bashrc /home/user/.bash_profile /home/user \
> /.bash_login /home/user/.bash_logout /home/user/.profile"
> touch $chfiles
> chown -f root:root $chfiles
> chattr +i $chfiles
> 
> I have put this in my Debian /etc/rc.local. Alternately, you can set
> those files one time in your templates using the above sequence and VMs
> that are created with that template (after that point in time) will
> inherit the settings. Note that you cannot just set files that already
> exist and ignore the missing ones, hence 'touch' will create the missing
> ones.
> 
> This also has the nice side-effect of addressing that old cautionary
> note about malware persisting through shell init scripts; it would have
> to find another way which IMHO might not exist or not for very long.
> 

First, I did acknowledge that ~/.bashrc and friends can trivially be
infected and can be used to gain persistence, but it would still only be
unprivileged persistence. That is enough to accomplish some goals, but
in those cases the sudo policy is irrelevant in the first place.

Like I said before, persistence and privilege are independent of each
other. You can have one without the other, both, or neither. A lot of
people are treating them as one and the same issue, so if I am wrong for
making this distinction, someone *please* point that out.

The reason I brought up the non-persistence of files not writable by
root was just to express that there's little need for sudo because
modifications made to files owned by root would be lost on restart. E.g.
installing software or making changes outside /home are probably not
common tasks because those changes would be lost on restart. There
definitely are exceptions to this rule, but they are infrequent enough
that clicking "yes" would not be inconvenient.

Second, you mention that ~/.bin/sudo could be overwritten with the
attacker's binary or a script. I'm not sure I understand what you mean
exactly... the real sudo works by virtue of being owned by root with
suid. An attacker running as user cannot create a file owned by root, so
neither the real sudo nor a fake one could elevate privileges. If you
mean that `su

Re: [qubes-users] Kicking the sudoers dead horse

2017-03-14 Thread sm8ax1
sm8ax1:
> Andrew David Wong:
>> On 2017-03-13 22:09, Chris Laprise wrote:
>>> On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
>>>> On 03/12/2017 12:45 PM, Andrew David Wong wrote:
>>>>> On 2017-03-11 19:41, Unman wrote:
>>>>>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise
>>>>>> wrote:
>>>>>>> On 03/11/2017 11:56 AM, Unman wrote:
>>>>>>>> On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
>>>>>>>>> 7v5w7go9ub0o:
>>>>>>>>>> Yep! And ISTM this is an argument for using dispvms
>>>>>>>>>> to handle mail (or any other WAN-exposed
>>>>>>>>>> client/server): start a dispvm; copy mail client and
>>>>>>>>>> mail "file" into it; do your mail; copy out and save
>>>>>>>>>> the updated mail file (which is text); flush away the
>>>>>>>>>> dispvm - all handled by a script(s).
>>>>>>>>> How do you figure that's less of a pain in the ass
>>>>>>>>> than typing a sudo password?
>>>>>>>>>
>>>>>>>> You're missing the point - that procedure is trivial to
>>>>>>>> set up in Qubes and addresses real security concerns.
>>>>>>>> Just putting a password on root access, or requiring some
>>>>>>>> dom0 interaction doesn't.
>>>>>>>>
>>>>>>>> This is important - security IS a pain in the ass. Qubes
>>>>>>>> can make it less so.
>>>>>>>>
>>>>>>> Yes, sm8ax1 got you there. :)
>>>>>>>
>>>>>>> DispVMs are nice to have when we think that certain
>>>>>>> operations carry threats. But its ridiculous to expect a
>>>>>>> typical user to do a majority of their tasks in them.
>>>>>>>
>>>>>> No, it isn't ridiculous to expect a typical user to work in 
>>>>>> disposableVMs. I've set up a number of users with a range of 
>>>>>> experience, and they are very comfortable with this. If the 
>>>>>> implementation is kept hidden generally speaking everything
>>>>>> goes fine. Some scripting to make things easier, and support
>>>>>> is probably no greater than usual ,except for "that funny
>>>>>> copy thing". I've said this before.
>>>>>>
>>>>>> Set up right I don't think that Qubes is outrageously
>>>>>> difficult to use, even with disposableVMs doing most of the
>>>>>> heavy lifting. But that's a separate issue.
>>>>
>>>>
>>>>
>>>> Agree with all of this. Working in a DispVM (e.g. browser, or
>>>> mail) is the same experience as working in a VM. Only difference
>>>> is clicking a script to start it up; inform the script of the
>>>> DispVM to work in; and telling the script to shutdown (copy
>>>> updates) at the end - in my case by entering a 
>>>>
>>>>
>>>>> I'd be interested in hearing more about this (in a separate
>>>>> thread, perhaps).
>>>>>
>>>>> In particular, no one has, to my knowledge, attempted to rebut
>>>>> the arguments I advanced against the "doing everything in
>>>>> DispVMs" approach here:
>>>>>
>>>>> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J
>>>>
>>>> RATS!  I missed that.
>>>>
>>>>
>>>>> Granted, that was almost two years ago, and some of the things
>>>>> I wrote there no longer apply. However, I still haven't seen a
>>>>> strong case made *in favor* of this approach to begin with. I
>>>>> would like to see one.
>>>>>
>>>>
>>>> This is the first I've seen your 4/1/15 note - sorry - wish we
>>>> could have discussed it then. You have the basic idea except for
>>>> the vital point of what happens at end of DispVM session (copying
>>>> as few as possible user files back to a VM or Vault). I take your
>>>> point 4 on space, and point 6 on RAM and CPU usage.
>>>>
>>>> I disagree on critical point 5.
>>>>
>>>> For example running a browser in a VM is indeed "more secure"
>>

Re: [qubes-users] Kicking the sudoers dead horse

2017-03-12 Thread sm8ax1
Unman:
> On Sat, Mar 11, 2017 at 04:43:41PM +0000, sm8ax1 wrote:
>> 7v5w7go9ub0o:
>>>
>>>
>>> On 03/11/2017 12:10 PM, Alex wrote:
>>>> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>>>>> On 03/11/2017 04:20 AM, Alex wrote:
>>>>>> the only really read-write directories (their changes are 
>>>>>> actually persisted) are /home and /usr/local.
>>>>> That is enough to be able to persist.
>>>> Yes, and that doesn't even need root :) So, both having root or 
>>>> not, there is some degree of persistence attainable.
>>>>
>>>> Installing via DNF or any other package manager is an easy route
>>>> to put files in the relevant "system" directories, but since these
>>>> are not persisted, it's actually more convenient, from a malware
>>>> point of view, to just place them in the home of the user and set
>>>> up some kind of autostart (eg bashrc, or systemd user units, or
>>>> gnome autostarts).
>>>
>>>
>>>
>>>
>>> Yep! And ISTM this is an argument for using dispvms to handle mail 
>>> (or any other WAN-exposed client/server): start a dispvm; copy mail 
>>> client and mail "file" into it; do your mail; copy out and save the 
>>> updated mail file (which is text); flush away the dispvm - all 
>>> handled by a script(s).
>>
>> How do you figure that's less of a pain in the ass than typing a sudo
>> password?
>>
> 
> You're missing the point - that procedure is trivial to set up in
> Qubes and addresses real security concerns. Just putting a password on
> root access, or requiring some dom0 interaction doesn't.
> 
> This is important - security IS a pain in the ass. Qubes can make it
> less so.
> 

Point taken. Someone at some point said requiring sudo would be too
inconvenient and new users wouldn't be familiar with it. I guess that
wasn't you. My mistake.

By the way, I'll call it "trivial" when there's an easy to use script,
complete with .desktop, readily available that does it. Writing said
script is more like "medium difficulty" for the average user.

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f9f7f2f1-7bb7-9a2e-93c9-118840747e70%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kicking the sudoers dead horse

2017-03-11 Thread sm8ax1
7v5w7go9ub0o:
> 
> 
> On 03/11/2017 12:10 PM, Alex wrote:
>> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>>> On 03/11/2017 04:20 AM, Alex wrote:
 the only really read-write directories (their changes are 
 actually persisted) are /home and /usr/local.
>>> That is enough to be able to persist.
>> Yes, and that doesn't even need root :) So, both having root or 
>> not, there is some degree of persistence attainable.
>> 
>> Installing via DNF or any other package manager is an easy route
>> to put files in the relevant "system" directories, but since these
>> are not persisted, it's actually more convenient, from a malware
>> point of view, to just place them in the home of the user and set
>> up some kind of autostart (eg bashrc, or systemd user units, or
>> gnome autostarts).
> 
> 
> 
> 
> Yep! And ISTM this is an argument for using dispvms to handle mail 
> (or any other WAN-exposed client/server): start a dispvm; copy mail 
> client and mail "file" into it; do your mail; copy out and save the 
> updated mail file (which is text); flush away the dispvm - all 
> handled by a script(s).

How do you figure that's less of a pain in the ass than typing a sudo
password?

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1b2ed6d3-0866-c0b4-a470-b82c2d724a6d%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Kicking the sudoers dead horse

2017-03-11 Thread sm8ax1
hib0...@gmail.com:
> This part of the file system is not rewritten on every boot. Are you 
> constantly somehow verifying your VM every boot, every 5 minutes, every web 
> page load?  Or are you restoring from a backup every boot or worse rebuilding 
> the entire VM from a template every time you need it? Do you just not care 
> that this VM could be under nefarious control and let the perpetrator read 
> your email etc?

Actually, I think it is, but I could be wrong.

I'm no expert so I hope someone jumps in and corrects me, but as I
understand it, /rw and /home are the only persistent directories, and
they are local to the VM.

Everything else is mounted as a temporary snapshot of a file owned by
the template (meaning the named TemplateVM can make persistent changes
to it), except for tmpfs filesystems like /run and /tmp.

So, malware could make itself persistent by infecting ~/.bashrc for
example, but `dnf install` or /usr/bin/audacious would go back to its
original state after a reboot.

If it were up to me (and I had the necessary time and skills), I would
harden all the things. Dom0 and DomUs alike. SELinux, AppArmor, Grsec,
musl, even OpenBSD where possible, and of course restricted root access.
Let the user incrementally disable security features if their favorite
apps don't work.

Xen is nice, but it's no panacea. I think about two years ago Xen got
hit pretty hard with a raft of critical security vulns and it caused bit
of controversy in the community.

Nevertheless I realize all this isn't easy and I appreciate the amount
of effort the developers have gone to in order to give us the Qubes we
have today. Qubes could be better, but there's a reason all of us left
our previous OSes after all, isn't there?


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c69fde54-0a47-6b85-0a33-a5596364e955%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Videostream with Qubes??

2017-03-09 Thread sm8ax1
Grzesiek Chodzicki:
> W dniu czwartek, 9 marca 2017 23:28:24 UTC+1 użytkownik evo napisał:
>> Am 03/09/2017 um 11:26 PM schrieb Grzesiek Chodzicki:
>>> W dniu czwartek, 9 marca 2017 23:19:23 UTC+1 użytkownik evo napisał:
 Am 03/09/2017 um 11:12 PM schrieb Grzesiek Chodzicki:
> W dniu czwartek, 9 marca 2017 21:41:02 UTC+1 użytkownik evo napisał:
>> On 03/09/2017 09:11 PM, Grzesiek Chodzicki wrote:
>>> W dniu czwartek, 9 marca 2017 21:01:12 UTC+1 użytkownik evo napisał:
 On 03/09/2017 08:37 PM, Grzesiek Chodzicki wrote:
> W dniu czwartek, 9 marca 2017 20:34:17 UTC+1 użytkownik evo napisał:
>> On 03/09/2017 08:27 PM, Grzegorz Chodzicki wrote:
>>>
>>>
>>> On 03/09/2017 08:23 PM, evo wrote:

 On 03/09/2017 08:10 PM, Grzesiek Chodzicki wrote:
> W dniu czwartek, 9 marca 2017 20:08:37 UTC+1 użytkownik evo 
> napisał:
>> On 03/09/2017 08:02 PM, Grzesiek Chodzicki wrote:
>>> W dniu czwartek, 9 marca 2017 19:44:38 UTC+1 użytkownik evo 
>>> napisał:
 Hello!

 i have problems with the most streams on the net.
 Youtube is ok, but i suppose rather slow.

 I think, this is the thing with flash, HTML5 and openH264.
 H264 is deactivated and if i want to activate it, it seems to 
 be not
 possible.

 Is it so, that HTML5 needs H264?
 Or is it so, that i need flash for every other stream.
 I tried also some links, that should be HTML5, but they were 
 not
 possible... maby they were not really in HTML5 or HTML5 does't 
 work good.

 Do somebody has an idea?
>>> try sudo nano /etc/qubes.guid.conf and add audio_low_latency = 
>>> true; parameter to the VM used for movie watching (or add it to 
>>> global variables).
>>> Alternatively, install Google Chrome (Not Chromium) and use 
>>> that.
>>>
>>
>> hmm... i don't have qubes.guid.conf in etc, not in dom0 and not 
>> in the VM
> Sorry, I meant /etc/qubes/guid.conf
>
 ah, ok, thanks!
 so i did add the new line under allow_fullscreen = true; by the 
 VM, that
 restarted the VM, but i think... nothing happens.
 if i want to stream MP4, it comes the download, which i don't want 
 at
 all. So firefox wants to download it instead of streaming.

 what i don't understand, what does audio have to do with stream?

 i will try it with chrome (i don't like)
>>> Video may stutter because video players and browsers automatically 
>>> try
>>> to synchronize video with audio (to avoid desyncs) so if audio 
>>> stutters,
>>> video will stutter as well. You may also want to try enable vertical
>>> blank synchronization in WIndow Manager tweaks.
>>>
>>> How does the formatting of the file look like? It should look like 
>>> this:
>>> VM: {
>>> work: {
>>> audio_low_latency = true;
>>> };
>>> };
>>> Additionally, You need to restart the VM after changing its 
>>> settings in
>>> the guid.conf file
>>>
>>
>> are ok, so low latancy is usefull also on youtube... is there any
>> security problems with it?
>
> IIRC this setting was used because having it on caused a CPU spike on 
> older kernels. It shouldn't matter now
>
>>
>> what do you mean with "window manager tweaks"?
>> where can i find vertical blank synchronization?
>
> Go to System Tools > Window Manager Tweaks > Compositor > Synchronize 
> drawing to vertical blank
>>
>> the formating is like
>>
>> VM: {
>>work: {
>> allow_fullscreen = true;
>> audio_low_latency = true;
>>
>> };
>> };
>>
>> i restarted the VM after change in quid.conf
>
> Formatting looks good, You may want to try restarting the physical 
> machine just in case.
>

 restarted the PM... firefox wants still to download the MP4-stream...
 i suppose that youtube runs better, quicker.. maby just my feeling and
 not fact.

 fedora don't have chrom in the sources, strange... i will try to 
 install
 it from google source or smth like that.

 but is there no possibility to play stream on firefox??
>>>
>>> You'll probably need 

Re: [qubes-users] SystemD sucks - qubes shouldn't use it

2017-03-09 Thread sm8ax1
Chris Laprise:
> On 03/08/2017 08:50 AM, taii...@gmx.com wrote:
> 
>> "The Linux kernel, I believe, is clean.
> 
> You lost me right there. I don't believe in hero worship, and if anyone
> thinks Linus is fallible it is the people on this list.

Thanks for addressing this, Chris.

Privilege escalation, uninitialized pointers, race conditions, you name
it, vulns are found in the kernel at what's in my opinion a somewhat
alarming rate. I seem to think a developer loudly brought up this
growing problem at linux.conf or a another event a year or two ago, but
the details aren't coming to me. I don't even follow kernel development
and I hear about security problems way more often than I'd like to for
ring0 code.

For some insight into why the Linux kernel is not as secure as you
think, in both rant style and by-example, regularly posted referring to
over a decade's worth of incidents and poor decisions, all you have to
do is visit https://www.grsecurity.net/

I'm not saying that Linux is a bad thing or the developers don't care or
that another OS is better, but to say the kernel "is clean" is just
plain wrong.

taii...@gmx.com:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
> I am tired of the "virtualization will protect you!" excuse, it only
> goes so far and some systemD issues such as using google DNS by default
> are simply inexcusable from a qubes perspective (designed to be a secure
> OS, but phoning home like that without asking isn't secure at all)

It's easy enough to override the defaults at compile-time, and most
distros do in fact. You can also of course set your own at run-time, but
most users won't do this and I agree Qubes should make an attempt to
protect users from that. systemd-timesyncd has a similar problem with
timeservers.

Actually, do these settings even matter in Qubes' default state?

My systemd-networkd.service is disabled and not running in my sys-net,
which is the way it was installed.

Further, /etc/resolv.conf is
> # Generated by NetworkManager
> nameserver 192.168.1.1

Which is the DNS server configured by DHCP.

Where does systemd-resolved come into play?

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9676f5aa-ec5a-b5fa-0653-8a3292a15e73%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] New User...Install won't setup and Run from SSD

2017-03-08 Thread sm8ax1
William Fisher:
> Hi,
> 
> My name is William Fisher, and I built a desktop specifically for Qubes Os.
> I have one Samsung M.2 NVMe SSD and one 1TB disk drive. After I install
> Qubes to the SSD and reboot, it does not recognize the SSD as a bootable
> device. Using the same install procedures on the HDD, everything works
> fine. When using Qubes from the HDD to access the SSD, the BOOT file is
> empty, so there are no files to rename as you've directed in the UEFI
> troubleshooting. Also, I cannot access the /BOOT/EFI/ file on my HDD, it
> says I don't have the required permissions. On install, I set up a password
> for the root user, but cannot act as the root user, even through terminal.
> There is no prompt for a password.
> 
> Also, I've tried to use a 4K monitor with Qubes, but the max resolution
> option is 1080p. I understand that there is a way to create custom
> resolution options through terminal using xrandr, but have tried and it
> failed when using addmode eDPI 2560x1600 (I was trying this resolution
> first as someone in an email string did this successfully).
> 
> Any help would be greatly appreciated, especially the the boot issues. I
> would prefer not booting Qubes off my HDD when I got an M.2 SSD
> specifically for Qubes.
> 
> Thank you,
> William fisher
> 

First, make sure your motherboard (UEFI) even supports booting from a
PCIe device. I don't have any PCIe SSDs so I don't know if it's common
for UEFI implementations to support booting from PCIe or not, and you
didn't mention what motherboard you have. Just covering all bases.

I'm just sort of guessing here, but try copying the /boot/efi directory
from the HDD to the SSD, then see if it'll boot from the SSD. You'll
have to mount the SSD's EFI boot partition somewhere first of course. If
it still won't boot from the SSD, try renaming the files as described in
the UEFI troubleshooting page.

You say it won't prompt for the root password. What output do you get
from the sudo command? If you can't get that to work, boot into the
Qubes installation media and use Ctrl+Alt+2 to switch to tty2 which
should have a root(able) shell on it.

If all else fails, try unplugging the HDD and reinstall Qubes, and if it
successfully boots, plug the HDD back in. It's unlikely but possible
that either the installer or the UEFI got confused about which device to
boot from. This is a shot in the dark, probably won't work, will take
some time, and will wear the SSD a little so use it as a last resort.

As for the xrandr issue, you might want to start a new thread with an
appropriate title if no one replies to it here.

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f89e9fa0-2975-b77c-8250-cee2cac01bf3%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes i3 Tips & Tricks

2017-03-06 Thread sm8ax1
Daniel Moerner:
> I've been using i3 in dom0 for about a month now, and I wanted to share a few 
> tips and tricks (partly so I can have them in a centralized place for 
> reference):
> 
> 1. To lock the screen on suspend and resume, you need to add a systemd target 
> in /etc/systemd/system. This has to use your username (or supposedly 
> xss-lock, which I haven't bothered figuring out how to use). I use the 
> following content, substituting for $USER:
> 
> [Unit]
> Description=Lock screen on suspend
> 
> [Service]
> User=$USER
> Type=forking
> Environment=DISPLAY=:0
> ExecStart=/usr/bin/i3lock -d -c 00
> 
> [Install]
> WantedBy=suspend.target
> 
> 2. Volume keys: Install pulseaudio-utils. Then put the following in 
> .i3/config:
> 
> bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 1 +5%
> bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 1 -5%
> bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute 1 toggle
> 
> I then customize the qubes-i3status command by adding: (I know this awk/sed 
> mixture is awful, and it's hard-coded for my system, which has two pulseaudio 
> sinks)
> 
> status_volume() {
>local muted=$(pactl list sinks | awk -F ' ' '/Mute/ {print $2}' | sed -s 
> 's/ //g' -e '2q;d')
>if [[ $muted == 'yes' ]]; then
>json volume "Volume: 0%"
>else
>local volume=$(pactl list sinks | awk -F ' ' '/Volume/ {print $2}' | 
> sed -s 's/ //g' -e '3q;d')
>json volume "Volume: $volume"
>fi
> }
> 
> And then add a local volume variable to the main() call. I update every 
> second.
> 
> 3. A few minor tweaks to the config file: See this pull request, which has 
> already been merged: https://github.com/QubesOS/qubes-desktop-linux-i3/pull/5 
> 
> A few more personal thoughts: Personally, I change the navigation to use vim 
> keys, and then remap horizontal split to 'b'. I also remap 'focus child' to 
> 'c', since I find it to be a useful shortcut. Originally I disabled 
> fullscreen, on the model of Xfce4, but I had to reenable it as part of a 
> workaround for https://github.com/QubesOS/qubes-issues/issues/1502
> 
> I'm sure I'm missing a few things, but I wanted to share this, since I 
> sometimes see people asking about i3, especially on IRC.
> 
> Best,
> Daniel 
> 

Thanks for this. I've used i3 on other OSes and I like it a lot. I
probably won't use it on Qubes however because of an issue that I'll
note here since it may or may not affect other users.

In i3 it is rather difficult to control the size of a window with fine
granularity, and in particular it is very difficult to restore the exact
size a window would have been created with. This is a problem for users
of Tor Browser, because websites and exit nodes can query the browser
window's size even when you have JavaScript disabled. This makes you an
easy fingerprinting target.

If anyone knows of any workarounds for this, perhaps forcing certain
kinds of windows to be created in floating mode and keep their original
size, please share them.

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bab51d99-56d2-af1e-96bd-0483eebd2653%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] First time user: initial issues and thoughts

2017-03-06 Thread sm8ax1
Chris Laprise:
> On 03/05/2017 08:11 AM, sm8ax1 wrote:
>>
>> Thanks, I read the custom install page prior to installing, but I was
>> unaware of #2340.
>>
>> To be honest, when I decided I wanted BTRFS, I just sort of assumed that
>> guest disk images were logical volumes to begin with. The custom install
>> page mentioned LVM in every scenario, so I thought it was necessary for
>> that reason. And the Xen wiki repeatedly mentions that logical volumes
>> are faster than image files on any kind of filesystem.  It was, however,
>> suspcious when the custom install page said "-l 100%FREE" for the root
>> LV. I guess that's what I get for assuming.
>>
>> Are there any plans for hooking Qubes up to the LVM in this way? LVM
>> itself supports block-level rw CoW snapshots, and the Xen project
>> strongly recommends it over image files.
> 
> Normally you shouldn't mix Btrfs with LVM, as the former is a kind of
> volume manager in itself.
> 
> I have used Btrfs on Qubes for probably close to 2 years and it has been
> very good in terms of stability and performance. However, anaconda
> (fedora's installer) doesn't handle a mixture of partitioning and fs
> options well, esp. if you select Btrfs. The only 'good' way I've found
> is to select a Btrfs system install and let it re-partition the whole
> disk; otherwise, it has a tendency to forget steps such as LUKS
> encryption layer.
> 
> Note that thin-provisoned LVM (probably the type you're referring to)
> incurs a speed penalty as well. Its really doing the same work as Btrfs,
> but without some of the nice features.

The installer worked the way I wanted it to after a few tries, as I
mentioned earlier. I just had to delete the filesystem from the LV
first. The custom install page even warns that it's likely to be
glitchy. I can't really complain.

I'm not sure what you mean by the installer forgetting the LUKS
encryption layer. That already existed on the disk before I used the
installer. I had to unlock it within the installer before I could setup
the root and swap LVs. If it were to overwrite the whole LUKS container
with a root filesystem then that's one hell of a bug.

About Btrfs...

You have a point that Btrfs can replace LVM for the most part and
thin-provisioned LVM's performance is probably comparable. However, I
was referring specifically to Xen Project's recommendation to use LVM
because the block device backend is faster than the filesystem backend
according to them. This is regardless of the performance difference
between btrfs and thin-provisioned LVM, presumably.

I mistakenly implied that snapshot capabilities even matter with things
as they are today. If Qubes can run on ext4, necessarily without any
CoW/snapshot infrastructure, then it seemingly could run on traditional
LVM just the same. The only difference is it would be running on a block
device rather than a filesystem. Snapshots and thin-provisioned LVM are
both beyond the scope of this comparison.

As a separate issue, CoW copies of blocks being created when a file is
randomly written to is just part of how Btrfs works and irrelevant to
snapshots (which AFAIK aren't used) in Qubes's case. It can cause bad
performance with random-write scenarios like virtual machine images.
Using an LV solves the problem, but so does `chattr +C`, so there's not
much of an argument here.

As an aside, sometimes the biggest advantage to using LVM is because
many early userspace implementations don't know how to unlock multiple
LUKS partitions (e.g. root (btrfs) and swap). Although you don't
technically need swap unlocked in early userspace, you do if you want to
resume from hibernation and/or only enter your password once. Btrfs
doesn't support swap files either.

Using Btrfs instead of LVM is completely valid in many cases. The
question is whether the performance advantage of traditional LVM would
justify supporting it in addition to image files.

>> I wanted to setup MAC address spoofing on my wireless interface too, so
>>>> I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
>>>> I restarted it my changes were gone. I read that I have to make changes
>>>> in the TemplateVM itself (fedora-23) for them to be persistent, but the
>>>> problem is that I don't necessarily need all VMs to have this change.
>>>> I'm still not sure of the correct way to make changes to a single VM
>>>> that inherits from a TemplateVM.
>>>
>>> On MAC anonymization:
>>>
>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>> That's more or less what I read on other sites. I think we should
>> consider putting a Big Fat Warning on that page saying that your changes
>> will be lost on restart if the VM belongs to a template, or you

Re: [qubes-users] always blank VM-untrusted. possible?

2017-03-05 Thread sm8ax1
evo:
> Hi!
> 
> is there any possibility to get everything deleted in home folder if i
> restart the VM (in that case untrusted)?
> 
> this would be more secure, so there will be no need to take care of
> surfing and such things.
> 
> greets
> evo
> 

DisposableVMs are meant for that.

My XFCE menu came with a Firefox in DispVM option out of the box.

I'm not sure if you can "mark" an arbitrary VM as disposable, but you
can clone an existing VM and delete it when you're done. It's a pretty
quick process.

https://www.qubes-os.org/doc/dispvm/
https://www.qubes-os.org/doc/dispvm-customization/
https://www.whonix.org/wiki/Qubes/Disposable_VM

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e24e8306-4cb4-5915-0dbc-1ca5b7da13e2%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How to use a and which mailclient in QUBES (via TOR)?

2017-03-05 Thread sm8ax1
Unman:
> On Sat, Mar 04, 2017 at 11:30:35PM -, pixr...@mail2tor.com wrote:
> 
>> What needs to be done that IMAP goes over TOR? can this be done and if so
>> how should I set it up in Qubes?
>>
> 
> Just put your mail qubes downstream from a TorVM, so that the traffic is
> routed through Tor.
> Or look at implementing this on a whonix workstation.
> 

New to this thread (and list) so sorry if I missed something, but
Icedove (Thunderbird) with TorBirdy is preinstalled in Whonix which is
included with Qubes. All you have to do is configure it with your email
account. It only took me a couple of minutes and it works well. I think
I had to manually add a shortcut via the Qubes VM manager.

As for which client to use, I think Claws is the only client officially
deemed safe. Thunderbird+TorBirdy seems pretty safe to me, at least
there are no critical outstanding bugs, but it's still considered
experimental. Beyond that, it's a matter of personal preference, but be
aware of both exploitation and fingerprinting matters especially in
clients not designed for Tor.

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0c861759-b024-9d37-9a5e-2adc51733192%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] First time user: initial issues and thoughts

2017-03-05 Thread sm8ax1
Andrew David Wong:
> On 2017-03-04 06:35, sm8ax1 wrote:
>> Hi,
> 
>> I just installed Qubes yesterday and wanted to share my thoughts and
>> some issues I ran into.
> 
>> Table of Contents
>> 1. Use Case / Thanks
>> 2. Minor issues with manual partitioning and assigning mountpoints
>> 3. First-boot dialog
>> 4. NetworkManager applet didn't start the first time
>> 5. Modifying /etc files in template-inherited VMs persistently
>> 6. Screensaver blacks screen but doesn't turn off the backlight
>> 7. sys-firewall uses much more RAM than it should have to
>> 8. Encrypted /boot partition support
> 
>> First, I want to thank the developers. I've used Xen with QEMU and GTK+
>> on other Linuxes before, so I'm familiar with some of the concepts. I
>> was trying to accomplish basically what Qubes did, but it was a real
>> pain to manage, the actual security of the whole system was
>> questionable, and even simple tasks like pasting text or transferring
>> files were a pain. You guys did a great job with Qubes. It's the OS I've
>> been waiting for.
> 
> 
> Welcome, and thank you for the thoughtful and organized feedback!
> 
>> I learned about it a long time ago, probably around the time it first
>> came out, but I didn't think about trying it until it was featured on
>> the Tor blog and I learned about some new features. (For anyone who's
>> interested, I had a thoughtful, though theoretical, debate with another
>> reader about the some of the design choices around Qubes:
>> https://blog.torproject.org/blog/tor-heart-qubes-os#comment-229452)
> 
>> The installation was pretty easy, but I ran into somewhat of an edge
>> case that held me up a little. I did my partitioning manually, and kept
>> the same GPT (and protective MBR) that was already installed.
> 
>> BIOS Boot Partition (1007K) - out-of-alignment filesystemless partition
>> that allows GRUB to embed itself
>> EFI System Partition
>> /boot partition
>> encrypted main partition with LVM
>>  root
>>  swap
> 
>> All good. Here's the issue. I thought I would "help" the installer by
>> creating a BTRFS LV for the root filesystem. It showed up in the
>> installer with a weird name like "btrfs.XXX" (where X is a digit that
>> changed on each reboot), and it didn't have the logical volume name in
>> the subtext like my swap LV did. I was typing "/" into the mountpoint
>> field, but instead of moving the partition up to the
>> to-be-assigned-a-mount-point group (above the list of available
>> partitions) when I clicked away like /boot and /boot/efi, the "/"
>> disappeared and the partition stayed put. I didn't think anything of
>> pre-formatting the LV with BTRFS because it was okay for all of the
>> other partitions.
> 
>> I worked around it by removing the filesystem from the LV (zeroing it
>> out), and then the installer finally allowed me to have a new BTRFS
>> filesystem created on the LV and a mountpoint assigned. I think at some
>> point I read in the documentation that the root filesystem MUST be newly
>> created, but it would have saved me a lot of time if the installer had
>> just told me that. Overall I'd say it did alright for an LVM-on-LUKS
>> with BTRFS installation though.
> 
> 
> Possibly related and/or helpful links:
> 
> https://www.qubes-os.org/doc/custom-install/
> https://github.com/QubesOS/qubes-issues/issues/2340
> (I've added a link to your post.)

Thanks, I read the custom install page prior to installing, but I was
unaware of #2340.

To be honest, when I decided I wanted BTRFS, I just sort of assumed that
guest disk images were logical volumes to begin with. The custom install
page mentioned LVM in every scenario, so I thought it was necessary for
that reason. And the Xen wiki repeatedly mentions that logical volumes
are faster than image files on any kind of filesystem.  It was, however,
suspcious when the custom install page said "-l 100%FREE" for the root
LV. I guess that's what I get for assuming.

Are there any plans for hooking Qubes up to the LVM in this way? LVM
itself supports block-level rw CoW snapshots, and the Xen project
strongly recommends it over image files.

And as a final thought, it really wouldn't be that hard for Qubes to run
`chattr +C $file` when a new image file is created (though CoW is
reenabled if you take a snapshot, according to #2340). Note that if you
want to do this after the fact, you have to recreate the file (setting
+C on a non-empty-file is undefined).

mv file.img file.img.bak
touch file.img
chattr +C file.img
cp file.img.back file.img
rm f

[qubes-users] First time user: initial issues and thoughts

2017-03-04 Thread sm8ax1
Hi,

I just installed Qubes yesterday and wanted to share my thoughts and
some issues I ran into.

Table of Contents
1. Use Case / Thanks
2. Minor issues with manual partitioning and assigning mountpoints
3. First-boot dialog
4. NetworkManager applet didn't start the first time
5. Modifying /etc files in template-inherited VMs persistently
6. Screensaver blacks screen but doesn't turn off the backlight
7. sys-firewall uses much more RAM than it should have to
8. Encrypted /boot partition support

First, I want to thank the developers. I've used Xen with QEMU and GTK+
on other Linuxes before, so I'm familiar with some of the concepts. I
was trying to accomplish basically what Qubes did, but it was a real
pain to manage, the actual security of the whole system was
questionable, and even simple tasks like pasting text or transferring
files were a pain. You guys did a great job with Qubes. It's the OS I've
been waiting for.

I learned about it a long time ago, probably around the time it first
came out, but I didn't think about trying it until it was featured on
the Tor blog and I learned about some new features. (For anyone who's
interested, I had a thoughtful, though theoretical, debate with another
reader about the some of the design choices around Qubes:
https://blog.torproject.org/blog/tor-heart-qubes-os#comment-229452)

The installation was pretty easy, but I ran into somewhat of an edge
case that held me up a little. I did my partitioning manually, and kept
the same GPT (and protective MBR) that was already installed.

BIOS Boot Partition (1007K) - out-of-alignment filesystemless partition
that allows GRUB to embed itself
EFI System Partition
/boot partition
encrypted main partition with LVM
root
swap

All good. Here's the issue. I thought I would "help" the installer by
creating a BTRFS LV for the root filesystem. It showed up in the
installer with a weird name like "btrfs.XXX" (where X is a digit that
changed on each reboot), and it didn't have the logical volume name in
the subtext like my swap LV did. I was typing "/" into the mountpoint
field, but instead of moving the partition up to the
to-be-assigned-a-mount-point group (above the list of available
partitions) when I clicked away like /boot and /boot/efi, the "/"
disappeared and the partition stayed put. I didn't think anything of
pre-formatting the LV with BTRFS because it was okay for all of the
other partitions.

I worked around it by removing the filesystem from the LV (zeroing it
out), and then the installer finally allowed me to have a new BTRFS
filesystem created on the LV and a mountpoint assigned. I think at some
point I read in the documentation that the root filesystem MUST be newly
created, but it would have saved me a lot of time if the installer had
just told me that. Overall I'd say it did alright for an LVM-on-LUKS
with BTRFS installation though.

The first-boot options dialog could have explained the options a little
better, or they should be explained in the documentation. For example,
the option to proxy all applications and upgrades through Tor, I
selected it because it sounded like what I wanted, but I didn't really
understand how it would affect the networking VM hierarchy or whether I
could still create unproxied VMs. I left the USB VM (sys-usb) option
unselected because I wasn't sure how reliable it would be, I don't have
an IOMMU anyway, and I don't connect a lot of random USB devices to my
computer, but I would like to try the feature in the future. All along I
was thinking "Can I change my mind later? Am I stuck with these
decisions for the rest of my life?"

Next, and this is the biggest one, the NetworkManager applet in sys-net
didn't start the first time, so I spent an a lot of extra time tinkering
with it and researching the problem until I found a bug report that
described the exact problem I was having. All I had to do was restart
sys-net, but it would have saved me a lot of time if it had started on
its own the first time.

I wanted to setup MAC address spoofing on my wireless interface too, so
I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when
I restarted it my changes were gone. I read that I have to make changes
in the TemplateVM itself (fedora-23) for them to be persistent, but the
problem is that I don't necessarily need all VMs to have this change.
I'm still not sure of the correct way to make changes to a single VM
that inherits from a TemplateVM.

Also, the screen saver doesn't turn off the display backlight like it
did on my old OS on this machine. Rather, the screen goes black but the
backlight is still on. I've seen other machines do the same thing, but I
know the hardware and drivers support turning off the backlight on this
machine if I can figure out how to configure it. I'm really hoping it
doesn't involve recompiling the kernel or anything like that.

When the Qubes VM Manager came up, my first thought (after noticing how
nice it looked) was "1400MB of RAM