Require script to run immed. after /rw mount

[Chris Laprise]

I am trying to setup templates so the startup sequence in template-based
VMs can take action on /rw contents before they can affect the execution
environment (bind-dirs, rc.local, etc).

Unless there is a setting for this (disabling startup execution of
private.img contents) that I'm not aware of, I think some modification
of Qubes would be necessary to properly enable such action. This is
because currently bind-dirs.sh activation is lumped-in with mount-dirs.sh.

My suggestion would be to put the activation of qubes/init/bind-dirs.sh
under a separate systemd service. Alternately, mount-dirs.sh could have
a hook that points to a specific user script in /etc.

--

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

[Chris Laprise]

On 04/14/2017 12:18 PM, Chris Laprise wrote:
> I am trying to setup templates so the startup sequence in template-based
> VMs can take action on /rw contents before they can affect the execution
> environment (bind-dirs, rc.local, etc).
>
> Unless there is a setting for this (disabling startup execution of
> private.img contents) that I'm not aware of, I think some modification
> of Qubes would be necessary to properly enable such action. This is
> because currently bind-dirs.sh activation is lumped-in with mount-dirs.sh.
>
> My suggestion would be to put the activation of qubes/init/bind-dirs.sh
> under a separate systemd service. Alternately, mount-dirs.sh could have
> a hook that points to a specific user script in /etc.

A possible workaround I'm trying is to have my systemd unit run before
qubes-mount-dirs.service and do an independent mount-dismount of /rw.

This allows my script to perform simple sanitizing operations in /rw
before anything in there has a chance to run. So far, it works...

[Jean-Philippe Ouellet]

On Sat, Apr 15, 2017 at 10:13 AM, Chris Laprise <tas...@openmailbox.org> wrote:
> On 04/14/2017 12:18 PM, Chris Laprise wrote:
>>
>> I am trying to setup templates so the startup sequence in template-based
>> VMs can take action on /rw contents before they can affect the execution
>> environment (bind-dirs, rc.local, etc).
>>
>> Unless there is a setting for this (disabling startup execution of
>> private.img contents) that I'm not aware of, I think some modification
>> of Qubes would be necessary to properly enable such action. This is
>> because currently bind-dirs.sh activation is lumped-in with mount-dirs.sh.
>>
>> My suggestion would be to put the activation of qubes/init/bind-dirs.sh
>> under a separate systemd service. Alternately, mount-dirs.sh could have
>> a hook that points to a specific user script in /etc.
>
>
> A possible workaround I'm trying is to have my systemd unit run before
> qubes-mount-dirs.service and do an independent mount-dismount of /rw.
>
> This allows my script to perform simple sanitizing operations in /rw before
> anything in there has a chance to run. So far, it works...

What is your long-term goal with this effort? This and your
"Qubes-VM-hardening" stuff [1] looks to be trying to allow data
persistence while aiming to avoid the ability for the persisted data
to somehow hijack control on subsequent VM boots.

If so, ISTM that this could be achieved using DispVMs with a
persistent rw volume mounted somewhere other than /home (or any path
which installed software automatically reads). Furthermore, such an
approach also seems more robust than any attempt to essentially
blacklist known-sensitive paths (which I think would eventually
converge towards wanting to protect all of ~/.*) no?

I'm curious what you have in mind and what the intended use case is.

Cheers,
Jean-Philippe

[1]: https://github.com/tasket/Qubes-VM-hardening

[Chris Laprise]

On 04/15/2017 02:50 PM, Jean-Philippe Ouellet wrote:
> What is your long-term goal with this effort? This and your
> "Qubes-VM-hardening" stuff [1] looks to be trying to allow data
> persistence while aiming to avoid the ability for the persisted data
> to somehow hijack control on subsequent VM boots.

Its not so much data as actual scripts... the latter roll out the red
carpet for malware in regular template-based VMs. A statement of purpose
for it would be: Leave no obvious pathways for malware to persist in the
appVM startup process. Not terribly ambitious but probably worth doing.

