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
>    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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20180513200200.62akvwphdg7iklv4%40hirauchi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to