Thoughts about installed software

[Robert Mittendorf]

Software that you don't need is a security risk as it imposes additional
attack surface - we all know that.
Besides exploits those tools might cause additional threat (e.G. RDP-
VNC-, SSH-Clients)
So you better do not install non-universal software* in a template VM.
*software that is not needed in every VM which is based on that template

So where to put non-universal software?

- user-space: allows malware to persist easily, because of persistent
write rights. And does not allow usage of standard repositories
- other (cloned) TemplateVM: You need to make sure that you keep all
templates up-to-date for security reasons, you need much more storage
space and cause more ssd aging

So what about a multi-level template system. That way you can keep at
least most software up-to-date with a single update process. This would
need a delta-filesystem instead of the current image=directory approach
i think. I don't know whether Xen has such capabilities?!

Robert

[Drew White]

Hi Robert,

Do you think you could build a template that would be that which you would consider secure?

Personally, I've been asking what packages are REQUIRED for full integration, and never gotten an answer that provides the information I request from anyone, not even the qubes devs.

I'm not sure if they don't know, or just think that the information is there when it isn't, but if you are able to build a secure template, one that is based for Qubes and works properly and fully, then you should do it and give it to them to put into the template repo.

I think it would be interesting if you could actually do it, rather than these insecure systemd templates.

[Manuel Amador (Rudd-O)]

On 10/12/2016 12:26 AM, Drew White wrote:
> Hi Robert,
> Do you think you could build a template that would be that which you would consider secure?
>
> Personally, I've been asking what packages are REQUIRED for full integration, and never gotten an answer that provides the information I request from anyone, not even the qubes devs.

All the packages in the template that are named qubes-* are required for
full integration. Additionally, NetworkMAnager, NetworkManager-wifi and
NetworkManager*fedora are also required for NetVMs to operate correctly.

The Fedora minimal template works fine as a very minimal base system.
Those NetworkManager packages are needed to use it as a sys-net template.

>
> I'm not sure if they don't know, or just think that the information is there when it isn't,

Of course they know. They build the templates. It's just that this
question is a low-priority question because this is something you could
have found out yourself.


--
Rudd-O
http://rudd-o.com/

[Drew White]

On Wednesday, 12 October 2016 11:30:27 UTC+11, Manuel Amador (Rudd-O) wrote:
> On 10/12/2016 12:26 AM, Drew White wrote:
> > Hi Robert,
> > Do you think you could build a template that would be that which you would consider secure?
> >
> > Personally, I've been asking what packages are REQUIRED for full integration, and never gotten an answer that provides the information I request from anyone, not even the qubes devs.
>
> All the packages in the template that are named qubes-* are required for
> full integration. Additionally, NetworkMAnager, NetworkManager-wifi and
> NetworkManager*fedora are also required for NetVMs to operate correctly.

So what do those packages require as dependancies though?
The dependancies are also required for full integration.
Just saying, there is more than just "qubes-*" to be thinking about.

> The Fedora minimal template works fine as a very minimal base system.
> Those NetworkManager packages are needed to use it as a sys-net template.

The Fedora minimal template is FAR from minimal. It still contain a lot of things it shouldn't, and is missing vital things too.

> >
> > I'm not sure if they don't know, or just think that the information is there when it isn't,
>
> Of course they know. They build the templates. It's just that this
> question is a low-priority question because this is something you could
> have found out yourself.

No, it's not a low-priority question, I was told that they didn't know. I can find the thread where they told me, if you want, or else you can search qubes-users for it.

[Robert Mittendorf]

Well, the discussion leaves the focus I intended it to have.
It is surely worth thinking about what a minimum templates needs to have.
Nevertheless I think Qubes is about "I know I can get exploited, so just
protect the other parts of the system". Afaik a normal Qubes template
has only the root user, so after an exploit the attacker is root in that
VM right?

My thoughts are more about continuing the attack to other QubesVMs or
even other systems by means of installed Software like a VNC client.

[pleo...@gmail.com]

https://www.qubes-os.org/doc/vm-sudo/ you can configure root account during instalaton process.If you want to have more secure apps then maybe use SElinux| Apparmor for additional security layer.

[Manuel Amador (Rudd-O)]

On 10/12/2016 05:25 AM, Drew White wrote:
>
> So what do those packages require as dependancies though?
> The dependancies are also required for full integration.
> Just saying, there is more than just "qubes-*" to be thinking about.

Are you trolling me with this question? Installing those qubes* packages:

* automatically shows you the dependencies on screen
* automatically installs the dependencies

