Bug 820860
| Summary: | SELinux is preventing /usr/bin/totem-video-thumbnailer from 'write' accesses on the directory totem. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Schindler <pschindl> |
| Component: | selinux-policy-targeted | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED EOL | QA Contact: | Ben Levenson <benl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | arifiauo, bnocera, chmelarz, cosimo.cecchi, dominick.grift, dwalsh, h.elghareeb, hirner, lvrabec, mgrepl, moez.roy, patrickcallahan42, vrutkovs |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:d2f6e833bb53226303927f293c43cc1d062797201fad15fe199b2eb1c2e2b9e1 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-08 11:40:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
What directory was this content created in? find ~ -name totem (In reply to comment #1) > What directory was this content created in? > > > find ~ -name totem /home/Downloads The problem is #rpm -qf /home/mgrepl/Downloads file /home/mgrepl/Downloads is not owned by any package So we don't have labeling for this directory. But we could try to use file name transition for this directory now. Downloads is not consistant across languages, I believe? Can we get totem-video-thumnailer to play its videos in a specific directory in the homedir? .totem or totem. Any idea why this is writing files to ~/Downloads directory? *** Bug 896217 has been marked as a duplicate of this bug. *** Attempted to download screenshots of video in video player by going to edit, then create screenshot gallery Package: (null) OS Release: Fedora release 18 (Spherical Cow) (In reply to comment #5) > Can we get totem-video-thumnailer to play its videos in a specific directory > in the homedir? .totem or totem. Any idea why this is writing files to > ~/Downloads directory? Because it was called that way. totem-video-thumbnailer doesn't spring up on its own, it's usually called by the file manager to generate thumbnails. I doubt this is trying to write file in the user's Downloads directory, but more likely in a ~/.cache/thumbnails/ sub-directory. In Patrick's case, he's trying to save a thumbnail of the currently playing movie in his Downloads directory. I don't understand what SELinux is trying to block here. Basically we are only allowing thumbnails to write to thumnail_home_t directories. /home/[^/]*/\.thumbnails(/.*)? unconfined_u:object_r:thumb_home_t:s0 /home/[^/]*/missfont\.log.* unconfined_u:object_r:thumb_home_t:s0 /home/[^/]*/\.cache/thumbnails(/.*)? unconfined_u:object_r:thumb_home_t:s0 We are trying to prevent bugs in thumbnail drivers from being able to take over you system. Writing content any location in the homedirs is exactly what we are trying to prevent. If totem-video-thumnailer not activated by running nautilus or the file browser,then I would not worry about confining it at all. (In reply to comment #9) > Basically we are only allowing thumbnails to write to thumnail_home_t > directories. > > /home/[^/]*/\.thumbnails(/.*)? unconfined_u:object_r:thumb_home_t:s0 > /home/[^/]*/missfont\.log.* unconfined_u:object_r:thumb_home_t:s0 > /home/[^/]*/\.cache/thumbnails(/.*)? unconfined_u:object_r:thumb_home_t:s0 > > We are trying to prevent bugs in thumbnail drivers from being able to take > over you system. Writing content any location in the homedirs is exactly > what we are trying to prevent. > > If totem-video-thumnailer not activated by running nautilus or the file > browser,then I would not worry about confining it at all. This is a very bizarre way of doing things IMO. The thumbnailers are simple programs that can be used outside writing into the thumbnails directory, such as being called by the user or other programs to generate galleries, etc. We could confine the binary used by the file manager for example (the ones declared in /usr/share/thumbnailers/) and provide a non-confined version for use by third-party programs and the users directly, but this would need to be clearly set out in the package guidelines so that people can adapt their packages. It would have been good to discuss this confinement with the stakeholders before implementing and deploying it. Well we did anounce it as a feature, and frankly this is the only bug we have had where the thumnailer needs to write to random directories. http://danwalsh.livejournal.com/54092.html Discusses the why. If we have to unconfine this thumbnailer, then we can just change it's label back to bin_t. (In reply to comment #11) > Well we did anounce it as a feature, and frankly this is the only bug we > have had where the thumnailer needs to write to random directories. Probably because most people would just disable SELinux if they saw this sort of problems. > http://danwalsh.livejournal.com/54092.html > > Discusses the why. I understand the why. But announcing it on your blog doesn't mean you discussed it with the stakeholders. I'm sure there's a repoquery command that could list all the packages that install files in /usr/share/thumbnailers/ so you could mail the maintainers of those packages. Or it could have been discussed/announced on fedora-devel (did I miss the discussion?). > If we have to unconfine this thumbnailer, then we can just change it's label > back to bin_t. I've also mentioned a way to avoid doing that wholesale. I think you should explore this avenue before unconfining it. I thought I had made this a feature page, but I am not able to find it, so I could be mistaken. I am willing to talk about that also. I have no problem with having alternate entrypoints into the code that do not do confinement. It could be as simple as having a shell script that calls the real code, and then we just use the shell script from the /usr/share/thumbnailers directory. Something like: Exec=/usr/bin/thumnail_confine /usr/bin/totem-video-thumbnailer -s %s %u %o And then we can just label the thumnail_confine script as thumb_exec_t, and remove the labels from the actual binaries. This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. *** Bug 1087044 has been marked as a duplicate of this bug. *** Description of problem: During creation of Screenshot Gallery in Gnome application "Videos". 1) In Videos application, go to menu and click on "Create Screenshot Gallery..." 2) Save the file to initiate the screenshot generation 3) This error pops up Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.2-200.fc20.x86_64 type: libreport I have the same problem with Fedora release 20 (Heisenbug). *** Bug 1134828 has been marked as a duplicate of this bug. *** Problem still persists in Fedora 21. When creating thumbnails in Gnome Videos (Totem), Selinux is preventing to save created thumbnail to home directory Packages: totem-3.13.92-1.fc21.x86_64 selinux-policy-3.13.1-79.fc21.noarch selinux-policy-targeted-3.13.1-79.fc21.noarch totem-video-thumbnailer is prevented from: 1) write (to home directory ~/Pictures) 2) add-name 3) create 4) write (to file of the new thumbnail) Local policy created for all 4 steps above allowed to create the thumbnail and save it in home dir. *** Bug 1146736 has been marked as a duplicate of this bug. *** This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 Description of problem: Occurs on creating a screenshot gallery Version-Release number of selected component: selinux-policy-3.13.1-146.fc23.noarch Additional info: reporter: libreport-2.6.2 hashmarkername: setroubleshoot kernel: 4.2.0-1.fc23.x86_64 type: libreport Description of problem: Attempt to create screenshot gallery in Gnome Videos Version-Release number of selected component: selinux-policy-3.13.1-158.14.fc23.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.4.6-301.fc23.x86_64 type: libreport *** Bug 1328511 has been marked as a duplicate of this bug. *** Description of problem: Creation of Screenshot Gallery is still not allowed with Videos (to save it in Pictures directory) Version-Release number of selected component: selinux-policy-3.13.1-185.fc24.noarch Additional info: reporter: libreport-2.7.0 hashmarkername: setroubleshoot kernel: 4.5.4-300.fc24.x86_64 reproducible: Not sure how to reproduce the problem type: libreport Description of problem: I wanted to create screenshot galery in gnome-videos Version-Release number of selected component: selinux-policy-3.13.1-203.fc25.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.7.0-0.rc7.git4.1.fc25.x86_64 type: libreport This is still a problem of the policy. We use totem-video-thumbnailer both for: 1) generating thumbnails in the file manager and video player (as called by libgnome-desktop) 2) generating galleries from totem itself, the gallery file created is written in a user-selected directory. The policy assumes that thumbnailers only ever do 1). They won't do that whether for use case 2) or when users invoke the thumbnailers through scripts. Restricting those thumbnailers to only ever do 1) is a regression. Please revert and discuss how we can better the security of the system without forcing regressions. If we change the label on the gnome thumbnailer, it should fix the issue. What is the path to this? (In reply to Daniel Walsh from comment #29) > If we change the label on the gnome thumbnailer, it should fix the issue. > What is the path to this? For totem/GNOME Videos it's at: /usr/bin/totem-video-thumbnailer But any of the thumbnailers referenced at /usr/share/thumbnailers/ might hit this restriction. I just tried it in rawhide (selinux-policy-3.13.1-219.fc26) and still nothing. Videos (Totem) is a core Gnome app and its feature does not work. This bug is opened for 4 years, there is really no solution found / available? SELinux is preventing totem-video-thu from add_name access on the directory Gallery-8.mp4-1.jpg. Plugin: catchall SELinux denied access requested by totem-video-thu. It is not expected that this access is required by totem-video-thu and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. If you believe that totem-video-thu should be allowed add_name access on the Gallery-8.mp4-1.jpg directory by default. You should report this as a bug. You can generate a local policy module to allow this access. Allow this access for now by executing: # ausearch -c 'totem-video-thu' --raw | audit2allow -M my-totemvideothu # semodule -X 300 -i my-totemvideothu.pp (In reply to Daniel Walsh from comment #29) > If we change the label on the gnome thumbnailer, it should fix the issue. > What is the path to this? Any success with your suggested solution? This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
libreport version: 2.0.10 executable: /usr/bin/python2.7 hashmarkername: setroubleshoot kernel: 3.3.4-5.fc17.x86_64 time: Fri 11 May 2012 10:34:21 AM CEST description: :SELinux is preventing /usr/bin/totem-video-thumbnailer from 'write' accesses on the directory totem. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that totem-video-thumbnailer should be allowed write access on the totem directory by default. :Then you should report this as a bug. :You can generate a local policy module to allow this access. :Do :allow this access for now by executing: :# grep totem-video-thu /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 :Target Context unconfined_u:object_r:user_home_t:s0 :Target Objects totem [ dir ] :Source totem-video-thu :Source Path /usr/bin/totem-video-thumbnailer :Port <Unknown> :Host (removed) :Source RPM Packages totem-3.4.1-2.fc17.x86_64 :Target RPM Packages :Policy RPM selinux-policy-3.10.0-121.fc17.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Permissive :Host Name (removed) :Platform Linux (removed) : 3.3.4-5.fc17.x86_64 #1 SMP Mon May 7 17:29:34 UTC : 2012 x86_64 x86_64 :Alert Count 1 :First Seen Fri 11 May 2012 10:30:00 AM CEST :Last Seen Fri 11 May 2012 10:30:00 AM CEST :Local ID 9fe9771c-08ad-4277-a12a-6c85c47b45f9 : :Raw Audit Messages :type=AVC msg=audit(1336725000.52:275): avc: denied { write } for pid=30743 comm="totem-video-thu" name="totem" dev="sda7" ino=3145787 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir : : :type=AVC msg=audit(1336725000.52:275): avc: denied { add_name } for pid=30743 comm="totem-video-thu" name=47616C6C6572792D31382E2048616E64656C202D20547261636B2031382D312E6A7067 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir : : :type=AVC msg=audit(1336725000.52:275): avc: denied { create } for pid=30743 comm="totem-video-thu" name=47616C6C6572792D31382E2048616E64656C202D20547261636B2031382D312E6A7067 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file : : :type=AVC msg=audit(1336725000.52:275): avc: denied { write } for pid=30743 comm="totem-video-thu" name=47616C6C6572792D31382E2048616E64656C202D20547261636B2031382D312E6A7067 dev="sda7" ino=3145789 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file : : :type=SYSCALL msg=audit(1336725000.52:275): arch=x86_64 syscall=open success=yes exit=ECHILD a0=b84b00 a1=241 a2=1b6 a3=238 items=0 ppid=1 pid=30743 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm=totem-video-thu exe=/usr/bin/totem-video-thumbnailer subj=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 key=(null) : :Hash: totem-video-thu,thumb_t,user_home_t,dir,write : :audit2allowunable to open /sys/fs/selinux/policy: Permission denied : : :audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied : :