Bug 441198 - SELinux denial for new formatted USB drive.
SELinux denial for new formatted USB drive.
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-07 01:06 EDT by Caius Chance
Modified: 2009-02-15 20:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-15 20:02:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
autofs_stuff as per request. (6.87 KB, text/plain)
2008-04-07 02:53 EDT, Caius Chance
no flags Details
gdb output (5.48 KB, text/plain)
2008-04-13 04:44 EDT, Caius Chance
no flags Details

  None (edit)
Description Caius Chance 2008-04-07 01:06:31 EDT
Description of problem:


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


How reproducible:


Steps to Reproduce:
1. Boot to Gnome environment.
2. Start gnome-terminal.
3. Gain root access.
4. Plug in the USB drive.
5. Unmount all auto mounted directories of the USB drive.
6. Remove all parititions in the USB drive using fdisk.
7. Create a new partition in W95 format using all space.
8. Write to partition table.
9. Format the partition using mkfs.vfat.
10. There is a pop up of SELinux Denial on the taskbar.
  
Actual results:

The following SELinux Denials:

Summary:

SELinux is preventing automount (automount_t) "read" to ./core.2350 (root_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

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

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for ./core.2350,

restorecon -v './core.2350'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:automount_t:s0
Target Context                system_u:object_r:root_t:s0
Target Objects                ./core.2350 [ file ]
Source                        automount
Source Path                   <Unknown>
Port                          <Unknown>
Host                          castor
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-28.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   catchall_file
Host Name                     castor
Platform                      Linux castor 2.6.25-0.200.rc8.git3.fc9.i686 #1 SMP
                              Sat Apr 5 00:00:10 EDT 2008 i686 i686
Alert Count                   1
First Seen                    西元2008年04月07日 (週一) 14時57分12秒
Last Seen                     西元2008年04月07日 (週一) 14時57分12秒
Local ID                      4dda2971-d0fd-4701-950f-7fafe10b45aa
Line Numbers                  

Raw Audit Messages            

host=castor type=AVC msg=audit(1207544232.188:20): avc:  denied  { read } for 
pid=4077 comm="automount" name="core.2350" dev=sda2 ino=97730
scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:root_t:s0
tclass=file

Expected results:

Mounted with none of the above error.

Additional info:

This is not happening when user unplug and plug the USB drive again.
Comment 1 Ian Kent 2008-04-07 02:47:53 EDT
Please provide the automount map you have created
to access these USB devices and obtain a debug
log as described at http://people.redhat.com/jmoyer
and post it to the bug.
Comment 2 Caius Chance 2008-04-07 02:53:42 EDT
Created attachment 301469 [details]
autofs_stuff as per request.
Comment 3 Caius Chance 2008-04-07 02:55:07 EDT
I didn't use autofs table (auto.master, etc) but it just as the way of
automatically mounted by system when USB drive is plugged in.
Comment 4 Jeffrey Moyer 2008-04-07 08:51:03 EDT
host=castor type=AVC msg=audit(1207544232.188:20): avc:  denied  { read } for 
pid=4077 comm="automount" name="core.2350" dev=sda2 ino=97730
scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:root_t:s0
tclass=file

This looks like automount may have dumped core, and selinux may be preventing it
from finishing that process.  I'm not sure why the act of dumping core would
trigger a read, though.  Is /core.2350 a valid core file?
Comment 8 Jeffrey Moyer 2008-04-09 08:42:25 EDT
What version of autofs are you running?
Comment 9 Caius Chance 2008-04-09 19:46:41 EDT
autofs-5.0.3-11.i386.rpm

Wasn't Ian saying this bug might be not related to autofs?
Comment 10 Ian Kent 2008-04-09 22:36:03 EDT
(In reply to comment #9)
> autofs-5.0.3-11.i386.rpm
> 
> Wasn't Ian saying this bug might be not related to autofs?

I did say that and I still think the actual problem is with hal.
But Jeff trying to find out if autofs SEGVed and why.

Is the core above an autofs core?

Ian
Comment 11 Ian Kent 2008-04-09 22:41:25 EDT
Ahhh, I see we changed the component but left it assigned
to Jeff, that's not right.

Lets follow through on the core file before passing it on.

Ian
Comment 12 Caius Chance 2008-04-09 22:58:37 EDT
So sorry if I confused you guysin previous comments.

That's seems to be the only core file I got at /.
Comment 13 Ian Kent 2008-04-09 23:04:05 EDT
(In reply to comment #12)
> So sorry if I confused you guysin previous comments.
> 
> That's seems to be the only core file I got at /.

It is an automount core file, what was the date stamp
on the original file?
Comment 14 Caius Chance 2008-04-09 23:34:18 EDT
2008-04-07
Comment 15 Ian Kent 2008-04-10 00:11:51 EDT
That is a bit odd since you've got the default configuration
and it isn't related to what you're doing with the USB devices.

It's a big ask but, if you're system hasn't changed much, could
you install the autofs-5.0.3-debuginfo-11 package and do:

gdb -c /core.2350 /usr/sbin/automount
gdb> thr a a bt

and post it here please.
Assuming the core is still in /, of course.

Ian
Comment 16 Jeffrey Moyer 2008-04-10 14:41:26 EDT
(In reply to comment #15)
> That is a bit odd since you've got the default configuration
> and it isn't related to what you're doing with the USB devices.
> 
> It's a big ask but, if you're system hasn't changed much, could
> you install the autofs-5.0.3-debuginfo-11 package and do:
> 
> gdb -c /core.2350 /usr/sbin/automount
> gdb> thr a a bt
> 
> and post it here please.
> Assuming the core is still in /, of course.

The point of getting the core was to do this myself, instead of putting that
burden on teh reporter.  However, I'm not getting very good results, as I don't
have a system that matches (different versions of libraries, etc).

So, yeah, could you please get us the gdb output, Caius?  You can find the
debuginfo rpm here:
 
http://koji.fedoraproject.org/packages/autofs/5.0.3/11/i386/autofs-debuginfo-5.0.3-11.i386.rpm

Thanks!
Comment 17 Caius Chance 2008-04-10 20:24:23 EDT
It isn't any problem for me to test. Will test during this weekend and get back
to you. Rgds.
Comment 18 Caius Chance 2008-04-13 04:44:49 EDT
Created attachment 302257 [details]
gdb output

Please kindly check and let me know if you want more info. I will keep the core
file for a  while.
Comment 19 Ian Kent 2008-04-14 02:03:51 EDT
(In reply to comment #18)
> Created an attachment (id=302257) [edit]
> gdb output
> 
> Please kindly check and let me know if you want more info. I will keep the core
> file for a  while.

This looks like something that I've started seeing on F-8 the
last couple of weeks. I don't see a segfault though but I
probably should be.

Can you re-test with autofs-5.0.3-12 when it gets to the
repository please.

Ian
Comment 20 Jon Stanley 2008-05-10 15:45:15 EDT
If you're interested, the package can be had here as well:

http://koji.fedoraproject.org/koji/buildinfo?buildID=46454
Comment 21 Bug Zapper 2008-05-14 05:00:20 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Brennan Ashton 2008-06-07 23:01:04 EDT
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Comment 23 Caius Chance 2008-06-09 20:01:47 EDT
I am sorry that I had been busy since then and there is no resources for me to
collect data. Please kindly drop this bug if there are no similar reports on
upstream tracker. Thank you very much.
Comment 24 Caius Chance 2009-02-15 13:32:14 EST
Not in Fedora 10 anymore. Please close this bug.

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