The recursive dependency information is trivial to discover.

--
Rudd-O
http://rudd-o.com/

[7v5w7go9ub0o]

On 10/11/2016 09:30 AM, Robert Mittendorf wrote:
> Software that you don't need is a security risk as it imposes
> additional attack surface - we all know that.
> Besides exploits those tools might cause additional threat (e.G. RDP-
> VNC-, SSH-Clients)
> So you better do not install non-universal software* in a template VM.
> *software that is not needed in every VM which is based on that template
>
> So where to put non-universal software?
>
> - user-space: allows malware to persist easily, because of persistent
> write rights. And does not allow usage of standard repositories
> - other (cloned) TemplateVM: You need to make sure that you keep all
> templates up-to-date for security reasons, you need much more storage
> space and cause more ssd aging

Interesting!!

Since r2.x, I've run each of my user apps in individual, dedicated,
dynamically-configured DispVMs; using scripts that: start up a new
DispVM, copies the application-specific files from the vault into the
DispVM; runs the application, copies any updated data (data only) back
from the DVM to the folder in the vault; discards the DVM. Of course the
vault remains offline, and programs are never invoked within the vault;
it is used exclusively to store data that is accessed safely in dispvms.

If a DVM becomes compromised or corrupted I simply dispose of the DispVM
and start anew. No worries about quiet infections of appvm user files,
as only updated data (in most cases txt files) is retained from the
DispVM back to the vault.

After your OP, it dawns on me that one could devise similar scripts to
start up a "barebones" DVM, dynamically modify it to be a dedicated
application DVM by copying both the application files AND the necessary
system (app) files into that DVM. Run the app; copy any updated data
(data only) back into the vault, and discard the DVM. (This is trivial
with some apps; e.g. keepassx; but could be involved with big
complicated apps)

This would keep the DispVMs smaller, and as you point out, with fewer
attack surfaces.

This would require two AppVMs: a "barebones" DVM (As per Rudd-O's
"minimal" point, I'll likely use the Qubes default with Firefox system
and FF "user" files installed), and a second AppVM containing and
maintaining the system and user application files - it would be brought
online only for the purpose of package manager updating.

I plan on testing/configuring this way with r4.x. Thank You for the OP.

[Robert Mittendorf]

Interesting idea. However I would not use the "move to VM" command like
this, as I experienced those requests getting lost One time files were
actually deleted, since that time I always use copy instead of move.
This is a problem with Linux (package based setup, dependency hell) - in
Windows you can run most Tools from their folder which you can place
anywhere you like. They may create files in other places (like the
registry), but they mostly run on a system they are copied to.

Depending on how you copy malware still might be able to persist. I
think about a browser extension, for example.

Robert

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Robert,

> However I would not use the "move to VM" command like this, as I
> experienced those requests getting lost One time files were
> actually deleted, since that time I always use copy instead of
> move.

Sounds troubling. Do you remember the last Qubes release version
where you experienced this kind of data loss?

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJX/kvQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfZA0P/0vw2dBijUk6vZtmWgsGzL/B
3l+H7KcVXu7zPzjEMwQAdufC0gn2JG8NVWH7HHe6ru42iME07JNww1RoOvwImq4h
/u8DojH7PYeO88TlmCquH9J9nxF7W6+LC0nEtsTAbEF0dxUUfHFL9MyOKGoU/nq+
JU78lKBfFstUCtcqib1J0ENAsRbY6oPj+XaAqkOGvX9uTqWPslUmncEstn4KXzIy
M8b86Vql3WJ0fJgYdVxrLzuFgbMHUIjk4vfv2dNGwQHaDYXA25wM9jdV9FbED0mk
pL6VTMwRHA5SCnXaTjHRJzS7+x/vOEGhNiwkyR5bpXiaHrxer3MmszC+oIgXuiXC
yWthLHJ/fqrZjSjClrLYlQbCiD5gz6tWsul8KSzAGh56vMVsfXghHs4QIcNv61xp
tfnQg4ESBtHLc3+LuDQRax6kkJVMCwX4s1KQQ3v6t8os7w/HBIBdkVHWkRBVKywu
8d/L2meN76DYyTsopjN5EfVOQ+/53dbTiUf+FTsl2ENM0yb6D8FcdgPm44XP9iE/
5eiWcKazFvFYs9wOxXrs+Ej8aw6WW5mBTeoRoC+jSxTmA4nPoTAjHT6aSwwnCTvM
MMtWk68WPbHic4ISDLl8X3OJCUjD6Yiar6Q5DoWWfwVGQZek/EVs/LwoCRhkSMn6
4E8tGXUwqvA9ADx9k/cL
=tp0q
-----END PGP SIGNATURE-----

