/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.
read() syscall do not guarantee to read as much data as requested. This
is especially important when reading from pipe - remote end can produce
data slower than we are reading them. Use read_all() helper to always
get requested amount of data.
Assume that all the files of directory are in continuous block (which is
true in case of qvm-backup stream). This will allow to terminate before
getting to the file end - especially useful when only qubes.xml
requested.
MIME-info database contains multiple entries for *.png, namely image/png
and image/x-apple-ios-png. The later one doesn't have associated handler
program, but this one is selected by mimeopen tool.
Not sure how this tool should behave in case of multiple matches (IOW is
it a bug in File::MimeInfo perl module used by mimeopen). Instead of
switching to different tool, which probably will break other files
(check #423), add override for this particular file type.
Actually one was real bug:
- current = ustar_rd(fd, &hdr, &buf, &sb);
+ current = ustar_rd(fd, &hdr, buf, &sb);
The others was mostly invalid printf format string.
Now dom0 will initiate real suspend process in VMs with PCI devices, so
workaround with unloading modules no longer needed.
Additionally it looks like unloading ehci-pci causes suspend problems on
some hardware (C200 Series Chipset).