>
> If so, ISTM that this could be achieved using DispVMs with a
> persistent rw volume mounted somewhere other than /home (or any path
> which installed software automatically reads). Furthermore, such an
> approach also seems more robust than any attempt to essentially
> blacklist known-sensitive paths (which I think would eventually
> converge towards wanting to protect all of ~/.*) no?

DispVMs have only worked for me on-and-off, and customization is
troublesome also (having app configs disappear). The implementation is
still too 'rube-goldberg' at present. Also don't want to add new storage
features to it.

Convergence towards '*'... nah. In /home I'm only interested in shell
autostart scripts: bash, sh, desktop.

My current POC can also address persistence of malware in the root-owned
parts of /rw. It will erase config, usrlocal, and bind-dirs if it finds
specific user-added dirs in /etc/default. It will also copy
scripts/files from there into the system. Even with this added scope,
the problem space remains quite compact.

>
> I'm curious what you have in mind and what the intended use case is.

Preventing shims and persistence loopholes in template-based VMs which
have protected root access (i.e. vm-sudo). An argument against vm-sudo
configuration is that its easy for an unpriv attacker to alter init
scripts and acquire root privs when a user grants them for legitimate
commands; Fixing that seems very realistic.

[Chris Laprise]

On 04/15/2017 10:13 AM, Chris Laprise wrote:
> A possible workaround I'm trying is to have my systemd unit run before
> qubes-mount-dirs.service and do an independent mount-dismount of /rw.
>
> This allows my script to perform simple sanitizing operations in /rw
> before anything in there has a chance to run. So far, it works...

Workaround has created a problem where hostname doesn't get set (shows
as 'localhost'). My service seems to interfere with
qubes-early-vm-config; Specifying it in 'After=' hasn't helped. I could
use some suggestions.

[Chris Laprise]

On 04/15/2017 04:59 PM, Chris Laprise wrote:
> On 04/15/2017 10:13 AM, Chris Laprise wrote:
>> A possible workaround I'm trying is to have my systemd unit run before
>> qubes-mount-dirs.service and do an independent mount-dismount of /rw.
>>
>> This allows my script to perform simple sanitizing operations in /rw
>> before anything in there has a chance to run. So far, it works...
>
> Workaround has created a problem where hostname doesn't get set (shows
> as 'localhost'). My service seems to interfere with
> qubes-early-vm-config; Specifying it in 'After=' hasn't helped. I could
> use some suggestions.
>
>

Hostname will be unset even if the script is blank.

---
[Unit]
Description=Script protections to enhance vm-sudo
After=qubes-early-vm-config.service
#Before=qubes-mount-dirs.service

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/lib/qubes/init/vm-sudo-protect.sh

[Install]
WantedBy=multi-user.target

---

The hostname is set if I comment-out 'Before='. But I need that line to
ensure my script runs before bind-dirs.

[Chris Laprise]

On 04/15/2017 05:52 PM, Chris Laprise wrote:

> Hostname will be unset even if the script is blank.
>

Looks like there is a race condition between some Qubes service files,
such as qubes-db.service and qubes-early-vm-config.service. This
prevents hostname from getting set.

If I add "After=qubes-db.service" to qubes-early-vm-config.service then
hostname gets set correctly.

[Patrick Schleizer]

Hi! :)

You want a hook exactly between mount-dirs.sh and bind-dirs.sh?

Chris Laprise:

> My suggestion would be to put the activation of qubes/init/bind-dirs.sh
> under a separate systemd service.

That would be nice, but may be hard to not break things.

Whonix uses various times:
After=qubes-mount-dirs.service

Also in systemd unit file that must use:
DefaultDependencies=no

For example in:
whonix-ws-firewall /lib/systemd/system/whonix-firewall.service

Perhaps create an qubes-bind-dirs.service that does nothing for now?
Then we actually start using it when Qubes / Whonix was upgraded to add
After=qubes-bind-dirs.service and old versions where made
deprecated/unsupported?

> Alternately, mount-dirs.sh could have
> a hook that points to a specific user script in /etc.

User script sounds a bit limited. What about something a little more
flexible?

Untested pseudo code:

if [ -d /etc/qubes/mount-dirs-post.d ]; then
run-parts /etc/qubes/mount-dirs-post.d
fi

Cheers,
Patrick

[Patrick Schleizer]

Chris Laprise:

> I am trying to setup templates so the startup sequence in template-based
> VMs can take action on /rw contents before they can affect the execution
> environment (bind-dirs, rc.local, etc).
>
> Unless there is a setting for this (disabling startup execution of
> private.img contents) that I'm not aware of, I think some modification
> of Qubes would be necessary to properly enable such action. This is
> because currently bind-dirs.sh activation is lumped-in with mount-dirs.sh.
>
> My suggestion would be to put the activation of qubes/init/bind-dirs.sh
> under a separate systemd service. Alternately, mount-dirs.sh could have
> a hook that points to a specific user script in /etc.
>

Btw you can hook between mount-dirs.sh and bind-dirs.sh already.

https://github.com/QubesOS/qubes-core-agent-linux/blob/d177e73bba077815ebfd15d9782f0787772067d9/vm-systemd/bind-dirs.sh#L121-L131

does the trick.

You could a hook here:
/usr/lib/qubes-bind-dirs.d/20_vm-sudo-protect.conf

Since all files in that folder get `source`ed by (`bash`) `bind-dirs.sh`.

The actual functionality of bind-dirs.sh would run after that.

https://github.com/QubesOS/qubes-core-agent-linux/blob/d177e73bba077815ebfd15d9782f0787772067d9/vm-systemd/bind-dirs.sh#L133

(Kicked off by: main "$@")

A bit hacky? Since that folder was supposed for configuration files, but
running hooks from there would work as well.

[Marek Marczykowski-Górecki]

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

On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
> Hi! :)
>
> You want a hook exactly between mount-dirs.sh and bind-dirs.sh?
>
> Chris Laprise:
> > My suggestion would be to put the activation of qubes/init/bind-dirs.sh
> > under a separate systemd service.
>
> That would be nice, but may be hard to not break things.

I'm worrying the same thing.

(...)

> > Alternately, mount-dirs.sh could have
> > a hook that points to a specific user script in /etc.
>
> User script sounds a bit limited. What about something a little more
> flexible?
>
> Untested pseudo code:
>
> if [ -d /etc/qubes/mount-dirs-post.d ]; then
> run-parts /etc/qubes/mount-dirs-post.d
> fi

IMO this is the way to go. In addition to your VM hardening scripts,
this could be used also for some /rw initialization, beyond /etc/skel.
AFAIR there was a need for similar thing to copy Tor Browser there.

