Re: [qubes-users] Re: Security questions (templates and kde)

[sevas]

 I couldve sworn I replied to these... Well, thanks to everyone who put their 2 
cents in! 

There is some stellar advice in here! Im going to have to go back later and 
read this whole thread and write down bullet points... 

Heres what I have so far. 

Templates 3 catagories. 
1) original (stripped of programs I dont want)
2) default (default template with minimal added functionality apps added)
3) network enabled 

#2 is divided into 
 a. default (default template with minimal added functionality apps added)
 b. EVERYTHING (everything that doesnt need internet access)

#3 is divided by program. 
One for GPG keyring, 
one for browsing, 
one for banking,
one for keepassx... 
and sys-net/firewall in one (which Im going to split now, Thanks Steve!)... 

although keypass is not networked. 

But thats all templates. 

-- 
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/da482d35-ffe0-4c88-9151-9cb6524c2467%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Security questions (templates and kde)

[Steve Coleman]

On 03/07/18 15:05, sevas wrote:

Cool. That gave me some ideas. Thanks for sharing your setup.

So, another infosec question Im trying to figure out...

Templates Vs AppVMs.


I find that I separate my Templates based on two criteria. What I want 
to limit access to, and what I do or do not trust


I want to limit sys-net to the absolute bare minimum of tools and 
functionality, because I want any adversary to have a really really hard 
time trying to leverage my sys-net to get to the next hop on the 
network. Your sys-net is the public attack surface which is available 
24x7 for attack on your host system. If somehow an adversary were to get 
a foothold on sys-net then they could set up shop and start attacking 
Xen, sys-firewall, or your network neighbors. You reall do not want a 
root-kit flashed into your NIC, trust me.


I want the tools for those tasks to be as limited as possible, and if I 
could remove everything right down to the kernel and network drivers, I 
would do that. Unfortunately we do need a shell environment to make 
networking to work, so not providing any tools or applications that 
would make their life easier is the goal to work towards.


For this reason I give sys-net its own stripped down software template. 
I want existence there to be painful if not impossible. I would like to 
even remove sudo and other convenience tools, and make that environment 
even more primitive, making it that much harder. For admin privs one 
could use dom0 and "qvm-run -u root sys-net ..." to manage maintenance 
tasks, but I have not had the time to test if this would even work in 
the long run. If I could have a single binary monolithic executable 
image that would work for me.


The other concern is what I do I trust, in that I trust the 
fedora/redhat distribution much more than I trust the fedora "fusion" 
project. If I had a vm where I needed some mp3 player from fusion, I 
would not want my Banking VM to be exposed to share libraries running 
from this other distribution. Keep the risky software out of AppVM's 
that you need to trust, while its Ok to provide the risky software to 
VM's that are only there for your pleasure and amusement. Draw a big red 
line down the middle, and never let the two meet.


So my Templates are divided as:

"fedora-26-net" Stripped to the bone
"fedora-26" general use VM's
"fedora-26-trusted" Banking, Purchasing, etc
"fedora-26-fusion" Web browsing, youtube, multimedia, social media, etc

For each AppVM I will personalize the dom0 menu to place the apps I 
intend each VM to use. Keep the menus clean, concise, and for the 
purpose. If an extra app exists in that VMs file system but does not get 
used, that's Ok by me. What I don't want is rogue software that I don't 
trust running in the wrong VM, hence their template'd separation based 
on what I do or do not trust.


Steve


--
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/67ac5e4b-88ee-827d-a9da-8adb3c6ffd51%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

