[qubes-devel] Re: Detect template updates available?

[joeviocoe]

Looks like qvm-features reads from /var/lib/qubes/qubes.xml... and they both 
show, "updates-available" set to 1.

But it appears that this value doesn't get cleared after a 
qubes.InstallUpdatesGUI is run.

-- 
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/7613e729-c833-43e6-92ce-0474135de4d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] Detect template updates available?

[joeviocoe]

In Qubes 4.0 (RC4)

How does Qube Manager (or previous Qubes Manager) detect when a template VM has 
an available update?

I understand that qubes-update-check.service is on the VMs that are running so 
it can report back to dom0 to let it know there is an update available for its 
template (or itself if standalone VM).

But on dom0, is there a file or flag that shows which VMs?  How does the 
manager app know?
After the UpdateVM (qubes.InstallUpdatesGUI) is run successfully on the 
template, and it completes a shutdown... how is this flag cleared.


Thanks.


P.S.
I found /var/lib/qubes/qubes.xml and its "updates-available" feature tag.  A 
couple of my templates are set to 1, but after an update, this doesn't change.

-- 
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/c758c1f7-96ca-4aa2-af53-cd7f2ab12b80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] QSB #38: Qrexec policy bypass and possible information leak

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #38:
Qrexec policy bypass and possible information leak.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #38 in the qubes-secpack:



Learn about the qubes-secpack, including how to obtain, verify, and read it:



View all past QSBs:



