selinux June 2022

selinux@lists.fedoraproject.org

6 participants
4 discussions

Re: qemu-ga guest-exec & SELinux
by Daniel P. Berrangé 21 Jun '22

21 Jun '22

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 0

qemu-ga guest-exec & SELinux
by Marc-André Lureau 20 Jun '22

20 Jun '22

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

2 1

btrfs, user created subvolumes
by Chris Murphy 13 Jun '22

13 Jun '22

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 0

polyinstantiation_enabled vs allow_polyinstantiation
by Iker Pedrosa 09 Jun '22

09 Jun '22

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?

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux June 2022