Re: Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Thursday, March 8, 2018 at 7:49:13 PM UTC+1, steve.coleman wrote:
> Glad to hear I'm not the only one paying attention to this particular 
> attack surface. There is nothing like a wide open 24x7 automated attack 
> surface to keep you up at nights wondering what web exploits will be 
> discovered next by the hacker community.  Even with layers of security 
> well before things get to me, I'm still wanting to be extremely diligent 
> with threat mitigation when it comes to unsolicited email.
> 
> On 03/07/18 20:55, 799 wrote:
> 
> > Do you mind writing some more details as I am interested how other 
> > people solve the email problem.
> > Are you really separating email in different AppVMs?
> 
> I only separate attached documents and move them to the respective 
> project VMs. The email itself is coming in from IMAP and I have an 
> elaborate set of macro filters that test the SMTP headers details, 
> validate, flags their state, and process them by moving them off of IMAP 
> and into an offline mail storage location. If it doesn't pass my barrage 
> of sanity tests then I don't even pull it onto my system.
> 
> > Even when you said, that the VM can only connect per SMTP I assume that 
> > you are not separating IMAP (incoming) and SMTP (outgoing) into two two 
> > VMs and then moving emails from the incoming mail VM to the offline mail VM?
> 
> Correct. Everything gets sorted base on work related vs personal 
> interests (eg. Qubes users forum has its own folder) with work/project 
> grouped and lower priority which I read when I can find time.
> 
> > You have one VM which makes both IMAP and SMTP correct?
> 
> Yes. As far as I can see that is the only way other than building some 
> sort of rpc mail proxy to make a distributed VM email system, and that 
> might just widen the attack surface. My email VM does nothing but sort 
> my email and allow me to send outgoing SMTP as well.
> 
> My email VM is denied access to the Internet so any links to malware 
> content will denies rough sites reach-back capability and prevents 
> drive-by malware installs. I don't see icons or web content and I am 
> just fine with that.
> 
> The qubes Thunderbird/DVM integration works nicely for automatically 
> opening any untrusted documents for testing, and if the document needs 
> to be retained I merely copy it to the appropriate VM for processing or 
> archiving.  The base of the email has already been moved off the IMAP 
> server and into file system storage into sorted folders for searching or 
> deletion after processing.
> 
> My goal is to automate the email processing grunt work and apply a 
> defense of security validations even before even copying it onto my 
> machine for processing. I have checks in place that validate which 
> emails came from what place, and test how it was authenticated and 
> passed through the IT infrastructure to get to me. A properly 
> authenticated internal email gets labeled as such.
> 
> If anything is different or suspicious it gets flagged as abnormal and 
> gets a manual inspection to determine the nature of the unexpected 
> "feature" of that email. External incoming PDF/DOC documents that could 
> have embedded macros get flagged as suspicious. It could be phishing or 
> IT changing their processing because of outages, etc. One day I might 
> look at putting in some basic deep-learning AI into the process stream 
> to make it even smarter at detecting processing anomalies such as faked 
> SMTP headers. That's a little too hard for Thunderbird at the moment.
> 
> > Which email/calendar client are you using and how do you move mails to 
> > your  offline email VM?
> 
> I have Thunderbird/IMAP with Lightning for calendar, because it works 
> fairly well for my purposes. I do use Davmail, but only for the calendar 
> side of things. One issue with calendar is I keep getting told that a 
> calendar event had changed and it asks whether to discard or send any 
> way, and that gets annoying. One day I'll take the time to figure out why.
> 
> I like that Thunderbird and the Lightning/calendar invites work 
> together. At one point Thunderbird got an update and lightning stopped 
> working, to the point that Thunderbird deactivated it. That sucked, so I 
> used OWA access for a while and just now realized lightning had been 
> updated so I reinstalled it. That is one problem with my email VM being 
> off-line, in that Thunderbird can't check for updates automatically. 
> That is a catch-22, but I still prefer to keep it this way. The less it 
> can do on the network, more minimal its attack surface.
> 
> > My setup:
> > Dedicated Email VM with Davmail installed. Davmail connects per OWA to 
> > our corporate Microsoft Exchange Server and acts as some kind of gateway 
> > to provide local SMTP/IMAP/CardDAV/CalDAV connections.
> > For emails I am running offlineimap which connects locally to Davmail 
> > and downloads all emails and creates a local maildir-repository.
> 
> > Contacts 

Re: Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Thursday, March 8, 2018 at 2:55:18 AM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 06.03.2018 10:04 nachm. schrieb "Steve Coleman" 
> Because the SMTP infrastructure was not designed with compartmentalization in 
> mind, and I only get my one email account to work with, this single "email" 
> VM is highly isolated. It gets its own software locked down configuration and 
> is firewalled with a default-deny network policy. The only services that this 
> VM can get to on the network is the required SMTP services, network 
> authentication, and the necessary  signing key management.  No internal 
> websites, no external sites, only the email App runs here. Well, Ok, the 
> calendar too. Anyway, there should be no "phoning home" from here, other than 
> through per use 2fa outbound email. Should any rouge malware be received, all 
> attachments are first scanned and "tested" in a DVM instance before being 
> separated and pushed across to the appropriate project VM for storage 
> management. All project related historical emails are then migrated to an 
> off-line but searchable storage by project. This specialized email VM 
> essentially sorts, filters, prioritizes, and bins any incoming data/mail for 
> easy processing.
> 
> 
> 
> Do you mind writing some more details as I am interested how other people 
> solve the email problem.
> Are you really separating email in different AppVMs?
> Even when you said, that the VM can only connect per SMTP I assume that you 
> are not separating IMAP (incoming) and SMTP (outgoing) into two two VMs and 
> then moving emails from the incoming mail VM to the offline mail VM?
> You have one VM which makes both IMAP and SMTP correct?
> Which email/calendar client are you using and how do you move mails to your  
> offline email VM?
> 
> 
> My setup:
> Dedicated Email VM with Davmail installed. Davmail connects per OWA to our 
> corporate Microsoft Exchange Server and acts as some kind of gateway to 
> provide local SMTP/IMAP/CardDAV/CalDAV connections.
> For emails I am running offlineimap which connects locally to Davmail and 
> downloads all emails and creates a local maildir-repository.
> Contacts and calendar entries are downloaded via vdirsyncer.
> All content is now locally available in this Email-AppVM and can now also be 
> used offline.
> Within this VM I have setup:
> For plaintext work:
> - neomutt - email client
> - khal - calendar
> - khard - adressbook
> - notmuch - fast search
> 
> 
> And as GUI email clients (connecting to the Davmail gateway / not using the 
> maildir-repository)
> - Evolution
> - Thunderbird
> 
> 
> Unfortunately not everything works with the Davmail Gateway:
> I can see the exchange Calendar in Thunderbird, but not the calendars of my 
> colleques. If I open a calendar entry I get an error.
> On Evolution calendar is working much better as I can open and view the 
> details of an calendar entry, I can create and edit calendar entries - 
> everything is synced per Davmail to our corporate Exchange.
> Strangely I can not delete calendar entries in Evolution.
> 
> 
> With khal I can also view/edit my  calendar entries in the terminal.
> Same for khard with my contacts.
> 
> 
> Todo:
> 1) Check why I can add/edit calendar entries but not delete them
> 
> 
> 2) optimize handling of attachments that PDFs / Office documents / Weblinks 
> are always opened in a DVM.
> I have been able to do this for Thunderbird but not yet for neomutt and 
> Evolution.
> 
> 
> 3) I'd like to integrate email and calendar into emacs org-mode, which I am 
> more and more using for PIM.
> 
> 
> 4) lock down EmailAppVM so that it can only access the Microsoft Exchange 
> Mailserver nothing more.
> I would do so by running IPtables within the VM with a default 
> incoming/outgoing DROP policy only adding what is absolutely necessary to get 
> mail/contacts/calendar working with the Exchange server
> 
> 
> I have also thought about separating email into more AppVMs but the usability 
> trade-off seems to high without gaining that much security.
> As the Email AppVM only is used for email/calendar it should have the same 
> security level like our Exchange Server. If it gets compromise it doesn't 
> make a difference what I have setup in Qubes.
> 
> 
> [799]