As for implementation - do we want it in /etc, /usr/lib, or both (so
files in /etc could override /usr/lib)? But having both means we can't
use run-parts :(

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY9T3oAAoJENuP0xzK19csOBcH/2o4kcg7xOBQuhlGzXrsTDUU
QNzrdzBRn6glM6mR0vv5cELSDE9EI9QcRI0uPWoETGBtD2nHHWgLRAq9gK8SwAso
4ySrBo3QvkozAMrAM7YISrOo4IGnwuCnPbTvv3j8hZb71CpC/J7jXnDjfF3pj9ZT
9a7oMudbnT1lRZ+xELx8yIQRKQhE6kk4cTRlMPSoVbOlxNUtH8Ajsq4Mn8dO2eQQ
HnWdBEW93PLU73fQyvCCnsvywgTaJOV/c4eKeLEvaYUFME+C0sHaD5CPOCzgdftx
T3RHmbxUMDdQG1WWvLoLEixdYmM9Yon/5hAI2XGbOOkfOsgiplKbfEuCHTUBwhI=
=aaTK
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
>>> Alternately, mount-dirs.sh could have
>>> a hook that points to a specific user script in /etc.
>
>> User script sounds a bit limited. What about something a little more
>> flexible?
>
>> Untested pseudo code:
>
>> if [ -d /etc/qubes/mount-dirs-post.d ]; then
>> run-parts /etc/qubes/mount-dirs-post.d
>> fi
>
> IMO this is the way to go. In addition to your VM hardening scripts,
> this could be used also for some /rw initialization, beyond /etc/skel.
> AFAIR there was a need for similar thing to copy Tor Browser there.
>
> As for implementation - do we want it in /etc, /usr/lib, or both (so
> files in /etc could override /usr/lib)?

Yes in both. Actually in all three. I.e. /etc/, /usr/lib and in
/usr/local (/rw) to make it complete.

> But having both means we can't
> use run-parts :(

Why not just use above "Untested pseudo code" three times with the
different dirs? :)

Cheers,
Patrick

[Marek Marczykowski-Górecki]

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

On Mon, Apr 17, 2017 at 11:06:00PM +0000, Patrick Schleizer wrote:
> Marek Marczykowski-Górecki:
> > On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
> >>> Alternately, mount-dirs.sh could have
> >>> a hook that points to a specific user script in /etc.
> >
> >> User script sounds a bit limited. What about something a little more
> >> flexible?
> >
> >> Untested pseudo code:
> >
> >> if [ -d /etc/qubes/mount-dirs-post.d ]; then
> >> run-parts /etc/qubes/mount-dirs-post.d
> >> fi
> >
> > IMO this is the way to go. In addition to your VM hardening scripts,
> > this could be used also for some /rw initialization, beyond /etc/skel.
> > AFAIR there was a need for similar thing to copy Tor Browser there.
> >
> > As for implementation - do we want it in /etc, /usr/lib, or both (so
> > files in /etc could override /usr/lib)?
>
> Yes in both. Actually in all three. I.e. /etc/, /usr/lib and in
> /usr/local (/rw) to make it complete.

No, the whole point about this script is to run something _before_
anything gets processed/run from /rw.

> > But having both means we can't
> > use run-parts :(
>
> Why not just use above "Untested pseudo code" three times with the
> different dirs? :)

Because it will not allow to disable/override a script in /usr/lib by
placing a script with the same name in /etc.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY9VVKAAoJENuP0xzK19csLYMH/0oAYM8dzZxPkCqVOvgRd4Pk
hPUIk6s5Hf79HOQTCjMStH8luoyoerg7F4NRGSVnW7qHqdOY3hKct3LUB8JYITtV
X+4XHnwIGqLr6ZEw6ekspvZXyBpqGkjjQEtrRPpStzqW3ViSFns/0aXkNZ4q6Pq1
BnK2FL7qpWDA3mftu8qsW/JqpWzU+IBZx0kxnJpb8R042DNl2Zmis9VFA9WAsojm
SBQVkCQ8KOJj6wGtEZIZl75wgXs+u96bIQ7uitLU6nJA8UcF6cFY1PPk4pgIIYNi
NmAaTNoxthfwEiwaIS61dNv/0Q5f9v1zJlak45AC49CiuE0Cxq/A3XPDF/1lKHY=
=a5JZ
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:
> On Mon, Apr 17, 2017 at 11:06:00PM +0000, Patrick Schleizer wrote:
>> Marek Marczykowski-Górecki:
>>> On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
>>>>> Alternately, mount-dirs.sh could have
>>>>> a hook that points to a specific user script in /etc.
>>>
>>>> User script sounds a bit limited. What about something a little more
>>>> flexible?
>>>
>>>> Untested pseudo code:
>>>
>>>> if [ -d /etc/qubes/mount-dirs-post.d ]; then
>>>> run-parts /etc/qubes/mount-dirs-post.d
>>>> fi
>>>
>>> IMO this is the way to go. In addition to your VM hardening scripts,
>>> this could be used also for some /rw initialization, beyond /etc/skel.
>>> AFAIR there was a need for similar thing to copy Tor Browser there.
>>>
>>> As for implementation - do we want it in /etc, /usr/lib, or both (so
>>> files in /etc could override /usr/lib)?
>
>> Yes in both. Actually in all three. I.e. /etc/, /usr/lib and in
>> /usr/local (/rw) to make it complete.
>
> No, the whole point about this script is to run something _before_
> anything gets processed/run from /rw.

Right. (Scratch that /rw idea.)

>>> But having both means we can't
>>> use run-parts :(
>
>> Why not just use above "Untested pseudo code" three times with the
>> different dirs? :)
>
> Because it will not allow to disable/override a script in /usr/lib by
> placing a script with the same name in /etc.

Alright. We can have that feature. Then perhaps let's use bash `source`.

Each snipped could define an entry function named
number_main_drop-in-name or so. For example.

/usr/lib/qubes-mount-dirs.d/50_bind_dirs.conf:

50_main_bind_dirs() {
/path/to/actual/script
}

To disable that, a lexically higher configuration file could just do.

/etc/qubes-mount-dirs.d/50_bind_dirs.conf:

50_main_bind_dirs() {
true
}

Then the mount-dirs.sh script could `source` all these `.conf`s, and use
`compgen` to get a list of function names, match these for `_main_`.
Then run these functions in lexical order.

Does that look good? If needed, I could as well describe that better or
write some pseudo code for that. I like this override / configureability
stuff.

Cheers,
Patrick

[Marek Marczykowski-Górecki]

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

IMO forcing people to writing a bash function in such script is a bad
idea. First of all, many will not do that, breaking this override
schema. If more elaborative script is needed anyway, lets work on full
files, like this:

IFS=$'\n'
readarray -t files_basename < <(
find /usr/lib/qubes-mount-dirs.d /etc/qubes-mount-dirs.d
-type f -executable -printf '%f\n' | sort | uniq)

for f in "${files_basename[@]}"; do
if [ -x "/etc/qubes-mount-dirs.d/$f" ]; then
"/etc/qubes-mount-dirs.d/$f"
elif [ -x "/usr/lib/qubes-mount-dirs.d/$f" ]; then
"/usr/lib/qubes-mount-dirs.d/$f"
endif
done

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY9XNeAAoJENuP0xzK19cs52QH/3/YH5YXGFMAxG4lsv791wy0
iMVih9emNtnpIDHyfeK2jX6p0PpiTv0Clxl1Ry3zZOC7/Gp1PmVVrYa4iCHy4/FH
h5+dlJemtDexSVSB1RqHcifPsM/N6GYfOH+W0gBdNuVgTCucf0EjMHWwZvsgDyom
zRzS0nieZioXQUSan6M77zOwF6mR2Y/yUIHBGeOPN9gXSBuBNJ2JRvnXNvbC2Rzp
AsZLqGqx5w4uRUm0UPiZ69t2cyzwOlgylP0fZlzBsfiNdfgtsVUCQpAgPJ69GKKz
NLu7u6RsQj/WQg3Wf/W/BQ/luFaMJgR1lomSzFLJokOnky5HWhX03ROhtp5xYUQ=
=0kzs
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:

Okay, I see. I think the people wishing to implement such overrides
would be capable to do it as per developer documentation but it's of
course up to you.

> First of all, many will not do that, breaking this override
> schema. If more elaborative script is needed anyway, lets work on full
> files, like this:
>
> IFS=$'\n'
> readarray -t files_basename < <(
> find /usr/lib/qubes-mount-dirs.d /etc/qubes-mount-dirs.d
> -type f -executable -printf '%f\n' | sort | uniq)
>
> for f in "${files_basename[@]}"; do
> if [ -x "/etc/qubes-mount-dirs.d/$f" ]; then
> "/etc/qubes-mount-dirs.d/$f"
> elif [ -x "/usr/lib/qubes-mount-dirs.d/$f" ]; then
> "/usr/lib/qubes-mount-dirs.d/$f"

> endif

fi

> done

That would make it easier for users to add a single override, better
usability from that perspective.

However, would not be ideal for developers. We'd loose flexibility.
Since then scripts could only be overwritten by users. Would not be a
proper override system for packages / developers.

Cheers,
Patrick

[Chris Laprise]

On 04/17/2017 06:12 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
>> Hi! :)
>>
>> You want a hook exactly between mount-dirs.sh and bind-dirs.sh?
>>
>> Chris Laprise:

>>> Alternately, mount-dirs.sh could have
>>> a hook that points to a specific user script in /etc.
>>
>> User script sounds a bit limited. What about something a little more
>> flexible?
>>
>> Untested pseudo code:
>>
>> if [ -d /etc/qubes/mount-dirs-post.d ]; then
>> run-parts /etc/qubes/mount-dirs-post.d
>> fi
>
> IMO this is the way to go. In addition to your VM hardening scripts,
> this could be used also for some /rw initialization, beyond /etc/skel.
> AFAIR there was a need for similar thing to copy Tor Browser there.

IIUC, this idea is for R4.x release..? It will be nice to have, but in
the meantime I'm still looking for a way to make this possible in R3.2
without getting medieval (sed /usr/lib...script.sh).

It would be really nice to activate my script on a per-VM basis(!) from
Qubes Manager settings. I'm having better luck doing it this way,
running it before meminfowriter and after qubes-sysinit.

[Marek Marczykowski-Górecki]

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

On Thu, Apr 20, 2017 at 05:46:48PM -0400, Chris Laprise wrote:
> On 04/17/2017 06:12 PM, Marek Marczykowski-Górecki wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Mon, Apr 17, 2017 at 10:02:00PM +0000, Patrick Schleizer wrote:
> > > Hi! :)
> > >
> > > You want a hook exactly between mount-dirs.sh and bind-dirs.sh?
> > >
> > > Chris Laprise:
> > > > Alternately, mount-dirs.sh could have
> > > > a hook that points to a specific user script in /etc.
> > >
> > > User script sounds a bit limited. What about something a little more
> > > flexible?
> > >
> > > Untested pseudo code:
> > >
> > > if [ -d /etc/qubes/mount-dirs-post.d ]; then
> > > run-parts /etc/qubes/mount-dirs-post.d
> > > fi
> >
> > IMO this is the way to go. In addition to your VM hardening scripts,
> > this could be used also for some /rw initialization, beyond /etc/skel.
> > AFAIR there was a need for similar thing to copy Tor Browser there.
>
> IIUC, this idea is for R4.x release..? It will be nice to have, but in the
> meantime I'm still looking for a way to make this possible in R3.2 without
> getting medieval (sed /usr/lib...script.sh).

