This have many advantages:
- prevent XSS (QubesOS/qubes-issues#1462)
- use default browser instead of default HTML viewer
- better qrexec policy control
- easier to control where are opened files vs URLs
For now allow only http(s):// and ftp:// addresses (especially prevent
file://). But this list can be easily extended.
QubesOS/qubes-issues#1462FixesQubesOS/qubes-issues#1487
rsvg-convert doesn't scale the image. Do it with convert, only when
really needed. Don't upscale the icon after converting to raster
version.
FixesQubesOS/qubes-issues#1884
* qubesos/pr/11:
Properly handle case of empty domain name.
Use proper quoting around variables.
Move usage information printing to separate function, and print usage to stderr; also added some spacing.
Use proper space-expanded tabs, as per the coding guidelines.
Those are currently barely useful, since starting the application isn't
the biggest bottleneck of DispVM. And since stderr is now visible on
qvm-open-in-dvm output, not scare the user with it.
* origin/pr/61:
update-proxy: use curl instead of wget in archlinux in order to limit additional dependencies
archlinux: properly add qubes markers in pacman.conf
archlinux: add Qubes Markers in pacman.conf so that changes done by qubes scripts are not inserted at the end of pacman.conf
implement update proxy support for archlinux
archlinux: add gcc and make as make dependencies
update qubes.InstallUpdateGUI to support archlinux
xdg-open is more robust in choosing default application for particular
file type: it supports fallback if the preferred application isn't
working, and most importantly it support system-wide defaults
(/usr/share/applications/defaults.list,
/usr/share/applications/mimeapps.list), so no "random" application is
chosen.
By default xdg-open tries to use environment-specific tool, like
gvfs-open - which isn't good for us, because many such tools do not wait
for editor/viewer termination. That would mean that DisposableVM would
be destroyed just after opening the file.
To avoid such effect, we set DE=generic.
FixesQubesOS/qubes-issues#1621
No functional change.
This will make it easier to switch the tool (without recompiling
vm-file-editor), or even use differrent tools depending on some
conditions.
QubesOS/qubes-issues#1621
Sending dbus calls to a service which isn't running _and is blocked to
not be started_ would result in timeout, which would delay the whole
system suspend.
FixesQubesOS/qubes-issues#1419
It is expected to not output anything on stdout. Especially remote end
may be already terminated, so writing there would result in EPIPE.
FixesQubesOS/qubes-issues#1592
To get endless sleep, `sleep inf` (or `sleep infinity`) can be used
instead of `sleep 365d`. Coreutils' sleep accepts any floating-point
number as an argument, which may be 'infinity', according to
`man strtod`.
This makes the qfile packing code reusable, for example for some dom0
tool. Now qfile-agent.c is only an interface for underlying library.
QubesOS/qubes-issues#1324
According to Desktop Entry Specification:
NoDisplay means "this application exists, but don't display it in the
menus". This can be useful to e.g. associate this application with MIME
types, so that it gets launched from a file manager (or other apps),
without having a menu entry for it (there are tons of good reasons
for this, including e.g. the netscape -remote, or kfmclient openURL kind
of stuff).
Apparently over half of desktop files in default Fedora template have
NoDisplay=true...
FixesQubesOS/qubes-issues#1348
Return some meaningful error code. Unfortunately the more meaningful
option (retrieving process exit code) can lead to false errors
(described in comment), but at least report exit code of tar2qfile.
When qfile-unpacker's child encountered an error, it would display an
error message and exit(1), but the parent didn't inspect its status and
exited successfully.
That was unfortunate for qvm-move-to-vm: Even if the destination VM e.g.
didn't have enough free disk space, the RPC call would claim to succeed
anyway, so the file would be deleted from the source VM.
Do not send 'which' command output to stdout, as it will mess real
backup data.
This fixes regression introduced by this commit:
commit dad5bfbd18
Author: HW42 <hw42@ipsumj.de>
Date: Thu Feb 5 03:14:41 2015 +0100
remove 'bashisms' or explicit use bash
/proc is needed to link files opened with O_TMPFILE to the filesystem.
If not available, fallback to using permissions to block file access,
instead of failing the whole file copy.
Otherwise, when the user moves directory, which is still in transfer,
somewhere else, it could allow malicious source domain to escape chroot
and place a file in arbitrary location.
It looks like bind mount is just enough - simple rename fails with
EXDEV, so tools are forced to perform copy+delete, which is enough to
keep unpacker process away from new file location.
One inconvenient detail is that we must clean the mount after transfer
finishes, so root perms cannot be dropped completely. We keep separate
process for only that reason.
Instead of directly using Exec= line, parse the file (at the launch
time) with Gio library. The main reason for this change is to handle
Terminal= option, but generally this approach should be more
bulletproof, especially when some fancy options are present in desktop
files.
It would be called by qvm-sync-clock instead of 'date' directly. This
gives a lot of flexibility - VM can control whether it want to sync time
this way. For now slight corrections (+-2sec) are ignored to not cause
problems by frequent time changes. But it can be easily extended to
refuse time sync when some other mechanism is used.
Buffer for directory headers history was too small. This can be
exploitable by some attacker capable of controlling backup stream, but
it isn't any security problem. We don't assume this part of backup
system to be trusted, the attacker can at most prevent user from
restoring some data, but will neither gain access to them, or compromise
any other Qubes component. This is equivalent to bug in any other tool
used in backup vm (like FTP client) and the Qubes backup system is
designed specifically to minimize impact of such bugs.
readlink(2) does not write a terminating NUL, and the read side
will already place a NUL after whatever it receives.
While it seems odd that this would be buggy (ie, synlinks on
the ohter side would be pointing to the wrong filename, though
I guess if we're lucky and the stack had a 0 byte at the right
place, symlink(2) would do what was expected), my reading of
the code tells me this patch is right. Needs testing to double
check.
This avoids the possibility that incoming files may match
an existing file in /tmp (whether from the target VM, or a
third VM that's also sent a file for editing), as well as
possible file leaks between domains.
If we're being sent something without a zero byte, we
could happily read off the end of the buffer. Interestingly,
the write part was checking for the max bound.
That one would also send more data to the other VM that what we
intended: the start of the env var data (which in similar code
on my host includes the GPG agent socket path, XDG session cookie,
and more.
The other side expects a fixed size though, so pad with NULs.
Interestingly, the original code was not vulnerable as it was
callocing enough space.