I do something similar yeah, although I haven't taken it was far as I'd like to 
yet, and you guys also bring up some interesting fresh ideas as well that I 
will follow up on and read later. 

I currently have 5 different AppVM's for different mail accounts. But 3 of them 
are only checked when I'm actively spending time work related to them, which is 
nice because I don't need to receive those emails when not in that work-mode 
anyway, so I don't get disturbed.

I've been thinking about the one direction firewall systems too, i.e. only 
allow in on one AppVM, and only allow out on another AppVM. But man it's a 
lot of AppVM's to do something like that, especially when I already got 5 
e-mail AppVM's, it'd 

Re: Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

[Steve Coleman]

Glad to hear I'm not the only one paying attention to this particular 
attack surface. There is nothing like a wide open 24x7 automated attack 
surface to keep you up at nights wondering what web exploits will be 
discovered next by the hacker community.  Even with layers of security 
well before things get to me, I'm still wanting to be extremely diligent 
with threat mitigation when it comes to unsolicited email.


On 03/07/18 20:55, 799 wrote:

Do you mind writing some more details as I am interested how other 
people solve the email problem.

Are you really separating email in different AppVMs?


I only separate attached documents and move them to the respective 
project VMs. The email itself is coming in from IMAP and I have an 
elaborate set of macro filters that test the SMTP headers details, 
validate, flags their state, and process them by moving them off of IMAP 
and into an offline mail storage location. If it doesn't pass my barrage 
of sanity tests then I don't even pull it onto my system.


Even when you said, that the VM can only connect per SMTP I assume that 
you are not separating IMAP (incoming) and SMTP (outgoing) into two two 
VMs and then moving emails from the incoming mail VM to the offline mail VM?


Correct. Everything gets sorted base on work related vs personal 
interests (eg. Qubes users forum has its own folder) with work/project 
grouped and lower priority which I read when I can find time.



You have one VM which makes both IMAP and SMTP correct?


Yes. As far as I can see that is the only way other than building some 
sort of rpc mail proxy to make a distributed VM email system, and that 
might just widen the attack surface. My email VM does nothing but sort 
my email and allow me to send outgoing SMTP as well.


My email VM is denied access to the Internet so any links to malware 
content will denies rough sites reach-back capability and prevents 
drive-by malware installs. I don't see icons or web content and I am 
just fine with that.


The qubes Thunderbird/DVM integration works nicely for automatically 
opening any untrusted documents for testing, and if the document needs 
to be retained I merely copy it to the appropriate VM for processing or 
archiving.  The base of the email has already been moved off the IMAP 
server and into file system storage into sorted folders for searching or 
deletion after processing.


My goal is to automate the email processing grunt work and apply a 
defense of security validations even before even copying it onto my 
machine for processing. I have checks in place that validate which 
emails came from what place, and test how it was authenticated and 
passed through the IT infrastructure to get to me. A properly 
authenticated internal email gets labeled as such.


If anything is different or suspicious it gets flagged as abnormal and 
gets a manual inspection to determine the nature of the unexpected 
"feature" of that email. External incoming PDF/DOC documents that could 
have embedded macros get flagged as suspicious. It could be phishing or 
IT changing their processing because of outages, etc. One day I might 
look at putting in some basic deep-learning AI into the process stream 
to make it even smarter at detecting processing anomalies such as faked 
SMTP headers. That's a little too hard for Thunderbird at the moment.


Which email/calendar client are you using and how do you move mails to 
your  offline email VM?


I have Thunderbird/IMAP with Lightning for calendar, because it works 
fairly well for my purposes. I do use Davmail, but only for the calendar 
side of things. One issue with calendar is I keep getting told that a 
calendar event had changed and it asks whether to discard or send any 
way, and that gets annoying. One day I'll take the time to figure out why.


