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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20180507203046.75237vrlizejcogb%40hirauchi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to