Actually, if the behaviour without any additional configuration would be
unchanged, we may consider it also for R3.2.

> It would be really nice to activate my script on a per-VM basis(!) from
> Qubes Manager settings. I'm having better luck doing it this way, running it
> before meminfowriter and after qubes-sysinit.

For this, take a look here:
https://www.qubes-os.org/doc/qubes-service/

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY+S1uAAoJENuP0xzK19cs4eIH/2zoQ3XyV9GfsAEjswuaNPBe
kg/fXOxsgL2+cLWFcncrXW249IqaHbxTdnmjEQ6/EvAacJENdf/LhWfL7KmK/J4i
rc8u5N2qtl9JRjX+08axIM212afZ8z22kBZS+zArWJuCphvDF2B+d/tWdmqXa5HV
syJAkVihBbU+LU/Ij+D52TBS8uOwijfswXvsOYNrhYLjF9akLiSzubzix0wXItiS
AvnPVj8QM+Y/60D9wPaApwg9MuifwS78myMfXaMFP9PwG3S/ptKHt5Dv2lmnWJRS
e+ajknxK8kP3O78q2p3W6RLrVFdN83tC89jxGzttxgX5nQ74R/Be5bDqRAPN/gQ=
=fJL0
-----END PGP SIGNATURE-----

[Chris Laprise]

Yes, already there. It seems to work well now. I settled on specifying
WantedBy=sysinit.target and no 'Before'.

https://github.com/tasket/Qubes-VM-hardening/blob/systemd/lib/systemd/system/vm-sudo-protect.service