I like that Thunderbird and the Lightning/calendar invites work 
together. At one point Thunderbird got an update and lightning stopped 
working, to the point that Thunderbird deactivated it. That sucked, so I 
used OWA access for a while and just now realized lightning had been 
updated so I reinstalled it. That is one problem with my email VM being 
off-line, in that Thunderbird can't check for updates automatically. 
That is a catch-22, but I still prefer to keep it this way. The less it 
can do on the network, more minimal its attack surface.



My setup:
Dedicated Email VM with Davmail installed. Davmail connects per OWA to 
our corporate Microsoft Exchange Server and acts as some kind of gateway 
to provide local SMTP/IMAP/CardDAV/CalDAV connections.
For emails I am running offlineimap which connects locally to Davmail 
and downloads all emails and creates a local maildir-repository.



Contacts and calendar entries are downloaded via vdirsyncer.


I had not heard of that, thanks. I'll look into that.

All content is now locally available in this Email-AppVM and can now 
also be used offline.

Within this VM I have setup:
For plaintext work:
- neomutt 

Re: [qubes-users] Re: Security questions (templates and kde)

[Mike Keehan]

On Wed, 7 Mar 2018 12:54:17 -0800 (PST)
Yuraeitha  wrote:

> 
> > I would love to hear how you divide your VMs up. I was looking for
> > examples online, but I couldnt find any; aside from an (ITL?) essay
> > I read last year. But starting easy and growing is good advice.   
> 
> Sure :)
> 
> I put some 6 to 7 launchers next to each others at the upper left
> corner. There are different ways to do this with Qubes in mind, for
> example two clean methods are to either put a single AppVM or similar
> AppVM's in a single launcher and then have multiple of launchers for
> different AppVM's, or instead put all browsers in a single launcher,
> all file-managers in another, all system tools and various VM
> terminals in another, music players and things like these in a mix
> launcher, work tools like libreoffice and similar in yet another one.

Thanks for that Yuraeitha!

I had been looking at editing the Qubes menu to sort it more to my
liking, and wasn't getting anywhere.  But your method of using xfce's
Launchers is just what I needed.  Five minutes work and now I have
a much better "menu" system.  Just what I want.

Thanks again,

   Mike.

-- 
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/20180308132121.27dc4323.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

[799]

Hello,

Am 06.03.2018 10:04 nachm. schrieb "Steve Coleman"

Because the SMTP infrastructure was not designed with compartmentalization
in mind, and I only get my one email account to work with, this single
"email" VM is highly isolated. It gets its own software locked down
configuration and is firewalled with a default-deny network policy. The
only services that this VM can get to on the network is the required SMTP
services, network authentication, and the necessary  signing key
management.  No internal websites, no external sites, only the email App
runs here. Well, Ok, the calendar too. Anyway, there should be no "phoning
home" from here, other than through per use 2fa outbound email. Should any
rouge malware be received, all attachments are first scanned and "tested"
in a DVM instance before being separated and pushed across to the
appropriate project VM for storage management. All project related
historical emails are then migrated to an off-line but searchable storage
by project. This specialized email VM essentially sorts, filters,
prioritizes, and bins any incoming data/mail for easy processing.


Do you mind writing some more details as I am interested how other people
solve the email problem.
Are you really separating email in different AppVMs?
Even when you said, that the VM can only connect per SMTP I assume that you
are not separating IMAP (incoming) and SMTP (outgoing) into two two VMs and
then moving emails from the incoming mail VM to the offline mail VM?
You have one VM which makes both IMAP and SMTP correct?
Which email/calendar client are you using and how do you move mails to
your  offline email VM?

My setup:
Dedicated Email VM with Davmail installed. Davmail connects per OWA to our
corporate Microsoft Exchange Server and acts as some kind of gateway to
provide local SMTP/IMAP/CardDAV/CalDAV connections.
For emails I am running offlineimap which connects locally to Davmail and
downloads all emails and creates a local maildir-repository.
Contacts and calendar entries are downloaded via vdirsyncer.
All content is now locally available in this Email-AppVM and can now also
be used offline.
Within this VM I have setup:
For plaintext work:
- neomutt - email client
- khal - calendar
- khard - adressbook
- notmuch - fast search

And as GUI email clients (connecting to the Davmail gateway / not using the
maildir-repository)
- Evolution
- Thunderbird

Unfortunately not everything works with the Davmail Gateway:
I can see the exchange Calendar in Thunderbird, but not the calendars of my
colleques. If I open a calendar entry I get an error.
On Evolution calendar is working much better as I can open and view the
details of an calendar entry, I can create and edit calendar entries -
everything is synced per Davmail to our corporate Exchange.
Strangely I can not delete calendar entries in Evolution.

With khal I can also view/edit my  calendar entries in the terminal.
Same for khard with my contacts.

Todo:
1) Check why I can add/edit calendar entries but not delete them

2) optimize handling of attachments that PDFs / Office documents / Weblinks
are always opened in a DVM.
I have been able to do this for Thunderbird but not yet for neomutt and
Evolution.

3) I'd like to integrate email and calendar into emacs org-mode, which I am
more and more using for PIM.

