Offering salt help

[viq]

I'm somewhat experienced with salt, are there any areas where additional set of eyes/hands would be useful?

Sorry, my python skills are slowly approaching what could be called "basic", so don't count on much from that side.

--

viq

[Chris Laprise]

For one, I think a lot of us who have encountered salt in Qubes feel
stymied by its organization and syntax, and would appreciate some help
in gaining traction with it. The official salt resources are of little
assistance.

Something I'd like to do in particular is a salt recipe for setting up
VM sudo/pam configuration. Also explore if its useful for configuring VPNs.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Thierry Laurion]

I think the best would be per example. That would help me, and I'm pretty sure it would help others.

QubesOS decided to document changes for specific threat models/needs. Here are some examples:

1. randomized mac configuration for NetworkManager is not deployed per under sys-net. It requires a simple file drop in. See here: https://www.qubes-os.org/doc/anonymizing-your-mac-address/
2. Discard flush was not implemented per default, which consumes spaces without reasons.  Making sure it is deployed would be awesome. https://www.qubes-os.org/doc/disk-trim/

Going around and implementing the examples given in configuration guides and creating salt formulas for them would be awesome. I haven't wrapped my head about the best way to do this. Enabling a top file would make it deployed next run? So it is better to compartmentalize changes by needs?

Any insight would be helpful! Providing a pull request in either SkyLab/QubesOS giving links to Qubes applied examples would help the larger community for sure!

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a417377a-c62b-23e4-0e5b-f3cfdef3ad48%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[viq]

What you're asking about ties into my question on qubes-devel https://groups.google.com/d/msgid/qubes-users/CALF8MVFrdUM4LoR-FD3pT3MRrLHBRRYNVHdxjYdoTEkKCQQc%3Dw%40mail.gmail.com

I'll have a look at showing some examples of what you're talking about. 

[viq]

Of course I meant qubes-users https://groups.google.com/forum/#!topic/qubes-users/PtzhBZ8pT4w

[awokd]

On Thu, April 19, 2018 8:50 pm, Chris Laprise wrote:
> On 04/19/2018 04:22 PM, viq wrote:
>
>> I'm somewhat experienced with salt, are there any areas where
>> additional set of eyes/hands would be useful?
>>
>> Sorry, my python skills are slowly approaching what could be called
>> "basic", so don't count on much from that side.
>> --
>> viq
>
> For one, I think a lot of us who have encountered salt in Qubes feel
> stymied by its organization and syntax, and would appreciate some help in
> gaining traction with it. The official salt resources are of little
> assistance.
>
> Something I'd like to do in particular is a salt recipe for setting up
> VM sudo/pam configuration. Also explore if its useful for configuring
> VPNs.

Friendlier documentation would be nice too:

https://www.qubes-os.org/doc/salt/
https://github.com/QubesOS/qubes-issues/issues/1983

[Thierry Laurion]

Sorry. Didn't get you were talking about architectural changes.

On my side, I deploy salt formulas from this project I decided to start contributing to in the goal of facilitating deployment.

It implies that you run your git environment and do the development in a specific VM, and syn your changes on dom0 from it before deployment.

 https://github.com/SkypLabs/my-qubes-os-formula/blob/master/copy-from-vm-to-dom0.sh

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a7a314d27787d13efcb7e1adce3eb71e.squirrel%40tt3j2x4k5ycaa5zt.onion.

[Patrick Schleizer]

viq:

The release of Whonix 14 is currently blocked due to missing salt files.

Qubes-Whonix 14 SaltStack state files required

https://github.com/QubesOS/qubes-issues/issues/3765

If you could help out with that one, that would be amazing!

Cheers,
Patrick

[viq]

I started looking at it, which led me to anon-whonix state [0] and
related, and unless I'm missing something the first, simplest, naive
approach would be to append "-14" to all references of templates,
something like this commit [1]. Which seems way too simple, so please
tell me what am I missing besides the "we want to control it via a
variable" :)

As a side note, while it may be late for that, I think I'd prefer to have
DVM name be closer to AppVM names than template names. When we'd have eg
whonix-ws-14 and based on in anon-whonix, DVM for me should be named
anon-whonix-dvm, and not whonix-ws-dvm. Or should it be
whonix-ws-14-dvm, and anon-whonix preference for DVM adjusted when we
get whonix 15?

[0] https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/anon-whonix.sls
[1] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/857ee77adef6ce970b5d2948804ff04928164525

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, May 03, 2018 at 03:22:53PM +0200, viq wrote:
> On 18-04-26 08:01:00, Patrick Schleizer wrote:
> > viq:
> > > I'm somewhat experienced with salt, are there any areas where additional
> > > set of eyes/hands would be useful?
> > >
> > > Sorry, my python skills are slowly approaching what could be called
> > > "basic", so don't count on much from that side.
> > >
> >
> > The release of Whonix 14 is currently blocked due to missing salt files.
> >
> > Qubes-Whonix 14 SaltStack state files required
> >
> > https://github.com/QubesOS/qubes-issues/issues/3765
> >
> > If you could help out with that one, that would be amazing!
>
> I started looking at it, which led me to anon-whonix state [0] and
> related, and unless I'm missing something the first, simplest, naive
> approach would be to append "-14" to all references of templates,
> something like this commit [1]. Which seems way too simple, so please
> tell me what am I missing besides the "we want to control it via a
> variable" :)