[7v5w7go9ub0o]

Dang! Right you are - I miss-wrote! I do indeed copy; e.g.:

qvm-run -q --pass-io vault 'tar -c -f - keepass' | qvm-run --pass-io $x
'tar -x -f -'

(where $x is the newly-created DispVM.)

So I'll add an additional, similar command that would copy the system
executable (e.g. keepassx) to the DVM, and instead of executing an
installed app - which I do now:

qvm-run -q $x 'keepassx /home/user/keepass/keepass.kdb' &

I'd start executing a recently-copied app; e.g. something like (./ may
not be needed):

qvm-run -q $x './home/user/keepass/keepassx
/home/user/keepass/keepass.kdb' &

Don't know how much this will save me, as I don't have a lot of "stuff"
installed, but it should reduce DVM size and attack surface (at the
acceptable cost of dynamically creating DVMs before executions).



In terms of browser extensions, I think they *ARE* an issue, and I
routinely copy only places.sqlite back to the vault; the rest of the DVM
is discarded.

IF I do want to update extensions, then I'll start the FF DVM, update
extensions, ublock, etc.; copy the whole shebang back to the vault; and
then shutdown - without exposing FF to anything else.

[Manuel Amador (Rudd-O)]

From a perspective of the current minimal template, the template needs:

* NetworkManager
* NetworkManager-wifi
* network-manager-applet

My manifest here says you must delete
NetworkManager-config-connectivity-fedora. I don't remember what that
package does.


--
Rudd-O
http://rudd-o.com/

[Drew White]

Yes it does, but what else does it need that I have installed that it won't tell me BECAUSE the things are ALREADY INSTALLED?

That's the rest of it...
I want to know what it all is, not just what I don't have.

Does that make sense now?

[Drew White]

On Wednesday, 12 October 2016 19:50:10 UTC+11, Robert Mittendorf wrote:
> Well, the discussion leaves the focus I intended it to have.
> It is surely worth thinking about what a minimum templates needs to have.
> Nevertheless I think Qubes is about "I know I can get exploited, so just
> protect the other parts of the system". Afaik a normal Qubes template
> has only the root user, so after an exploit the attacker is root in that
> VM right?

By Default, yes, unless you actually secure your templates properly.
If you secure the templates, they would have a very very very hard time even thinking about getting root access in a template.

> My thoughts are more about continuing the attack to other QubesVMs or
> even other systems by means of installed Software like a VNC client.

In general, they can't.
Unless you are meaning gaining access via the Dom0 passthru system where you can copy files to other vms?
Or unless you are using an InterVM machine, like I do. But I only ever allow the ports I require to be used at that time. I do have one area that is set up as a complete, but they can only talk to each other, nothing else.

So if you configure Qubes correctly, including the VMs, it will be very difficult to actually attack other VMs in the way I think you may be thinking it's easy?

[Manuel Amador (Rudd-O)]

On 10/13/2016 12:31 AM, Drew White wrote:
> On Thursday, 13 October 2016 00:39:04 UTC+11, Manuel Amador (Rudd-O) wrote:
>> On 10/12/2016 05:25 AM, Drew White wrote:
>>> So what do those packages require as dependancies though?
>>> The dependancies are also required for full integration.
>>> Just saying, there is more than just "qubes-*" to be thinking about.
>> Are you trolling me with this question? Installing those qubes* packages:
>>
>> * automatically shows you the dependencies on screen
>> * automatically installs the dependencies
>>
>> The recursive dependency information is trivial to discover.
>
> Yes it does, but what else does it need that I have installed that it won't tell me BECAUSE the things are ALREADY INSTALLED?

Like I said, trivial to discover. Literally first answer on Google:

https://stackoverflow.com/questions/16843928/is-there-any-way-to-retrieve-a-dependency-tree-from-yum

# repoquery --requires --recursive --resolve <RPM>

Wow, such hard, many work.

--
Rudd-O
http://rudd-o.com/

[094142174178942479]

Hello,

sounds quite interessting :-)

How would be a encrypted software-database. Inside are all compressed folders, pathes and files and if you run some app, it will payed in this DVMs?

Nice would be, if the protocols and logs get played back inside this database. And they are also compressed and enrypted.

In the end you have an database, which maintain all the running coding, configurations and security-logs (So AppArmor can be used to see the good or bad behaviors).

Kind Regards

[193840242421424214249]

Hello,

how I found out, if the minimal Templates D8 or F22 will contain only "exploit proof" applications, which support all ASLR - against code injection - like the browsers?

Or if not, how can I build an ASLR D8 template for Qubes?

Kind Regards

[097403710470970q970q97w89]

Template VM Hierachy?

Was still some topic (and would meet the user logic to design more foundation TVM's and higher specific TVM's on top of them)...

https://groups.google.com/forum/#!searchin/qubes-users/vm$20hierachy%7Csort:relevance/qubes-users/iLJjTTQqgrw/-0OG1jrZPgAJ

[Jeremy Rand]

Rusty Bird:

> Hi Robert,
>
>> However I would not use the "move to VM" command like this, as I
>> experienced those requests getting lost One time files were
>> actually deleted, since that time I always use copy instead of
>> move.
>
> Sounds troubling. Do you remember the last Qubes release version
> where you experienced this kind of data loss?
>
> Rusty

In Qubes 3.0, I noticed that source files for the "move to VM" command
would be deleted even if the move failed due to insufficient disk space
in the destination VM. (It goes without saying that this is a Very Bad
Thing.) I'm not sure if this is still the case in newer releases of Qubes.

Cheers,
-Jeremy

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Jeremy!

> In Qubes 3.0, I noticed that source files for the "move to VM"
> command would be deleted even if the move failed due to
> insufficient disk space in the destination VM. (It goes without
> saying that this is a Very Bad Thing.)

That was fixed in R3.1:
https://github.com/QubesOS/qubes-issues/issues/1355

> I'm not sure if this is still the case in newer releases of Qubes.

I don't think it is. There's also another commit somewhere to call
syncfs() after copying. So qvm-move-to-vm *should* be safe since R3.1
(unless the destination VM was debian-7 based, which had an old glibc
without syncfs() support).

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJYAJr5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfMj4P/0g3dif0bYm1fYO3E3Cs+zQC
GtsFZX6As/7XL+RliVDK0GB7c9XuB0ycaXCbcnu3uNNhknm76wEkxkAe3Gq4dxPC
t/NDwTQY0oSzlOxYrJ8jAqWUWSfe4buSecV+u5vC2iKO0UrGe8YIEZvM2+YhpsQT
FOdKSNUvw4MJqy9xmjeYLtH6wtWzJyEN2B9n+yVScpTaA1MBO5WnmTu3pts1WmjT
iUVHNr84Qzf/rcZnZIfTYThH+HSA8gJgN/RAeOE9ghzyEzcKkrznPWyMSuaW8SmO
FW+djKx6lTOcJKg50BJHH/aSwrJxnIfIa1MtoLseMPEsDf+UHcAY6ASKRROt+7pn
v9ORB/uB/uERBigik1yd9bAivauqqLbi8Dj7hBwc4XteEikvVUXAsOsEJl7lmaC1
I7Wzb8YXxvEAyJFINXItK5ZJT1x0D/5m+07oKD5oBf8aNY8CFHTEPUUQFmTQLOId
XZg/pBhIOpmIsx3z+Zk3+VJCIz7tzR9BpRCAvN8FOZPs5HEG4Hu914Eb01ErwDE3
keM5Bu1mW/HsGcAvnXBGLfQ6MtFFmdNoqbS5Jrj2cv0q/9yGPmf44u4NqTNbQiAu
mlqKx+8mx6H5/EBagZKNxVmFqUy+ShpsIhro9VlHaCoNF21ttjOr8/B4zaPb2igx
9SChvvIPXA5HKfR4FK5H
=Bj5/
-----END PGP SIGNATURE-----

[Robert Mittendorf]

>> However I would not use the "move to VM" command like this, as I
>> experienced those requests getting lost One time files were
>> actually deleted, since that time I always use copy instead of
>> move.
> Sounds troubling. Do you remember the last Qubes release version
> where you experienced this kind of data loss?

> [...][...]

> qvm-move-to-vm *should* be safe since R3.1
> (unless the destination VM was debian-7 based, which had an old glibc
> without syncfs() support).
>
> Rusty

3.1 - but I dont remember src & dest types

>> My thoughts are more about continuing the attack to other QubesVMs or
>> even other systems by means of installed Software like a VNC client.

> But I only ever allow the ports I require to be used at that time. I do have one area that is set up as a complete, but they can only talk to each other, nothing else.
>
> So if you configure Qubes correctly, including the VMs, it will be very difficult to actually attack other VMs in the way I think you may be thinking it's easy?

Good point, Drew. The problem is reduced significantly if you reduce the
firewall exceptions to a minimum.