4) lock down EmailAppVM so that it can only access the Microsoft Exchange
Mailserver nothing more.
I would do so by running IPtables within the VM with a default
incoming/outgoing DROP policy only adding what is absolutely necessary to
get mail/contacts/calendar working with the Exchange server

I have also thought about separating email into more AppVMs but the
usability trade-off seems to high without gaining that much security.
As the Email AppVM only is used for email/calendar it should have the same
security level like our Exchange Server. If it gets compromise it doesn't
make a difference what I have setup in Qubes.

[799]

-- 
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/CAJ3yz2txubQV8-Btuxje%2BFvfT5aq8aLHdxjnBRhVBRkFOLz6bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Wednesday, March 7, 2018 at 9:05:51 PM UTC+1, sevas wrote:
> Cool. That gave me some ideas. Thanks for sharing your setup. 
> 
> So, another infosec question Im trying to figure out...
> 
> Templates Vs AppVMs. 
> 
> I find myself with, currently, 8 templates and growing. 
> This is because I am installing different programs in different VMs
> and Im not wanting to install all my programs into a single VM. 
> 
> Of course, one solution is to install all my programs into a single 
> templateVM and only enable the programs I need in the AppVM. 
> 
> But it seems more secure to me if I keep different templates for 
> different needs and then create a AppVM to run them in. Is this 
> good or am I wasting my time and hard drive space?
> 
> For instance I have a template specifically for one set of 
> sys-net/sys-firewall and another template for sys-net2/sys-firewall2. 
> And another the vault and more to come.

heck even dating is becoming a new huge business these days, especially with 
all these new tools and algorithms to pair people. It makes sense to make an 
AppVM for stuff like that too, don't use your phone for it, and stay clear of 
the advanced dating sites. 

This is a good example of data mining, where people might forget their privacy. 
It's essentially a gold mine for data mining, and we're probably gonna see huge 
industries in the coming years, privacy traded for love. It's a sad 
development. Nevertheless, AppVM's serves as a good use here too to minimize 
the profiling companies whom seek to profile everyone and know everything about 
you, so that they can sell your profile for profit to anyone who wants to buy.

-- 
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/e520a080-e584-420c-85e2-4cec51e1eb2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Wednesday, March 7, 2018 at 9:05:51 PM UTC+1, sevas wrote:
> Cool. That gave me some ideas. Thanks for sharing your setup. 
> 
> So, another infosec question Im trying to figure out...
> 
> Templates Vs AppVMs. 
> 
> I find myself with, currently, 8 templates and growing. 
> This is because I am installing different programs in different VMs
> and Im not wanting to install all my programs into a single VM. 
> 
> Of course, one solution is to install all my programs into a single 
> templateVM and only enable the programs I need in the AppVM. 
> 
> But it seems more secure to me if I keep different templates for 
> different needs and then create a AppVM to run them in. Is this 
> good or am I wasting my time and hard drive space?
> 
> For instance I have a template specifically for one set of 
> sys-net/sys-firewall and another template for sys-net2/sys-firewall2. 
> And another the vault and more to come.

I also made a launcher for all my Qubes scripts that I didn't keybind. They are 
definitely valuable for purposes like that as well :) You can also make scripts 
that sends commands into an AppVM from dom0, so essentially, you can securely 
control it from a secure domain, but also at the same time link keybinds in 
AppVM's to your keyboard or XFCE4 shortcuts. Scripting in Qubes is awesome. But 
be mindful of running dangerous or unknown scripts, they can do a lot of harm, 
in particular in dom0.

I suspect at some point we might be able to move scripts out of dom0 though, 
actually, it might even be possible now with USB keyboards? I'm not sure, I 
have to check that one day, it would definitely make scripts that control 
AppVM's more secure. But the issue here is probably the few scripts that 
control actions within dom0 though. For example changing screen resolution and 
move the screen to left or right, i.e. when plugging in an extra HDMI TV 
monitor or projector. This too might change in Qubes 4.1. as well when how 
graphics works in Qubes is changed. Well, there is definitely a lot of things 
to think about and reflect on, but that too in and on itself can be fun if you 
enjoy solving small puzzles like these.

-- 
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/9c1dd311-42a6-4f62-a631-9dd78bb1f1cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Tuesday, March 6, 2018 at 7:42:40 PM UTC+1, sevas wrote:
> I wasnt going to say anything... lol. But I was leaning towards debian. But 
> fedora. Thats Red Hat. They are the leading administrative suite as far as I 
> know. Or were. They must have good security or whos going to throw up a 
> server?
> 
> >In particular, Fedora's downfall is that its one of the very few distros
> >that don't sign/secure their overall software manifest; a MITM attacker
> >can prevent you from receiving specific bug fixes without you realizing
> 
> The above statement reminded me that it says that in the docs. And that does 
> seem like a make or break statement for template choices. Key signing is a 
> fine implementation on qubes. 
> 
> ha, I did read that one too about the ugly kde. 
> 
> @Yuraeitha
>  I havent quite tackled the security through compartmentalization part yet. I 
> have put some thought into it though, and after dividing my attack surface 
> between functions (keyring, passwords, misc files, etc) I realized that each 
> function has only one app to go with it. So I may as well just have one app 
> running in each VM. Or in the case of splitVMs, multiple apps for each 
> program!
> 
> I would love to hear how you divide your VMs up. I was looking for examples 
> online, but I couldnt find any; aside from an (ITL?) essay I read last year. 
> But starting easy and growing is good advice. 
> 
> >In particular, Fedora's downfall is that its one of the very few distros
> >that don't sign/secure their overall software manifest; a MITM attacker
> >can prevent you from receiving specific bug fixes without you realizing
> 
> The above statement reminded me that it says that in the docs. And that does 
> seem like a make or break statement for template choices. Key signing is a 
> fine implementation on qubes. 
> 
> @Tim W
> >Correct.  I have had both on and functioned fine.
> Thats good to know. I know I read somewhere that it was buggy with 3.2, I 
> think?
> 
> As far a attack surface goes, I like using konsole better than xterm or 
> uxterm and when installing that on debian or fedora, it required many 
> dependencies. I removed it, but Im going to take a second look.

