Bug 820860 - SELinux is preventing /usr/bin/totem-video-thumbnailer from 'write' accesses on the directory totem.
SELinux is preventing /usr/bin/totem-video-thumbnailer from 'write' accesses ...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
24
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Ben Levenson
abrt_hash:d2f6e833bb53226303927f293c4...
: Reopened
: 896217 1087044 1134828 1146736 1328511 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-11 04:35 EDT by Petr Schindler
Modified: 2017-08-08 07:40 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 07:40:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Schindler 2012-05-11 04:35:54 EDT
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
:
:
Comment 1 Daniel Walsh 2012-05-15 23:12:25 EDT
What directory was this content created in?


find ~ -name totem
Comment 2 Arif Tri Waluyo 2012-06-25 17:37:12 EDT
(In reply to comment #1)
> What directory was this content created in?
> 
> 
> find ~ -name totem

/home/Downloads
Comment 3 Miroslav Grepl 2012-06-26 05:57:42 EDT
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.
Comment 4 Daniel Walsh 2012-06-26 06:22:00 EDT
Downloads is not consistant across languages, I believe?
Comment 5 Daniel Walsh 2012-06-26 06:27:36 EDT
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?
Comment 6 Daniel Walsh 2013-01-16 16:11:18 EST
*** Bug 896217 has been marked as a duplicate of this bug. ***
Comment 7 patrickcallahan42 2013-02-14 16:19:04 EST
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)
Comment 8 Bastien Nocera 2013-02-19 09:06:22 EST
(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.
Comment 9 Daniel Walsh 2013-02-20 07:00:11 EST
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.
Comment 10 Bastien Nocera 2013-02-20 07:15:49 EST
(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.
Comment 11 Daniel Walsh 2013-02-20 07:23:19 EST
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.
Comment 12 Bastien Nocera 2013-02-20 07:36:57 EST
(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.
Comment 13 Daniel Walsh 2013-02-20 07:50:23 EST
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.
Comment 14 Fedora End Of Life 2013-07-04 01:41:47 EDT
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.
Comment 15 Fedora End Of Life 2013-08-01 12:54:18 EDT
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.
Comment 16 Miroslav Grepl 2014-04-14 02:56:22 EDT
*** Bug 1087044 has been marked as a duplicate of this bug. ***
Comment 17 Zdenek Chmelar 2014-05-03 17:13:30 EDT
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
Comment 18 RH 2014-07-12 06:55:27 EDT
I have the same problem with Fedora release 20 (Heisenbug).
Comment 19 Miroslav Grepl 2014-08-28 08:51:43 EDT
*** Bug 1134828 has been marked as a duplicate of this bug. ***
Comment 20 Zdenek Chmelar 2014-09-18 07:39:17 EDT
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.
Comment 21 Miroslav Grepl 2014-09-26 04:12:07 EDT
*** Bug 1146736 has been marked as a duplicate of this bug. ***
Comment 22 Jan Kurik 2015-07-15 11:09:12 EDT
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
Comment 23 Vadim Rutkovsky 2015-09-04 11:31:26 EDT
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
Comment 24 Zdenek Chmelar 2016-04-19 10:25:31 EDT
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
Comment 25 Lukas Vrabec 2016-04-21 10:11:04 EDT
*** Bug 1328511 has been marked as a duplicate of this bug. ***
Comment 26 Zdenek Chmelar 2016-05-19 03:57:47 EDT
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
Comment 27 Zdenek Chmelar 2016-07-24 09:52:23 EDT
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
Comment 28 Bastien Nocera 2016-09-21 10:55:59 EDT
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.
Comment 29 Daniel Walsh 2016-09-21 14:12:18 EDT
If we change the label on the gnome thumbnailer, it should fix the issue.  What is the path to this?
Comment 30 Bastien Nocera 2016-09-28 05:38:28 EDT
(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.
Comment 31 Zdenek Chmelar 2016-10-12 18:33:18 EDT
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?
Comment 32 Haitham El-Ghareeb 2017-07-24 19:33:21 EDT
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
Comment 33 Haitham El-Ghareeb 2017-07-24 19:37:49 EDT
(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?
Comment 34 Fedora End Of Life 2017-07-25 14:30:16 EDT
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.
Comment 35 Fedora End Of Life 2017-08-08 07:40:59 EDT
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.

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