Bug 624540 - (staff_u) SELinux is preventing /usr/bin/nautilus (deleted) "write" access on /media/TerraVolume.
(staff_u) SELinux is preventing /usr/bin/nautilus (deleted) "write" access on...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
: Reopened, RHELNAK, SELinux
: 571460 (view as bug list)
Depends On:
Blocks: 723722
  Show dependency treegraph
 
Reported: 2010-08-16 15:24 EDT by Matěj Cepl
Modified: 2015-07-16 07:30 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 723722 (view as bug list)
Environment:
Last Closed: 2015-07-16 07:30:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matěj Cepl 2010-08-16 15:24:13 EDT
Just plugged in USB external hard-drive (or NAS) and got this.

Podrobný popis:

[SELinux je v tolerantním režimu. Přístup byl povolen.]

SELinux denied access requested by nautilus. It is not expected that this access
is required by nautilus 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.

Povolení přístupu:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Další informace:

Kontext zdroje                staff_u:staff_r:staff_t:s0-s0:c0.c1023
Kontext cíle                 system_u:object_r:mnt_t:s0
Objekty cíle                 /media/TerraVolume [ dir ]
Zdroj                         nautilus
Cesta zdroje                  /usr/bin/nautilus (deleted)
Port                          <Neznámé>
Počítač                    johanka.ceplovi.cz
RPM balíčky zdroje          
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.7.19-39.el6
Selinux povolen               True
Typ politiky                  targeted
Vynucovací režim            Permissive
Název zásuvného modulu     catchall
Název počítače            johanka.ceplovi.cz
Platforma                     Linux johanka.ceplovi.cz
                              2.6.32-54.el6.jwltest.22.x86_64.debug #1 SMP Wed
                              Jul 28 17:48:33 EDT 2010 x86_64 x86_64
Počet upozornění           1
Poprvé viděno               Po 16. srpen 2010, 15:19:10 EDT
Naposledy viděno             Po 16. srpen 2010, 15:19:10 EDT
Místní ID                   fc366c6a-2c68-452a-bc8d-bac13c2c5e63
Čísla řádků              

Původní zprávy auditu      

node=johanka.ceplovi.cz type=AVC msg=audit(1281986350.996:2003): avc:  denied  { write } for  pid=2137 comm="nautilus" name="/" dev=sdb2 ino=2 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mnt_t:s0 tclass=dir

node=johanka.ceplovi.cz type=SYSCALL msg=audit(1281986350.996:2003): arch=c000003e syscall=21 success=yes exit=0 a0=1ebe9e0 a1=2 a2=400000 a3=1 items=0 ppid=2227 pid=2137 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="nautilus" exe=2F7573722F62696E2F6E617574696C7573202864656C6574656429 subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null)
Comment 2 RHEL Product and Program Management 2010-08-16 15:58:37 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 3 RHEL Product and Program Management 2010-08-18 17:19:14 EDT
Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.

If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.
Comment 4 Tomáš Bžatek 2011-01-14 12:05:14 EST
Does this still happen in an fully updated system? What filesystems do you have on the device? I could imagine spawning some external helper would cause the denial.

If you're not sure, can you please attach output of the `udisks --dump` command?
Comment 5 Matěj Cepl 2011-01-14 16:50:26 EST
(In reply to comment #4)
> Does this still happen in an fully updated system? What filesystems do you have
> on the device? I could imagine spawning some external helper would cause the
> denial.

It was never mine, just something halfline loaned me to backup when I was in Boston. It had ext3 as a filesystem, I believe (as much as I dimly remember).

> If you're not sure, can you please attach output of the `udisks --dump`
> command?

does it make any sense when I have different operating system (Rawhide) and no access to the particular drive?
Comment 6 Tomáš Bžatek 2011-01-17 11:20:05 EST
(In reply to comment #5)
> It was never mine, just something halfline loaned me to backup when I was in
> Boston. It had ext3 as a filesystem, I believe (as much as I dimly remember).
I've just tried to plug an USB stick with three partitions, all formatted with ext3. No denials, automounted just fine.

(In reply to comment #0)
> node=johanka.ceplovi.cz type=AVC msg=audit(1281986350.996:2003): avc:  denied 
> { write } for  pid=2137 comm="nautilus" name="/" dev=sdb2 ino=2
> scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:mnt_t:s0 tclass=dir

I've just noticed the "staff_u" context - is this something you've changed? I'm running unconfined.
Comment 7 Matěj Cepl 2011-01-17 11:27:17 EST
(In reply to comment #6)
> I've just noticed the "staff_u" context - is this something you've changed? I'm
> running unconfined.

http://danwalsh.livejournal.com/18312.html

I think Dan could explain more.
Comment 8 Daniel Walsh 2011-01-17 11:53:13 EST
Yes this is an issue with confined users.  Unconfined users would not generate the AVC.

This is an SELinux issue.  nautilus is doing the correct thing.

Nautilus is asking what access is available on all files/devices that it is displaying, the problem is SELinux originally could not tell the difference between

access(/dev/foo, W_OK)

and

write(/dev/foo, 1)

In Rawhide we now have a mechanism to say dontaudit the access checks, while I am not sure we have this in RHEL6 yet.
Comment 9 Eric Paris 2011-01-17 11:58:39 EST
This is not available in RHEL6.  If you feel this should be backported, you're going to need to open a kernel bug, but at this point, unless we have a customer asking for it, it's going to be defered to 6.2....
Comment 10 Tomáš Bžatek 2011-01-17 12:17:18 EST
(In reply to comment #7)
> http://danwalsh.livejournal.com/18312.html
Thanks, able to reproduce it now. I'll keep my user under staff_u for some time, just for curiosity.

On a sidenote, small design issue - after creating new ext3 filesystem I was unable to access it right away, even having proper permissions. Mounted fine, but denied listing. Had to do restorecon manually. Either this should be done automatically by palimpsest/udisks or mkfs (this is rather intrusive).
Comment 11 Daniel Walsh 2011-01-17 14:05:39 EST
What was not able to access it? unconfined_t should have been,  staff_t would not be able to.
Comment 12 Daniel Walsh 2011-01-17 14:06:24 EST
I think 6.2 is fine for this, as it is not a huge problem and most people using confined users probably are using nautilus to look at random locations.
Comment 13 Tomáš Bžatek 2011-01-20 08:56:30 EST
(In reply to comment #11)
> What was not able to access it? unconfined_t should have been,  staff_t would
> not be able to.
Yeah, bash running in staff_t context.
Comment 14 Miroslav Grepl 2011-02-10 10:55:19 EST
*** Bug 571460 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Walsh 2011-07-20 17:49:09 EDT
https://bugzilla.redhat.com/show_bug.cgi?id=723722
Comment 23 RHEL Product and Program Management 2012-07-10 01:55:08 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 24 RHEL Product and Program Management 2012-07-10 21:54:46 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

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