> I would love to hear how you divide your VMs up. I was looking for examples 
> online, but I couldnt find any; aside from an (ITL?) essay I read last year. 
> But starting easy and growing is good advice. 

Sure :)

Before that I should probably mention how I initiate them too. From the 
beginning of using Qubes, I transitioned from the default Qubes XFCE4 menu to 
the Whisker menu, and then finally from the Whisker menu to a handful of 
Launcher plugins. I still use the Whisker menu, but only lightly for things I 
didn't put in the launchers. Both the XFCE4 launcher and the XFCE4 whisker menu 
plugins are included in Qubes 4 RC-2 and RC-3. I'm not sure about RC-4 and 
RC-5, but it's probably there too. Qubes 3.2. doesn't include Whisker menu, but 
it includes the Launcher. Also both Whisker menu and Launcher allows you to 
change icons, name and even the path to files. This gives you a LOT of 
flexibility. You can also easily add scripts to launchers or the whisker menu, 
but it's even more easy with the launcher because it essentially creates copies 
rather than linking to the original shortcuts. So if you for example take a 
random shortcut in launcher, and you edit it by changing the icon, name or the 
path, then it will not change the original shortcut. This is one of the reasons 
I like launcher's so much, though, not the only reason. It can also be done in 
a way that it looks very stylish if you're creative with it, and it's also much 
quicker to access your various of apps. Furthermore it's easier to keep track 
of all the Apps you use this way. Some of these might be subjective taste, 
others may apply to everyone. But give launchers or even whisker menu a try and 
see if it fits you after you modified them to fit your needs.

I put some 6 to 7 launchers next to each others at the upper left corner. There 
are different ways to do this with Qubes in mind, for example two clean methods 
are to either put a single AppVM or similar AppVM's in a single launcher and 
then have multiple of launchers for different AppVM's, or instead put all 
browsers in a single launcher, all file-managers in another, all system tools 
and various VM terminals in another, music players and things like these in a 
mix launcher, work tools like libreoffice and similar in yet another one. To 
add a finish to it, I changed the color to dark, and found some cool looking 
stylish icons free to download and use, i.e. from devianart. Only get the png 
or jpg formats, preferably png though. Moved them to an offline AppVM, and then 
selected some 15 at a time, and right clicked and used the convert to trusted 
img. Which is like using the qvm-convert-img command. This way you can remove 
exploits that might be hiding in pictures, and since it's an offline VM without 

Re: [qubes-users] Re: Security questions (templates and kde)

['awokd' via qubes-users]

On Wed, March 7, 2018 8:05 pm, sevas wrote:


> Of course, one solution is to install all my programs into a single
> templateVM and only enable the programs I need in the AppVM.
>
> But it seems more secure to me if I keep different templates for
> different needs and then create a AppVM to run them in. Is this good or am
> I wasting my time and hard drive space?

Excluding standalone, development, and Whonix VMs, I like a small, medium,
large approach to TemplateVMs.

Small- doesn't even need a desktop manager like GNOME; xterm only;
required utilities only for sys-* VMs

Medium- the standard fedora-26 or debian-9 template with a handful of
small utilities for password mgmt. etc., for most non-sys-* AppVMs

Large- Medium plus Java, Libreoffice, photo editing etc. AppVMs based on
this never get a network connection and are used for document mgmt.


-- 
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/cfe076599089b53bcfc1ac036fdcf834.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Security questions (templates and kde)

[sevas]

Cool. That gave me some ideas. Thanks for sharing your setup. 

So, another infosec question Im trying to figure out...

Templates Vs AppVMs. 

I find myself with, currently, 8 templates and growing. 
This is because I am installing different programs in different VMs
and Im not wanting to install all my programs into a single VM. 

Of course, one solution is to install all my programs into a single 
templateVM and only enable the programs I need in the AppVM. 

But it seems more secure to me if I keep different templates for 
different needs and then create a AppVM to run them in. Is this 
good or am I wasting my time and hard drive space?

For instance I have a template specifically for one set of 
sys-net/sys-firewall and another template for sys-net2/sys-firewall2. 
And another the vault and more to come. 

-- 
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/4a6275f8-6b6b-4ce4-89d6-a7a450162b98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Security questions (templates and kde)

[Steve Coleman]

