Re: qemu-ga guest-exec & SELinux
by Daniel P. Berrangé
On Tue, Jun 21, 2022 at 10:42:39AM +0200, Renaud Métrich wrote:
> Hi there,
>
> I'm the BZ reporter.
>
> I think the safe solution is to provide something similar to what was done
> for vmtools: have a context switching to become sort of "unconfined" domain.
>
> This context switch has to happen only the executor and we already have a
> solution, I documented it in the BZ.
>
> I don't think having an additional boolean is necessary, unless we want to
> restrict the commands the guest can execute.
If we allow QGA to execute arbitrary commands, running those commands
unconfined_t, then what is the point of having any SELinux policy
for QGA at all. It can just execute "/bin/sh" or "/bin/perl", passing
any script commands it wants, having them run as unconfined_t and thus
escape all SELinux confinement of QGA.
I didn't realize that we in fact already allowed runing any command
labelled bin_t. That already makes the QGA policy useless as a security
measure and should be addressed IMHO by putting that existing rul;e
behind a boolean, defaulting to disabled.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
1 year, 3 months
qemu-ga guest-exec & SELinux
by Marc-André Lureau
Hi!
https://bugzilla.redhat.com/show_bug.cgi?id=2093355 ("AVCs when trying to
execute a command through qemu-ga ("guest-exec" command)") describes an
issue with fedora/rhel SELinux rules, where some program executions are
denied.
qemu-ga has "virt_qemu_ga_t" context, and is not allowed to execute
binaries that are not "bin_t", iiuc. The suggestion from Renaud Métrich is
for qemu-ga exec command to launch the user program through an helper
program that would have the virt_qemu_ga_unconfined_exec_t context, and
appropriate rules in selinux (similar to fsfreeze-hook rules), so any
program can be executed. qemu-ga would thus ship and use that helper, in
all OS, to avoid varying code paths.
Does that sound reasonable or should we try to find a solution with SELinux
rules instead?
thanks
--
Marc-André Lureau
1 year, 3 months
btrfs, user created subvolumes
by Chris Murphy
Hi,
Two questions as it relates to btrfs subvolumes created by users on Fedora.
Question 1, should new subvolumes within the ~/ hierarchy have the
same label as a new directory?
$ mkdir hi
$ btrfs subvolume create hi2
$ ls -lZ
drwxrwxr-x. 1 chris chris unconfined_u:object_r:user_home_t:s0
0 Jun 13 15:55 hi
drwxrwxr-x. 1 chris chris system_u:object_r:unlabeled_t:s0
0 Jun 13 15:55 hi2
Is this expected? Or should I file a bug?
Question 2, should users be allowed to remove subvolumes (including
subvolume snapshots) they own?
There's a bit of background here:
* Users can 'btrfs subvolume create' without privileges
* Users can't 'btrfs subvolume delete' without privileges, unless the
Btrfs file system is mounted with option "user_subvol_rm_allowed"
* Users can remove empty subvolumes without privileges, e.g. rmdir or
rm -rf so long as the user owns all the items contained in the
subvolume.
OK a bit more background. A subvolume is a file b-tree. It's where all
file and directory metadata is located: inode, datetime, permissions,
xattr, compression info, extent info.
When deleting a subvolume, none of the contents are checked for
permissions at all - the tree is just snipped off the file system, and
the extents are later freed by a kernel cleaner thread. So it's
essentially an immediately returning command, with the expensive
backref walk done by a dedicated kernel thread later.
On any file system when deleting a directory, all the contents have
permissions checked. If the user can't delete an item, then the
directory won't be empty, and they won't be able to remove it. This is
the same for btrfs subvolumes when using the same commands, rmdir and
rm -rf. The subvolume can't be deleted until it's empty. This can be
quite alot more expensive than just a subvolume delete.
I'm wondering if anyone can imagine problems with enabling
user_subvol_rm_allowed mount option on Fedora desktops by default? And
whether SELinux can or should have some role in preventing mistakes?
Like if SELinux could distinguish between an active user home
directory that is also a btrfs subvolume - don't allow the user to
stab themselves in the foot. But let them delete any other subvolume
they own. Or maybe it's low enough risk.
Thanks,
--
Chris Murphy
1 year, 3 months
polyinstantiation_enabled vs allow_polyinstantiation
by Iker Pedrosa
Hi,
I would like to know what's the difference between the two booleans provided in the title. Is there any documentation that I could check? Is any of them needed when I'd like to have poly-instantiated directories with SELinux in enforcing mode?
1 year, 3 months