I think it's that simple. But as you've said, better add pillar for
that, so one could easily switch later to 15 or so.

Thanks for looking into it!

> As a side note, while it may be late for that, I think I'd prefer to have
> DVM name be closer to AppVM names than template names. When we'd have eg
> whonix-ws-14 and based on in anon-whonix, DVM for me should be named
> anon-whonix-dvm, and not whonix-ws-dvm. Or should it be
> whonix-ws-14-dvm, and anon-whonix preference for DVM adjusted when we
> get whonix 15?
>
> [0] https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/anon-whonix.sls
> [1] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/857ee77adef6ce970b5d2948804ff04928164525
>

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlrrD+YACgkQ24/THMrX
1yw8uQf5Aac/od0nVbzgA2a9dAg+G/ugEDbTZJlRj6xpOuOdqTSE8Cpv7KbfgIgc
2T0dYwpbSpIjgiAV8ajWvOC8Fp2eNiroEcrS27eDEiFMSO+M1gp5RVgg7QSMUif1
C2m3V/boh/Jfu1wvRryfIyhMk9bOE5GeP9vHPg41Bdzzc7sEAOfSH5KBa3WBSG1w
OG13oJE5yISrzCd5BuRi0K1PI1LqRcJkt1rHdH+W+rgY0L+IOd4l6ttsigFMXzGZ
jof0lpPPiZjKb4Sh3clXrY1tNTg8q/b1Bt5Lq4B4GKy1SUziNtbUtZlkTrJEnTL3
X46JOMuYVYaCLhyvG7LtjCT6qbh9eg==
=Jeso
-----END PGP SIGNATURE-----

[viq]

On 18-05-03 15:34:31, Marek Marczykowski-Górecki wrote:
> On Thu, May 03, 2018 at 03:22:53PM +0200, viq wrote:
> > On 18-04-26 08:01:00, Patrick Schleizer wrote:
> > > viq:
> > > > I'm somewhat experienced with salt, are there any areas where additional
> > > > set of eyes/hands would be useful?
> > > >
> > > > Sorry, my python skills are slowly approaching what could be called
> > > > "basic", so don't count on much from that side.
> > > >
> > >
> > > The release of Whonix 14 is currently blocked due to missing salt files.
> > >
> > > Qubes-Whonix 14 SaltStack state files required
> > >
> > > https://github.com/QubesOS/qubes-issues/issues/3765
> > >
> > > If you could help out with that one, that would be amazing!
> >
> > I started looking at it, which led me to anon-whonix state [0] and
> > related, and unless I'm missing something the first, simplest, naive
> > approach would be to append "-14" to all references of templates,
> > something like this commit [1]. Which seems way too simple, so please
> > tell me what am I missing besides the "we want to control it via a
> > variable" :)
>
> I think it's that simple. But as you've said, better add pillar for
> that, so one could easily switch later to 15 or so.

OK, then an attempt at doing that in another commit [2]. I tried to make it
so that the default version ("14") could be changed in one spot, I'm not
certain that adding to the load macro is the right spot - or is it?
Also, I realised I'm most likely not using it correctly, thus [3], but I
think a single place to define the default version instead of
{{ salt['pillar.get']('qvm:whonix:version', '14') }} throughout multiple
files would be better.

> Thanks for looking into it!
>
> > As a side note, while it may be late for that, I think I'd prefer to have
> > DVM name be closer to AppVM names than template names. When we'd have eg
> > whonix-ws-14 and based on in anon-whonix, DVM for me should be named
> > anon-whonix-dvm, and not whonix-ws-dvm. Or should it be
> > whonix-ws-14-dvm, and anon-whonix preference for DVM adjusted when we
> > get whonix 15?

Part of my modifications creates whonix-ws-{{ version }}-dvm

> > [0] https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/anon-whonix.sls
> > [1] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/857ee77adef6ce970b5d2948804ff04928164525

[2] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/4b7a07ba8e4b1e5f4aa458a9d2a586bd6730340f
[3] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/dc5cbf32942548c5753824afce8875c2063b1ef9

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Template processing order probably is wrong in [2] -
defaults.whonix_version is defined only in `load` function, but you try
to use it while defining `defaults`.

> but I
> think a single place to define the default version instead of
> {{ salt['pillar.get']('qvm:whonix:version', '14') }} throughout multiple
> files would be better.

I think you can create a single helper file with just {% set
whonix_version ... %} and include it wherever you need.