On 03/06/18 13:42, sevas wrote:


  I havent quite tackled the security through compartmentalization part yet. I 
have put some thought into it though, and after dividing my attack surface 
between functions (keyring, passwords, misc files, etc) I realized that each 
function has only one app to go with it. So I may as well just have one app 
running in each VM. Or in the case of splitVMs, multiple apps for each program!

I would love to hear how you divide your VMs up. I was looking for examples 
online, but I couldnt find any; aside from an (ITL?) essay I read last year. 
But starting easy and growing is good advice.


Sevas, In case it gives you any ideas, here is how I "generally" do my 
own VM compartmentalization with two use-cases, work and home.



At Work:

One VM is specifically designated for "Internet" browsing, and it has 
every security plugin that I could find that offers any additional 
measure of security. That's of course a balance of risk, because 
somebody whom I do not personally know had to write that plugin. But 
again that's why I believe programs like IDA Pro and radare2 were 
written, for us insanely paranoid software geeks. In some rare cases I 
simply use a DVM for browsing the darker corners of the Internet, or for 
researching/checking any kind of untrusted URL's I might be weary of. I 
can't use whonix here so the DVM is the next best thing for this.


Each "project" I work on with any kind of "need-to-know" associated with 
it (specific contract, internal documents, preliminary research, 
Wan/Intranet search, timecards, etc) gets its own VM by default. Its 
better not to mix some things, so keeping them separate is often safer.


Because the SMTP infrastructure was not designed with 
compartmentalization in mind, and I only get my one email account to 
work with, this single "email" VM is highly isolated. It gets its own 
software locked down configuration and is firewalled with a default-deny 
network policy. The only services that this VM can get to on the network 
is the required SMTP services, network authentication, and the necessary 
 signing key management.  No internal websites, no external sites, only 
the email App runs here. Well, Ok, the calendar too. Anyway, there 
should be no "phoning home" from here, other than through per use 2fa 
outbound email. Should any rouge malware be received, all attachments 
are first scanned and "tested" in a DVM instance before being separated 
and pushed across to the appropriate project VM for storage management. 
All project related historical emails are then migrated to an off-line 
but searchable storage by project. This specialized email VM essentially 
sorts, filters, prioritizes, and bins any incoming data/mail for easy 
processing.



At Home:

Each member of the family gets one VM for the Internet. Personal email 
comes to each individuals account. These accounts are not used for any 
financial purposes.


One email account is used for household billing receipts and 
collecting/separating tax related documents, which may then get pushed 
to a "Vault VM" used for eventual tax preparations or long term archival 
storage. This VM gets limited use as it never browses the Internet and 
rarely ever sends email.


One VM is for general Purchasing, and is used only for that. You find 
what you want on the Internet then cut and paste the URL here. Its an 
intermediate level of security because credit cards have a limited 
personal financial obligation if the number gets away from you. Its very 
inconvenient if it does, but life does not end if that happens. Still 
you want to be cautious here by limiting your overall exposure to the 
Internet to just the sites you actually buy from.


One VM is for Banking and only that. No searching for anything, no 
email, nothing. If a bank account number gets away you re generally 
toast. Your not getting it back unless somehow you can claim it under 
some kind of insurance coverage. Its a much higher risk for loss and 
therefor needs to be treated as such.


One optional VM is allocated to general Investments monitoring, but it 
has no financial accounts associated with it. It only keeps track of 
numbers for things you want to monitor, and does financial computations. 
Basically its for planning retirement.  This is an idea I'm still toying 
with but have not settled on any particular set of tools, as I may be 
writing what I really want, but who has the time?


The Vault VM, with no network, meant for off line storage of important 
documents, before being archived off line in cold storage. Things like 
this years tax receipts might be a good example.



Steve.



--
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 

[qubes-users] Re: Security questions (templates and kde)

[sevas]

I wasnt going to say anything... lol. But I was leaning towards debian. But 
fedora. Thats Red Hat. They are the leading administrative suite as far as I 
know. Or were. They must have good security or whos going to throw up a server?

>In particular, Fedora's downfall is that its one of the very few distros
>that don't sign/secure their overall software manifest; a MITM attacker
>can prevent you from receiving specific bug fixes without you realizing

The above statement reminded me that it says that in the docs. And that does 
seem like a make or break statement for template choices. Key signing is a fine 
implementation on qubes. 

ha, I did read that one too about the ugly kde. 

@Yuraeitha
 I havent quite tackled the security through compartmentalization part yet. I 
have put some thought into it though, and after dividing my attack surface 
between functions (keyring, passwords, misc files, etc) I realized that each 
function has only one app to go with it. So I may as well just have one app 
running in each VM. Or in the case of splitVMs, multiple apps for each program!

I would love to hear how you divide your VMs up. I was looking for examples 
online, but I couldnt find any; aside from an (ITL?) essay I read last year. 
But starting easy and growing is good advice. 

>In particular, Fedora's downfall is that its one of the very few distros
>that don't sign/secure their overall software manifest; a MITM attacker
>can prevent you from receiving specific bug fixes without you realizing

The above statement reminded me that it says that in the docs. And that does 
seem like a make or break statement for template choices. Key signing is a fine 
implementation on qubes. 

