Bug 547546 - RFE: the security drivers must remember original permissions/labels and restore them after
Summary: RFE: the security drivers must remember original permissions/labels and resto...
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: yafu
URL:
Whiteboard:
Keywords: FutureFeature, Reopened, Upstream
: 796072 1113327 1126678 1191802 (view as bug list)
Depends On: 1524792
Blocks: 1203710 1205796 1420851 1477664 756082 822052 829181 1126678 1288337
TreeView+ depends on / blocked
 
Reported: 2009-12-14 21:58 UTC by Daniel Berrange
Modified: 2019-04-17 12:43 UTC (History)
27 users (show)

(edit)
Clone Of:
: 1652078 (view as bug list)
(edit)
Last Closed: 2019-04-17 12:38:02 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 636156 None NEW RFE: security: restore original file label/owner 2019-05-16 08:30 UTC

Internal Trackers: 636156

Description Daniel Berrange 2009-12-14 21:58:04 UTC
Description of problem:
The current SELinux and uid/gid changing code always restores the permissions back to a default generic label, and root:root respectively. These are bad assumptions, because the original file may have had non-default/non-root labelling/ownership.

There needs to be a mechanism for the security drivers to record the original credentials, so they can be correctly restored later. This needs to be persistent across libvirtd restart, and cope with multiple guests using the same files concurrently.

Version-Release number of selected component (if applicable):
libvirt-0.7.4

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 RHEL Product and Program Management 2009-12-14 22:26:04 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Daniel Berrange 2010-01-20 15:47:58 UTC

*** This bug has been marked as a duplicate of bug 534010 ***

Comment 4 Laine Stump 2011-08-24 19:50:34 UTC
Bug 534010 was initially opened for a much narrower problem (image files are chowned to root during domain restore, even if dynamic_ownership=0), which has been resolved. In order to track the larger problem properly, I'm re-opening this bug rather than creating a new one.

Comment 6 Wayne Sun 2011-11-29 07:43:51 UTC
package:
# rpm -q libvirt
libvirt-0.9.4-23.el6.x86_64

possible test steps:

scenario 1:
1. prepare a domain, chown the disk file to non-root user
# chown wayne:wayne /var/lib/libvirt/images/rhel6u2
# ll -Z /var/lib/libvirt/images/
-rw-r--r--. wayne wayne system_u:object_r:virt_image_t:s0 rhel6u2

2. start the domain
# virsh start rhel6u2
Domain rhel6u2 started

3. check the file ownership
# ll -Z /var/lib/libvirt/images/rhel6u2
-rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c31,c303 /var/lib/libvirt/images/rhel6u2

4. destroy the domain and recheck
# virsh destroy rhel6u2
Domain rhel6u2 destroyed

# ll -Z /var/lib/libvirt/images/rhel6u2
-rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel6u2

5. restart libvirtd and recheck
# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
# ll -Z /var/lib/libvirt/images/rhel6u2
-rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel6u2

^^after destroy and libvirtd restart, the disk file restore to root:root

scenario 2:
1. prepare a shareable non-root iso file
# ll -Z /var/lib/libvirt/images/aa.iso
-rw-r--r--. wayne wayne system_u:object_r:virt_content_t:s0 aa.iso

2. attach the iso file to active domain and check ownership
prepare insert.xml using /var/lib/libvirt/images/aa.iso as source file
# virsh update-device rhel6u2 insert.xml
Device updated successfully

# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

3. eject the iso file and recheck
# virsh update-device rhel6u2 /root/eject.xml 
Device updated successfully

# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

4. destroy domain and recheck
# virsh destroy rhel6u2
Domain rhel6u2 destroyed

# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

5. restart libvirtd and recheck
# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

^^after detach and restart libvirtd, the shareable iso file remain qemu:qemu

Comment 7 Martin Kletzander 2012-05-25 13:38:02 UTC
As you mentioned in Bug 534010, there are three possibilities to go around this problem. The cleaner ones (xattr or acl) are not possible on all mounts/filesystems.
My question is if we can say that dynamic_ownership=1 is only supported on these mounts and otherwise behave the same way as with dynamic_ownership=0, but with warning (for example)?
Thanks

Comment 8 Martin Kletzander 2012-05-30 16:13:09 UTC
Setting CondNAK:Design as we're not sure which way to head with this problem yet.

Comment 9 Jiri Denemark 2012-10-02 09:52:51 UTC
*** Bug 796072 has been marked as a duplicate of this bug. ***

Comment 11 Richard W.M. Jones 2013-05-31 08:18:00 UTC
Make bug non-private.

Comment 12 Daniel Berrange 2013-12-13 12:38:34 UTC
Clearing needinfo flag, since this discussion moved upstream.

Comment 15 Jiri Denemark 2014-08-05 14:06:33 UTC
*** Bug 1113327 has been marked as a duplicate of this bug. ***

Comment 16 Michal Privoznik 2014-09-10 13:27:45 UTC
I've proposed patches upstream:

https://www.redhat.com/archives/libvir-list/2014-September/msg00551.html

Comment 18 Michal Privoznik 2014-12-01 10:03:11 UTC
*** Bug 1126678 has been marked as a duplicate of this bug. ***

Comment 22 Ján Tomko 2016-02-11 09:28:45 UTC
*** Bug 1191802 has been marked as a duplicate of this bug. ***

Comment 30 Adrien 2018-07-10 07:59:39 UTC
Hi all,

I've just hit this problem of restoring permissions to root:root when undefining a domain.
I'm surprised to see that this issue was opened on 2009 and still opened :-/
Is their anything to do to find a solution?

Best,
Adrien

Comment 33 Michal Privoznik 2018-07-27 12:37:21 UTC
I've started some discussion upstream:

https://www.redhat.com/archives/libvir-list/2018-July/msg01874.html

Comment 37 Michal Privoznik 2018-12-19 15:29:11 UTC
And I've just pushed patches to the master:

e05d8e570b qemu.conf: Allow users to enable/disable label remembering
1845991d9b tools: Provide a script to recover fubar'ed XATTRs setup
1e63dea999 tests: Introduce qemusecuritytest
d9043c06e6 virSecuritySELinuxRestoreAllLabel: Restore more labels
d81f3e02d7 virSecuritySELinuxRestoreAllLabel: Reorder device relabeling
edacf25da7 virSecuritySELinuxTransactionRun: Implement rollback
b44fd42016 security_selinux: Restore label on failed setfilecon() attempt
4dc37a39cf security_selinux: Remember old labels
1e9c472452 security_selinux: Track if transaction is restore
d7420430ce virSecurityDACRestoreImageLabelInt: Restore even shared/RO disks
1845d3ad5d security_dac: Remember old labels
fa808763b2 security_dac: Allow callers to enable/disable label remembering/recall
a30e6d17c9 virSecurityDACRestoreAllLabel: Restore more labels
08e3b1c0dc virSecurityDACRestoreAllLabel: Reorder device relabeling
06af6609e9 virSecurityDACTransactionRun: Implement rollback
86def3c88c security_dac: Restore label on failed chown() attempt
f9a0019fea security: Include security_util
f497b1ad59 util: Introduce xattr getter/setter/remover

v4.10.0-118-ge05d8e570b

Comment 38 Jiri Denemark 2019-01-25 11:29:57 UTC
This feature was disabled upstream due to some non-trivial bugs by

commit fc3990c7e64be1da1631952d3ec384ebef50e125
Refs: v5.0.0-rc2-4-gfc3990c7e6
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Mon Jan 14 17:53:43 2019 +0100
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Tue Jan 15 09:45:22 2019 +0100

    qemu: Temporary disable owner remembering

    Turns out, that there are few bugs that are not that trivial to
    fix (e.g. around block jobs). Instead of rushing in not
    thoroughly tested fixes disable the feature temporarily for the
    release.

    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
    ACKed-by: Peter Krempa <pkrempa@redhat.com>

Comment 39 Michal Privoznik 2019-03-28 15:26:18 UTC
Patches for the bugs posted upstream:

https://www.redhat.com/archives/libvir-list/2019-March/msg01948.html

Comment 40 Jaroslav Suchanek 2019-04-17 12:38:02 UTC
This will be fixed in rhel-8 version in the bug 1652078.


Note You need to log in before you can comment on or make changes to this bug.