> > Thanks for looking into it!
> >
> > > As a side note, while it may be late for that, I think I'd prefer to have
> > > DVM name be closer to AppVM names than template names. When we'd have eg
> > > whonix-ws-14 and based on in anon-whonix, DVM for me should be named
> > > anon-whonix-dvm, and not whonix-ws-dvm. Or should it be
> > > whonix-ws-14-dvm, and anon-whonix preference for DVM adjusted when we
> > > get whonix 15?
>
> Part of my modifications creates whonix-ws-{{ version }}-dvm
>
> > > [0] https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/anon-whonix.sls
> > > [1] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/857ee77adef6ce970b5d2948804ff04928164525
> [2] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/4b7a07ba8e4b1e5f4aa458a9d2a586bd6730340f
> [3] https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/dc5cbf32942548c5753824afce8875c2063b1ef9

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlrrMb4ACgkQ24/THMrX
1yyz3gf/Zc+RK2thRB41gnFZFKv3kHaYsRciIyjoAYnH6RVnfulivnb80vz6T9bI
IwIyArKUWWzobOeOdwVT2UkxGurKQXJboeYQTOk14DDvYfQGT9+QAUi2L5SDRt+L
Y63FGt8ibW0tWzv8R32cMh9CMSprS5HIwCXaxW1ExxS1mljCMMA6PQtbDeGWfinY
Q+EEZLIwTFQnnEDkV8xeh9DLzSLJoRWYiQPUhy4j346dCuRCvG9vP9euDsHHL9tq
7biPYg0bGU1DzOTbhqwN+B5/7R73FERCGQSkn6zbFPovxfxlMh5ZOB4Be1bz9O/Y
1wj3nHf5j4ZdfMT6a8ZqMY0VMPRDZQ==
=ZCBt
-----END PGP SIGNATURE-----

[Patrick Schleizer]

viq:

> As a side note, while it may be late for that, I think I'd prefer to have
> DVM name be closer to AppVM names than template names. When we'd have eg
> whonix-ws-14 and based on in anon-whonix, DVM for me should be named
> anon-whonix-dvm, and not whonix-ws-dvm. Or should it be
> whonix-ws-14-dvm, and anon-whonix preference for DVM adjusted when we
> get whonix 15?

This would be a general Qubes discussion. Whatever convention is default
in Qubes, Qubes-Whonix would follow.

I am not sure, but I think it was discussed before and decided to go
with the "close to TemplateVM" naming rather than "close to AppVM"
naming style. I personally don't have a preference here. It's a bit
difficult/confusing so or so.

Cheers,
Patrick

[viq]

On 18-04-20 01:14:56, Thierry Laurion wrote:
> I think the best would be per example. That would help me, and I'm pretty
> sure it would help others.
>
> QubesOS decided to document changes for specific threat models/needs. Here
> are some examples:

I was thinking some about those, and they are somewhat tricky to
automate.

> 1. randomized mac configuration for NetworkManager is not deployed per

> under sys-net. It requires a simple file drop in. See here:
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/

This requires modification to a template that sys-net is based on. I
don't know how to automate the detection of that. Ways to go about it
that I see is either allowing user to configure which template to act
on, or placing this file in ALL templates.

> 2. Discard flush was not implemented per default, which consumes spaces

> without reasons. Making sure it is deployed would be awesome.
> https://www.qubes-os.org/doc/disk-trim/

This one's a bit tricky for another reason:
"Add (...) to kernel cmdline (follow either GRUB2 or EFI, not both):"
I don't know how to detect which way the system was booted, so again it
would be up to the user to configure where the change is to happen.

> Going around and implementing the examples given in configuration guides
> and creating salt formulas for them would be awesome. I haven't wrapped my
> head about the best way to do this. Enabling a top file would make it
> deployed next run? So it is better to compartmentalize changes by needs?

Yeah, currently the approach seems to be to enable particular formulas
is the master_tops system, and then a highstate will ensure that all are
true.

Which also ties in with another thing I was thinking about. Currently a
lot of states use file.prepend[1] to put text in a file. My sysadmin
experience keeps yelling at me to use instead file.accumulated[2] to
combine together all the pieces, and then manage the whole file with
file.managed[3] - but that would wipe any manual modifcations. Which for
me is a good thing, but not everyone may agree.

> Any insight would be helpful! Providing a pull request in either
> SkyLab/QubesOS giving links to Qubes applied examples would help the larger
> community for sure!

[1] https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.prepend
[2] https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.accumulated
[3] https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.managed

[viq]

On 18-04-20 01:14:56, Thierry Laurion wrote:

> I think the best would be per example. That would help me, and I'm pretty
> sure it would help others.
>
> QubesOS decided to document changes for specific threat models/needs. Here
> are some examples:
>

> 1. randomized mac configuration for NetworkManager is not deployed per

> under sys-net. It requires a simple file drop in. See here:
> https://www.qubes-os.org/doc/anonymizing-your-mac-address/

So I believe this would look something like https://github.com/viq/qubes-mgmt-salt-dom0-virtual-machines/commit/02738ed385eda797a42b77ce83f3f3e36ddee902
No, I did not test it, and I'm not sure how to tie it in with the
master_tops system, as the other *.top files present in this directory.

> 2. Discard flush was not implemented per default, which consumes spaces