```

 ---===[ Qubes Security Bulletin #38 ]===---

  February 20, 2018


  Qrexec policy bypass and possible information leak

Summary


One of our developers, Wojtek Porczyk, discovered a vulnerability in the way
qube names are handled, which can result in qrexec policies being bypassed, a
theoretical information leak, and possibly other vulnerabilities. The '$'
character, when part of a qrexec RPC name and/or destination
specification (like '$adminvm', '$default', or one of the variants of
'$dispvm') is expanded according to shell parameter expansion [1]
after evaluating the qrexec policy but before invoking the RPC handler
executable. 

Impact
===

1. Potential policy bypass. The qrexec argument value that is delivered to the
   handler executable can be different from the value that is present in the
   RPC policy at the time the policy is evaluated. This is especially
   problematic when the policy is defined as a blacklist of arguments rather
   than a whitelist, e.g.  "permit any arguments to example.Call but
   PROHIBITED". If an attacker were to call 'example.Call+PROHIBITED$invalid',
   the argument would not match the blacklisted variable at the time of policy
   evaluation, so it would be admitted.  However, performing shell parameter
   expansion on the argument results in the prohibited value, which is what the
   actual handler receives.

2. Potential information leak. If the qrexec handler acts upon the argument,
   the attacker could read or deduce the contents of those variables.

3. Other potential vulnerabilities. Some of the variables present in the
   environment, like $HOME and $PATH, also contain characters that are not
   permissible in qrexec names or arguments that could theoretically lead to
   other classes of vulnerabilities, such as directory traversal.

Technical details
==

The '$' character is used in several places in qrexec and is therefore an
allowed character in parameters to Qubes RPC calls. It is also allowed as part
of the RPC name. The validation code is as follows [2]:

static void sanitize_name(char * untrusted_s_signed, char 
*extra_allowed_chars)
{
unsigned char * untrusted_s;
for (untrusted_s=(unsigned char*)untrusted_s_signed; *untrusted_s; 
untrusted_s++) {
if (*untrusted_s >= 'a' && *untrusted_s <= 'z')
continue;
if (*untrusted_s >= 'A' && *untrusted_s <= 'Z')
continue;
if (*untrusted_s >= '0' && *untrusted_s <= '9')
continue;
if (*untrusted_s == '$' ||
   *untrusted_s == '_' ||
   *untrusted_s == '-' ||
   *untrusted_s == '.')
continue;
if (extra_allowed_chars && strchr(extra_allowed_chars, 
*untrusted_s))
continue;
*untrusted_s = '_';
}
}

and is invoked as [3]:

sanitize_name(untrusted_params.service_name, "+");
sanitize_name(untrusted_params.target_domain, ":");

Those arguments are part of the basis of policy evaluation. If policy
evaluation was successful, the parameters are then forwarded to the destination
domain over qrexec, and the call is executed using the qubes-rpc-multiplexer
executable, which is invoked by a POSIX shell. The exact mechanism differs
between dom0 and other qubes [4]:

if self.target == 'dom0':
cmd = '{multiplexer} {service} {source} {original_target}'.format(
multiplexer=QUBES_RPC_MULTIPLEXER_PATH,
service=self.service,
source=self.source,
original_target=self.original_target)
else:
cmd = '{user}:QUBESRPC {service} {source}'.format(
user=(self.rule.override_user or 'DEFAULT'),
service=self.service,
source=self.source)

# ...

try:
subprocess.call([QREXEC_CLIENT] + qrexec_opts + [cmd])

For the dom0 case, these are the relevant parts from the executable referenced
as QREXEC_CLIENT above [5]:

/* called from do_fork_exec */
void do_exec(const char *prog)
{
execl("/bin/bash", "bash", "-c", prog, NULL);
}

/* ... */

static void prepare_local_fds(char *cmdline)
{
/* ... */
do_fork_exec(cmdline, _pid, _stdin_fd, 

Re: [qubes-devel] qubes-firewall script error handling

[Chris Laprise]

On 02/18/2018 06:30 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Feb 18, 2018 at 01:10:44PM -0500, Chris Laprise wrote:

I'm thinking about posting a PR to have qubes-firewall raise errors whenever
a firewall script from qubes-firewall-user-script or qubes-firewall.d
returns an error code.

The object is to provide a way to make the qubes-firewall service fail when
firewall scripts encounter an error. On failure, the result would be that
forwarding (or networking) is disabled and any units bound to qubes-firewall
would not run.

Default behavior would be little different than it is now, given that shell
scripts are fault-tolerant. But script authors will have the option of using
"set -e" or "exit 1" etc. so the service goes into a failed state.


Problems like crashed qubes-firewall are very annoying and it isn't easy
to find where such service have crashed. Also, script exiting with
non-zero code can happen for various reasons, including misusing "[
condition ] && action" syntax. I've seen far to many errors like that.


The intention is for a script author who wants net enabled only if 
firewall script runs exactly right... they can use "set -e". Otherwise 
the service wouldn't be affected by an error.


As for finding errors when they occur, looking at journalctl is pretty 
informative since related lines about failure are highlighted and twice 
mention the method i.e. "self.run_user_script". I was wondering if the 
service could also do a notify-send, or even call a qubes-rpc method 
that merely informs about VM state in such a case.


Alternately, instead of failing the service could handle the error by 
simply logging it and disabling forwarding for the proxyVM. Another 
service (post-misc?) might display an informational popup about 
forwarding state.




But if the script author know what he/she is doing, having option to
fail closed is a good idea. What about choosing en exit code that would
cause the effect you propose? And let that not be 1. This could allow
both: fail closed for conscious user, and harder to break the setup by
stupid error. The idea is inspired by Restart*ExitStatus= settings of
systemd.service and git bisect run.


I think this would put a burden on the script writer to improvise (and 
not accidentally undermine) their own facsimile of try/catch so that 
sending the special exit code is possible. In this case, the script 
writer has already done (precariously) 95% of what is needed to prevent 
the proxyvm from going online anyway. IOW


I'm asking about this because I started to put checks for firewall rules 
in the qubes-tunnel startup code, but it seems kludgey to have a 
non-firewall script check for specific rules. Its cleaner to just 
enforce error checking in the first place.


-

Also... looking at how qubes-firewall fails at that point, its different 
than the 3.2 behavior I remember where enabling of forwarding followed 
in sequence after the user script. When the R4.0 service fails at 
run_user_script the system continues with forwarding enabled which seems 
suboptimal.



--

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

--
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/b728315b-85f2-a380-06c1-33df47737d65%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] Split-git?

[Wojtek Porczyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Feb 17, 2018 at 04:01:06PM +0100, Marek Marczykowski-Górecki wrote:
> On Sat, Feb 17, 2018 at 01:44:40AM -0800, Elias Mårtenson wrote:
> > Has anyone considered implementing split-git? The idea being that you'd 
> > have a custom git protocol that forwards requests over qrexec to a git 
> > repository on a different vm.
> > 
> > The reading I started thinking about it is that I have a vm for Keybase, 
> > and I'm using the keybase git provider for some private repositories. It 
> > would be nice to be able to work with those repositories from a vm which 
> > does not have Keybase installed.
> > 
> > I can also envision other usecases for a split-git implementation.
> > 
> > I have started working on a proof-of-concept but I'm nowhere near anything 
> > that works yet. That's why I'm asking here if anyone else have worked on 
> > the same thing, before spending more time on it.
> 
> There are one and a half existing implementations of similar feature:
> 
> 1. Running plain git protocol over qrexec: 
> https://www.qubes-os.org/doc/development-workflow/#git-connection-between-vms
>- there is no validation of the protocol itself, only some policy for
>  repository access (hardcoded into the script)
> 
> 2. Wojtek tried something similar to your idea - forwarding specific
> requests over qrexec (at git object level), with data validation before
> passing it to git. AFAIK this is in very early stage and very limited
> scope (pushing one signed tag + dependencies?).

This is my take: https://github.com/woju/qubes-app-split-git
After first consulting with Marek I was under impression that this may not be
that useful, but if you ask, I'm happy to share.

It mostly works, but has purposefuly limited functionality. It fetches one
tag. The tag has to be signed and the rest of the objects (the commit the tag
points to, its tree and recursively any blobs and trees) are verified based on
their SHA1. You can't fetch branches nor any other refs, but you can fetch tag
and fast-forward an existing branch to it. Any objects are verified in memory
before writing them to .git/objects.

gpg --no-default-keyring --keyring gittrust.kpx --import < trustedpubkey.asc
git remote add origin qrexec://remoteqube/repo.git?keyring=gittrust.kbx

# the first time
git fetch origin tag v1.0
git checkout -b master v1.0

# after some time
git fetch origin tag v1.1
git merge --ff-only v1.1

I'll probably write some README to cover installation.

Marek is right that this is very early stage, so bugs are very much expected.


- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJaiwLeAAoJEL9r2TIQOiNR0rIQAJM2AEt5Fp+2f6gWoMDlcKIl
+jhxQ/Yky00Y1O4OBL27ZrtfSE3A1Iy5U2bzTrW/gXbWqF31PTo/Jjq6gplL/dLF
ir+jX3OhnsQumlNIc3Uqrq8TqNYI8mkezF7MOlwDFExcOKYQJfOJdjZFtNoUbwc5
nHJlB4LZhinCv3fPJ2qBWOz8fHJ+KUtOpqfxSTGG6apz+fdmRmk/r7KC6bQEzsh8
kBtGTDc9JcKI3TFncwc/KYnzUWU3mGe9nGvCwHd+6Xhsk4wmnOL0Q7emmnbt72mw
Xa4QNUb0HKwoI0QboXmdQxQ1wlBDZG5B96N24p2v68HyLVsk+O4ZM0HB94aN8njH
Ip5oQaHDod2cifCvwYmyBu6qYjEjKY1q3dC3vRQGBKDBmOQ1y8O9bw3aWFP6V4Ne
TI5UBuL3+5hdvy7CL5bGmHditvR3LPe8+DxBjSdEklufR6EQOquxgiMlp7DY4tQg
v6NeXtJR+hc7xLvhk55DhhkGuFHvkZCfqko0eDe4KQ0nAmK6DKlSv10747BTAdmQ
8kVUQbyJovjy1ejlHwrwgeM8lrjKyDABNsh9d4zHR7Ozz7zRXU1dujYn370k9agR
WgUe+4wl3bpMQlhCOPsQvV3CdkG6hQhaC0lJb1jeGd06UCzAe6UCKHEWIBAbkNes
I3pqLtjgsqeWmW9RwK8V
=Q3LW
-END PGP SIGNATURE-

-- 
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/20180219170121.GK1198%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] clocksync service is not enabled on any vm's in rc4

[bowabos]

On Saturday, 17 February 2018 15:07:55 UTC, Elias Mårtenson  wrote:
> On Saturday, 17 February 2018 22:55:20 UTC+8, Marek Marczykowski-Górecki  
> wrote:
> 
> > That's weird, it should be enabled in sys-net by default. Did you had
> > any problems during installation, requiring manual sys-net setup?
> 
> The installation worked fine as far as I can tell.
> 
> The only unusual thing was after initial boot, when it initialises the system 
> for the first time (the part where you answer which vm's you want created, 
> etc). After I had done this, you're supposed to click "finish" (or something 
> to that effect) but I accidentally clicked on the same button again. This 
> caused the installer to run again.
> 
> I don't think that would cause any issues, but that's the only thing I did 
> that was out of the ordinary.
> 
> After adding the clocksync service to sys-net, activating it, and rebooting, 
> the time is now properly synchronised.
> 
> Regards,
> Elias

I can confirm that I had the same problem. I did the same mistake during 
install on one of my systems, not sure it was on the one at fault, but quite 
probably. Another system I installed later is fine (I probably did not do the 
install mistake).

-- 
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/839695ae-5e75-4852-ab25-3d78cdcf1407%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.