@Tim W
>Correct.  I have had both on and functioned fine.
Thats good to know. I know I read somewhere that it was buggy with 3.2, I think?

As far a attack surface goes, I like using konsole better than xterm or uxterm 
and when installing that on debian or fedora, it required many dependencies. I 
removed it, but Im going to take a second look. 

-- 
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/674efcc2-48b2-4956-ae64-6fdcddbc8365%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Security questions (templates and kde)

[Amilton Justino]

Em segunda-feira, 5 de março de 2018 19:39:37 UTC-3, sevas  escreveu:
> Does choosing a TemplateVM have any tactical advantage to security?
> 
> 
> Does installing KDE have any tactical disadvantage to security?

Hello everyone
I agree with Chris Laprise: the choice of the model is not critical.
I use some distros in Qubes:
Debian, Fedora, Ubuntu, slackware, blackarch
More important than distro is their mindset for workflow, segmentation and 
security issues.

Thank you for the explanations Yuraeitha and Chris Laprise.

-- 
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/f1c11bf2-d6fa-4945-aabe-4e973f91adf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Security questions (templates and kde)

[Yuraeitha]

On Monday, March 5, 2018 at 11:39:37 PM UTC+1, sevas wrote:
> Does choosing a TemplateVM have any tactical advantage to security?
> 
> 
> Does installing KDE have any tactical disadvantage to security?

There are people more knowledgeable than I here, some much more, so I may be 
corrected on some points, but the overall picture should be correct.

First you would want to split up the comparison further first, for example the 
security that prevents an attacking from breaching fedora/debian/whonix and 
gain unauthorized access to dom0 "should" be about the same no matter which 
template you choose for your AppVM's, it should be the same hard to breach 
security. Of course an attacker would first have to breach an AppVM before they 
can try breach dom0, but the way I understand it, if dom0 can be breached, then 
so too can the AppVM's security which is supposedly easier to attack, than it 
is to attack dom0 from the VM. But having extra security in the AppVM won't 
harm and adds some extra layers of protection to dom0. If you're a low profile 
target, then it may not be worth the trouble for the attacker to get at you 
without some kind of pay-off or reward at the end. The more tricky you make it 
for them, with the less motivation incentives, the more secure you are. Of 
course making it too tricky might also serve as a challenge to be broken, so 
don't become a target by making yourself stand out as a challenge to be cracked 
either. Try mingle in the crowd, i.e. act the same way as other Qubes/Linux/WWW 
users do. It may also be worth it to hide that you're a Qubes user, or even 
that you're Linux user, whereever possible, so that you don't attract unwanted 
challenge attention.

As for the templates, Fedora has more frequent release cycles, while Debian is 
more slow release cycle based.

Debian - As far as I'm aware, the Debian Project Leader is voted on annually by 
a democratic community of developers and maintainers. Debian is more slowly 
releasing, and generally focus on stability and reliability.

Fedora - On the other hand, is acting like a test-bed for Red Hat Enterprise 
and CentOS, and release updates and new features quicker in order to test them 
out. Some of the leaders, including the Project Leader, are appointed by Red 
Hat, while seemingly a lot of the leadership is community based. 

In general it seems Debian relies on longer testing periods to ensure 
reliability, while Fedora puts in more effort and does it quicker. Which is 
best is probably a matter of which approach you deem more reliable. If you 
trust open source review, editing and testing, then debian is more reliable and 
secure. But if you trust experts to be able to put it together better than open 
source reviews can manage in a relatively short time-frame, then fedora is more 
secure. Generally the belief that many open source projects take time to 
review, which goes to say that Fedora can act quicker on issues than Debian can 
do, because Fedora is more centralized and focused, while Debian is more 
decentralized and community dependent.

Personally, I don't believe the open source aspect is always living up to its 
name, code is not always being reviewed and checked for errors and security 
flaws, and maybe some are so sophisticated that the reviwer don't see them 
until years later when someone else discoveres them, and in all that time 
in-between you have no idea if some skilled hackers, groups or organizations 
have used these exploits to their own gain and interest. More time won't 
nessicarily change open source code reliability and security, it also needs 
people actually looking at the code too, which is a given but often forgotten 
element. Fedora is in that sense better as more ressources are initially 
invested into the test-bed, but it still preserves the open source aspect as 
well for long-term open source reviews from third-parties. The pre-zero-day 
attacks disvocered from Fedora are also less likely to be spread wide and far, 
and may likely be exotic among the group of the very, very skilled 
hackers/orgnisations, but not so common-place on the internet. The odds of you 
being the target of a zero-day here is therefore less.

Debian also patch up security issuered discovered as time go on, but is as I 
understand it less quick to have their own code reveiwed, and features are 
slower released too. The stability is a strength towards Debian, security 
updates from third-party code is also quick, but the review of own code is 
likely not as fast as Fedora's. But with fedroa you have to sacrifice some 
stability, although not much, but some nonetheless.

It's an subjective evaluation, but honestly I feel fedora is more secure, while 
debian may be more stable, but in the end they are still somewhat close to each 
others in terms of security and reliability.

Of course beyond that, the normal firewall policy and security oversight 
implemented in normal Linux use-cases, should also be done in the Qubes